Und wie gehen Sie mit HTTPS um?

Vor Kurzem habe ich über Indexierung bzw. Indexierungskontrolle geschrieben und das Thema HTTPS schließt sich daran fast nahtlos an. Auch Dominik hat sich das Thema SSL und Google bereits vorgenommen (siehe „Die Sache mit SSL und Google„) und heute möchte ich mich damit beschäftigen, wie man mit einer Website, die unter HTTP und HTTPS läuft bzw. verfügbar ist, umgehen sollte. Denn es drohen, speziell seit einigen Monaten, ein paar Probleme.

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 die gesamte Domain. Dieses Setup hat zur Folge, dass jede Seite (mindestens) unter zwei URLs 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. So ist es möglich, HTTPS über die robots.txt vom Crawling auszuschließen. Ob das eine gute Lösung ist, werde ich später im Text beantworten. Für mein Beispiel gehe ich davon aus, dass unter den beiden Protokollen dieselben Inhalte ausgespielt werden.

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 URLs, 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 Linkjuice, sondern auch externer 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. Besser ist es immer, wenn es von vornherein nur eine URL für einen Seiteninhalt gibt.
Um das HTTP und HTTPS Setup kurz zusammenzufassen: Aus SEO-Sicht alles andere als optimal!

Erschwerend kommt seit einiger Zeit hinzu, dass der Firefox Browser, sofern eine Seite auch unter HTTPS erreichbar ist, den Nutzer immer auf die HTTPS schickt, wenn eine Domain über das Eintippen des Domainnamens in der Browserzeile aufgerufen wird. Wenn wir jetzt davon ausgehen, dass der durchschnittliche Nutzer a) nicht weiß, dass man die Website eigentlich unter HTTP ranken will und b) ihm das auch zu 99,99% völlig egal ist, kommt es zum Problem: Wenn der Nutzer (freiwillig) einen Link setzen will, kopiert er sich die URL aus der Browserzeile. Der Link verweist dann auf HTTPS.

Beispiel Content.de

Die bekannte Plattform für Texterstellung www.content.de ist eine der Domains, die 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:

# neuer verlinkender Domains Linkziel HTTP Linkziel HTTPS
114 100 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:

robots.txt HTTPS-Version von Content.de

Durch die Crawling-Einstellungen in der robots.txt entwertet Content.de blöderweise 12% seiner eingehenden Links aus den letzten sechs Wochen!

Was ist die Lösung?

Zuallererst sollte man sich natürlich fragen, ob es überhaupt notwendig ist, dass die eigene Website auch 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.

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 Karl Kratz wertet die Verwendung eines SSL-Zertifikates sicher nicht umsonst als ein Trustsignal an Suchmaschinen. Denn welcher Spammer macht sich schon die Mühe, ein eigenes Zertifikat zu kaufen?
Problematisch wird die Verwendung von HTTPS nur dann, wenn das Zertifikat ausläuft und dadurch die Website nicht mehr erreichbar ist.

Sofern 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, um das bevorzugte Protokoll kenntlich zu machen. Für diese Variante hat sich beispielsweise auch Amazon entschieden.

Diesen Artikel teilen



Kommentare (7)

  • Timo Antworten

    Sicher das Google nicht damit umgehen kann? Wäre doch mal etwas für Matt Cutts Videoblog.

    • Stephan Czysch Antworten

      Wie meinen? Mit HTTPS kann Google problemlos umgehen

  • Roman Skuballa Antworten

    Toller Beitrag, sehr hilfreich. Denkst Du, dass man das Problem SEO technisch durch die rewrite rule in der .htaccess löst? So wird es ja klassisch bei duplicate Domain Content gemacht. Würde mich brennend interessieren.

  • Andrea Puiatti Antworten

    Für ein Projekt habe ich genau dieses Problem.
    Einige URLs -sehe ich auf Google- sind mit https und viele andere nicht.
    Um sicher zu sein, werde ich wahrscheinlich auf den frontend https komplett auszuschalten lassen ausser auf den Seiten wo eine transaktion entstehen kann

  • Robert Antworten

    Also ich habe eine Seite komplett nur mit https und sie ist auch komplett bei google indexiert. Die Seite ist allerdings bei Google gehostet

  • Sven Antworten

    Hallo, der Beitrag ist zwar schon etwas her, aber vielleicht kann mir ja doch jemand Auskunft geben.

    Die folgende Seite ist daran interessiert, dass Kunden sich registrieren und nutzt in der Registrierungsphase https.

    http://www.hompage.de leitet während des Registrierungsprozess auf https://www.hompage.de.

    Wertet Google den Eintritt eines Besuchers in den Registrierungsprozess als Verlassen der Site, sprich wird die Bounce Rate somit negativerweise beeinflusst?

    Vielen Dank.

    • Stephan Czysch Antworten

      Damit habe ich mich nicht beschäftigt. Ich würde von „Ja“ ausgehen, auf die SEO-Performance sollte dies allerdings keinen Einfluss haben

Hinterlasse einen Kommentar

Ihre E-Mail-Adresse wird nicht veröffentlicht.

Wir sind bekannt aus...

  • Werben und Verkaufen
  • Internet World Business
  • lead Digital
  • t3n
  • https://www.trustagents.de/wp-content/uploads/2016/07/5.png
  • Markt und Mittelstand
  • IHK
  • n-tv