Die Umstellung auf eine SSL-Verschlüsselung für eine Website ist immer von einem leichten Mysterium umgeben. Während die einen behaupten, es handele sich um einen simplen Protokoll-Wechsel, stellen die anderen einen Vergleich mit einem vollwertigen Website Relaunch auf. Die Frage nach der eigentlichen Sinnhaftigkeit wird dagegen in diesem Artikel gut behandelt. Wie sich aber in 8 überschaubaren Schritten der vollständige und SEO-freundliche Wechsel auf https durchführen lässt, lest Ihr im folgenden Artikel.
Schritt 1: Kaufe und installiere Dir ein SSL-Zertifikat
Der erste Schritt, den Du unternehmen musst, um von http auf https umzustellen, besteht darin, ein SSL-Zertifikat zu erwerben und es auf dem Server zu installieren, auf dem Deine Website gehostet wird. Es gibt viele Unternehmen, die SSL-Zertifikate anbieten, auch wenn einige von ihnen recht teuer sind. Wenn Du nur über ein begrenztes Budget verfügst, gibt es einige wenige Unternehmen, die kostenlose SSL-Zertifikate anbieten, darunter Cloudflare oder SSL For Free. Bevor Du dich jedoch für ein kostenloses SSL-Zertifikat entscheidest, solltest Du sicherstellen, dass Dein Server damit kompatibel ist. Wenn Du dich für ein kostenloses SSL-Zertifikat entscheidest, suche nach einem Tutorial, das erklärt, wie es installiert wird. Für SSL For Free empfehle ich dieses Video. Für Cloudflare sieh dir dieses Video an.
Wenn Du über ein begrenztes Budget verfügst, aber kein kostenloses SSL-Zertifikat verwenden möchtest, kannst Du jederzeit zu einem Webhosting-Anbieter wechseln, der SSL-Zertifikate anbietet. Heutzutage bieten viele Webhosting-Unternehmen SSL-Zertifikate an, zusammen mit Tutorials, die Dir bei der Installation helfen. Beachte jedoch, dass ein Wechsel des Webhosting-Providers unter Umständen ein größerer Aufwand ist als der Erwerb und die Installation eines SSL-Zertifikats, also überlege es Dir gut, bevor Du dich entscheidest, was zu tun ist.
Schritt 2: Weiterleitungen, Weiterleitungen, Weiterleitungen!
Nicht umsonst wird der Vergleich mit einem Website Relaunch häufig aufgestellt. Hier muss man allerdings streng genommen etwas differenzieren: Bei einem vollwertigen Website Relaunch sind in aller Regel mehr Faktoren betroffen als die reine URL-Struktur. Bei einer https-Umstellung aber könnte man den Switch am ehesten noch mit einem Domain-Wechsel vergleichen (es sei denn natürlich, die Umstellung erfolgt im Rahmen eines vollständigen Relaunchs, was durchaus Sinn machen kann, an dieser Stelle aber nicht Thema ist).
Wie auch immer man den Vorgang letztendlich bezeichnen möchte – Fakt ist, dass Weiterleitungen sowohl beim Website Relaunch (mit URL-Struktur-Wechsel), einem Domain-Umzug/Wechsel als eben auch bei der https-Umstellung der absolut wichtigste Faktor sind. Also: Finger weg von exotischen Ideen wie einem Canonical Tag Setup von http auf https, einem noindex der http-Variante oder gar einer kompletten 404 Statuscode-Flut der http-Variante. Hier verhält es sich tatsächlich exakt wie bei einem normalen Relaunch: Wer keine 1:1 Weiterleitungen der alten URLs auf die neuen URLs vornimmt, muss mit massiven Ranking-Verlusten in Folge von Deindexierungen rechnen. Richte 301 Weiterleitungen ein, die von den http-URLs auf ihre jeweiligen https-Versionen verweisen.
Hinweis für WordPress-Benutzer: Wenn Deine Website mit WordPress erstellt wurde, kannst Du das Plugin Really Simple SSL verwenden, um Deine http-URLs mit nur einem Klick auf ihre https-Varianten umzuleiten. Vergiss auch nicht, Deine WordPress-Adresse (URL) und Deine Website-Adresse (URL) unter ‚Einstellungen‚ (Allgemein) auf https zu aktualisieren.
Schritt 3: Ressourcen in https ausliefern
Was häufig vergessen wird, sind Ressourcen wie Bilder, CSS-Dateien, JavaScript-Bibliotheken etc. Streng genommen können wir an dieser Stelle auch PDF-Dokumente aufführen. Auch hier gilt: Alles was im Zuge der SSL-Umstellung nicht auf https ausgeliefert wird, bedeutet im Nachgang eine parallele Existenz von http- und https-Varianten. Und die wollen wir tunlichst vermeiden. Von daher: Jegliche eingebundenen Ressourcen dürfen ausschließlich über URLs mit https aufrufbar sein.
Schritt 4: Canonicals, hreflang-Attribute, Alternates umstellen
Jetzt wirds ein bisschen tricky – daher: aufmerksam lesen! Canonical-Tags sind keine Lösung, um eine https-Umstellung zu realisieren (siehe Punkt 2)! Es kann aber der Umstand vorliegen, dass in der Gesamtstruktur einer Website eben gewisse Canonical-Tag-Konfigurationen bereits gesetzt sind. Sei es zur Vermeidung von doppelten Inhalten, zum Ausschluss von Parametern oder wozu auch immer – das ist an dieser Stelle unerheblich. Sollten diese Canonical-Tag-Konfigurationen auch nach der https-Umstellung noch notwendig sein, so muss auch unbedingt gewährleistet sein, dass die in den Canonical-Tags angegebenen URLs jetzt auch in https angegeben werden.
Genauso verhält es sich mit zwei Standard-Konfigurationen, die mittlerweile vielleicht etwas geläufiger sind: Wer hreflang-Tags einsetzt, um verschiedenen Sprachvarianten auszuzeichnen, muss auch die URLs in den hreflang-Tags jetzt in https angeben. Und wer alternate-Tags einsetzt, um eine mobile Variante auszuzeichnen, muss auch diese URLs mit https angeben (wenn die mobile Variante ebenfalls auf https umzieht). Umgekehrt müssen natürlich die Desktop-URLs im Canonical der mobilen Website wieder mit https ausgezeichnet werden. Das alles erfolgt weiterhin im Quellcode.
Schritt 5: Interne Verlinkung anpassen
Ein weiterer wichtiger Punkt, der Parallelen zum „vollwertigen Relaunch“ hat, ist die interne Verlinkung. Auch hier ist es wichtig, dass die intern gesetzten Links einer Website nicht durch die ausgezeichneten Weiterleitungen abgefangen werden, sondern direkt angepasst werden. Am einfachsten und komfortabelsten ist das natürlich mit relativ-gesetzten Verlinkungen möglich, da hierbei eine manuelle Anpassung nicht mehr von Nöten ist. Liegt jedoch keine seitenweite relative interne Verlinkung vor, so muss Hand angelegt werden. Das kann abhängig vom Umfang der Website extrem (zeit-)aufwendig werden, ist aber die sicherste Variante, um auch intern keine Linkpower zu verlieren.
Schritt 6: XML Sitemap aktualisieren
Ähnlich verhält es sich mit der XML-Sitemap (bzw. Sitemaps), die ohnehin in der Google Search Console jeder Website hinterlegt werden sollte/n. Auch hier gilt: theoretisch kann der Googlebot auch die alten http-Varianten in der Sitemap bei korrekt gesetzten Weiterleitungen verfolgen und dann die https-Varianten erreichen. Um diesen wenig effizienten Zwischenschritt aber zu vermeiden, sollten innerhalb der XML-Sitemap/s immer sofort die neuen https-URLs ausgegeben werden.
Schritt 7: Robots.txt prüfen
Das ist schnell abgehakt: Natürlich sollte im Zuge der Umstellung immer nochmal geprüft werden, ob die robots.txt nicht zufällig sämtliche URLs, die mit https ausgegeben werden, blockieren. Aus welchem Grund eine solche Konfiguration Sinn machen sollte, ist eine andere Frage – aber hier habe ich schon die wildesten Dinge gesehen. Also: schnell einmal reinschauen und bei Bedarf die Zeile, die https blockiert, entfernen. Im Übrigen sollten die http-Varianten ebenfalls nicht blockiert werden, falls es doch noch einige Inhalte gibt, die im reinen http ausgeliefert werden (nicht ratsam aber durchaus realistisch).
In dem Zuge lässt sich jetzt noch schnell prüfen, ob die neue XML-Sitemap vernünftig über die https-URL verlinkt wird.
Schritt 8: Google Search Console neu aufsetzen
Zu guter Letzt erfordert die Google Search Console ein vollständiges Neu-Aufsetzen der Property. Wer sich also über abstürzende Werte in der Suchanalyse nach der Umstellung wundert, sollte prüfen, ob die Domain mit https in der Search Console angelegt ist. Hier ist eine neue Validierung in aller Regel erforderlich, was bei einem über den gleichen Google Account angelegten Analytics / GTM Profil aber kein Problem darstellen sollte.
Wer übrigens möchte, kann auch in Analytics das Protokoll auf https umstellen, das macht aber kaum einen Unterschied, da die Daten bei korrekt implementiertem Tracking-Code ohnehin erfasst werden. In jedem Fall sollte jedoch die Verknüpfung zwischen Analytics Property und Search Console Property neu vorgenommen werden, damit weiterhin die korrekten Zahlen übertragen werden.
Noch ein Schlusswort zu Zertifikaten
Um den kommunizierenden Server als vertrauenswürdig zu identifizieren, muss im Zuge der SSL Umstellung immer ein validiertes und gültiges SSL-Zertifikat eingebunden werden. Dieses lässt sich beim Hoster beantragen – die Zertifizierung erfolgt letztendlich über eine vertrauenswürdige Institution, wie etwa Geotrust, Twathe oder Globalsign. Das Validierungsverfahren des Zertifikats erfolgt in unterschiedlichen Sicherheitsstufen, was letztendlich auch in unterschiedlich vertrauenswürdigen Zertifikaten resultiert. Ich empfehle hier mindestens das organisationsvalidierte SSL-Zertifikat, da durch dieses neben dem reinen Domain-Namen auch noch der Unternehmensname und -standort als Identifikation in der Browserzeile ausgegeben werden. Das ist einfach ein zusätzliches Trust-Signal.
Wer die aufgeführten Schritte korrekt durchführt, sollte in aller Regel die SSL-Umstellung ohne böse Überraschungen über die Bühne bringen und gegebenenfalls sogar von einem positiven Rankingfaktor profitieren. Natürlich gibt es immer und bei jeder Website irgendwelche Ausnahmen, auf die man reagieren muss – aber das lässt sich im Einzelnen nicht standardisieren. Ich freue mich natürlich über alle ergänzenden Hinweise in den Kommentaren.
Ein Kommentar
Frank schrieb am 11. November, 2020 @ 14:17
Dem Punkt 2 kann ich nur bedingt zustimmen.
Die Variante mit Canonicals von http auf https für einen Zeitraum von etwa 6-8 Wochen (bis die neue https Struktur komplett im Google Index gelandet ist) funktioniert bei meinen Kunden schon seit zig Jahren weitestgehend reibungslos. Gerade stelle ich einen der letzten Kunden im Rahmen eines Relaunches um – läuft sehr schwankungsfrei 😉