Ich kaufte eine Domain, die erstmals im Jahr 2000 registriert worden war. Auf dem Papier wirkte diese Geschichte eher wie ein Vorteil. Nach dem Launch der neuen Website füllten sich die Server-Logs jedoch mit Requests auf Seiten, die ich nie angelegt hatte.
Mehr als 1.000 Requests pro Tag trafen URLs, die im neuen Projekt gar nicht existierten. In der Analytics-Auswertung erschien das als großer Ausschlag beim Direct Traffic mit fast keiner Interaktion. Gleichzeitig besuchte der Yandex-Crawler alte Pfade erneut, erhielt 404 Not Found, und Yandex Webmaster sammelte innerhalb einer Nacht mehr als 900 Fehler.
Meine erste Erklärung war einfach: Alte Bots rufen tote URLs auf, Yandex sieht diese Aktivität und crawlt sie deshalb weiter. So sah die Reihenfolge aus meiner Perspektive aus. Beweisen konnte ich diese Kausalität mit meinen Daten aber nicht.
Was ich tatsächlich bestätigen konnte
Es gab drei getrennte Beobachtungen. Erstens erhielt der Server viele Requests auf URLs aus dem früheren Leben der Domain. Zweitens führte dieser Traffic praktisch zu keiner sinnvollen Nutzerinteraktion. Drittens rief auch der Yandex-Crawler alte Pfade auf, und im Webmaster-Dashboard erschienen innerhalb einer Nacht mehr als 900 Fehler.
Operativ war das relevant: laute Logs, unnötige Requests und ein Fehlerreport, den ich aufräumen musste. Diese Fakten beweisen aber nicht, dass Drittanbieter-Bots den Yandex-Crawler ausgelöst haben oder dass die Fehler Rankings oder organischen Traffic direkt verschlechtert haben. Crawling ist nicht Indexierung, Indexierung ist nicht Ranking, und ein Fehlerbericht ist kein Beweis für eine Abstrafung.
Was ich bei 404 und 410 zu stark vereinfacht hatte
Früher dachte ich ungefähr so: 404 heißt „gerade nicht da“, 410 heißt „dauerhaft weg“. Als Eselsbrücke funktioniert das, technisch ist es aber nicht exakt.
404 Not Found bedeutet, dass der Server keine aktuelle Repräsentation der angeforderten Ressource liefern kann. Der Status sagt für sich allein nicht, ob dieser Zustand vorübergehend oder dauerhaft ist. 410 Gone ist spezifischer und passt, wenn der Server weiß, dass die Ressource nicht mehr verfügbar ist und dieser Zustand dauerhaft sein soll.
Auch für SEO ist diese Präzision wichtig. Suchmaschinen können URLs sowohl nach 404 als auch nach 410 aus dem Suchbestand entfernen. Deshalb beschreibe ich 410 heute nicht mehr als einen magisch „stärkeren SEO-Status“ und behaupte auch nicht, dass 404 für gelöschte Seiten grundsätzlich falsch wäre.
Warum gezielte 410-Antworten in meinem Fall trotzdem sinnvoll waren
Die alten Pfade waren keine vorübergehende Störung. Sie gehörten zu Inhalten aus der früheren Geschichte der Domain und hatten im neuen Projekt keinen Platz. Für diese konkreten URLs wusste ich, dass sie dauerhaft verschwunden waren. Damit beschrieb 410 Gone ihren Zustand präzise.
Ich konfigurierte deshalb gezielte 410-Antworten für bekannte Legacy-Pfade, statt jede unbekannte URL pauschal als 410 zu behandeln. Nach dieser Änderung gingen das Crawl- und Reporting-Rauschen rund um die alten Pfade zurück, und die Situation in den Webmaster-Tools wurde deutlich sauberer.
Bei der Kausalität bleibe ich vorsichtig. Ich kann sagen, dass die Verbesserung auf die gezielte 410-Umstellung folgte und dass der Status semantisch korrekt war. Ich kann nicht beweisen, dass 410 allein jeden Bot gestoppt hat. Ein beliebiger Drittanbieter-Bot kann einen HTTP-Status ignorieren und dieselbe URL weiterhin endlos anfragen.
Die Entscheidungsregel, die ich heute benutze
Die nützliche Frage lautet nicht „Ist 410 besser als 404?“, sondern „Was ist mit dieser URL tatsächlich passiert?“
- Es gibt einen klaren Ersatz: eine permanente Weiterleitung wie
301auf die wirklich entsprechende neue URL. - Die alte Ressource ist nachweislich dauerhaft entfernt und hat keinen Ersatz:
410 Goneist eine präzise Wahl. - Die URL ist nur unbekannt, falsch geschrieben oder hat nie existiert: ein normales
404 Not Foundist passend.
Was ich vermeiden würde: jede tote URL nur zum Verschwinden der Fehler auf die Startseite umzuleiten. Das verschleiert den tatsächlichen Zustand der Ressource und kann für Nutzer und Crawler schlechter sein.
Wie ich eine alte Domain heute vor dem Launch prüfen würde
Wenn ich erneut eine Domain mit Vorgeschichte nutze, behandle ich ihre URL-Historie als Teil einer Migration, selbst wenn ich die alte Website gar nicht migriere.
- Den alten URL-Footprint untersuchen. Historische URLs und offensichtliche Legacy-Bereiche schon vor dem Launch suchen.
- Access-Logs ab Tag eins beobachten. Wiederholte Requests auf Pfade, die man selbst nie erstellt hat, zeigen, dass die Domain extern noch „erinnert“ wird.
- Menschen, Suchmaschinen-Crawler und zufällige Bots trennen. Ein Ausschlag beim Direct Traffic und ein Crawler-Fehler sind unterschiedliche Signale und sollten nicht in eine einzige Ursache gepresst werden.
- Wiederkehrende tote URLs klassifizieren. Für wichtige Muster bewusst zwischen 301, 404 und 410 entscheiden.
- Das Ergebnis getrennt messen. Request-Frequenz, Crawler-Berichte und Indexierung separat beobachten, statt alles unter einem unscharfen Begriff wie „SEO Health“ zusammenzufassen.
Dieser Aufwand ist klein im Vergleich dazu, das Problem erst zu entdecken, wenn Logs und Webmaster-Tools bereits voller Rauschen sind.
Was 410 nicht löst
410 ist eine HTTP-Aussage über den Zustand einer Ressource. Es ist keine Firewall, kein Rate Limiter und kein Bot-Blocking-Mechanismus. Wenn ein Scraper nach einer 410-Antwort weiter Requests sendet, muss der Server sie weiterhin empfangen und beantworten. Ist die eigentliche Ursache missbräuchliches Request-Volumen, ist das ein separates Infrastrukturproblem.
410 ist auch kein SEO-Boost. Der korrekte Status hilft einem Crawler zu verstehen, was mit einer URL passiert ist; allein dadurch rankt die neue Website nicht besser.
Die Lektion, die geblieben ist
Überraschend war nicht, dass eine alte Domain alte URLs hatte. Überraschend war, wie schnell diese unsichtbare Vergangenheit nach dem Launch wieder sichtbar wurde: mehr als 1.000 Requests pro Tag auf Seiten, die es bei mir nicht gab, fast keine Interaktion und mehr als 900 Yandex-Webmaster-Fehler in einer Nacht.
Eine alte Domain ist kein leerer Namespace. Alte Links, Crawler, Skripte und Bots können Pfade noch Jahre nach dem Verschwinden des ursprünglichen Inhalts kennen. Meine heutige Regel ist simpel: die Historie prüfen, den Status zurückgeben, der der Realität entspricht, und operativen Bot-Traffic nicht mit Aussagen über Suchmaschinen verwechseln.
Historie kann ein Vorteil sein. Sie ist aber auch Zustand, den man übernimmt.