Yandex crawlte meinen Blog ohne /en. 308-Redirects verhinderten 404-Fehler

Ich rollte ein Sitemap-Update mit ungefähr 3.000 neuen Seiten unter /en/blog/... aus. Kurz danach fiel mir in Yandex Webmaster ein unerwartetes Muster auf: Yandex versuchte, die entsprechenden Pfade unter /blog/... zu crawlen – also ohne den Präfix /en.

Hätten diese URLs einfach 404 geliefert, hätten potenziell Tausende unnötiger Crawl-Aufrufe auf nicht vorhandenen Pfaden landen können. Zum Glück hatte ich bereits permanente 308-Redirects von den Pfaden ohne Sprachpräfix auf die tatsächlichen englischen URLs eingerichtet.

Diese kleine defensive Routing-Schicht war am Ende deutlich wertvoller, als ich erwartet hatte.

Was ich tatsächlich beobachtet habe

Die bestätigte Abfolge war einfach:

1. Ich veröffentlichte ein Sitemap-Update mit ungefähr 3.000 neuen Seiten im Schema /en/blog/....
2. Danach zeigte Yandex Webmaster, dass Yandex entsprechende /blog/...-URLs zu crawlen versuchte.
3. Für diese alternativen Pfade existierten bereits 308-Redirects.
4. Statt auf einer 404-Seite zu enden, wurden die Requests an die vorgesehenen /en/blog/...-URLs weitergeleitet.

Einen Punkt aus meiner ursprünglichen Beschreibung muss ich präzisieren: Ich kann nicht beweisen, dass Yandex „die Sitemap falsch geparst“ hat. Ich habe die unerwarteten Crawl-Pfade nach dem Sitemap-Update beobachtet, aber diese zeitliche Nähe beweist nicht die interne Ursache. Suchmaschinen können URLs aus verschiedenen Signalen und historischen Quellen kennen. Ohne weitere Belege ist die korrekte Aussage deshalb nur: Yandex crawlte Pfade, die ich nicht erwartet hatte.

Diese Unterscheidung ist wichtig. Ein ungewöhnlicher URL-Request eines Crawlers ist eine Beobachtung. Die genaue Erklärung, warum dieser URL gewählt wurde, ist eine eigene Behauptung.

Warum die 308-Redirects geholfen haben

Meine Redirect-Logik behandelte den kürzeren Pfad praktisch als permanente Alternative zur lokalisierten URL:

/blog/example-post  -> 308 ->  /en/blog/example-post

Dadurch erreichte ein Crawler trotz unerwartetem Einstieg die Seite, die ich tatsächlich ausliefern wollte.

308 Permanent Redirect ist ein permanenter HTTP-Redirect, der Request-Methode und Body beibehält. Bei normalen GET-Anfragen eines Crawlers ist diese Methodenerhaltung meist nicht der entscheidende Punkt; in meinem Fall war vor allem relevant, dass der Redirect ausdrücklich permanent ist. Die aktuelle Dokumentation von Yandex Webmaster klassifiziert sowohl 301 als auch 308 als permanente Redirects.

Offizielle Yandex-Webmaster-Dokumentation zu Redirects.

Das bedeutet nicht, dass 308 für SEO grundsätzlich besser als 301 wäre. Ich hatte 308 bereits im Einsatz, und sie erfüllten genau die Aufgabe, die ich brauchte: Ein unbeabsichtigter URL wurde nicht zur Sackgasse.

Ein Redirect ist ein Sicherheitsnetz, kein Sitemap-Fix

Die Redirects begrenzten die Folgen, machten das unerwartete Crawling aber nicht wünschenswert. Jeder unnötige Redirect ist ein zusätzlicher Request und ein zusätzlicher Hop. Zu breite Regeln können außerdem Fehler in der URL-Generierung verdecken, wenn man nicht mehr nach der Quelle der falschen URLs sucht.

Wenn eine Sitemap selbst veraltete oder redirectende URLs enthält, sollte man die Sitemap korrigieren und die endgültigen URLs eintragen. Redirects sollten alte, alternative oder versehentlich entdeckte Pfade auffangen – nicht unsaubere URL-Daten rechtfertigen.

In meinem Fall enthielt die Sitemap bereits /en/blog/.... Die Redirects machten die Site lediglich robuster, falls ein Crawler über /blog/... kam.

Was ich nach so einem Vorfall heute prüfen würde

1. Die tatsächlich ausgelieferte Sitemap öffnen. Nicht nur dem Generator vertrauen, sondern die deployte Datei und mehrere echte URLs prüfen.
2. Endantworten testen. URLs, die indexiert werden sollen, sollten möglichst direkt auf der vorgesehenen Seite landen und nicht durch vermeidbare Redirect-Ketten laufen.
3. Vorhersehbare Alternativpfade testen. Wenn ein alter oder präfixloser URL ein permanentes Ziel hat, sollte die Zuordnung eindeutig und 1:1 sein.
4. Redirect-Ketten vermeiden. A -> B -> C ist schwieriger zu kontrollieren als A -> C.
5. Crawler-Berichte wenn möglich mit serverseitigen Daten abgleichen. Webmaster-Tools sind hilfreich, zeigen aber nicht immer, wo ein URL ursprünglich entdeckt wurde.
6. Aus Crawling allein keine Ranking-Schlüsse ziehen. Crawling, Indexierung, Ranking und Traffic sind unterschiedliche Stufen.

Ein minimaler Test kann so aussehen:

curl -I https://example.com/blog/example-post

HTTP/2 308
location: https://example.com/en/blog/example-post

Das Beispiel ist nur illustrativ. Entscheidend ist, Statuscode und Ziel tatsächlich zu prüfen, statt davon auszugehen, dass die Routing-Regel funktioniert.

Was ich daraus ableiten kann – und was nicht

Ich kann bestätigen, dass die bereits eingerichteten 308-Redirects verhinderten, dass die unerwarteten /blog/...-Requests in 404-Fehlern endeten, und sie auf die vorgesehenen URLs weiterleiteten.

Ich kann nicht bestätigen, dass der Sitemap-Parser von Yandex die Ursache war. Ebenso habe ich keinen Ranking-Gewinn, keinen Indexierungsgewinn und keine konkrete Menge an „gerettetem“ Traffic gemessen. Solche Aussagen wären stärker als meine Daten.

Meine eigentliche Lektion ist enger und nützlicher: Eine URL-Architektur sollte vorhersehbare Fehler an ihren Grenzen abfangen können. Eine saubere Sitemap bleibt die erste Verteidigungslinie. Eine präzise permanente Redirect-Schicht ist die zweite.

Wenn beides vorhanden ist, wird aus einem unerwarteten Crawl-Pfad deutlich seltener eine große Menge toter URLs.