Die Website auf das HTTPS-Protokoll umstellen: Ablauf und Weiterleitungen

HTTPS ist die verschlüsselte Version des HTTP-Protokolls. Es ist zum Standard geworden: Chrome und Firefox kennzeichnen HTTP-Seiten als „Nicht sicher“, Besucher zögern, dort ihre Daten einzugeben, und Google berücksichtigt HTTPS im Ranking.

Eine Website auf HTTPS umzustellen ist eine eigene Migration. Der Domainname bleibt gleich, aber das Protokoll aller URLs ändert sich, und Google betrachtet http:// und https:// als zwei verschiedene Adressen: Jede Seite muss auf ihre HTTPS-Entsprechung weitergeleitet werden, in einem einzigen Schritt. Dieser Artikel beschreibt den Ablauf, dann die Weiterleitungsregeln mit oder ohne www und die Reihenfolge, in der sie geschrieben werden. Für die andere Seite, die des Besuchers, siehe wie man eine sichere Website erkennt.

HTTPS bietet drei Garantien:

• Vertraulichkeit: Der Austausch zwischen Browser und Server ist verschlüsselt; in einem öffentlichen WLAN kann niemand ein Passwort oder eine Kartennummer mitlesen;
• Integrität: Seiten und Daten können auf dem Transportweg nicht verändert werden;
• Authentifizierung: Das Zertifikat bestätigt, dass die Website tatsächlich zu diesem Domainnamen gehört.

Chrome zeigt für HTTPS-Websites keinen Hinweis „Sicher“ mehr an: Es ist umgekehrt, HTTP-Seiten tragen den Hinweis „Nicht sicher“, der rot wird, sobald dort Daten eingegeben werden. HTTPS ist auch ein Rankingsignal für Google, ein bescheidenes: Es ersetzt keinen relevanten Inhalt.

Die meisten Hoster stellen kostenlos ein Let's-Encrypt-Zertifikat bereit, das im Kundenbereich aktiviert und automatisch erneuert wird. Für ein kostenpflichtiges Zertifikat führt der Weg über einen CSR (Certificate Signing Request), der auf dem Server erzeugt wird: Er enthält den öffentlichen Schlüssel und den zu zertifizierenden Domainnamen und wird an die Zertifizierungsstelle übermittelt. Auch das übernimmt meist der Hoster.

Es gibt drei Validierungsstufen: nur die Domain (DV), die Organisation (OV) und die erweiterte Validierung (EV), die die Identität des Unternehmens genauer prüft. Alle verschlüsseln gleich, und die Browser heben EV-Zertifikate seit 2019 nicht mehr in der Adressleiste hervor. Prüfen Sie, dass das Zertifikat alle ausgelieferten Varianten abdeckt: exemple.fr und www.exemple.fr sowie etwaige Subdomains.

Ersetzen Sie vor der Umstellung die Adressen mit http:// überall dort durch https://, wo die Website sie schreibt: interne Links in den Inhalten, Menüs, Canonical- und hreflang-Tags, Sitemap, strukturierte Daten. Auch die von den Seiten geladenen Ressourcen (Bilder, Skripte, Stylesheets, Schriften) müssen per HTTPS kommen: Sonst meldet der Browser gemischte Inhalte und blockiert die Ressource unter Umständen.

Aktualisieren Sie bei WordPress die „WordPress-Adresse“ und die „Website-Adresse“ in den allgemeinen Einstellungen und ersetzen Sie dann die alten Adressen in der Datenbank mit einem Suchen-und-Ersetzen-Werkzeug, das serialisierte Daten berücksichtigt (zum Beispiel WP-CLI search-replace). Prüfen Sie auch die Einstellungen der Plugins, die Adressen speichern, und die Adresse der Sitemap in der robots.txt.

Die Seiten müssen nicht einzeln weitergeleitet werden: Nur das Protokoll ändert sich, also genügt eine Regel in der Serverkonfiguration für alle URLs, samt Pfad. Es ist eine dauerhafte 301-Weiterleitung: Sie teilt Google mit, die alte Adresse im Index durch die neue zu ersetzen, und führt Besucher mit einem HTTP-Lesezeichen auf die richtige Seite. Die Regeln mit oder ohne www und ihre Reihenfolge folgen weiter unten.

Eine Property vom Typ „Domain“ deckt bereits alle Varianten ab, HTTP wie HTTPS. Andernfalls fügen Sie die https://-Property Ihrer Website hinzu (mit oder ohne www, je nachdem, welche kanonisch wird) und reichen dort die HTTPS-Sitemap ein. Google findet die neuen Adressen so schneller, und Sie verfolgen ihre Indexierung im Seitenbericht.

Prüfen Sie das Zertifikat (gültig, für jede Hostvariante), das Fehlen gemischter Inhalte und vor allem die Weiterleitungen: Jede alte Adresse muss mit einer einzigen 301 auf ihre endgültige Adresse antworten. Beobachten Sie danach Indexierung und Traffic in den folgenden Wochen; bei einem Rückgang prüfen Sie zuerst die Weiterleitungen und das Zertifikat.

Dieselbe Seite kann unter vier Adressen antworten: http://exemple.fr, http://www.exemple.fr, https://exemple.fr und https://www.exemple.fr. Wählen Sie eine davon als kanonische Version (hier HTTPS mit www) und leiten Sie die drei anderen dorthin weiter, in einem einzigen Schritt und mit demselben Pfad.

Der häufigste Fehler sind zwei Regeln, die aufeinander folgen: eine, die auf HTTPS umstellt, und eine andere, die das www ergänzt. http://exemple.fr/page geht dann zu https://exemple.fr/page und anschließend zu https://www.exemple.fr/page: zwei Weiterleitungen statt einer, langsamer für Besucher und für Google. Die Wahl zwischen mit und ohne www behandelt unser Artikel zur www-Weiterleitung.

In der Datei .htaccess im Stammverzeichnis der Website oder in der Serverkonfiguration:

RewriteEngine On

# Jede Adresse per http oder auf einem anderen Host als www.exemple.fr geht mit einer einzigen Weiterleitung zu https://www.exemple.fr, gleicher Pfad
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} !^www\.exemple\.fr$ [NC]
RewriteRule ^ https://www.exemple.fr%{REQUEST_URI} [L,R=301]

Die beiden Bedingungen sind mit [OR] verknüpft: Die Regel greift, wenn die Anfrage per HTTP oder auf einem anderen als dem kanonischen Host eintrifft, und leitet direkt auf die endgültige Adresse. Hinter einem CDN oder Load Balancer, der HTTPS terminiert, erhält der Server alle Anfragen per HTTP: %{HTTPS} ist dann immer off, und es muss der Header X-Forwarded-Proto geprüft werden, sonst entsteht eine Weiterleitungsschleife.

Ein server-Block für HTTP, ein weiterer für HTTPS ohne www; die Website selbst wird vom Block https://www.exemple.fr ausgeliefert:

# http, mit oder ohne www: zu https://www.exemple.fr, gleicher Pfad
server {
    listen 80;
    server_name exemple.fr www.exemple.fr;
    return 301 https://www.exemple.fr$request_uri;
}

# https ohne www: zu https://www.exemple.fr (das Zertifikat muss exemple.fr abdecken)
server {
    listen 443 ssl;
    server_name exemple.fr;
    return 301 https://www.exemple.fr$request_uri;
}

Fällt die Umstellung auf HTTPS mit einem Relaunch zusammen, ändern sich auch die URLs: Der Server trägt dann zwei Arten von Regeln. Die genauen Weiterleitungen, eine pro URL, bilden den Weiterleitungsplan: diese alte Seite auf jene neue Seite. Die generischen Regeln gelten für eine ganze Gruppe von Adressen: die Umstellung auf HTTPS, das Ergänzen des www, ein komplett verschobenes Verzeichnis.

Apache liest die Regeln der Reihe nach und hält bei der ersten an, die weiterleitet. Steht die generische Regel vorn, geht http://exemple.fr/ancienne-page.html zuerst zu https://www.exemple.fr/ancienne-page.html, dann findet eine zweite Anfrage die genaue Weiterleitung auf /nouvelle-page: eine Kette aus zwei Weiterleitungen und ein Zwischenschritt, den es gar nicht gibt. Setzen Sie daher zuerst die genauen Weiterleitungen, mit der vollständigen Zieladresse (Protokoll und Host inbegriffen), dann die Regeln nach Muster, zuletzt die generischen Regeln:

RewriteEngine On

# 1. Die genauen Weiterleitungen, URL für URL (der Weiterleitungsplan), auf die vollständige Zieladresse
RewriteRule "^/?ancienne-page\.html$" "https://www.exemple.fr/nouvelle-page" [L,R=301,NC,QSD,NE]
RewriteRule "^/?categorie/produit-42$" "https://www.exemple.fr/boutique/produit-42" [L,R=301,NC,QSD,NE]

# 2. Die Regeln nach Muster (ein ganzes Verzeichnis)
RewriteRule ^actualites/(.*)$ https://www.exemple.fr/blog/$1 [L,R=301]

# 3. Die generischen Regeln: http auf https, Host ohne www auf www
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} !^www\.exemple\.fr$ [NC]
RewriteRule ^ https://www.exemple.fr%{REQUEST_URI} [L,R=301]

So führt die alte HTTP-Adresse in einem einzigen Schritt zur neuen HTTPS-Adresse; Adressen ohne genaue Weiterleitung laufen über die generische Regel. Dieselbe Logik gilt zwischen einer Regel nach Muster und den Ausnahmen, die sie abdeckt: zuerst die Ausnahme.

Bei Nginx wird ein return, das direkt im server-Block steht, vor jedem location-Block ausgeführt: Genaue Weiterleitungen in location-Blöcken würden für HTTP-Anfragen nie gelesen. Fragen Sie sie vor der generischen Regel ab, zum Beispiel mit einer map:

# Im http-Kontext: die genauen Weiterleitungen, Pfad für Pfad
map $uri $nouvelle_adresse {
    default "";
    /ancienne-page.html /nouvelle-page;
    /categorie/produit-42 /boutique/produit-42;
}

server {
    listen 80;
    server_name exemple.fr www.exemple.fr;
    # Zuerst die genauen Weiterleitungen, dann die generische Regel (gleicher Test im Block für 443)
    if ($nouvelle_adresse) {
        return 301 https://www.exemple.fr$nouvelle_adresse;
    }
    return 301 https://www.exemple.fr$request_uri;
}

Die von Swan exportierte .htaccess-Datei enthält nur genaue Weiterleitungen, eine pro URL, auf die vollständige Adresse der Produktions- (oder Test-)Domain, Protokoll und Host inbegriffen: Setzen Sie sie vor Ihre generischen Regeln. Sie enthält keine Regel für die Umstellung auf HTTPS; diese bleibt in der Konfiguration der Website zu schreiben. Wo diese Regeln am besten liegen, steht in wo man den Weiterleitungsplan ablegt.

Um zu prüfen, ob eine alte Adresse in einem einzigen Schritt ans Ziel führt, rufen Sie sie per HTTP ab: Die Antwort muss eine 301 sein, deren Header Location die endgültige HTTPS-Adresse ist.

curl -sI http://exemple.fr/ancienne-page.html

HTTP/1.1 301 Moved Permanently
Location: https://www.exemple.fr/nouvelle-page

Zeigt Location auf eine Zwischenadresse (dieselbe Seite per HTTPS oder den Host ohne www), steht eine generische Regel vor der genauen Weiterleitung. Die SEO-Risiken einer Weiterleitungskette behandelt unser Artikel zu den Risiken von Weiterleitungen für SEO.