Wie uns dieser seltsame Bug 30% Sichtbarkeit gekostet hat

Pascal Landau
Pascal ist Head of Marketing Technology and SEO bei ABOUT YOU und verantwortet dort die Entwicklung interner Tools im Online Marketing.
Artikel teilen
4. Juli 2017 22 Kommentare
… zumindest temporär – man möge mir die click-baity Überschrift verzeihen ;) In diesem Artikel möchte ich zum einen die Hintergründe erläutern, die dazu geführt haben und zum anderen unser Vorgehen zur Diagnose und Behebung darstellen.

Achtung: Ziemlich ausführlich – bei wenig Zeit gerne direkt zum tl;dr springen.

Bevor wir tiefer in das komplexe Konstrukt aus Canonicals, Hreflangs, Race Conditions und einem sehr sehr seltsamen Indexierungs- bzw. Ranking- Verhalten von Google eintauchen, erstmal zu den Fakten:

30% down – Houston, wir haben ein Problem

Der ein oder andere dürfte neben diesem Blog auch der Facebook Seite von Sistrix folgen. Dort wurde am vorletzten Freitag folgender Beitrag gepostet:

-30% Sichtbarkeit – so kann das Wochenende starten… Da wir zu diesem Zeitpunkt noch keine Gewissheit (sofern es die überhaupt gibt – dazu später mehr) über die genauen Hintergründe hatten, haben wir uns erstmal zurückgehalten.

Diagnose

Intern hatten wir die Situation seit Mittwochabend (07.06.2017) unter Beobachtung und sind am Folgetag tiefer in die Analyse eingestiegen. Bitte im Hinterkopf behalten, denn zu dem Zeitpunkt hatten wir viele Infos noch nicht (wie etwa die Sichtbarkeitsentwicklung in AT/CH).

Anhand des täglichen Sichtbarkeitsindizes zeichnete sich seit Sonntag (04.05.2017) ein Abfall der Sichtbarkeit ab:

Allerdings gab es auf technischer Seite keine offensichtlichen Anzeichen für Probleme. Eindeutig wäre so etwas wie:

  • Sperrung von Teilbereichen der Webseite in der robots.txt
  • Großflächig falsch gesetzte Canonical / Hreflang Tags
  • Falsches Ausspielen von robots noindex meta Tags
  • Falsche Status Codes (non-200)
  • Inkorrekte geo- oder mobile Redirects

Die Betonung liegt hier leider auf „offensichtlich“, denn bei entsprechenden Quickchecks (á la URL aufrufen und Quelltext checken) war tatsächlich alles in Ordnung (ich komme später dazu, warum das keine verlässliche Methode ist). Die Ursachenforschung ging also weiter, wobei wir uns auf folgende Bereiche konzentriert haben:

  • Analyse des SEO Traffics
  • Analyse von externen Daten
  • Analyse der Daten der Search Console
  • Re-Evaluierung von Tickets aus den letzten Deployments im Shop

Analyse des SEO Traffics

Wir setzen Google Analytics 360 als primäres Webtracking Tool bei uns ein und haben entsprechende Custom Segments zur Segmentierung einzelner Seitenbereiche eingerichtet (All, Kategorien, Produkte, etc.). Zur Eingrenzung des SEO Traffics über Google nutzen wird dazu google / organic und google / organic brand.

Unser SEO Reporting bilden wir über das Google Data Studio ab, da wir hier die Segmente aus Google Analytics übernehmen können und alle Seitenbereiche übersichtlich auf einen Blick vergleichen können.

Dabei fallen zwei Dinge auf:

  1. Seit dem 5. Juni steigt die Differenz zur Vorwoche im Gesamt-Traffic sichtbar an (gleichfarbige, blassere Linie)
  2. Dieser Trend zeigt sich vor allem auf unseren Kategorieseiten (Google – Category).

Analyse von externen Daten

Um das Problem weiter einzugrenzen, haben wir uns zunächst die Keywords angeschaut, bei denen wir deutlich an Rankings verloren hatten. Oder konkret: Die verlorenen Top-20 Rankings zwischen dem 04.06.2017 und dem 08.06.2017

Die URLs

  • www.aboutyou.de/frauen/bekleidung
  • www.aboutyou.de/maenner

stechen bereits in der Übersicht hervor und das Bild deckt sich insgesamt mit unseren Traffic Daten, denn unsere Kategorien liegen unter /frauen/ bzw. /maenner/. Schaut man sich sowohl die konkreten URLs (ohne abschließenden /) als auch die Summe der Damenmode-Kategorien (alles unter /frauen/bekleidung/) im täglichen Verlauf an, sieht man den Einbruch deutlich.

Unser /about/ Segment, das hauptsächlich für unsere Marken rankt, ist zwar ebenfalls betroffen aber bei weitem nicht so stark (relativ betrachtet).

Bei der konkreten Kontrolle der verlorenen Rankings sind dann zum ersten Mal Anomalien aufgefallen. Tatsächlich waren die URLs für die generischen Suchanfragen nicht mehr auffindbar, aber durch Eingabe der konkreten URL als Suchbegriff waren sie teilweise noch „im Index“.

Ein Blick in den Cache zeigte dann zum Beispiel folgendes Bild:

 

Obwohl wir im deutschen Index gesucht haben und auch eine deutsche URL gerankt hat, wird im Cache von Google die Variante unsere AT Domain angezeigt. Ab hier wurde es spannend und es gab eine Reihe „ungeklärter Fragen“:

  • Ist das ein Sonderfall oder können wir ein Pattern ableiten?
  • Wie verhalten sich andere Webseiten, die in mehreren Ländern aktiv sind?
  • Warum sollte Google eine „andere“ URL im Cache anzeigen?

Vorab sollte man noch erwähnen, dass wir sowohl Canonical als auch Hreflang auf den Kategorieseiten korrekt implementiert haben. D.h. die deutsche URL zeigt per Canonical auf sich selbst und via de-AT Hreflang auf die canonical Variante in AT (vice versa auf der AT URL). Hier haben wir eine sehr hohe Gewissheit, dass das auch über die gesamte Zeit hinweg der Fall war.

Ist das ein Sonderfall oder können wir ein Pattern ableiten?

Eine Quantifizierung des Problems erwies sich als schwierig: Wie findet man raus, für welche URLs Google die URLs eines anderen Landes „cached“? Das Verhalten war definitiv nicht bei allen URLs von www.aboutyou.de der Fall.

Glücklicherweise haben wir auf unseren einzelnen Länder-Domains einige diskriminierende site-wide Elemente, z.B. die Email Adresse des Kundenservice im Footer. Konkret: kundenservice@aboutyou.at sollte nur auf aboutyou.at auftauchen. Für aboutyou.de müsste es kundenservice@aboutyou.de sein.

Dadurch konnten wir mit dem Query https://www.google.de/search?q=site:aboutyou.de%20%22kundenservice@aboutyou.at%22 zumindest feststellen, dass es sich nicht um einen Einzelfall handelte.

Wie verhalten sich andere Webseiten, die in mehreren Ländern aktiv sind?

Ich muss allerdings zugeben, dass ich solche Suchanfragen nicht häufig durchführe und es könnte auch durchaus legitim sein, dass Google bei einer solchen Anfrage das „site:“ einfach ignoriert. Gerade bei site: Queries kommt es gerne mal zu Nebeneffekten.

Das ist mir damals schon bei Tchibo aufgefallen, weil ich irgendwann mal site:www.tchibo.at gecheckt habe und dafür auch Ergebnisse mit www.tchibo.at URLs bekam – obwohl die Seite schon immer per 301 auf eduscho.at weitergeleitet hat.

Klar, anderes Setup aber ein Beispiel dafür, dass man bei sowas lieber zweimal hinschauen sollte.

Um also sicher zu gehen, dass wir einem „echten“ Problem auf der Spur sind, musste ein Vergleich her. Auch hier bot sich Tchibo an, weil mir die Implementierung geläufig war und ich wusste, dass Hreflang und Canonical Infos korrekt und seit ausreichend langer Zeit implementiert waren. Als Unterscheidungsmerkmal diente in diesem Fall die Bestellhotline, die auf jeder Seite im Footer verlinkt ist:

Nope, keine Ergebnisse. Wir haben noch einige andere Domains getestet, aber das Ergebnis war das gleiche: Auch bei einer site: Abfrage spielt Google nicht den Content einer anderen Domain aus, auch wenn diese via Hreflang „verlinkt“ ist. Scheinbar liegt bei uns also wirklich etwas im Argen.

Warum sollte Google eine „andere“ URL im Cache anzeigen?

Die Antwort auf diese Frage scheint eindeutig: Immer dann, wenn eine „andere“ URL für das Ranking relevant ist, wird diese im Cache von Google angezeigt. Das tchibo.at Beispiel macht das deutlich – ein Blick in den Cache zeigt hier erwartungsgemäß „eduscho.at“.

In diesem Falle scheint es jedoch offensichtlich, da es sich um eine 301 Weiterleitung handelt.

Dennoch war unser Zwischenfazit bisher:

Aus irgendeinem Grund verwendet Google unsere österreichische Domain als Basis für das Ranking im deutschen Index. Das dabei trotzdem weiterhin die deutschen URLs angezeigt werden, ließe sich durch die hreflang Angaben erklären, denn genau das tut Hreflang ja: Google „rankt“ die eine Domain, aber spielt in den SERPs die andere aus, weil sie besser auf das Land passt.

Aber weiter in der Diagnose. Welche Möglichkeiten gibt es sonst noch um URLs zu konsolidieren? Eigentlich nur weitere Weiterleitungen (3xx Status Codes), Canonical Tags, Hreflang Tags oder Alternate Mobile Tags. In einigen Sonderfällen möglicherweise auch noch „identischer“ Inhalt (Google dürfte dann „eigenständig“ ermitteln, welche URL als Canonical gewertet wird).

Oder gar extern: Ein expliziter Seitenumzug angestoßen durch die Search Console. Hat da also jemand…?

Analyse der Daten der Search Console

Die entsprechenden Einstellungen werden unter https://www.google.com/webmasters/tools/change-address?hl=de&siteUrl=https://www.aboutyou.de/ vorgenommen, aber dort zeigte sich nichts Auffälliges:

Zum Vergleich: So würde es aussehen, wenn tatsächlich ein Seitenumzug beantragt worden wäre:

Außerdem muss für Schritt 2 ein 301 Redirect eingerichtet werden – das wäre dann doch aufgefallen 😉 Ein Blick in die Suchanalyse zeigte einen leichten Traffic-Anstieg für AT und CH bei in etwa gleichbleibender Performance für DE. Nichts, was direkt negativ auffällig war.

Auffällig war hingegen der Report zur Internationalen Ausrichtung – vor allem für aboutyou.at.

Insgesamt zwar „interessant“ aber nicht wirklich hilfreich in punkto Problemdiagnose. Unterm Strich also eher enttäuschend, was Google hier an Infos zur Verfügung stellt. Dass die Daten um ein paar Tage zurückhängen macht die Sache leider nicht besser (man beachte das „Status: 06.06.2017“ im „Internationale Ausrichtung“ Report)

Also auf zum nächsten Punkt.

Re-Evaluierung von Tickets aus den letzten Deployments im Shop

In der Woche vor dem Sichtbarkeitseinbruch haben wir zwei Features/Bugfixes deployt, die einen direkten Einfluss auf das Crawling-Verhalten von Google haben:

Ticket: „Googlebot for Smartphones currently not recognized“

Seit März 2016 nutzt Google einen anderen User Agent zum Smartphone Crawling. Da wir eine mobile Subdomain einsetzen (https://m.aboutyou.de/) und Smartphone User beim Aufruf der Desktop-Seite dorthin weiterleiten, sollte Google genauso behandelt werden.

Diese Redirects werden bei uns direkt im Varnish durchgeführt (unser http Cache; mehr dazu). Das ist zwar extrem schnell, aber traditionell ziemlich schwer zu testen. Zusätzlich werden dort ebenfalls unsere Geo-Redirects ausgesteuert – könnte es sein, dass dabei etwas schiefgelaufen ist und Google beim Aufruf der deutschen Seite zu einem anderen Land weitergeleitet wird?
Da wir bei unseren Tickets versuchen, die Nachkontrolle so effizient wie möglich zu gestalten, hat sich für solche Checks bash scripting in Kombination mit curl bewährt, weil es genügend Flexibilität bei überschaubarem Aufwand und einfacher Teilbarkeit gewährleistet. Das folgende Script war also bereits als Kommentar hinterlegt:

In anderen Worten: Rufe die Startseiten von unseren Länder Domains mit unterschiedlichen User-Agents auf, folge etwaigen Weiterleitungen und gib die URLs inklusive Status Codes dazu aus.

Der Output war wie erwartet:

Nur der mobile Crawler wird beim Aufruf der Desktopseite auf die mobile Variante weitergeleitet, der normale Googlebot bekommt aber in jedem Fall einen 200 Status Code.

Zwar hätten wir zur vollständigen Sicherheit noch einen Proxy aus den USA nutzen müssen, aber die Redirects schienen wie geplant zu funktionieren. Als normaler Nutzer (ohne Googlebot User-Agent) wäre ich z.B. beim Aufruf von www.aboutyou.at defaultmäßig auf www.aboutyou.de weitergeleitet worden.

Das schien also nicht das Problem zu sein.

Ticket: „Homepage Go-Live“

Auf der „code.talks commerce special 2017“ hat unser CTO Sebastian Betz mehr oder weniger in einem Nebensatz fallen lassen, dass wir unser Shop Frontend gerade auf einen komplett neuen, React-basierten Stack umstellen. Mittelfristig wird der Shop dann zu einer Single Page Application, mit all den Herausforderungen, die das an das SEO stellt.

Da das technologisch ein ziemlich heftiges Brett ist, ziehen wir sukzessive einzelne Bereiche der Seite um und sind mit unserer Startseite gestartet. Daran sind bei uns (jeweils für DE, AT und CH) konkret folgende URLs geknüpft:

  • https://www.aboutyou.de/
  • https://www.aboutyou.de/frauen
  • https://www.aboutyou.de/maenner

Nun sollte man an dieser Stelle noch erwähnen, dass die Seiten serverseitig via NodeJS pre-rendered werden und hier einfach mal fundamental andere Paradigmen gelten als bei PHP basierten Applikationen (Single Request Lifecycle vs. non-blocking Event Loop). Hier gibt es also so richtig viel Potenzial für nicht offensichtliche Probleme.

Nichtsdestotrotz sind die URLs im neuen Stack durch die übliche QA gelaufen (inklusive Canonical und Hreflang Check) und waren in allen Kriterien fehlerfrei. Naja, meistens…

Die Sache mit der Konsistenz

Wie sich später herausstellte hatten wir bei dem initialen Deployment mit sog. Race Conditions zu kämpfen. Race Conditions sind in der Informatik fehlerhafte Zustände, die durch parallele Prozesse zu Stande kommen. Oder anders: Wenn zwei Personen gleichzeitig am gleichen Dokument arbeiten, dann kann es schonmal passieren, dass die erste Person etwas speichert, was die zweite Person überschreibt. Und Person eins ist dann ziemlich perplex, weil ihre Arbeit futsch ist.

Das Blöde an dieser Art von Problemen ist, dass sie nur unter bestimmten Umständen auftreten und sich dadurch extrem schwer reproduzieren und beheben lassen.

Dem Problem auf der Spur

Glücklicherweise haben wir bereits vor einiger Zeit intern begonnen, ein umfassendes, automatisiertes Testing Tool zu entwickeln. Dabei werden fest definierte URLs regelmäßig (damals 24, aktuell ca. 150 Mal pro Tag) gecrawlt, archiviert und auf diverse Faktoren geprüft. Darunter unter anderem Status Codes, Canonical Tags und Hreflang Infos.

Kurz nach dem Deployment des obigen Tickets gab es sporadische Alerts, dass einige Checks fehlschlugen – allerdings auf absurde Art und Weise. So wurde zum Beispiel berichtet, dass der Canonical Tag von https://www.aboutyou.de/ auf https://www.aboutyou.at/ zeigen sollte.

Da zu jedem Check die komplette Response (inklusive Header und Body) gespeichert wird, konnten wir aber sicher sagen, dass der Fehler zum Zeitpunkt des Crawlens tatsächlich vorhanden war. Diese spezifischen Fehler traten wohlgemerkt nur auf den drei URLs (pro Land) auf, die vom neuen Stack betroffen waren.

Der oben beschriebene Fall ist zwar nicht zwingend das, was auch Google beim Crawlen gesehen hat. Es zeigt aber, dass die Ausspielung der Canonicals inkonsistent war, denn diese Fehler traten zwar mehrfach aber eben nur sporadisch auf.

Dieses Problem war uns beim Auftritt des Sichtbarkeitseinbruchs bereits bekannt. Allerdings war die Prio des Bug Tickets als „niedrig“ eingestuft, denn eigentlich war die „Angriffsfläche“ massiv eingeschränkt – schließlich handelte es sich um lediglich drei URLs pro Domain und die sollten wohl keinesfalls für einen 30%igen Verlust der Sichtbarkeit verantwortlich sein (zumal sich das ja auch in Sistrix entsprechend gezeigt hätte).

Dennoch war es die „heißeste“ Spur, die wir hatten und auf Grund der zuvor ermittelten Anomalien (österreichischer Cache bei deutscher URL) sind wir uns relativ sicher, dass es sich ungefähr so zugetragen haben muss:

Unsere deutsche Startseite war auf Grund der Race Conditions sporadisch der Meinung, dass sie eigentlich die österreichische Startseite ist. Und das hat sie auch kundgetan – zum Beispiel über den Canonical Tag. Google hat aber vermutlich keine Entscheidung auf URL Basis getroffen, sondern einfach angenommen, dass wir global alles von www.aboutyou.de auf www.aboutyou.at ziehen wollen statt „nur“ die Startseite und daraufhin angefangen weitere URLs „um zu ranken“.

Da /frauen und /maenner ebenfalls betroffen waren, wurden die Unterseiten zu diesen Verzeichnissen entsprechend schneller neu bewertet und schlagen sich heftiger in der Sichtbarkeit nieder (Achtung, dieser Part ist nun wirklich ziemlich spekulativ).

„Lösung“ und Status Quo

Nachdem die Wurzel des Problems identifiziert schien, haben wir möglichst schnell einen Hotfix am Freitag (09.06.2017) deployt, der endlich wieder ein „sauberes“ und vor allem konsistentes Canonical Setup garantierte.

Zusätzlich haben wir die Startseiten aller Länder via Search Console submitted um Google möglichst schnell unseren Fix mitzuteilen. Und dann… begann das Warten. Letztendlich hatten wir keinerlei Garantie, dass das a) das Ursprungsproblem war und wir b) mit dem Fix alles Notwendige getan hatten. Da der Sichtbarkeitsverlust in Etappen von Statten ging war davon auszugehen, dass eine etwaige Recovery ebenfalls nicht von heute auf morgen zu sehen wäre.

Am Freitagabend konnte ich zumindest für Keywords wie „Damenmode online“ (/frauen) und „Herrenmode online“ (/maenner) wieder Rankings feststellen. Es sah also gut aus. Um ganz sicher zu gehen versuchte ich zusätzlich eine „offizielle“ Aussage von Google zu bekommen:

Was zwar nicht funktionierte, aber immerhin andere SEOs auf das Problem aufmerksam machte. An dieser Stelle nochmal danke an @BastianGrimm, der einige Details eines ähnlichen Falls mit mir teilte. Hier scheint also tatsächlich Google nicht ganz unschuldig zu sein. Eine entsprechende Bestätigung wäre also immer noch höchst willkommen 😉 Eine inoffizielle Bestätigung, dass sich die noch betroffenen Unterseiten beim nächsten Crawlen wieder erholen haben wir inzwischen erhalten.

Zum Glück bestätigte uns auch die Sichtbarkeitsentwicklung:

Als ungewollten, aber durchaus positiven Nebeneffekt konnten wir übrigens zusätzlich massive Verbesserungen in AT und CH feststellen. Wird vermutlich nicht auf dem Niveau bleiben, aber schaut nicht schlecht aus.

Fazit

Unter Strich bleibt die Frage: Was ist „tatsächlich“ passiert und wie können wir es in Zukunft vermeiden?

Als tl;dr würde ich es wie folgt formulieren:

Durch einen Fehler bei der Umstellung auf einen neuen Technologie-Stack haben wir temporäre Inkonsistenzen bei der Ausspielung unserer Canonical Informationen für die Startseite an Google übermittelt. Das hat ausgereicht, damit Google unsere gesamte deutsche Domain mit der österreichischen konsolidiert und nur letztere zur Ermittlung des Rankings verwendet (auch im deutschen Index).

Durch die Behebung des Bugs auf unserer Seite sowie das zeitnahe Übermitteln über die Search Console erholen sich die dadurch verlorenen Rankings kontinuierlich wieder.

Da wir keine definitive Aussage von Google bekommen werden und ich nicht den Anspruch erhebe, sämtliche Faktoren eingeschlossen zu haben, habe ich die Meinung/Erfahrung einiger weiterer Kollegen* eingeholt. Daraus ergaben sich ergänzend weitere mögliche Faktoren:

  • In mindestens zwei weiteren Fällen gab es ein ähnliches Problem bei der Umstellung von http auf https (Google „rankt“ auf einmal die https Variante statt der http Variante). In einem Fall waren keine/nur teilweise Canonicals gesetzt und im anderen wurden relative (statt absolute) verwendet. Grundproblem aber auch hier: „Plötzlich“ site-wide Anpassung des Rankings.
  • Identischer Content scheint ein Problem zu sein, selbst wenn Canonical und Hreflang korrekt implementiert sind. Das kann bei uns auch ein Faktor gewesen sein, weil wir zum Teil die gleichen Inhalte verwenden. Vermutung geht hier dahin, dass es einen „Threshold“ für die Kombination verschiedener Signale gibt (gleicher Content, Hreflang, Canonical, …) und bei Google dann irgendwann ein Schalter kippt.
  • In einem weiteren Fall wurde einer der stärksten Backlinks (site-wide, starke Authority) von .com auf .at geändert. Also die linkgebende Seite hat sich geändert, nicht das Linkziel. Kurz darauf sind die Rankings in DE eingebrochen und in AT gestiegen.

*Dank geht an:

Wie können wir so etwas in Zukunft verhindern?

Den wichtigsten Schritt haben wir bereits mit Einführung unseres Monitoring Tools gemacht. In der aktuellen Entwicklungsphase von About You (neue Technologien, viele Deployments, starke Skalierung) können wir uns nicht mehr auf „manuelle“ Prüfungen verlassen. Es gibt inzwischen einfach zu viele Faktoren, die Fehler nur unter bestimmen Situationen entstehen lassen (Race Conditions, Caching Probleme, mehrere Application Server mit unterschiedlichen Code Ständen).

Tests müssen deshalb regelmäßig und automatisch laufen, auf allen Systemen (von Integration bis Production) um etwaige Bugs frühzeitig erkennen und beheben zu können. Diese Erkenntnis konnte ich 1-zu-1 aus der Software-Entwicklung übertragen, wo ich mit dieser Philosophie sehr gute Erfahrungen gemacht habe.

Zusätzlich werden wir sämtliche Bugs die in Richtung inkorrekte Canonicals gehen radikal hoch-priorisieren. Dieses Problem hat gezeigt, dass selbst vermeintlich klar abgrenzbare Probleme („es waren nur drei URLs betroffen“) unerwartete Ausmaße annehmen können. Leider sind wir hier immer noch in einer Abhängigkeit von Google die uns im Zweifel keinen Fehler erlaubt.

Wir haben während der Analyse noch ein paar weitere Erkenntnisse gewinnen können, die für diesen Artikel nicht unbedingt relevant sind, aber Webmastern mit ähnlichen Problemen eventuell weiterhelfen können (z.B. Delays beim Refresh des Google Caches). Also gerne kommentieren oder direkt an mich wenden (Xing, LinkedIn, Twitter).

Shameless Plug zum Schluss: Gleiches gilt übrigens, wenn ihr das nächste Mal hautnah dabei sein möchtet. Oder in anderen Worten: Analytisch denkende, zahlengetriebene und vor allem lernfreudige, hochmotivierte SEOs sind immer gerne gesehen.

4. Juli 2017, 11:19

Hi Pascal,

danke für die Insights. Euer Monitoring Tool ist ziemlich cool. Das ist wahrscheinlich nicht Open Source, oder?

LG Tom

4. Juli 2017, 13:11

Hallo Pascal,

auch von mir ein Dankeschön für den ausführlichen Einblick in eure Arbeit – wirklich sehr spannend zu sehen, wie bei den „großen“ gearbeitet wird 🙂

Mich würde es auch interessieren, was für ein Monitoring Tool ihr einsetzt?

Liebe Grüße
Isabel

4. Juli 2017, 14:16

Hey Tom, Isabel,

wir entwickeln das Tool inhouse (von daher ja, closed source) und prüfen inzwischen ca. 10.000 Kriterien auf ca. 1000 URLs alle 10 Minuten (insgesamt; aufgeteilt auf 4 Länder).

Auf dem nächsten SEO Meetup in Hamburg stelle ich das Tool vor, https://www.meetup.com/de-DE/SEO-HH/events/240959583/ – also falls ihr vor Ort seid gerne vorbei schauen 😉

Viele Grüße
Pascal

Konstantin
4. Juli 2017, 16:36

Sehr spannend, vielen Dank für die Einblicke! Ich wünschte wir hätten auch so ein Monitoring wie ihr im Einsatz, spätestens jetzt hat es sich ja definitiv bezahlt gemacht. Auch finde ich es super, dass ihr so offen kommuniziert, bei uns darf leider absolut nichts nach außen dringen, was die Arbeit nicht unbedingt erleichtert.

Kleiner Hinweis: Dass ihr ziemliche viele tote Subdomains und externe Links auf 403er 404rer habt ist bekannt? dein.aboutyou.de wäre hier eines von mind. 18 Beispielen.

4. Juli 2017, 16:48

Das liest sich vor allem wie ein ziemlich vergurkter Entwicklungsprozess.

4. Juli 2017, 17:31

Hi Pascal, schöner Einblick in das Canonical Problem. Das Verhalten von Google kann man schon verstehen, denn ein Canonical der Startseite hat viel Gewicht. Bei der Entwicklung auf der .de & .ch Domain könnte man glatt vor Weihnachten versuchen, dieses Verhalten zu reproduzieren 😉 Gruß Martin

4. Juli 2017, 18:12

@Konstantin: Jain, ist so halb auf dem Schirm. Wir hatten früher mal ein Open Commerce System, da gibt es Subdomain-mäßig noch einige Altlasten. Aber das ganze Backlink Thema ziehen wir als Nächstes glatt, Stichwort curbl (Insiders will know ;))

@Norbert: Nah. Fehler passieren, vollkommen normal. Und es gibt einfach gewisse Problemklassen, die sind präventiv schwer zu erkennen. Aber ich bin auch eher für „Fail Fast, Fail Often“, weil du dann deine Prozesse darauf auslegst, dass jederzeit alles schiefgehen kann. Aus der Erkenntnis ist letztendlich auch Kubernetes entstanden ¯\_(ツ)_/¯

Jens
4. Juli 2017, 22:27

Hallo Pascal,
Danke für deine umfassende Analyse die du mit uns teilst. Du erwähntst am Ende Delays beim Refresh des Google Caches – hatte ich neulich bei einer externen Seite. Eine egtl gelöschte Page hatte statt einem 404 weiterhin eine 200 übergeben. Das scheint in vielen cms so zu sein. Google hat das Ergebnis noch für Wochen dringehabt, und wir konnten nicht ran da Fremdseite. Vg Jens

5. Juli 2017, 08:29

Respekt! Endlich mal ein detaillierter Einblick in die Arbeit eines „Leidensgenossen“. 😉

SEO ist nämlich nicht immer nur Link-Geschummle und Content-Anbiederung an die Google-Krake, sondern auch spannende Recherchearbeit … irgendwas zwischen Sherlock Holmes und MacGyver.

Grüße,
Torsten

5. Juli 2017, 14:57

Hallo Pascal,
ich habe ein sehr ähnliches Problem allerdings OHNE den problematischen Einsatz von länderspezifischen Canonicals und die dadurch verursachten Interpretationen von Google aktuell bei meiner Webseite.

Anscheinend interpretiert Google die Startseite eine meiner Domains zu einer anderen Domain zugehörig. Beide Domains sind .de, sind aber recht ähnlich aufgebaut.

Es gibt Verlinkungen untereinander auf diesen beiden Domains, diese sind aber alle Nofollow. Diese sorgen bei Google aber trotzdem offensichtlich zu Verwirrungen und ordnen Backlinks, die EINDEUTIG auf Domain A leiten nur der Domain B zu.
Es gibt definitiv keine 301er oder falsche Canonicals.

Hört sich doch ähnlich an, oder? Google interpretiert einzelne Signale wohl so, dass weitere Verbindungen vorausgesetzt werden und entsprechende Effekte sich auswirken.
Ist bestimmt keine Absicht und verursacht auf jeden Fall Verwirrungen bei uns und macht die SEO-Steuerung fast unmöglich.

Dadurch kann ich z.B. auf Domain A soviele Backlinks wie ich will erhalten, diese werden aber immer nur Domain B zugeordnet. (lt. Search Console und Google Cache der betreffenden Startseite)

Hast Du dazu eine Idee?

Beste Grüße
Markus

5. Juli 2017, 15:11

Hey Pascal,

wir hatten ja schon das Vergnügen, da sich bei uns ähnliches abgespielt hatte – zumindest was den Drop und die .at-URLs für .de im Cache angeht.

Mein Frage: Seht ihr seit dem Fix einen beständigen Rückgang der Seiten, welche mit der österreichischen Variante für die deutsche URL im Cache liegen? Aktuell sehe ich mit https://www.google.de/search?q=site:aboutyou.de%20%22kundenservice@aboutyou.at%22 insgesamt 2.650 Treffer – dein Screenshot zeigt 3.280 Treffer an – es ist also ein Rückgang zu verzeichnen.

Denkst du das tendiert irgendwann gegen Null? Und besteht nicht doch noch die Gefahr, dass Google zumindest für diese 2.650 Seiten wieder versucht die falsche Version zu ranken (oder dies sogar aktuell schon/noch tut)?

Danke für Deine Einschätzung und die tollen Insights,

Marc

5. Juli 2017, 15:42

@Markus Das müsste man sich im Detail anschauen. Meine erste Idee wäre „identischer“ Content – aber wie gesagt, da müsste man tiefer einsteigen.

@Marc Die „Rankings“ waren innerhalb weniger Tage wieder da, das ging also sehr schnell. Das Problem scheint aber noch nicht vollständig gelöst zu sein, denn es gibt immer noch Seiten, die zwar ein aktuelles Cache-Datum bei Google haben, aber immer noch den gleichen Fehler aufweisen.

Wir kennen noch einen weiteren Bug bei uns (der aber schon „immer“ existiert), bei dem
wir gewisse Produkte/Kategorien/etc. unter bestimmten Umständen manchmal temporär auf noindex setzen (hat was mit unserem http caching und der Behandlung von Tracking Parametern zu tun; steht ganz oben auf der PrioListe ;)). Das im Artikel beschriebene Verhalten (DE rankt, AT liegt aber im Cache) tritt auch dann auf, wenn die deutsche Seite auf noindex steht, aber die AT indexiert werden darf und via hreflang auf DE verweist. Beispiel (in dem Fall dauerhaft noindex):
https://www.aboutyou.de/frauen/sport/sportarten/snowboard (noindex)
https://webcache.googleusercontent.com/search?q=cache:https://www.aboutyou.de/frauen/sport/sportarten/snowboard (zeigt auf .at)

Das wäre einer der nächsten Ansatzpunkte. Zusätzlich glaube ich, dass das Thema „kompletter Duplicate Content“ auch einen Einfluss haben kann. das müssen wir aber genauer untersuchen.

Viele Grüße
Pascal

5. Juli 2017, 21:42

Hey,
vielen Dank für die Veröffentlichung dieser tollen Analyse. Echt spannend. Hätte nie gedacht, dass Google einem in diesem Fall einfach mal die Entscheidung abnehmen will. Einfach mal alles auf AT ändern. Nicht so schlau von Google eigentlich.
Wenn du dazu eine Meldung von Google bekommst würde ich mich freuen wenns du den Artikel noch mit den Infos anreichert.
Viele Grüße
Sascha

6. Juli 2017, 02:01

Hallo Pascal,
gerne kann ich Dir weitere Infos zukommen lassen und wir können eventuelle Parallelen in unseren Fällen finden.
Sende mir gerne eine Email unter ms@jobbörse.de, dann schicke ich Dir weitere Details.

Beste Grüße
Markus

Patrick
6. Juli 2017, 09:46

Hallo Pascal,

danke für den wirklich sehr guten Artikel. Was mir besonders gefallen hat, ist deine Beschreibung der Problemsuche. Die einzelnen Schritte bieten mehr Ansatzpunkte für eigene Problemfindungen, als nur zu schreiben: Wir hatten das Problem und haben es gelöst, BAM.

Zu der Thematik selbst:

Wir selbst haben im kleineren Rahmen ein ähnliches Problem für unsere AT-Domain (in Wechselwirkung mit der DE-Domain). Hier gibt in den AT-SERPs einige Pages, die zwar die richtige AT-Page ausspielen, aber Page Title und auch Cache verweisen auf die DE-Version: https://www.google.at/search?q=site:contorion.at+intitle:contorion.de&cad=h

Im canonical Tag und hreflang haben wir keinen Fehler gefunden. Ich habe auch vor einiger Zeit die betroffenen Seiten in GSC gepushed mit der Vermutung, dass diese AT-Pages einfach sehr selten gecrawlt werden. Hat aber nicht wirklich gefruchtet.

Ich hatte es schon einigen SEOs gezeigt, vielleicht findet ihr etwas?

6. Juli 2017, 18:20

Hey Pascal,

du schreibst:
„[…] und prüfen inzwischen ca. 10.000 Kriterien auf ca. 1000 URLs alle 10 Minuten [..]“

geht das nicht ziemlich zu Lasten der Server? Oder ist das ganze so performant?

Beste Grüße
Christian

7. Juli 2017, 13:26

@Patrick Crawling-Verhalten würde ich immer direkt aus den Logfiles parsen. Das wäre auf jeden Fall das erste, was ihr checken solltet. Wenn ihr exemplarische URLs habt, dann würde ich hier tatsächlich mal versuchen, den Content der unterschiedlichen Länder-URLs so „stark“ zu individualisieren, dass sie als „eigenständige“ Seiten durchgehen. Wenn ihr daraus nen kausalen Zusammenhang ableiten könnt, dann könnte man das im Nachgang auch systemisch sicherstellen uns skalieren.

@Christian momentan noch kein Problem, wobei Skalierung noch ein Thema werden wird. Aktuell ist es aber hardware-technisch relativ kostengünstig, weil wir unsere Anforderungen selbst definieren. Sprich: Ich brauch zB keine Historie aller Daten, keine Backups, keine Hochverfügbarkeit etc.

Werden wir sukzessive nachziehen, aber für äquivalente Hardware würdest du für den aktuellen Stand bei Digital Ocean so zwischen 100 und 200 Euro zahlen.

Viele Grüße
Pascal

Patrick
7. Juli 2017, 16:16

@Pascal:

Danke für den Hinweis und auch die Antwort. Ich habe mal 2-3 dieser URLs gecheckt. Google crawlt die original AT-Domain URLs eigentlich recht regelmäßig. Daher irritiert mich dieser Cache-Eintrag: https://webcache.googleusercontent.com/search?q=cache:78S1x6sm–8J:https://www.contorion.at/handwerkzeug/schraubenschluessel-ratschen/stecknuss-steckschluesseleinsatz/universalstecknuss/c-cpwn%3Fvct%3Dcp_cat_cpwn+&cd=2&hl=de&ct=clnk&gl=at.

Wir werden uns nun testweise der Contentseite widmen. Es ist kein sehr großes Problem, aber ein irritierendes. Bisher konnte noch keiner eine technische Ursache finden.

Ich hoffe du schreibst auch weiterhin für Sistrix Artikel 🙂

10. Juli 2017, 14:16

Hallo Pascal,

auch von mir ein Dankeschön für den ausführlichen Einblick in eure Arbeit – wirklich sehr spannend zu sehen, wie bei den „großen“ gearbeitet wird 🙂

Mich würde es auch interessieren, was für ein Monitoring Tool ihr einsetzt?

Liebe Grüße
John

11. Juli 2017, 09:58

Hi Pascal,
danke für die detaillierten Insights! Wir hatten auch schon einige ähnliche Fälle. Gerade die Vermischung von (korrekten) hreflangs im Cache stelle ich immer häufiger fest. Ob das tatsächlich noch ein Indikator für den Fehler ist, da bin ich mir inzwischen nicht mehr sicher. In allen drei näher untersuchten Fällen gab es allerdings auch Probleme hinsichtlich Inkonsistenz – Vermischungen auf URI-Ebene oder Probleme in Sachen Rendering. Lass uns da gern mal austauschen!
Viele Grüße
Felix

Eugen
12. Juli 2017, 11:11

Ist zwar interessant, sieht aber danach aus, dass die ganzen Onepager / React Spielchen sich als unendliche Arbeitsbeschaffungsmaßnahmen erweisen. Es kann doch niemand im Ernst behaupten, dass die Anzahl der Millisekunden, die beim Rendering von Onepager EVENTUELL IRGENDWANN gewonnen wird, wirklich die ganzen SEO-Knieschüsse wiedergutmacht. Und ja, auch ein PHP-Shop lässt sich in jeder Größe blitzschnell laden – es kommt, wie immer, auf die Qualifikation der Programmierer und des Architekten an.

Florian
21. Juli 2017, 10:18

Verständnisfrage zu folgendem Abschnitt:

„Vorab sollte man noch erwähnen, dass wir sowohl Canonical als auch Hreflang auf den Kategorieseiten korrekt implementiert haben. D.h. die deutsche URL zeigt per Canonical auf sich selbst und via de-AT Hreflang auf die canonical Variante in AT (vice versa auf der AT URL). Hier haben wir eine sehr hohe Gewissheit, dass das auch über die gesamte Zeit hinweg der Fall war.“

Also aus meiner Sicht liegt eher hier das Problem. Die DE-Seite behauptet zwar per Canonical „Ich bin das Original“ verweist dann aber per Hreflang auf die AT Version, welche auch wiederum per Canonical sagt „Ich bin das Original“.
Die deutsche Seite ist also nicht auf sich selbst referenziert, sondern gibt sämtliche Hreflang-Signale an die AT-Variante weiter und umgekehrt.
Würde mich als Google auch verwirren. Welche Seite soll ich denn jetzt für welchen Index ausgeben? Oder verstehe ich da was falsch?

Grüße
Florian