HTTPS-Umstellung und SEO: Anleitung ohne Rankingverlust

Aktualisiert: 5 Min. Lesezeit Redaktion SEO-Trick
Kurz gesagt

Eine HTTPS-Umstellung kostet bei richtiger Umsetzung keine Rankings. Du richtest ein gültiges Zertifikat ein, leitest jede http-URL per 301 auf ihr https-Gegenstück, stellst Canonicals, interne Links und Sitemap um und behebst Mixed Content. Die Adressänderung in der Search Console brauchst du dafür nicht, Google erkennt den Wechsel selbst.

Wer heute noch eine Website ohne HTTPS betreibt, hat meist kein SEO-Problem, sondern ein Vertrauensproblem. Chrome und Firefox schreiben neben die Adresse „Nicht sicher“, und bei Formularen wird die Warnung deutlicher. Die HTTPS-Umstellung ist trotzdem nicht trivial, denn technisch ist sie für Google ein Website-Umzug: Jede URL bekommt eine neue Adresse. Gut gemacht, merkst du im Ranking davon nichts.

HTTPS-Umstellung und SEO: was Google offiziell sagt

Im August 2014 hat Google im Blogbeitrag „HTTPS as a ranking signal“ angekündigt, HTTPS als Rankingsignal zu nutzen. Google beschrieb es damals als „very lightweight signal“, das weniger als ein Prozent der Suchanfragen weltweit beeinflusste und weniger Gewicht hat als die Qualität der Inhalte. Wer also auf einen Rankingsprung durch HTTPS hofft, wird enttäuscht.

Relevanter ist ein anderer Punkt: In der Doku zur Kanonisierung nennt Google HTTPS als Signal bei der Wahl der kanonischen URL. Gibt es dieselbe Seite unter http und https, bevorzugt Google die https-Version. Die Umstellung bringt also vor allem Klarheit, welche Adresse im Index steht.

Für die Adressänderung in der Search Console ist ein Protokollwechsel ausdrücklich nicht vorgesehen. Google erkennt ihn über die Weiterleitungen selbst. Wann das Tool gebraucht wird, steht im Ratgeber zur Search Console Adressänderung.

Von http auf https umstellen: Zertifikat und Test

Auf einem eigenen Server mit nginx holst du das Zertifikat am schnellsten mit certbot:

sudo certbot certonly --nginx -d beispiel.de -d www.beispiel.de

Google empfahl in der Ankündigung von 2014 Zertifikate mit 2048-Bit-Schlüsseln. certbot verwendet seit Version 2.0 standardmäßig ECDSA-Schlüssel, und wer RSA wählt, bekommt 2048 Bit als Voreinstellung. Ob Zertifikat und Kette stimmen, prüfst du so:

echo | openssl s_client -connect beispiel.de:443 -servername beispiel.de 2>/dev/null | openssl x509 -noout -subject -issuer -enddate
subject=CN = beispiel.de
issuer=C = US, O = Let's Encrypt, CN = R11
notAfter=Jan 16 08:12:44 2027 GMT

Die genaue Bezeichnung der ausstellenden Zwischenstelle ändert sich bei Let’s Encrypt von Zeit zu Zeit, wichtig sind der richtige Name und ein Ablaufdatum in der Zukunft. Bei Shared Hosting aktivierst du das Zertifikat meist mit einem Klick im Kundenmenü. Danach rufst du die Website unter https auf, noch bevor eine Weiterleitung aktiv ist.

Mixed Content beheben

Mixed Content heißt: Die Seite selbst kommt über https, aber einzelne Bilder, Skripte oder Schriften werden noch über http geladen. Browser blockieren aktive Inhalte wie Skripte dann ganz. Bilder schreiben aktuelle Browser teils automatisch auf https um, und wenn das scheitert, fehlen sie oder das Schloss-Symbol verschwindet. Typische Quellen:

  • fest eingetragene http://-Adressen in Beiträgen und Seiten (bei WordPress in der Datenbank)
  • Theme- oder Plugin-Dateien mit absoluten http-Pfaden
  • eingebettete Karten, Videos oder Widgets von Drittanbietern
  • Bild-URLs in CSS-Dateien

Eine schnelle Suche im ausgelieferten HTML findet die meisten Fälle:

curl -s https://beispiel.de/ | grep -oE '(src|href)="http://[^"]+"' | sort -u

Google riet schon 2014 zu relativen URLs für Ressourcen auf derselben Domain. Bei WordPress ersetzt du alte Adressen am besten mit wp search-replace 'http://beispiel.de' 'https://beispiel.de' über WP-CLI, vorher mit --dry-run testen und eine Sicherung anlegen.

301-Weiterleitung von http auf https

Erst wenn https fehlerfrei läuft, schaltest du die Weiterleitung scharf. Für nginx:

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

In der .htaccess:

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]

Achte darauf, dass http, https, www und ohne www zusammen in höchstens einem Schritt auf der Zieladresse landen. Wie du das mit einem kurzen curl-Loop für alle vier Varianten prüfst, steht im Artikel www oder ohne www. Grundlagen zu Status-Codes und Weiterleitungsketten erklärt der Ratgeber zur 301-Weiterleitung.

Canonicals, Sitemap und HSTS

Nach der Weiterleitung kommen die Stellen, an denen die alte Adresse noch steckt:

StelleWas zu ändern ist
<link rel="canonical">absolute https-URL
hreflangalle Sprachversionen mit https
XML-Sitemapnur https-URLs, neu einreichen
robots.txtSitemap-Zeile auf https, https nicht sperren
interne Links, Menüshttps oder relative Pfade
strukturierte Datenurl, logo, image mit https
externe ProfileGoogle-Unternehmensprofil, Social Media, Branchenbücher

Der letzte Schritt ist HSTS. Der Header weist Browser an, deine Domain künftig nur noch über https aufzurufen:

add_header Strict-Transport-Security "max-age=300" always;

Fang mit fünf Minuten an. Läuft alles ein paar Tage stabil, erhöhst du auf max-age=31536000 (ein Jahr). includeSubDomains setzt du erst, wenn wirklich jede Subdomain https kann, sonst sperrst du etwa einen alten Mailserver-Webzugang aus. Für SEO ist HSTS kein Faktor, es schützt deine Besucher.

Einige Endungen erzwingen das von vornherein: Die Endungen .app und .dev stehen komplett auf der HSTS-Preload-Liste der Browser, dort gibt es gar keinen http-Zugang mehr.

Typische Fehler bei der HTTPS-Umstellung

Die meisten Probleme, die ich nach einer Umstellung sehe, haben mit Google gar nichts zu tun:

  1. Das Zertifikat deckt nur beispiel.de ab, nicht www.beispiel.de. Wer die www-Variante aufruft, sieht eine Warnung statt der Weiterleitung.
  2. Die Weiterleitung schickt alles auf die Startseite statt auf die gleiche URL unter https.
  3. Hinter einem Proxy oder CDN erkennt der Server die Verbindung nie als https und leitet endlos weiter. In der .htaccess hilft dann eine Bedingung auf %{HTTP:X-Forwarded-Proto}.
  4. Die robots.txt der https-Version sperrt alles, weil sie aus einer Testumgebung kopiert wurde.
  5. Die automatische Verlängerung des Zertifikats läuft nicht. Let’s-Encrypt-Zertifikate gelten 90 Tage, certbot renew --dry-run zeigt, ob die Erneuerung klappt.

Punkt fünf fällt meist erst nach drei Monaten auf, dann aber gleich mit einer Browser-Warnung für alle Besucher.

Nach der HTTPS-Umstellung: worauf du achtest

In den ersten Wochen schaust du in der Search Console auf zwei Dinge. Im Indexierungsbericht sollten die http-URLs als „Seite mit Weiterleitung“ auftauchen und die https-URLs als indexiert. Im Leistungsbericht sollten Klicks und Impressionen insgesamt stabil bleiben, auch wenn sie sich zwischen den Varianten verschieben. Mit einer Domain-Property siehst du beides in einem Bericht.

Kurzfristige Schwankungen sind bei jedem Umzug normal. Hält ein Rückgang länger an, liegt es fast immer an einer der Stellen aus der Tabelle oder an einer Weiterleitung, die nicht für jede URL greift. Planst du die HTTPS-Umstellung zusammen mit einem neuen Domainnamen, solltest du beides trennen und den Domainwechsel erst danach angehen. Ein neuer Name lässt sich vorher bequem in der Domain-Suche bei betadomain finden, die Kosten aller Endungen stehen in der Preisliste.

Schritt für Schritt

  1. Zertifikat ausstellenEin gültiges TLS-Zertifikat für alle verwendeten Hostnamen einrichten, mit und ohne www, zum Beispiel per certbot und Let's Encrypt mit 2048-Bit-RSA- oder ECDSA-Schlüssel.
  2. Website unter https testenDie Website unter https aufrufen, bevor eine Weiterleitung aktiv ist, und Fehler im Browser-Entwicklerwerkzeug prüfen.
  3. Mixed Content behebenBilder, Skripte, Stylesheets und iframes, die noch über http geladen werden, auf https oder relative Pfade umstellen.
  4. 301-Weiterleitung aktivierenJede http-URL per 301 auf dieselbe URL unter https umleiten, in einem Schritt und inklusive der www-Variante.
  5. Canonicals, interne Links und Sitemap umstellenCanonical-Tags, hreflang, interne Links und die XML-Sitemap verwenden nur noch https-URLs.
  6. HSTS einschaltenDen Strict-Transport-Security-Header erst mit kurzer Laufzeit setzen und nach einigen Tagen ohne Probleme auf ein Jahr erhöhen.
  7. Search Console prüfenDomain-Property verwenden oder die https-Property anlegen, neue Sitemap einreichen und Indexierung sowie Leistung in den folgenden Wochen beobachten.

Domain gefunden? Prüfen und registrieren kannst du sie direkt bei Domain ohne Lockvogelpreis – Jahrespreis ab 2,99 €.

Häufige Fragen

Ist HTTPS ein Rankingfaktor?

Ja, aber ein kleiner. Google hat 2014 angekündigt, HTTPS als sehr leichtgewichtiges Signal zu nutzen, das damals weniger als ein Prozent der Suchanfragen weltweit betraf. Wichtiger ist, dass Google bei gleichen Inhalten die HTTPS-Version als kanonische URL bevorzugt und Browser http-Seiten als unsicher markieren.

Muss ich die HTTPS-Umstellung in der Search Console melden?

Nein. Das Tool zur Adressänderung ist für Wechsel von http auf https ausdrücklich nicht vorgesehen. Wenn du eine Domain-Property nutzt, sind beide Protokolle ohnehin im selben Bericht enthalten. Bei URL-Präfix-Properties legst du die https-Version zusätzlich an.

Wie lange dauert es, bis Google die https-URLs zeigt?

Das hängt davon ab, wie oft Google deine Seiten crawlt. Häufig besuchte Seiten wechseln innerhalb von Tagen, selten besuchte Unterseiten können Wochen brauchen. Eine aktuelle Sitemap mit den https-URLs beschleunigt das.

Brauche ich ein kostenpflichtiges SSL-Zertifikat für SEO?

Nein. Google unterscheidet bei der Bewertung nicht zwischen kostenlosen und kostenpflichtigen Zertifikaten. Ein Let's-Encrypt-Zertifikat ist für Suchmaschinen genauso gut wie ein gekauftes. Entscheidend für Besucher ist nur, dass es gültig ist und alle verwendeten Hostnamen abdeckt.