Immer up-to-date bleiben!? Jetzt Newsletter abonnieren

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. Denn durch den falschen Umgang Parallelbetrieb von HTTP und HTTPS kann es zu einer massiven Erhöhnung der Adressen einer Website und Duplicate Content kommen. Dominik hat sich das Thema SSL und Google bereits vorgenommen (siehe „Die Sache mit SSL und Google„).

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 paralelle 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 durchschnittliche Nutzer

  • nicht weiß, dass man die Website eigentlich unter HTTP ranken will und
  • ihm das auch zu 99,99% völlig egal ist,

kommt es zum Problem: Wenn der Nutzer einen Link setzen will, kopiert er 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:

# 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

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.

Diesen Artikel teilen



Kommentare (9)

  • 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

  • Malte Antworten

    Hallo Stephan,
    wieso gibt es das Manko längere Ladezeiten bei HTTPS-Seiten nicht mehr? Leider bist du darauf in deinem Artikel nicht näher eingegangen. Ansonsten klasse Artikel!

    • Stephan Czysch Antworten

      Hallo Malte,

      den Geschwindigkeitsunterschied gibt es noch, es ist aber bei Weitem nicht mehr so gravierend wie noch vor 7-8 Jahren. Mittlerweile zeigen die gängigen Browser nicht-https Seiten als „unsicher“ an und https ist laut Googles Ankündigung ein Rankingfaktor (siehe https://webmasters.googleblog.com/2014/08/https-as-ranking-signal.html). Er ist zwar einer, aber einer von vielen 😉

      Viele Grüße
      Stephan

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