IndexNow, Instant Indexing und Crawl Budget Strategie in einem Echtzeit Web

IndexNow sagt Suchmaschinen, was sich geändert hat, und Google hört nicht zu

Eine Suchmaschine erfährt erst dann, dass sich deine Seite geändert hat, wenn ihr Crawler wiederkommt und nachsieht. Bei einem Shop, dessen Preise sich täglich bewegen, ist diese Wartezeit genau die Lücke zwischen dem, was auf der Seite steht, und dem, was im Suchergebnis steht. IndexNow schließt einen Teil dieser Lücke. Es ist ein kleines, offenes Protokoll: Sobald eine Seite neu dazukommt, sich ändert oder verschwindet, schickt deine Website die Adresse sofort an eine Suchmaschine, statt auf deren Besuch zu warten.

Zwei Tatsachen rahmen diesen ganzen Artikel. Erstens funktioniert IndexNow für Bing, Yandex, Seznam, Naver, Yep und ein paar weitere, und eine einzige Meldung erreicht sie alle.¹² Zweitens macht Google nicht mit. Google hat 2021 angekündigt, das Protokoll zu testen, und seine eigene Dokumentation verweist dich bis heute stattdessen auf Sitemaps und die Search Console.³⁴ Eine ehrliche Strategie hat deshalb zwei Hälften. Den Suchmaschinen, die zuhören, sagst du sofort Bescheid, wenn sich etwas ändert. Und bei Google sorgst du dafür, dass jeder Besuch seines Crawlers etwas bringt. Genau das meinen die Leute mit Crawl Budget.

Ich gehe die beiden Hälften in dieser Reihenfolge durch, und ein erfundener Shop begleitet uns durch den ganzen Text.

Beispiel: der Shop in diesem Artikel

Radteile Rheinland ist ein erfundener Fahrradteileshop in Köln. Kein echtes Unternehmen, jede Zahl ausgedacht. Er verkauft rund 14.000 Produkte unter www.radteilerheinland.example, und die Inhaberin Hanna passt ständig Preise und Bestände an. An einem normalen Tag ändern sich etwa 600 Produktseiten: Ein Preis sinkt von 34,99 € auf 32,99 €, ein Satz Bremsbeläge ist ausverkauft, eine neue Reifenserie kommt rein. Ihr Ärger ist einfach erklärt: In den Suchergebnissen steht der Preis von gestern, und wer draufklickt, geht verärgert wieder.

Wie Suchmaschinen Änderungen finden, ohne dass es ihnen jemand sagt

Ein Crawler ist Software, die Seiten abruft, so wie ein Browser, nur eben für eine Suchmaschine. Neue Adressen findet er über Links auf Seiten, die er schon kennt, und über Sitemaps, also Dateien, in denen die URLs einer Website aufgelistet sind. Danach entscheidet er selbst, wann er jede Adresse wieder besucht. Eine beliebte Seite schaut er sich oft an. Eine ruhige Seite wartet vielleicht wochenlang.

Google ist beim Tempo erstaunlich offen. In seiner Anleitung zum erneuten Crawlen schreibt Google sinngemäß, dass das Crawlen einige Tage bis einige Wochen dauern kann und dass eine Anfrage nicht garantiert, dass eine Seite sofort oder überhaupt in den Suchergebnissen erscheint.⁴ So funktioniert das Abholprinzip: Die Suchmaschine entscheidet, wann sie hinschaut.

Die Kosten treffen beide Seiten. Ein Crawler, der nicht wissen kann, ob sich eine Seite geändert hat, muss sie abrufen, um es herauszufinden. Bing hat das beim Start von IndexNow klar benannt: Ein direktes Signal verringert die Notwendigkeit, nur auf Verdacht zu crawlen, um zu prüfen, ob sich der Inhalt geändert hat.⁵ Crawlen auf Verdacht ist wie an jeder Tür zu klingeln, um zu sehen, ob jemand umgezogen ist. Meistens ist niemand umgezogen.

Beispiel: wie lange Hannas Preisänderung braucht

Hanna hebt den Preis einer Standpumpe an einem Montagmorgen von 19,99 € auf 24,99 € an, ohne irgendein Signal zu senden.

1. Die Seite ändert sich am Montag um 9:00 Uhr auf ihrem Server.
2. Ein Crawler hat die Seite zuletzt vor acht Tagen abgerufen. Produktseiten tief in einer Kategorie sind nicht beliebt genug, um täglich abgerufen zu werden.
3. Laut seinem Zeitplan ist der nächste Besuch in etwa einer Woche fällig. Nichts sagt ihm, dass er früher kommen soll.
4. Bis dahin zeigt das Suchergebnis 19,99 €. Wer draufklickt, findet 24,99 €, und diese Überraschung kostet den Verkauf und ein Stück Vertrauen gleich mit.

Es geht nicht um die genaue Zahl der Tage, die habe ich mir ausgedacht. Es geht darum, dass Hanna beim Abholprinzip keinen einzigen Hebel hat.

Was IndexNow ist, in einer einzigen Anfrage

IndexNow gibt ihr diesen Hebel. Es ist ein offenes Protokoll, entwickelt von Microsoft Bing und Yandex und am 18. Oktober 2021 gestartet.⁵ Die Idee passt in einen Satz: Wenn eine URL auf deiner Website neu ist, sich ändert oder gelöscht wird, schickst du sie an eine teilnehmende Suchmaschine, und diese gibt sie an alle anderen Teilnehmer weiter.

Das Weitergeben steht im Protokoll und hängt nicht vom guten Willen ab. Um mitzumachen, muss eine Suchmaschine zustimmen, dass die bei ihr eingereichten URLs automatisch mit allen anderen teilnehmenden Suchmaschinen geteilt werden, und zwar zeitnah.¹² Du meldest also an einen Endpunkt, und die anderen erfahren es mit.⁶

Wer hört heute zu? Die Teilnehmerliste von indexnow.org nennt Bing, Yandex, Seznam (die tschechische Suchmaschine), Naver (die südkoreanische), Yep, das Internet Archive und den Crawler von Amazon, Amazonbot.⁷ Google steht nicht drauf.

Dass dir die Website gehört, beweist du mit einem Schlüssel. Du denkst dir einen Schlüssel aus, legst ihn in eine Textdatei auf deiner eigenen Website und schickst ihn bei jeder Meldung mit. Die Suchmaschine ruft diese Datei ab und prüft so, ob der Absender die Website kontrolliert.¹ Kein Konto, kein Passwort.

Das Diagramm läuft von oben nach unten. Dein Teil endet beim zweiten Schritt. Alles danach passiert bei den Suchmaschinen, und die letzten beiden Schritte vergessen die meisten: Eine Meldung ist ein starker Hinweis, kein Befehl. Bing sagt in seiner Dokumentation ganz direkt, dass IndexNow nicht garantiert, dass Seiten gecrawlt oder indexiert werden.⁸ Yandex sagt dasselbe über seinen eigenen Endpunkt.⁹

Beispiel: Hannas Standpumpe mit IndexNow

Gleicher Montag, gleiche Pumpe. Diesmal schickt der Shop die URL der Pumpe um 9:02 Uhr an IndexNow, zwei Minuten nachdem die Änderung gespeichert ist. Bing prüft ihre Schlüsseldatei, nimmt die URL an und gibt sie an Yandex, Seznam, Naver und die anderen weiter. Wann Bing die Seite abruft, entscheidet weiterhin Bing, aber laut Bing werden gemeldete URLs in der Regel bevorzugt behandelt.⁸ Bei Google hat sich überhaupt nichts geändert.

Die Einrichtung: Schlüsseldatei, eine URL, viele URLs

Drei Teile, und jeder muss genau zur dokumentierten Schnittstelle passen, weil die Suchmaschinen alles ablehnen, was abweicht.

Der Schlüssel und die Schlüsseldatei

Der Schlüssel muss zwischen acht und 128 Zeichen lang sein und darf nur Klein und Großbuchstaben von a bis z, die Ziffern null bis neun und den Bindestrich enthalten.¹¹⁰ Üblich ist eine zufällige Zeichenkette aus 32 Hexadezimalzeichen. Hier ist Hannas, für dieses Beispiel erfunden:

a3f9c2e17b4d48e6a0b5c9d2e8f1a7c4

Empfohlen ist eine Textdatei im Stammverzeichnis der Website, benannt nach dem Schlüssel selbst, mit dem Schlüssel als einzigem Inhalt, gespeichert als UTF-8:¹

https://www.radteilerheinland.example/a3f9c2e17b4d48e6a0b5c9d2e8f1a7c4.txt

Wenn du nicht ins Stammverzeichnis schreiben kannst, darfst du die Datei auch woanders auf demselben Host ablegen und mit dem Parameter keyLocation darauf verweisen. Der Haken: Eine Schlüsseldatei deckt nur URLs in ihrem eigenen Ordner und darunter ab. Eine Datei in /katalog/ bürgt für URLs unter /katalog/, aber nicht für /hilfe/.¹

Eine URL, mit einer GET Anfrage

Für eine einzelne Seite reicht eine einfache GET Anfrage. Der Parameter url muss URL kodiert sein:¹¹⁰

curl "https://api.indexnow.org/indexnow?url=https%3A%2F%2Fwww.radteilerheinland.example%2Fprodukte%2Fstandpumpe&key=a3f9c2e17b4d48e6a0b5c9d2e8f1a7c4"

api.indexnow.org ist der gemeinsame, weltweite Endpunkt. Du könntest die Anfrage genauso an www.bing.com/indexnow oder yandex.com/indexnow schicken. Das Ergebnis ist dasselbe, wegen der Regel zum Weitergeben.⁶

Viele URLs, mit einer POST Anfrage

Für mehr als eine Seite schickst du einen JSON Body. Die dokumentierten Felder sind host, key, das optionale keyLocation und urlList, eine Liste mit bis zu 10.000 URLs pro Anfrage. Der Content Type ist JSON in UTF-8:¹¹⁰

curl -X POST "https://api.indexnow.org/indexnow" \
  -H "Content-Type: application/json; charset=utf-8" \
  -d '{
    "host": "www.radteilerheinland.example",
    "key": "a3f9c2e17b4d48e6a0b5c9d2e8f1a7c4",
    "urlList": [
      "https://www.radteilerheinland.example/produkte/standpumpe",
      "https://www.radteilerheinland.example/produkte/bremsbelaege-scheibe",
      "https://www.radteilerheinland.example/produkte/gravelreifen-40mm"
    ]
  }'

Jede URL in urlList muss zu dem host gehören, den du angibst, sonst schlägt die Anfrage fehl.¹

Was die Antwort bedeutet

Der Statuscode sagt dir, was passiert ist, und es lohnt sich, jeden einzelnen mitzuschreiben:¹⁸¹⁰

• 200 heißt, die URLs sind angekommen.
• 202 heißt angekommen, der Schlüssel wird aber noch geprüft (normal bei einem neuen Schlüssel).
• 400 heißt, die Anfrage war fehlerhaft aufgebaut.
• 403 heißt, die Schlüsseldatei wurde nicht gefunden oder enthält den Schlüssel nicht.
• 422 heißt, eine URL gehört nicht zum Host, oder der Schlüssel verletzt die Formatregeln.
• 429 heißt zu viele Anfragen, was die Suchmaschinen als möglichen Spam werten.

Ein 200 bestätigt den Empfang, mehr nicht.

Beispiel: IndexNow in Hannas Shop einbauen

Hannas Shop läuft auf Ruby on Rails. Sobald sich Preis, Bestand oder Text eines Produkts ändert, landet die URL des Produkts in einer kleinen Warteschlange. Ein Hintergrundjob, also eine Aufgabe, die außerhalb der Webanfrage läuft, damit der Shop nie darauf warten muss, holt die Warteschlange alle zehn Minuten ab und schickt sie in einem einzigen POST:

require "net/http"
require "json"

class IndexNowJob < ApplicationJob
  ENDPOINT = URI("https://api.indexnow.org/indexnow")
  HOST = "www.radteilerheinland.example"

  def perform(urls)
    # Doppelte URLs entfernen, dann in Pakete von höchstens 10.000 teilen
    urls.uniq.each_slice(10_000) do |batch|
      body = { host: HOST, key: ENV.fetch("INDEXNOW_KEY"), urlList: batch }
      response = Net::HTTP.post(ENDPOINT, body.to_json,
                                "Content-Type" => "application/json; charset=utf-8")
      Rails.logger.info("IndexNow #{response.code} for #{batch.size} URLs")
    end
  end
end

Gehen wir einen Tag durch. Rund 600 Produktseiten ändern sich, manche mehrfach, morgens eine Preissenkung, nachmittags ausverkauft. uniq entfernt die doppelten URLs innerhalb jedes Zehnminutenfensters. Ein Tag hat 144 solcher Fenster, also enthalten die meisten nur eine Handvoll URLs, weit unter der Grenze von 10.000, und each_slice macht daraus eine Anfrage pro Fenster. Genau für diese Form wurde das Protokoll gebaut.

Liefe Hannas Shop stattdessen auf einer gehosteten Plattform, bräuchte sie vielleicht gar keinen Code. Bing nennt Plattformen mit eingebautem IndexNow, darunter Shopify, Wix Studio und Duda, Plugins für WordPress wie Yoast und Rank Math sowie die Einstellung Crawler Hints von Cloudflare für Websites hinter dessen Netzwerk.⁸

Was du meldest und was du weglässt

Die Suchmaschinen sagen deutlich, wie sie es haben wollen. Drei Regeln decken fast alles ab.

Melde nur echte Änderungen. Bing will URLs, die neu dazugekommen sind, sich geändert haben oder gelöscht wurden, seit du IndexNow nutzt.⁸ Yandex bittet darum, nur neue, geänderte oder gelöschte Seiten zu melden.⁹ Die IndexNow FAQ ergänzt, dass du nicht jede kleine Layout oder Designänderung melden sollst, sondern dich auf das konzentrierst, was zählt, etwa Inhalt, Preise und Verfügbarkeit.⁶ Ein neuer Footer ist keine Nachricht.

Melde auch Löschungen und Weiterleitungen. Wenn ein Produkt aus dem Sortiment fällt und seine Seite einen 404 oder 410 liefert, oder wenn eine Seite per Weiterleitung umzieht, meldest du diese URL. Die FAQ sagt das ausdrücklich, weil die Suchmaschinen die alte Adresse so schneller entfernen oder aktualisieren können.⁶

Melde nicht die ganze Website noch einmal. Laut FAQ ist IndexNow nicht dafür gedacht, alle URLs einer Website auf einmal einzureichen, mit einer Ausnahme für eine frische Migration oder einen Relaunch.⁶ Für eine Seite, die sich oft ändert, empfiehlt die FAQ mindestens fünf Minuten Abstand zwischen zwei Meldungen derselben URL, und die Referenz von Yandex bittet um Abstände von zehn Minuten, falls du erneut melden musst.⁶¹⁰ Jede gemeldete URL zählt außerdem auf das Crawl Kontingent deiner Website bei diesen Suchmaschinen, Rauschen kostet also etwas.⁶⁸

Nichts davon ersetzt eine Sitemap. Bing hat im Juli 2025 empfohlen, beides zu kombinieren: eine vollständige Sitemap für die Abdeckung und IndexNow, um jede geänderte URL schnell zu melden.¹¹ Die Sitemap ist die vollständige Inventarliste. IndexNow ist die Änderungsmitteilung.

Beispiel: Hannas erste Woche und der Fehler, den ich abstellen würde

Hannas früherer Entwickler wollte helfen und hatte eine nächtliche Aufgabe eingerichtet, die "sicherheitshalber" alle 14.000 Produkt URLs an IndexNow schickte. Von diesen 14.000 hatten sich an dem Tag etwa 600 tatsächlich geändert. Rund 13.400 Meldungen, etwa 96 % des Pakets, kündigten also Änderungen an, die es nie gab, und jede davon zählte auf das Crawl Kontingent des Shops. Ein Signal, das jede Nacht falschen Alarm schlägt, ist irgendwann kein Signal mehr.

Die Lösung ist der Job von oben: nur die URLs, deren Preis, Bestand oder Text sich geändert hat, alle zehn Minuten gesammelt, dazu ausgelistete Produkte in dem Moment, in dem sie 410 liefern, und alte URLs in dem Moment, in dem sie weiterleiten. Die nächtliche Komplettmeldung fliegt raus. Die Sitemap bleibt, mit einem ehrlichen lastmod Datum bei jedem Produkt.

Wo Google heute steht

Ein guter Teil des Internets ist hier zu optimistisch. Das hier lässt sich tatsächlich belegen.

Im November 2021, einen Monat nach dem Start, sagte Google gegenüber Search Engine Roundtable, man werde die möglichen Vorteile des Protokolls testen.³ Das ist die letzte öffentliche Aussage von Google zu IndexNow, die ich finden kann. Auf der Teilnehmerliste von indexnow.org steht Google nicht.⁷ Googles eigene Seite zum erneuten Crawlen nennt zwei Wege, das URL Prüftool in der Search Console für einzelne Seiten und eine Sitemap für viele, und erwähnt IndexNow nicht.⁴ Fünf Jahre später ist ein Test, aus dem nie Unterstützung wurde, in der Praxis ein Nein, egal was noch kommt.

Google hat außerdem seine eigene Abkürzung zum Melden abgeschafft. Bis 2023 konntest du den Sitemap Endpunkt von Google anpingen, um zu sagen, dass sich eine Sitemap geändert hat. Im Juni 2023 hat Google diesen Endpunkt abgekündigt, und inzwischen ist er abgeschaltet: Anfragen daran liefern einen 404, und Code, der ihn noch aufruft, bewirkt nichts Sinnvolles mehr.¹² Wenn dein Shop oder ein Plugin Google immer noch anpingt, ruft es in einen leeren Raum.

Was Google tatsächlich nutzt, ist das lastmod Datum in der Sitemap, also der Zeitpunkt der letzten Änderung einer Seite. Google verwendet es, wenn es durchgängig und überprüfbar stimmt, und es soll die letzte wesentliche Änderung der Seite wiedergeben, nicht etwa eine neue Jahreszahl im Copyright im Footer.¹³ In der Ankündigung von 2023 war Google deutlicher: Wer falsche Daten meldet, dem glaubt Google irgendwann nicht mehr.¹² changefreq und priority ignoriert Google komplett.¹³

Es gibt eine Indexing API von Google, aber sie ist keine allgemeine Abkürzung. Laut Google darf sie nur für Seiten mit einem JobPosting oder einem BroadcastEvent, eingebettet in ein VideoObject, genutzt werden, also für Stellenanzeigen und Livestreams.¹⁴

Beispiel: was Hanna für Google tut

Für Google ist Hannas Hebel die Sitemap. Ihre Produktsitemap wird jede Stunde neu erzeugt. Das lastmod jedes Produkts kommt aus dem Moment, in dem sich Preis, Bestand oder Beschreibung zuletzt geändert haben, nicht aus dem Zeitpunkt, an dem die Sitemap Datei gebaut wurde. Die Sitemap steht in der robots.txt und ist in der Search Console eingereicht. Für die seltene dringende Seite, etwa einen Rückruf für einen fehlerhaften Bremshebel, nutzt sie das URL Prüftool von Hand.

Danach sorgt sie dafür, dass die Besuche des Googlebot etwas bringen. Das ist Crawl Budget, und darum geht es im Rest dieses Artikels.

Crawl Budget gibt es wirklich, aber nur für manche Websites

Google definiert Crawl Budget als die Menge an URLs, die Google crawlen kann und will, und behandelt jeden Hostnamen als eigene Website mit eigenem Budget.¹⁵ Zwei Dinge bestimmen es.

Das Crawling Kapazitätslimit legt fest, wie stark Google crawlen kann, ohne deinem Server zu schaden. Jede Website startet mit einem vorsichtigen Standardwert. Antworten deine Seiten schnell und zuverlässig, steigt das Limit. Werden sie langsam, liefern sie 5xx Serverfehler oder einen 429, sinkt es.¹⁵

Der Crawling Bedarf beschreibt, wie viel Google crawlen will. Er steigt mit der Zahl der URLs, die Google von deiner Website kennt (dem wahrgenommenen Bestand), mit ihrer Beliebtheit und damit, wie schnell sie veralten. Den Bestand nennt Google den Faktor, den du am stärksten positiv beeinflussen kannst, weil Google jede doppelte oder nutzlose URL, die es kennt, zu crawlen versucht.¹⁵

Jetzt der Teil, der oft unter den Tisch fällt. Googles Leitfaden ist für große Websites geschrieben, also grob eine Million Seiten, die sich wöchentlich ändern, oder mittlere Websites ab 10.000 Seiten, die sich täglich ändern, oder Websites mit vielen URLs im Status "Gefunden, zurzeit nicht indexiert" in der Search Console. Google nennt diese Schwellen ausdrücklich grobe Richtwerte, keine exakten Grenzen. Wenn deine neuen Seiten meist am Tag der Veröffentlichung gecrawlt werden, brauchst du den Leitfaden laut Google gar nicht: Halte die Sitemap aktuell und schau in den Bericht zur Indexierung.¹⁵ Für eine Visitenkartenwebsite mit 40 Seiten ist Crawl Budget nicht dein Problem, und wer dir dafür eine Crawl Budget Analyse verkauft, verkauft dir ein Problem.

Beispiel: Gehört Hannas Shop dazu?

Hanna hat 14.000 Produkte, und etwa 600 davon ändern sich jeden Tag. Damit fällt sie in Googles zweite Gruppe, 10.000 Seiten oder mehr mit täglichen Änderungen. Ihr Indexierungsbericht in der Search Console zeigt außerdem rund 2.100 Produkt URLs mit dem Status "Gefunden, zurzeit nicht indexiert": Google weiß, dass es sie gibt, ist aber noch nicht dazu gekommen, sie abzurufen. Ihre Website ist genau die Sorte, bei der sich ein Nachmittag Crawl Budget lohnt.

Lies deine Serverlogs, um zu sehen, wohin das Crawling geht

Meinungen über Crawl Budget kosten nichts, solange man sie nur hat, und viel, sobald man danach handelt. Die Zugriffslogs deines Servers klären die Frage. Jede Anfrage eines Crawlers ist eine Zeile in diesem Log: der Zeitpunkt, die URL, der Statuscode und der User Agent, also der Name, den sich der Client selbst gibt.

Stell zuerst sicher, dass eine Anfrage, die behauptet, der Googlebot zu sein, auch wirklich von ihm kommt, denn jeder kann "Googlebot" in einen User Agent schreiben. Googles Methode ist ein umgekehrter Lookup im Domain Name System (DNS) für die IP Adresse, eine Prüfung, ob der Name auf googlebot.com, google.com oder googleusercontent.com endet, und danach ein normaler Lookup, der bestätigt, dass der Name wieder auf dieselbe IP zeigt. Alternativ gleichst du die IP mit den Adressbereichen ab, die Google veröffentlicht.¹⁶ Lässt du das weg, verfälschen Scraper im Googlebot Kostüm jede Zahl, die danach kommt.

Sortiere die bestätigten Anfragen danach nach URL Typ und Statuscode. Dann sagt dir ein einziges Verhältnis, wie viel des Crawlings verschwendet ist:

$$w = \frac{c_{\text{waste}}}{c_{\text{total}}}$$

Dabei ist $w$ der Verschwendungsanteil, $c_{\text{waste}}$ die Zahl der bestätigten Crawler Anfragen im Zeitraum, die auf URLs gingen, die du nie im Index haben willst (Filterkombinationen, interne Suchergebnisse, Weiterleitungsketten, Soft 404 Seiten), und $c_{\text{total}}$ die Gesamtzahl der bestätigten Crawler Anfragen im selben Zeitraum. Es ist eine ganz normale Rate, Ereignisse geteilt durch Gelegenheiten, erklärt in Grundlagen: Verhältnisse und Raten.

Beispiel: ein Monat Googlebot in Hannas Shop

Ich nehme einen Monat aus Hannas Logs, behalte nur Anfragen, die als Googlebot bestätigt sind, und davon nur HTML Seiten. Es sind 180.000. Nach URL Typ sortiert sieht das so aus.

Die waagerechte Achse zeigt den Typ der URL, die der Googlebot angefragt hat. Die senkrechte Achse zeigt die Zahl der Anfragen im Monat. Die Erkenntnis steckt im ersten Balken. Der größte einzelne Verbraucher von Googlebots Zeit sind Filterkombinationen, URLs wie /reifen?breite=40&farbe=schwarz&sort=preis, die fast Kopien von Kategorieseiten sind. Die Produktseiten, die Hanna wirklich frisch halten will, bekommen weniger als ein Drittel des Crawlings.

Jetzt das Verhältnis, Schritt für Schritt. Die Verschwendung sind Filterkombinationen, interne Suche, Soft 404 Seiten und Weiterleitungsketten zusammen: $c_{\text{waste}} = 81.000 + 12.000 + 12.000 + 9.000 = 114.000$. Die Gesamtzahl ist $c_{\text{total}} = 180.000$.

Also $w = 114.000 / 180.000 = 0{,}633$. Fast zwei Drittel der Besuche des Googlebot gingen auf Seiten, die Hanna nie in der Suche haben wollte. Dieselben Logs zeigen, dass Filterseiten deutlich über eine Sekunde zum Antworten brauchen, und langsame Antworten halten das Kapazitätslimit niedrig.¹⁵ Sie verschwendet also ein Budget, das ohnehin schon gedrückt wird.

Behebe die Verschwendung an der Quelle, nicht mit noindex

Jede Korrektur stammt aus Googles eigenen Empfehlungen und passt zu einem Balken im Diagramm.

Filterkombinationen. Laut Googles Leitfaden zur Facettennavigation, also den Filter und Sortieroptionen auf Kategorieseiten, rufen Crawler typischerweise eine sehr große Zahl dieser URLs ab, und die Zeit dort fehlt für neue, nützliche Seiten. Wenn du gefilterte Seiten nicht in der Suche brauchst, ist die stärkste Option, sie in der robots.txt per Disallow auszuschließen. Ein Canonical Link auf die Hauptkategorie hilft weniger und langsamer.¹⁷

Interne Suchergebnisse. Sie sind endlos und doppeln die Kategorieseiten. Googles Leitfaden sagt, unwichtige URLs wie diese in der robots.txt zu sperren.¹⁵

Soft 404 Seiten. Eine Soft 404 Seite sagt "nicht gefunden" oder "nicht mehr verfügbar", liefert aber den Status 200, also kommt der Crawler immer wieder. Google sagt, du sollst sie beseitigen und für dauerhaft entfernte Seiten einen echten 404 oder 410 liefern.¹⁵

Weiterleitungsketten. Ein Link, der auf eine URL weiterleitet, die wieder weiterleitet, kostet eine Anfrage pro Sprung. Googles Leitfaden rät, lange Ketten zu vermeiden.¹⁵ Lass interne Links und alte Weiterleitungen direkt auf die endgültige URL zeigen.

Tempo und Caching. Schnellere Antworten heben das Kapazitätslimit, und wenn dein Server HTTP Caching unterstützt, kann er die Frage des Crawlers "Hat sich das geändert?" mit einem kurzen 304 Not Modified beantworten statt mit der ganzen Seite.¹⁵

Zwei Dinge sagt Google ausdrücklich, dass du sie lassen sollst. Nutze noindex nicht, um Crawl Budget zu sparen, denn Google muss die Seite trotzdem abrufen, um das Tag zu sehen. Und nutze die robots.txt nicht, um Budget vorübergehend umzuschichten, sondern nur, um URLs zu sperren, die nie gecrawlt werden sollen. Google ergänzt ein Detail, das man zweimal lesen sollte: Frei gewordenes Budget wandert nur dann zu anderen Seiten, wenn Google schon am Kapazitätslimit deiner Website war.¹⁵

Das Diagramm läuft von oben nach unten, ein URL Typ nach dem anderen. Die erste Frage teilt alles in gewollt und ungewollt. Gewollte URLs brauchen nichts Raffiniertes: Tempo, einen Eintrag in der Sitemap und ein ehrliches Datum. Ungewollte URLs bekommen die direkteste zutreffende Antwort, die es gibt, weg, umgezogen oder gesperrt, in dieser Reihenfolge. Die Logs eines Monats sind die Messung, die des nächsten Monats die Kontrolle.

Beispiel: Hannas Shop einen Monat später

Das würde ich ändern, in dieser Reihenfolge, mit dem erfundenen Ergebnis.

1. Filter und Sortierparameter auf Kategorieseiten kommen per Disallow in die robots.txt. Jede Kategorie behält eine ungefilterte, crawlbare Version.
2. /suche kommt in die robots.txt.
3. Ausgelistete Produkte, die bisher "leider nicht mehr verfügbar" mit einem 200 zeigten, liefern jetzt 410 und werden am Tag der Auslistung an IndexNow gemeldet.
4. Etwa 900 alte Weiterleitungen, die zweimal sprangen, zeigen jetzt direkt auf die endgültige Seite.
5. Antworten von Filterseiten werden gecacht, und Produktseiten liefern 304, wenn sich seit dem letzten Besuch des Crawlers nichts geändert hat.

Das bestätigte Googlebot Log des nächsten Monats hat 135.000 HTML Anfragen. Die Änderung an der robots.txt ging erst ein paar Tage nach Monatsbeginn live, deshalb wurden vorher noch einige Filter URLs abgerufen.

Die Achsen sind dieselben wie vorher: der URL Typ unten, die Anfragen im Monat an der Seite. Die Erkenntnis: Das Diagramm steht jetzt auf dem Kopf. Die Produktseiten sind mit Abstand der höchste Balken. Die neue Verschwendung ist $c_{\text{waste}} = 3.000 + 2.000 + 1.000 + 0 = 6.000$, also $w = 6.000 / 135.000 = 0{,}044$, herunter von $0{,}633$.

Wie viel mehr Aufmerksamkeit haben die Produktseiten bekommen? Die prozentuale Veränderung:

$$\Delta\% = \frac{v_{\text{new}} - v_{\text{old}}}{v_{\text{old}}} \times 100$$

Dabei ist $\Delta\%$ die prozentuale Veränderung, $v_{\text{new}}$ der neue Wert (Anfragen auf Produktseiten nach den Korrekturen) und $v_{\text{old}}$ der alte Wert (Anfragen auf Produktseiten davor). Die Formel und der Unterschied zu einer Veränderung in Prozentpunkten stehen in Grundlagen: Prozente.

Schritt für Schritt: $v_{\text{new}} = 104.000$ und $v_{\text{old}} = 52.000$, also $\Delta\% = (104.000 - 52.000) / 52.000 \times 100 = 100\ \%$. Die Produktseiten bekamen doppelt so viele Besuche, bei insgesamt weniger Anfragen. Das gesamte Crawling ist gesunken, und das ist in Ordnung: Es gibt weniger Müll anzuschauen.

Zwei ehrliche Anmerkungen. Das funktioniert, weil Hannas Shop zu Googles Zielgruppe gehörte und am Kapazitätslimit festhing. Auf einer kleinen, schnellen Website würden dieselben Änderungen die Logs aufräumen und sonst wenig, weil frei gewordenes Budget nur wandert, wenn du am Limit warst.¹⁵ Und in den Wochen danach sollten die 2.100 Produkte mit "Gefunden, zurzeit nicht indexiert" langsam weniger werden. Das ist die Zahl, die ich beobachten würde, nicht die Zahl der Crawls.

Wie ich das selbst mache und was du erwarten kannst

Auf keferboeck.com mache ich dasselbe in kleinerem Maßstab. Wenn ich einen Artikel veröffentliche oder aktualisiere, schickt ein kurzes Skript die neuen und geänderten URLs an IndexNow, und die Sitemap trägt das echte Datum der Änderung. Es ist der Job von oben, mit weniger URLs und ohne Preise.

Was du ehrlich von IndexNow erwarten kannst: eine bessere Chance, dass Bing und die Suchmaschinen, die mit Bing teilen, schnell reagieren, und bei Google gar keine Veränderung. Wie viel das wert ist, hängt davon ab, wie viel deines Traffics über den Index von Bing kommt, und das ist ein Teil der Geschichte in wie man in ChatGPT und KI Suchmaschinen rankt.

Was du von Arbeit am Crawl Budget erwarten kannst: Auf einer großen oder sich schnell ändernden Website geht das Crawling dorthin, wo das Geld ist, und weniger Seiten hängen in der Warteschleife. Auf einer kleinen Website bekommst du ein aufgeräumtes Log und wenig mehr, also bezahl nicht dafür. Und wenn dein Crawling Problem eigentlich Tausende fast identische Seiten sind, die du absichtlich gebaut hast, ist das ein anderes Gespräch, nämlich über Programmatic SEO mit Struktur.

Zusammengenommen ist die Strategie für ein Web in Echtzeit kurz. Sag den Suchmaschinen, die zuhören, sofort Bescheid, wenn sich etwas ändert, und nur dann. Halte die Sitemap ehrlich für die eine, die nicht zuhört. Und lies deine Logs, bevor du irgendwem etwas über Crawl Budget glaubst, mich eingeschlossen.

Footnotes

1. IndexNow.org, Dokumentation, https://www.indexnow.org/de_de/documentation

2. IndexNow.org, Search engines: requirements for participating search engines, https://www.indexnow.org/searchengines

3. Barry Schwartz, Google is testing IndexNow, Search Engine Roundtable, 10. November 2021 (Sekundärquelle, gibt Googles Aussage wieder), https://www.seroundtable.com/google-indexnow-32396.html

4. Google, Google um erneutes Crawlen deiner Website bitten, Google Search Central Dokumentation, https://developers.google.com/search/docs/crawling-indexing/ask-google-to-recrawl?hl=de

5. Microsoft Bing Webmaster Tools Team, IndexNow: Instantly Index your web content in Search Engines, Bing Webmaster Blog, 18. Oktober 2021, https://blogs.bing.com/webmaster/october-2021/IndexNow-Instantly-Index-your-web-content-in-Search-Engines

6. IndexNow.org, Häufig gestellte Fragen (FAQ), https://www.indexnow.org/de_de/faq

7. IndexNow.org, Participating search engines (searchengines.json), https://www.indexnow.org/searchengines.json

8. Microsoft Bing, IndexNow: Get started, Bing Dokumentation, https://www.bing.com/indexnow/getstarted

9. Yandex, IndexNow, Yandex Webmaster Hilfe, https://yandex.com/support/webmaster/indexing-options/index-now.html

10. Yandex, IndexNow API reference, Yandex Webmaster Hilfe, https://yandex.com/support/webmaster/indexnow/reference.html

11. Fabrice Canel und Krishna Madhavan, Keeping content discoverable with sitemaps in AI powered search, Bing Webmaster Blog, 31. Juli 2025, https://blogs.bing.com/webmaster/July-2025/Keeping-Content-Discoverable-with-Sitemaps-in-AI-Powered-Search

12. Gary Illyes, Ping Endpunkt für Sitemaps wird eingestellt, Google Search Central Blog, 26. Juni 2023, https://developers.google.com/search/blog/2023/06/sitemaps-lastmod-ping?hl=de

13. Google, Sitemap erstellen und einreichen, Google Search Central Dokumentation, https://developers.google.com/search/docs/crawling-indexing/sitemaps/build-sitemap?hl=de

14. Google, Kurzanleitung für die Indexing API, Google Search Central Dokumentation, https://developers.google.com/search/apis/indexing-api/v3/quickstart?hl=de

15. Google, Verwaltung des Crawling Budgets für große Websites, Google Search Central Dokumentation, https://developers.google.com/search/docs/crawling-indexing/large-site-managing-crawl-budget?hl=de

16. Google, Googlebot und andere Google Crawler überprüfen, Google Search Central Dokumentation, https://developers.google.com/search/docs/crawling-indexing/verifying-googlebot?hl=de

17. Google, Crawling von URLs der Facettensuche verwalten, Google Search Central Dokumentation, https://developers.google.com/search/docs/crawling-indexing/crawling-managing-faceted-navigation?hl=de