Wie eine Seite entdeckt und erneut gecrawlt wird

Hier gibt es drei separate Fragen, und sie haben drei unterschiedliche Antworten: wie ein Crawler eine Seite findet, wie schnell er erfährt, dass sich die Seite geändert hat, und was Sie über das Ergebnis sehen können. Diese Seite beantwortet alle drei anhand der tatsächlichen Timer.

Wie findet ein Crawler überhaupt eine Seite?#

Zwei automatische, Pull-basierte Wege:

1. Die Sitemap. Jeder Eigentümer erhält eine sitemap.xml, in der jede Seite jedes indexierten Repositorys sowie ein Eintrag pro tatsächlich übersetzter Sprache aufgeführt ist. Sie wird auf dem eigenen Host der Website bereitgestellt und höchstens einmal pro Stunde neu erstellt.
2. robots.txt benennt sie. Jeder von Docsbook gehostete Host stellt eine robots.txt mit einer Sitemap:-Zeile bereit, die auf die Sitemap verweist, die zu diesem Host gehört. Die Apex-Domain enthält mehrere: ihre eigene, eine pro Produktdokumentationswebsite und eine pro öffentlicher Showcase-Website mit aktiviertem SEO – da diese Websites nur von der Apex-Domain aus erreichbar sind und ein Crawler sonst nicht auf sie verwiesen würde.

Darüber hinaus wird die Seitenleiste auf jeder Seite als echte HTML-Links gerendert, sodass jeder Crawl einer beliebigen Seite gleichzeitig ein Crawl der Inhaltsübersicht ist.

Wie schnell erreicht eine Änderung eine Suchmaschine?#

Push. Wenn eine Änderung über Docsbook veröffentlicht wird — durch den Editor, einen Agenten, die MCP-Tools oder eine Änderung der Workspace-Einstellungen — invalidiert Docsbook seine eigenen Caches für diese Website sofort. Für Websites, die auf dem docsbook.io-Apex gehostet werden, sendet es außerdem eine IndexNow-Benachrichtigung, die den Stamm der Website und ihre Sitemap nennt. Dieser Aufruf erfolgt als Fire-and-forget-Aufruf: Er nennt zwei URLs statt der geänderten Seiten (zu diesem Zeitpunkt ist nur „diese Website hat sich geändert“ bekannt, und die Sitemap ermöglicht es einer teilnehmenden Suchmaschine, die Einzelheiten zu ermitteln), blockiert die Veröffentlichung nie und lässt sie auch nie fehlschlagen. Ein Ausfall von IndexNow wird protokolliert, statt angezeigt zu werden.

Pull. Alles andere wartet darauf, dass ein Crawler zurückkehrt und die Sitemap erneut einliest.

Und nun der ehrliche Teil: Docsbook hat keinen GitHub-Webhook. Ein Commit, der direkt in dein Repository gepusht wird und Docsbook umgeht, löst weder eine Invalidierung noch einen IndexNow- Push aus. Er wird von Zeitgebern erfasst:

Eine in Docsbook bearbeitete Seite ist für den nächsten Crawler also innerhalb von Sekunden aktuell; eine direkt auf GitHub gepushte Seite kann bis zu 24 Stunden lang aus dem Cache ausgeliefert werden. Das 24-Stunden-Fenster ist ein bewusster Kompromiss: Bot-Crawls, die jede Seite stündlich neu rendern, waren der mit Abstand größte Posten auf der Hosting-Rechnung, und Dokumentationsseiten werden deutlich häufiger gelesen als geschrieben.

Was passiert, wenn eine Seite umbenannt wird?#

Eine über Docsbook vorgenommene Verschiebung schreibt den alten Seitenpfad → neuen Seitenpfad in eine .docsbook/redirects.json-Datei im selben Commit wie die Verschiebung, und die alte URL liefert anschließend eine permanente 308-Weiterleitung auf die neue. Permanent, nicht vorübergehend, denn eine vorübergehende Weiterleitung weist Suchmaschinen an, die nicht mehr gültige URL als kanonische URL beizubehalten — und genau das Ranking geht dadurch verloren, das die Weiterleitung eigentlich bewahren soll. Die Zuordnung enthält bis zu 500 Einträge, wobei die ältesten zuerst entfernt werden, und sie wird nur für Anfragen berücksichtigt, die ohnehin auf einen 404-Fehler zuliefen.

Eine Umbenennung, die du selbst durch Verschieben der Datei in git vornimmst, erhält keine Weiterleitung: Niemand hat die Zuordnung geschrieben. Du kannst den Eintrag von Hand hinzufügen — es handelt sich um eine einfache Datei in deinem Repository, und beide Seiten sind Seitenpfade, also das, was in einer URL erscheint.

Was genau macht die Search-Console-Integration?#

Sie liest Daten ein. Die Daten fließen nur in eine Richtung: Google → Docsbook, über den schreibgeschützten Search-Analytics-Bereich. Docsbook übermittelt keine URLs, beantragt keine Indexierung und schreibt nichts in Ihr Search-Console-Konto. Außerdem müssen Sie nichts verbinden: Docsbook liest eine Search-Console-Domain-Property auf docsbook.io, die nach Googles Definition „Daten für alle Subdomains, Protokolle und Unterpfade aggregiert“, und filtert die Zeilen auf die URLs herunter, die zu Ihrer Website gehören.

Was im Adminbereich angezeigt wird: durchschnittliche Position, Impressionen, Klicks, die Suchanfragen, für die Ihre Seiten ranken, ein täglicher Trend und eine Liste mit „Verbesserungspotenzial“ – Suchanfragen auf Position 5–20, die bereits sichtbar sind, aber noch keine Spitzenposition erreichen. Zeiträume von 7, 28 und 30 Tagen; 7 Tage ist die Standardeinstellung, weil nur 30 Tage Verlauf gespeichert werden. Daher ist dies der einzige Zeitraum, für den ein gleich langer vorheriger Zeitraum zum Vergleich verfügbar ist.

Drei Einschränkungen werden angezeigt statt verborgen. Googles Daten sind etwa zwei Tage verzögert, daher ist immer ein Datum „Daten bis“ sichtbar. Eine Aktualisierung ist nur einmal alle 24 Stunden zulässig, da Google selbst täglich aktualisiert und ein zweiter Abruf Kontingent verbrauchen würde, um identische Zahlen zurückzugeben. Und die Gesamtwerte werden auf Seitenebene aggregiert, nicht durch Summieren der Suchanfragezeilen: Google hält Suchanfragen mit geringem Suchvolumen aus Datenschutzgründen zurück, sodass die Aufschlüsselung nach Suchanfragen nur einen Teil des tatsächlichen Traffics abdeckt. Unsere eigene Messung für die eigene Dokumentations-Property von Docsbook: 91 Impressionen bei Summierung nach Suchanfrage gegenüber 413 bei Summierung nach Seite. Das betrifft eine Website an einem Tag und soll die Richtung der Abweichung zeigen, nicht ihre Größe auf Ihrer Website.

Warum diese Mechanismen (Belege)#

Grenzen und offene Fragen#

• IndexNow wird heute nicht für Kundenseiten gesendet. Das Protokoll verlangt, dass jede URL in einer Übermittlung denselben Host verwendet, und dass sich eine Schlüsseldatei im Stammverzeichnis dieses Hosts befindet. Docsbook hostet diesen Schlüssel nur auf dem docsbook.io-Apex, daher werden Übermittlungen für die eigene Dokumentation von Docsbook und für Showcase-Seiten auf dem Apex versendet — nicht für <owner>.docsbook.io-Seiten und nicht für benutzerdefinierte Domains. Das Hosting eines Schlüssels pro Mandant ist eine separate Aufgabe und noch nicht umgesetzt.
• Offene Frage: Wie schnell IndexNow tatsächlich ist. In Docsbooks Codekommentar heißt es: „innerhalb von Minuten, statt auf den nächsten geplanten Crawl zu warten“. Die eigene FAQ von IndexNow sagt lediglich, dass es „die Wahrscheinlichkeit erhöht, dass wichtige Änderungen schneller entdeckt und gecrawlt werden“, und nennt keinen Zeitrahmen. Betrachten Sie Minuten als Hoffnung, nicht als Messwert — wir haben keine entsprechenden Daten veröffentlicht.
• Google ist kein Teilnehmer von IndexNow. indexnow.org nennt als unterstützende Dienste „Microsoft Bing, Naver, Seznam.cz, Yandex, Yep“ — fünf Suchmaschinen, und Google ist weder auf dieser Seite noch in der Protokolldokumentation darunter. Die Entdeckung durch Google erfolgt weiterhin über die Sitemap und das normale Crawling.
• Offene Frage: Wie geheim der IndexNow-Schlüssel ist. Docsbook behandelt den Schlüssel als öffentliche Kennung — er ist offen hardcodiert, und die Schlüsseldatei wird nicht authentifiziert im Stammverzeichnis des Apex bereitgestellt, wie es die FAQ verlangt („keine Anmeldung erforderlich“, damit eine Suchmaschine „den Domainbesitz bestätigen“ kann). Dem Verständnis „er ist kein Geheimnis“ widerspricht die eigene Protokollseite von IndexNow, auf der steht: „Nur Sie und die Suchmaschinen sollten den Schlüssel und den Speicherort Ihrer Schlüsseldatei kennen“. Beides kann für eine Datei, die jeder Client abrufen kann, nicht vollständig zutreffen. Was der Schlüssel bei einer Kopie bewirken kann, ist begrenzt — er sagt lediglich: „Dieser Host wurde geändert“, mehr nicht — aber betrachten Sie „konstruktionsbedingt öffentlich“ als unsere Interpretation eines Protokolls, das dies nicht ausdrücklich sagt.
• Die Abdeckung der Search Console endet bei von Docsbook gehosteten Hosts. Die Domain-Property umfasst docsbook.io und seine Subdomains. Eine Website auf Ihrer eigenen benutzerdefinierten Domain ist nicht in dieser Property enthalten, daher werden für sie keine Positionen abgerufen. Für die Bereitstellung dieser Zahlen ist ein Google-Autorisierungsablauf pro Kunde erforderlich, den es noch nicht gibt — verwenden Sie für eine benutzerdefinierte Domain vorerst Ihr eigenes Search-Console-Konto.
• Der Verlauf der Search Console umfasst hier 30 Tage. Google speichert deutlich mehr; Docsbook speichert pro Website ein rollierendes 30-Tage-Fenster. Deshalb gibt es in der 30-Tage-Ansicht keinen Vergleichszeitraum.
• Nichts hier sorgt dafür, dass eine Seite rankt. Entdeckung und erneutes Crawling sind die Bereiche, die Docsbook automatisieren kann. Ob eine gecrawlte Seite rankt, entscheidet Google anhand Ihrer Inhalte, und kein Timer auf dieser Seite ändert daran etwas.

Verwandte Themen#

• SEO — was Docsbook für die Sichtbarkeit in Suchmaschinen tut
• Wie Docsbook den Kopf einer Seite erstellt
• Analysen
• GEO — von KI-Assistenten zitiert werden
• KI-Übersetzungen