Das SEO-Team des Marktplatzes schrieb seine Indexierungsregel um, nachdem eine einfache „weniger als 3 Inserate = noindex“-Richtlinie dazu geführt hatte, dass Kategorieseiten aus Google verschwanden und Wochen brauchten, um wieder aufzutauchen. Durch das Hinzufügen eines einseitigen „Unlock“-Eintrags, der es einer Seite ermöglicht, von „noindex“ zu „index“ zu wechseln, aber niemals zurück, konnte die Website das ständige Hin- und Herflackern stoppen.

Warum die ursprüngliche Regel nach hinten losging

Die Kleinanzeigen-Plattform generiert viele Kategorie- und Standortseiten. Wenn eine Seite zum ersten Mal erscheint, enthält sie oft nur eine Handvoll Inserate, weshalb das Team beschloss, sie vor der Suche zu verbergen, bis sie eine Mindestschwelle von drei Artikeln erreicht. Die Logik war simpel:

  • < 3 Inserate → noindex-Meta-Tag hinzufügen
  • ≥ 3 Inserate → Tag entfernen (Indexierung erlauben)

Anfangs hielt dies „Thin Content“-Seiten mit geringem Wert aus den Google-Ergebnissen fern. Das Problem entstand, als Inserate abliefen. Eine Seite mit fünf Inseraten an einem Tag konnte am nächsten Tag auf zwei sinken, was sofort zum Wechsel zurück auf noindex führte. Google folgte dem Befehl, entfernte die URL aus dem Index, und die Seite verlor alle bisher aufgebauten Rankings. Sobald ein neues Inserat hinzukam, wurde die Seite wieder indexierbar, aber der Wiedereinstiegsprozess dauerte Wochen.

Das Ergebnis war ein ständiger „An-Aus“-Zyklus: Seiten gelangten in den Index, verschwanden, kehrten zurück und so weiter.

Die einseitige „Unlock“-Lösung

Der Kernfehler bestand darin, dass die Regel kein Gedächtnis hatte; sie berechnete den Schwellenwert bei jeder Anfrage neu. Das Team führte eine kleine Datenbanktabelle ein – seo_unlocks –, die aufzeichnet, wann eine Seite zum ersten Mal die Marke von drei Inseraten erreicht. Der neue Workflow sieht wie folgt aus:

  1. Anzahl der Inserate prüfen. Wenn die Seite drei oder mehr aktive Inserate hat, fortfahren.
  2. Einen Unlock-Eintrag schreiben. Füge einen Datensatz für diese Seite in seo_unlocks ein.
  3. Die Seite als dauerhaft indexierbar behandeln. Selbst wenn die Anzahl später unter drei fällt, verhindert das Vorhandensein eines Unlock-Eintrags, dass die Seite wieder in den noindex-Prozess gerät.

Da der Unlock nur einmal geschrieben werden kann, kann eine Seite von „noindex“ zu „index“ wechseln, aber niemals zurück. Das Team fügte Sicherheitsvorkehrungen hinzu, damit gefilterte URLs (z. B. Suchergebnisse mit Preisspannen) keine Unlocks für ihre übergeordneten Kategorien erstellen können, und kapselte den Datenbankaufruf in einen try/catch-Block, um zu verhindern, dass ein Datenbankfehler die gesamte Website zum Absturz bringt.

Was dies für das Crawl-Budget und Thin Pages bedeutet

Ein weit verbreiteter Irrtum ist, dass noindex Crawl-Budget spart. Google muss die Seite dennoch abrufen, das Tag lesen und sie dann aus dem Index entfernen. Wenn das Ziel ist, Google daran zu hindern, ein ganzes URL-Muster abzurufen, ist das richtige Werkzeug die robots.txt. Verwenden Sie noindex nur dann, wenn Google die Seite zwar sehen, aber nicht in den Suchergebnissen anzeigen soll.

Für Verzeichnisse, Jobbörsen und Marktplätze, die auf einer großen Anzahl automatisch generierter Seiten basieren, ist die Lehre klar: Regeln für Thin Pages müssen mit einer Persistenzschicht gekoppelt werden, die sich merkt, wann eine Seite sich einen Platz im Index verdient hat. Ohne dieses Gedächtnis kann ein vorübergehender Rückgang des Inhalts dazu führen, dass eine Seite ihr aufgebautes Ranking verliert, und der Wiedereinstieg kann Wochen dauern.

Fazit

Eine statische „wenn Anzahl < 3, dann noindex“-Regel erzeugt SEO-Volatilität für Websites mit dynamischen Inseraten. Das Hinzufügen eines einseitigen Unlock-Eintrags verleiht der Regel ein Gedächtnis, sodass Seiten ihren Indexierungsstatus verdienen und behalten können, selbst wenn die Anzahl der Inserate schwankt. Kombiniert man dies mit der korrekten Verwendung von robots.txt für echte Einsparungen beim Crawl-Budget, kann man sowohl die Rankings als auch die Serverressourcen schützen.