Durch den Parallelbetrieb und den falschen Umgang mit HTTP und HTTPS kann es zu einer massiven Erhöhung der Adressen einer Website und Duplicate Content kommen. Doch was ist die Lösung für dieses Problem und wie geht man am besten damit um?
Das Domainsetup
Besonders bei Online-Shops kommt es regelmäßig vor, dass eine Website sowohl unter HTTP als auch unter HTTPS erreichbar ist. Die Erreichbarkeit beschränkt sich nicht nur auf einzelne Seiten, sondern gleich auf die gesamte Domain. Dieses Setup hat zur Folge, dass jeder Inhalt (mindestens) unter zwei Adressen für Suchmaschinenrobots crawlbar ist.
Grundsätzlich muss es nicht der Fall sein, dass HTTP und HTTPS denselben Seiteninhalt anzeigen. Die beiden Protokolle können gänzlich getrennt sein und z.B. auch eine eigene robots.txt verwenden. Entsprechend wertet Google in der Google Search Console http://www.trustagents.de und https://www.trustagents.de als komplett getrennte Properties (Tipp: Unser Google Search Console Buch).
Es ist möglich, HTTPS über die robots.txt vom Crawling auszuschließen und selbiges für http:// zuzulassen. Ob das eine gute Lösung ist? Dazu kommen wir gleich. Für mein Beispiel gehe ich davon aus, dass unter den beiden Protokollen dieselben Inhalte ausgespielt werden. Das dürfte der Standardfall sein. http://www.example.com/unterseite und
https://www.example.com/unterseite zeigen exakt identische Inhalte.
Wo liegt das Problem?
Als SEOs haben wir gelernt, dass jeder Seiteninhalt nur unter einer URL erreichbar sein sollte. Selber Content und andere URL bedeutet mehr Adressen, die ein Bot crawlen muss sowie mehr URLs, die intern verlinkt werden oder wurden (bzw. eventuell auch automatisch intern verlinkt sind). Dadurch verteilt sich nicht nur interner, sondern auch externer Linkjuice auf mehr Seiten als notwendig.
So erhält man unter Umständen Links auf verschiedene URLs, die denselben Inhalt anzeigen, anstatt auf DIE eine URL. Zwar kann man über das Canonical-Tag dieses Problem beheben, allerdings löst das Canonical-Tag nie den Kern des Problems, sondern lindert nur Symptome. Die Inhalte sind unter mehreren Adressen verfügbar und Google muss analysieren, ob die Varianten (nahezu) identisch sind und die Signale auf der kanonischen Version vereinigen. Besser ist es immer, wenn es von vornherein nur eine URL für einen Seiteninhalt gibt. Also entweder http, oder https. Um das parallele Betreiben von HTTP und HTTPS kurz unter SEO-Sicht zu bewerten: Das ist alles andere als optimal!
Erschwerend kommt seit einiger Zeit hinzu, dass der Firefox Browser beim Parallelbetrieb von HTTP und HTTPS den Nutzer immer auf die HTTPS-Version schickt, wenn eine Domain über das Eintippen des Domainnamens in der Browserzeile aufgerufen wird.
Wenn wir jetzt davon ausgehen, dass der/die durchschnittliche Nutzer:in
- nicht weiß, dass man die Website eigentlich unter HTTP ranken will und
- ihm/ihr das auch zu 99,99% völlig egal ist,
kommt es zum Problem: Wenn der/die Nutzer:in einen Link setzen will, kopiert er/sie sich die URL aus der Browserzeile und der Link verweist dann auf HTTPS.
Probleme beim parallelen Betrieb von HTTP und HTTPS am Beispiel Content.de
Die bekannte Plattform für Texterstellung www.content.de ist eine der Domains, die (momentan) unter beiden Protokollen erreichbar ist und denselben Seiteninhalt anzeigt. Aus diesem Grund habe ich mir aus MajesticSEO die Backlinkdaten von content.de gezogen und mir speziell die Links herausgesucht, die erstmalig im November und Dezember gefunden worden sind.
Insgesamt sind dabei folgende Zahlen herausgekommen:
Anzahl neuer verlinkender Domains: 114
Anzahl Linkziele HTTP: 100
Anzahl Linkziele HTTPS: 14
Zwar verweist der überwiegende Anteil der Verlinkungen auf HTTP, aber immerhin 12% der neu-verlinkenden Domains verweist auf ein Linkziel unter dem HTTPS-Protokoll. Wie content.de mit der HTTPs Version umgeht, seht ihr hier:
Das Crawling der HTTPS:// Version ist per robots.txt gesperrt. Google darf also nicht auf diese Seiten zugreifen und der der externe Linkjuice „versickert“. Dadurch entwertet Content.de blöderweise 12% seiner eingehenden Links der letzten beiden Monaten!
Was ist die Lösung?
Zuallererst sollte man sich natürlich fragen, ob es überhaupt notwendig ist, dass die eigene Website parallel unter HTTPS (vollständig) erreichbar sein muss. Oder macht es eventuell Sinn, komplett auf HTTPS umzusteigen? Dann kann man das Problem mit den beiden Protokollen von vornherein umgehen, indem man die HTTP-Version auf HTTPS weiterleitet. Aus SEO-Sicht ist die Verwendung von HTTPS kein Problem, wie auch Matt Cutts vor Kurzem bestätigt hat. *edit* Seit August 2014 wertet Google HTTPS als einen Rankingfaktor.
Vor einigen Jahren sprach die längere Ladezeit von HTTPS-Seiten noch gegen die Verwendung des Protokolls – dieses Manko gibt es mittlerweile aber nicht mehr. Und den Einsatz von HTTPS kann man durchaus als ein Vertrauenssignal werden. Denn welcher Suchmaschinen-Spammer macht sich schon die Mühe, ein SSL-Zertifikat zu kaufen? Problematisch wird die Verwendung von HTTPS nur dann, wenn das Zertifikat ausläuft und dadurch die Website nicht mehr erreichbar ist.
Wenn man zu dem Schluss kommt, dass das Setup aufgrund von (IT-)Restriktionen weiterhin vollständig mit demselben Inhalten unter beiden Protokollen laufen muss, sollte auf das Canonical-Tag zurückgegriffen werden. Heißt die HTTPS Varianten verweisen per Canonical-Tag auf die äquivalente HTTP-Version und beide sind per robots.txt zum Crawling freigegeben. Für diese Variante hat sich aktuell beispielsweise Amazon entschieden.
