in SEO

Hands-on: Von http auf https umstellen am Beispiel von ricardo.ch

Hands-on: Von http auf https umstellen am Beispiel von ricardo.ch
4.67 (93.33%) 3 votes


Im August 2014 hat Google offiziell bekannt gegeben eine sichere Verbindung zwischen Webbrowser und Webserver mittels der Benutzung eines sogenannten Secure Socket Layer (SSL) Zertifikat als Ranking Signal zu bewerten, sprich Seiten die auf https laufen im Ranking zu bevorzugen (Quelle).
ricardo.ch lief bisher immer auf einem Standard Transport Layer Security (TLS) http Protokoll, ausschliesslich die Bereiche nach Log-In liefen bis dato unter https.

Im April 2015 haben wir ricardo.ch im responsive Design ge-relauncht. Mit unserem neuen Responsive Design änderten wir auch die Log-in Prozedur, indem wir die bisherige Log-in Seite durch ein Overlay ersetzten, was uns dazu zwang die Seite auf https zu migrieren.

ein overlay mittels dem man sich bei ricardo.ch anmelden kann

Neue Log-In Prozedur bei ricardo.ch mittels Overlay

Spezielle Herausforderung bei dem ganzen Projekt war, dass wir erst einmal nur einzelne Seitenbereiche launchten und somit die Migrierung nur partiell durchführen konnten. Angefangen mit unserer Produkt Detail Page über die Homepage zu den Produkt Listings haben wir peu à peu den kompletten Buyer Flow responsive gestaltet.

Eine Umstellung zu https ist nicht ganz so einfach, bzw. benötigt einige Vorüberlegungen. Im folgenden Post möchte ich die Herausforderungen und Überlegungen, die dieses Projekt für mich geboten hat teilen.

Was ist TLS/SSL & HTTPS?

SSL steht wie oben schon erwähnt für Secure Socket Layer welches im Prinzip ermöglicht die Verbindung zwischen Webbrowser und Webserver zu verschlüsseln (Quelle), sprich alle Daten die ein User in seinem Browser, beispielsweise in ein Suchfeld auf der Seite eingibt, bleiben zwischen User und Server verschlüsselt.
Eine verschlüsselte Domain wäre demzufolge: https://www.domain.ch

Eine unverschlüsselte Domain wäre: http://www.domain.ch

 

Vorteil einer Migration für den User

Das Gefühl der Sicherheit ist der grösste Vorteil für den User . Das https sowie das Schlosssymbol sollen dem User ein sicheres Gefühl vermitteln. Das soll Auswirkungen z.B auf die Conversion Rate haben, User die wissen in einer sicheren Umgebung zu surfen, geben auch lieber Kreditkarten an den Shop weiter.

schlosssymbol bei sicherer https verbindung

Das Schlosssymbol im Chrome Browser zeigt ob die Verbindung eine sichere ist

Vorherige Fragen und Herausforderungen

Wie bereits vorweg erwähnt konnten wir nicht einfach die komplette Seite migrieren, da wir ersteinmal nur partiell, für einzelne Bereiche in Responsive Design gelauncht haben.

War es also möglich HTTPS nur für einige Bereiche, für andere aber nicht zu launchen? 

Dies ist kein Problem. Allerdings war es aus User Sicht wenig ratsam dies zu tun, denn dieser wechselt mitten im Buyer Flow zwischen verschiedenen Protokollen hin und her. Dies kann beispielsweise dazu führen, dass der Browser dem User beim Wechsel von einer sicheren Verbindung zu einer unsicheren informiert.

 

Verschiedene Browser Meldungen über unsicheren Content auf einer https domain

Verschiedene Browser Meldungen über unsicheren Content auf einer https domain


Muss ich ein neues Search Console Konto aufsetzen?

Ja, für Google sind Domains sowohl mit http als auch mit https zwei verschiedene Domains.

Muss ich mein Disavow File auch für die https Version hochladen?

Ich habe zu diesem Fall nicht wirklich Informationen finden können. Nachdem ich aber das Search Console Konto für die https Version aufgesetzt hatte, ware im Disavow Tool keine Datei hinterlegt, sprich sicher ist sicher und das selbe Disavow File sollte auch auf die HTTPS Version geladen werden.

Know How aneignen

Bei der Migration haben mir folgende Beiträge geholfen:

1. https://support.google.com/webmasters/answer/6073543?hl=de

2. http://blog.searchmetrics.com/de/2014/08/22/https-als-ranking-faktor-was-bedeutet-das/

3. http://moz.com/blog/seo-tips-https-ssl

4. http://www.onlinemarketing-praxis.de/webdesign-webentwicklung/webseite-und-online-shop-auf-https-umstellen

5. http://www.paulirish.com/2010/the-protocol-relative-url/

6. http://de.wikipedia.org/wiki/Server_Name_Indication

7. https://support.google.com/webmasters/answer/6033049?hl=de&ref_topic=6033084

8. http://blog.searchmetrics.com/us/2015/03/03/https-vs-http-website-ssl-tls-encryption-ranking-seo-secure-connection/

9. https://www.youtube.com/watch?v=cBhZ6S0PFCY

10. http://www.iab.net/iablog/2015/03/adopting-encryption-the-need-for-https.html

11. http://googlewebmastercentral.blogspot.de/2014/08/https-as-ranking-signal.html

Worauf ist bei der Migration zu achten?

Bei einer Migration von http zu https müssen alle internen Ressourcen, sprich CSS Files, CDN Server Pfade, interne Links, Bildpfade etc. angepasst werden.

Externe Ressourcen wie Scripts von Werbepartnern etc. müssen ebenfalls berücksichtigt werden. Nur so vermeidet man das bestimmte Ressourcen nicht laden, oder der Browser die Nachricht gibt dass nicht alles auf Sicherheitprotokoll verfügbar ist (siehe oben).

Weiter sollte man folgende Fehler vermeiden:

  • Das Zertifikat ist abgelaufen oder läuft demnächst ab
  • Das Zertifikat läuft auf dem falschen Hostnamen (www.ricardo.ch oder ricardo.ch)
  • https ist nicht in robots.txt gesperrt
  • https Seiten stehen nicht auf noindex
  • https Seiten geben die richtigen Status Codes aus.

Die eigentliche Migration

Header anpassen

Im Header Bereich befinden sich viele SEO relevante Informationen wie z.B. das Canonical Link Element oder die rel=alternate Link Elemente. Diese mussten zwingend angepasst werden und sollten weder relativ noch protokollrelativ ausgwiesen werden, sondern mit vollständigem Pfad angegeben werden. (Quelle)

1. rel=canonical anpassen

Um Google mittzuteilen dass eine Umstellung von http zu https stattgefunden hat und die URLs aus dem Index ausgetauscht werden müssen, empfahl es sich zuerst das rel=canonical Element anzupassen. Wichtig zu betonen ist hier (nach meiner Erfahrung) dass die Canonicals als erstes, vor den redirects, gesetzt werden sollten (warum erkläre ich später).

Aus 

<link rel=“canonical“ href=“http://www.ricardo.ch/“ />

wird

<link rel=“canonical“ href=“https://www.ricardo.ch/“ />

Canonical auf https anpassen

https angepasster Canonical Link

2. rel=alternate anpassen

Dasselbe gilt für die alternativen Sprachversionen die ricardo hat.

Aus 

<link rel=“alternatehreflang=“fr-CHhref=“http://www.fr.ricardo.ch/“ />

wird

<link rel=“alternatehreflang=“fr-CHhref=“https://www.fr.ricardo.ch/“ />

 

rel=alternate auf https umstellen

Auf https angepasste alternate links

 

3. Interne Ressourcen anpassen

Alle Ressourcen, deren URL auf derselben Domain laufen, werden als relativer Pfad angegeben, alle Ressourcen die auf Subdomains oder anderer Domain laufen in protokollrelativen URLs (siehe nächster Punkt) (Quelle)

Für ricardo sieht dies folgendermassen aus:

CSS File in relativer URL angegeben

Eine CSS Datei im relativen URL Format angegeben

 

 3. Externe Ressourcen anpassen

Externe Ressourcen sind im Prinzip alle Anfragen zu fremden Domains die es braucht um die Seite darzustellen. Dies können Content Delivery Networks sein, Urls zum Image Server oder aber auch Anfragen zu sozialen Netzwerken wie Facebook und Twitter, sowie Anfragen zu externen Tools wie z. B. Optimizely.

Weiss man hundertprozentig dass diese Ressourcen in https zugänglich sind, ist es zu empfehlen immer den ganzen URL Pfad mit https anzugeben.

Ist dies aber unklar kann man den Link als protokollrelativen Pfad angeben.

Wenn der Browser auf der https Seite landet, den protokollrelativen Pfad findet, versucht er diesen Request erst in https zu laden, ist dieses nicht verfügbar lädt er den request in http. So vermeidet man Browsermeldungen dass es Seiteninhalte gibt, die nicht sicher sind.

Protokollrelative URLs

Links in der Navigation zu auto.ricardo.ch angegeben in protokollrelativen URLs

 

Serverseiteige Weiterleitung

Um den User von der alten http Url zur neuen https Url weiterzuleiten und im Index auszutauschen muss ein ein 301 redirect  (Unterschied 301 und 302 redirect) gesetzt werden. Dies kann über einen sogenannten serverseitigen Redirect passieren. ricardos Redirects werden alle über ein F5 Server gemanaged. Hierfür wird dann eine iRule geschrieben, die folgendermassen aussieht:

irule welche http traffic auf https umleitet

IRule auf dem F5 Server zur Umleitung der HTTP Anfragen zu https

 

Browserweiterleitung durch HSTS

Läuft die Seite vollständig auf https gibt es die Möglichkeit alle Anfragen, sei es von Browsern oder anderen User Agents, mittels eines Http Strict Transport Security (HSTS) dazu zu zwingen ausschliesslich Verschlüsselte (https) Bereiche aufzurufen.

Ein Browser beispielsweise wird dann beim ersten Kontakt über einen Header Eintrag darüber informiert dass alle Verbindungen zur Webseite per SSL/TLS verschlüsselt werden sollen (Quelle).

Mit anderen Worten, geht ein Browser direkt auf verschlüsselte Seiten ohne vorher die Seite in http anzufragen. Dies spart zum einen Zeit und zum anderen schützt es vor sogenannten Man-in-the-middle Angriffen.

Redirect Ausgabe HSTS

Browserweiterleitung durch HSTS Modul

 

Austausch der URLs im Index durch Google

Nachdem, zumindest technisch gesehen, eine Migration abgeschlossen ist, ist es wichtig regelmässig den Austausch der Urls im Index von Google zu kontrollieren. Hierfür bestehen zwei Möglichkeiten.

1. site Abfrage

2. Search Console

Site Abfrage:

Über die Abfrage site:www.ricardo.ch inurl:https im Suchfeld , spuckt Google alle Seiten der URL aus, die es mit https im Index gefunden hat, selbiges für http.

Ich habe die Werte über Wochen manuell, montags in ein Google Doc dokumentiert und daraus folgenden Graph gebastelt:

Ein Graph auf dem man sehen kann wie http urls deinddexiert und https indexiert sind

Rote Linie zeigt die Anzahl der https indexierten, blaue Linie die Anzahl der http Urls im Google Index

 

Search Console:

Die Zahlen der Indexierung/De-indexierung unterscheiden sich bei Site Abfrage und in Google Webmaster Tools massiv. Dies ist dadurch bedingt dass Google in dem Graphen auch Urls mitzählt die bspw einen Parameter angehängt haben aber nicht fürs indexing freigegeben sind oder aber URLs die zwar für den Index bereitgestellt sind, aber in der Suche nicht ausgespielt werden, bzw. gesperrt sind. Bei ricardo kann die hohe Zahl in den Tools auch viele abgelaufene Produktseiten beinhalten.

google_indexierungsstatus_https_search_console

Indexierungsstatus der HTTPS Version in der Google Search Console

google_indexierungsstatus_http_search_console

Indexierungsstatus der HTTP Version in der Google Search Console

 

Tipp zum Schluss.

Ich würde auf jeden beim nächsten Mal erst die Canonicals setzen und warten bis Google die Seiten deindexiert hat und erst dann die Redirects setzten.

Wie oben zu sehen, Google benötigt unheimlich lange die alten Seiten aus dem Index zu hauen, möglicherweise könnte man dies so beschleunigen. Sitemaps sind bei ricardo leider noch nicht möglich, wären aber auch eine gute Möglichkeit zur Beschleunigung.