Viele neue URLs veröffentlichen: Crawling, Indexierung und sinnvolles Pacing

Ein grosser Content-Rollout wird nicht allein wegen seines Tempos als Spam behandelt. Trotzdem können Technik, Qualität und URL-Menge Crawling und Indexierung bremsen. So planst du Rollouts anhand überprüfbarer Signale statt erfundener Wochenquoten.

Jan-Hendrik HeuingAktualisiert

Das Veröffentlichungstempo allein ist kein Spam-Signal

Google veröffentlicht keine Regel, nach der 20, 50 oder 100 neue Seiten pro Woche erlaubt wären. Auch die Behauptung, eine Domain dürfe wöchentlich höchstens fünf bis zehn Prozent ihres Bestands ergänzen, hat keine offizielle Grundlage.

Viele neue URLs können trotzdem Probleme sichtbar machen. Google muss sie entdecken, abrufen, rendern, konsolidieren und auf Indexeignung prüfen. Wenn Seiten langsam laden, einander stark ähneln oder intern kaum verlinkt sind, wird nicht jede URL sofort aufgenommen. Das liegt nicht automatisch daran, dass ein grosser Drop Misstrauen ausgelöst hat.

Crawling und Indexierung sind getrennte Schritte

Beim Crawling ruft Googlebot eine URL und ihre Ressourcen ab. Danach prüft Google unter anderem Inhalt, Canonical-Signale, Duplikate und Indexeignung. Eine erfolgreich gecrawlte Seite wird nicht zwingend indexiert.

Das sogenannte Crawl-Budget besteht aus Kapazität und Nachfrage. Laut Googles aktueller Dokumentation zum Crawl-Budget ist die vertiefte Optimierung vor allem für sehr grosse oder sehr schnell veränderte Websites relevant. Google nennt als grobe Grössenordnungen mindestens eine Million Seiten mit regelmässigen Änderungen, mindestens 10'000 sehr schnell veränderte Seiten oder einen hohen Anteil Gefunden, zurzeit nicht indexiert.

Für eine typische B2B-Website mit einigen hundert oder wenigen tausend URLs reichen meist eine aktuelle Sitemap, saubere interne Links und die regelmässige Prüfung des Indexierungsberichts.

Was einen grossen Rollout tatsächlich bremst

Server und Rendering: Langsame Antworten, 5xx-Fehler, 429-Antworten und aufwendiges Rendering können die Crawl-Kapazität senken. Der Server muss zusätzliche Bot-Abrufe bewältigen können.

Unklare URL-Bestände: Filter, Parameter, Duplikate, Soft-404-Seiten und Redirect-Ketten verschwenden Abrufe. Canonicals und HTTP-Status müssen vor dem Rollout stimmen.

Geringe Crawl-Nachfrage: Google priorisiert URLs nach Faktoren wie Aktualität, Beliebtheit, Qualität und Relevanz. Eine technisch erreichbare URL wird deshalb nicht automatisch häufig gecrawlt.

Ähnliche oder schwache Seiten: Viele Varianten mit kaum eigenständigem Nutzen können als Duplikate zusammengefasst, nicht indexiert oder bei manipulativer Absicht als Scaled Content Abuse eingeordnet werden. Dabei zählt der Zweck und Wert der Seiten, nicht das Veröffentlichungsdatum allein.

Warum ein gestaffelter Rollout trotzdem sinnvoll sein kann

Wellen sind eine Qualitäts- und Risikokontrolle, kein Trick zum Aufbau von Google-Vertrauen. Ein Pilot zeigt, ob Template, Daten, Canonicals, interne Links, Performance und Tracking wie geplant funktionieren.

Bei einer programmatischen Seitengruppe kann der Ablauf so aussehen:

  1. Eine repräsentative Auswahl veröffentlichen.
  2. Abruf, Rendering, Canonical und Indexierungsstatus prüfen.
  3. Inhaltliche Unterschiede und Datenqualität manuell kontrollieren.
  4. Fehler am Template oder Datenmodell beheben.
  5. Die nächste Gruppe erst nach bestandener Prüfung freigeben.

Wie gross eine Welle sein darf, hängt von Serverkapazität, Fehlerrisiko, redaktioneller Prüfung und Gesamtbestand ab. Eine allgemeingültige Wochenquote gibt es nicht.

Sitemaps richtig einsetzen

Eine Sitemap hilft Google, gewünschte URLs zu entdecken. Sie garantiert weder Crawling noch Indexierung. Halte sie aktuell, führe nur kanonische und indexierbare URLs auf und pflege lastmod nur bei tatsächlichen inhaltlichen Änderungen.

Mehrere Sitemaps können grosse Bestände nach Seitentyp oder Bereich gliedern und die Auswertung erleichtern. Sie teilen Google aber kein festes Crawl-Budget pro Segment zu. Der Vorteil ist vor allem operativ: Probleme lassen sich in Search Console einer Seitengruppe zuordnen.

Interne Links und Navigation

Jede neue Seite sollte über crawlbare interne Links erreichbar sein. Eine URL, die nur in der Sitemap steht, kann entdeckt werden, ist aber für Nutzer und Suchsysteme schlecht in die Website eingeordnet.

Verlinke neue Seiten aus dem passenden Hub, aus relevanten Artikeln und aus einer nachvollziehbaren Navigation. Vermeide künstliche Linkblöcke, in denen jede Variante auf jede andere verweist. Die Linkstruktur soll die inhaltliche Beziehung abbilden.

Indexierung beantragen ohne falsche Erwartung

Für wenige wichtige URLs kann die URL-Prüfung in Search Console einen erneuten Crawl anstossen. Google weist in der Dokumentation zur Indexierungsanfrage darauf hin, dass der Vorgang Tage bis Wochen dauern kann und keine Aufnahme in den Index garantiert.

Die Aussage, eine manuelle Anfrage verkürze die Indexierung zuverlässig von Tagen auf Stunden, ist daher nicht haltbar. Für viele URLs ist eine Sitemap vorgesehen. Wiederholte Anfragen für dieselbe URL beschleunigen den Vorgang nicht.

Was du in Search Console prüfst

Der Indexierungsbericht zeigt, welche bekannten Seiten indexiert und welche ausgeschlossen sind. Die Gründe müssen pro URL-Gruppe interpretiert werden.

Gecrawlt, zurzeit nicht indexiert kann auf Qualität, Duplikate, geänderte Auswahl oder eine noch ausstehende Bewertung hindeuten. Es ist kein eindeutiger Beweis für eine Domain-Abwertung. Gefunden, zurzeit nicht indexiert weist darauf hin, dass Google die URL kennt, aber noch nicht abgerufen hat.

Eine pauschale gesunde Indexierungsquote wie 85 Prozent gibt es nicht. Ein Shop mit vielen Filter-URLs hat ein anderes Soll als ein Wissensportal, dessen Sitemap nur kanonische Artikel enthält. Vergleiche deshalb eingereichte kanonische URLs mit dem tatsächlich gewünschten Indexbestand.

Ergänzend zeigen Crawl-Statistiken Host-Probleme, Antwortzeiten, Dateitypen und Abrufe. Aus einer sinkenden Frequenz allein lässt sich jedoch nicht ableiten, dass Google nach einem Rollout defensiver geworden ist.

Eine belastbare Entscheidung vor dem Rollout

Prüfe vor der Veröffentlichung:

  • Hat jede URL einen eigenständigen Zweck für Nutzer?
  • Sind Daten und feste Textbestandteile fachlich geprüft?
  • Stimmen Statuscode, Canonical, Sprache und Indexierungsregeln?
  • Kann der Server die zusätzlichen Abrufe stabil beantworten?
  • Ist jede Seite intern sinnvoll erreichbar?
  • Sind Sitemap und Monitoring nach Seitengruppe vorbereitet?
  • Gibt es einen Prozess für Korrekturen und Aktualisierungen?

Wenn diese Punkte erfüllt sind, muss ein Rollout nicht künstlich verlangsamt werden, um einen erfundenen Google-Grenzwert einzuhalten. Eine Staffelung bleibt sinnvoll, wenn sie Fehler früh sichtbar macht und das Team die einzelnen Wellen sauber prüfen kann.