Sollte ich für HTTP auf HTTPS 301 oder 308 verwenden?

Beide sind permanent, und Google behandelt sie gleich. 301 ist der übliche Standard für Websites. Nimm 308, wenn Clients POST-Requests an deine HTTP-URLs schicken, denn dann bleiben Methode und Body garantiert erhalten.

Schadet die Umstellung auf HTTPS meinen Rankings?

Nein. Ein permanenter Redirect vererbt PageRank, und Google bevorzugt HTTPS-URLs ohnehin als kanonische Version. Kurze Schwankungen während des Recrawls sind normal. Entscheidend ist, dass jede URL 1:1 und in einem einzigen Hop auf ihr HTTPS-Pendant zeigt.

Ersetzt HSTS den Redirect?

Nein. Browser erfahren von HSTS erst über eine HTTPS-Antwort, Erstbesucher und Crawler brauchen also weiterhin den serverseitigen Redirect. HSTS schützt danach wiederkehrende Besucher, indem die unsichere Anfrage komplett entfällt.

Warum führt mein HTTPS-Redirect zu ERR_TOO_MANY_REDIRECTS?

Meist wird TLS schon vor deinem Server terminiert, etwa durch einen Load Balancer oder Cloudflare im Modus „Flexible“. Dein Server sieht dann jede Anfrage als HTTP und leitet erneut um. Prüf X-Forwarded-Proto statt %{HTTPS} oder stell Cloudflare auf „Full (strict)“. Mehr dazu unter Redirect-Ketten und -Schleifen.

HTTP auf HTTPS umleiten: 301 vs. 308, HSTS & Beispiele

Jede HTTP-URL deiner Website sollte mit genau einem permanenten Redirect auf ihrer HTTPS-Version landen. Hier erfährst du, wie du das einrichtest, mit HSTS absicherst und prüfst.

Warum du HTTP auf HTTPS umleiten musst

Mit dem TLS-Zertifikat allein ist es nicht getan. Solange http://example.com/ noch ganz normal mit 200 OK antwortet, existiert jede Seite doppelt: Besucher landen über alte Links, Lesezeichen oder die Eingabe ohne Protokoll auf der unverschlüsselten Variante, und Suchmaschinen sehen zwei URLs, die sich gegenseitig Konkurrenz machen.

Ein serverseitiger Redirect von HTTP auf HTTPS löst beides:

Sicherheit: Nach der ersten Anfrage läuft der gesamte Traffic verschlüsselt. Cookies, Formulardaten und Logins gehen nicht mehr im Klartext übers Netz.
SEO: Google bevorzugt HTTPS-URLs als kanonische Version und nutzt HTTPS als leichtes Ranking-Signal. Ein permanenter Redirect bündelt die Signale beider Varianten auf einer URL.
Browser-Warnungen: Browser markieren HTTP-Seiten als „Nicht sicher“, spätestens sobald ein Formularfeld auftaucht.
Moderne Features: HTTP/2 im Browser, Service Worker, Geolocation und viele weitere APIs funktionieren nur in einem sicheren Kontext.

301 oder 308?

Beide Statuscodes sind permanent, und Google behandelt sie gleich: Sie vererben PageRank und sind ein starkes Signal dafür, dass die Ziel-URL die kanonische ist. Der Unterschied liegt in der Request-Methode. Bei einem 301 dürfen Clients beim Folgen aus einem POST ein GET machen, ein 308 garantiert dagegen, dass Methode und Body erhalten bleiben (siehe RFC 9110).

Statuscode	Permanent	Methode bleibt erhalten	Typischer Einsatz
`301 Moved Permanently`	Ja	Nicht garantiert	Standard für HTTP auf HTTPS, überall unterstützt
`308 Permanent Redirect`	Ja	Ja	APIs und Formulare, die POST-Requests über HTTP bekommen
`302` / `307`	Nein	302: nein, 307: ja	Ungeeignet, nur schwaches Kanonisierungssignal

Für normale Websites ist 301 die pragmatische Wahl. Bekommt dein HTTP-Endpunkt POST-Requests, etwa Webhooks oder API-Aufrufe, nimm 308 – oder sorg besser dafür, dass die Clients gleich HTTPS aufrufen. Mehr dazu in 307 vs. 308 und 301 vs. 302.

Server-Konfiguration

Apache (.htaccess)

Diese Regel leitet jede HTTP-Anfrage auf denselben Host und Pfad per HTTPS um. Voraussetzung ist mod_rewrite:

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Steht Apache hinter einem Load Balancer oder Reverse Proxy, der TLS terminiert, ist %{HTTPS} immer off – und du baust dir eine Endlosschleife. Prüf in dem Fall den Header, den der Proxy mitschickt:

RewriteEngine On
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Weitere Muster findest du im .htaccess-Guide, oder du lässt dir die Regeln vom .htaccess-Generator schreiben.

nginx

In nginx ist ein eigener Server-Block für Port 80 sauberer und schneller als ein if im HTTPS-Block:

server {
    listen 80;
    listen [::]:80;
    server_name example.com www.example.com;
    return 301 https://$host$request_uri;
}

Mit $host bleibt der angefragte Hostname erhalten. Willst du gleichzeitig www vereinheitlichen, trag den Ziel-Host fest ein (siehe unten). Mehr Fälle deckt der nginx-Guide ab, und der nginx-Generator erzeugt dir passende Blöcke. Für andere Plattformen gibt es Anleitungen zu Cloudflare, WordPress und IIS.

Ein einziger Hop – auch mit www

Ein Klassiker: HTTPS- und www-Redirect laufen hintereinander.

http://example.com/seite
  301 → https://example.com/seite
  301 → https://www.example.com/seite

Das sind zwei Roundtrips, bevor überhaupt Inhalt kommt, und eine Redirect-Kette, die Crawler bei jeder URL abarbeiten müssen. Besser: Jede nicht-kanonische Variante zeigt direkt auf die finale URL. In Apache:

RewriteEngine On
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} !^www\.example\.com$ [NC]
RewriteRule ^ https://www.example.com%{REQUEST_URI} [L,R=301]

In nginx liefern sowohl der Port-80-Block als auch ein HTTPS-Block für den nicht bevorzugten Host die finale URL zurück:

server {
    listen 80;
    listen [::]:80;
    server_name example.com www.example.com;
    return 301 https://www.example.com$request_uri;
}

server {
    listen 443 ssl;
    listen [::]:443 ssl;
    server_name example.com;
    ssl_certificate     /etc/ssl/example.com/fullchain.pem;
    ssl_certificate_key /etc/ssl/example.com/privkey.pem;
    return 301 https://www.example.com$request_uri;
}

Achte darauf, dass dein Zertifikat beide Hostnamen abdeckt. Sonst sehen Besucher von https://example.com eine Zertifikatswarnung, bevor der Redirect überhaupt greifen kann. Wie du den bevorzugten Host wählst, steht im Guide zum www-Redirect.

Ausnahme: Willst du deine Domain in die HSTS-Preload-Liste eintragen lassen, verlangen die Kriterien, dass HTTP zuerst auf HTTPS desselben Hosts umleitet. Bei Preload-Domains ist http://example.com → https://example.com → https://www.example.com also Absicht – nur so bekommt der Browser den HSTS-Header für die Hauptdomain zu sehen.

HSTS: Der Browser merkt sich HTTPS

Der Redirect allein lässt eine kleine Lücke: Die allererste Anfrage geht weiterhin per HTTP raus und könnte abgefangen werden. Der Response-Header Strict-Transport-Security schließt diese Lücke für wiederkehrende Besucher. Hat der Browser ihn einmal gesehen, schreibt er jede http://-Anfrage an diesen Host intern auf https:// um, ohne überhaupt ins Netz zu gehen (siehe MDN: Strict-Transport-Security).

Apache (mit mod_headers):

Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"

nginx (im HTTPS-Server-Block):

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

Browser akzeptieren den Header nur in HTTPS-Antworten, über HTTP wird er ignoriert. Führ ihn schrittweise ein:

Starte mit einem kurzen max-age wie 300 (fünf Minuten) und ohne includeSubDomains.
Prüf, ob wirklich jede genutzte Subdomain per HTTPS funktioniert – auch interne Tools, Webmailer und Staging-Hosts.
Erhöh auf eine Woche, dann einen Monat, dann 31536000 (ein Jahr).
Nimm includeSubDomains erst dazu, wenn du sicher bist, dass keine Subdomain mehr HTTP braucht.

Die HSTS-Preload-Liste und ihre Risiken

Browser bringen eine fest eingebaute Liste von Domains mit, die schon beim allerersten Aufruf nur per HTTPS angesprochen werden. Für die Aufnahme braucht dein Header mindestens max-age=31536000, includeSubDomains und die Direktive preload. Eingereicht wird die Domain über die Preload-Website des Chromium-Projekts.

Überleg dir diesen Schritt gut:

Preload gilt für alle Subdomains, auch für solche, die du erst in Zukunft anlegst. Jede Subdomain ohne gültiges Zertifikat ist dann nicht mehr erreichbar.
Das Austragen dauert. Es greift erst mit neuen Browser-Versionen, und wer ältere Versionen nutzt, behält den Eintrag noch monatelang.
Du kannst nicht mal eben auf HTTP ausweichen, wenn ein Zertifikat abläuft oder das CDN spinnt. Zertifikatsfehler lassen sich bei HSTS-Hosts nicht wegklicken.

Für die meisten Websites reicht ein normaler HSTS-Header mit einem Jahr max-age. Preload lohnt sich, wenn du alle Subdomains im Griff hast und die Zertifikate automatisch erneuert werden.

Mixed Content beseitigen

Nach der Umstellung können HTTPS-Seiten noch Ressourcen per http:// einbinden: Bilder, Skripte, Stylesheets, iframes oder Webfonts. Aktive Inhalte wie Skripte blockieren Browser komplett, passive wie Bilder werden entweder automatisch auf HTTPS hochgestuft oder ebenfalls blockiert. Die Folge: zerschossene Layouts, fehlende Funktionen und eine Warnung in der Adresszeile.

Durchsuch Templates, Datenbank und CMS-Einstellungen nach fest eingetragenen http://-URLs und ersetz sie durch https:// oder relative URLs.
Stell die Website-Adresse im CMS um. In WordPress müssen sowohl die WordPress-Adresse als auch die Website-Adresse mit https:// beginnen.
Pass Canonical-Tags, hreflang-Links, Open-Graph-URLs und die XML-Sitemap auf die HTTPS-URLs an.
Als Sicherheitsnetz sorgt der Header Content-Security-Policy: upgrade-insecure-requests dafür, dass Browser eingebundene Ressourcen automatisch per HTTPS laden.

Stell auch interne Links um. Der Redirect fängt sie zwar ab, aber jeder interne Link auf http:// kostet einen zusätzlichen Roundtrip.

Redirect testen

Gib http://example.com/ in den Redirect Checker ein und schau dir das Ergebnis an:

Der erste Hop sollte 301 oder 308 liefern, nicht 302.
Der Redirect sollte direkt auf die finale URL führen – genau ein Hop.
Die finale URL sollte mit 200 antworten.
Pfad und Query-String müssen erhalten bleiben: http://example.com/a?b=1 muss auf https://example.com/a?b=1 landen, nicht auf der Startseite.

Teste alle vier Kombinationen: http:// und https://, jeweils mit und ohne www. Mit dem Bulk-Checker geht das in einem Rutsch. Der Header-Checker zeigt dir, ob der Strict-Transport-Security-Header in den HTTPS-Antworten tatsächlich ankommt.