Google hat die Dokumentation zur Indexing API an mehreren Stellen überarbeitet. Auf den ersten Blick wirkt das wie eine kleine redaktionelle Änderung, so eine typische Aufräumaktion in Entwicklerdokumenten. Wenn du aber mit technischer SEO, Jobbörsen, Livestream-Seiten oder automatisierten Indexierungsprozessen arbeitest, solltest du genauer hinschauen. Denn entfernt wurden nicht nur ein paar alte Formulierungen, sondern Hinweise, an denen sich viele über Jahre orientiert haben: Aussagen zur Standard-Quota, zum früheren Freigabeprozess, zur Nutzung neben oder statt Sitemaps und zur anfänglichen Testphase.
Der Kern ist ziemlich einfach, aber leider nicht ganz sauber zu interpretieren: Google hat mehrere Passagen gestrichen, die bisher erklärt haben, dass es für die Indexing API eine anfängliche Standard-Quota zum Testen gibt. Besonders auffällig ist die entfernte Angabe von 200 Anfragen für Onboarding und Tests. Gleichzeitig gibt es Hinweise aus praktischen Tests, dass neue Service Accounts offenbar weiterhin eine Art 200er-Quota sehen können. Genau dieser Widerspruch macht die Änderung so interessant. Aus meiner Erfahrung sind solche Dokumentationsänderungen selten völlig zufällig. Manchmal zieht die Dokumentation der technischen Realität hinterher, manchmal wird sie vorab bereinigt, bevor eine Änderung im Backend tatsächlich sichtbar wird. Und manchmal, ja, manchmal wird schlicht ein alter Prozess entfernt, ohne dass dadurch sofort alles anders funktioniert.
Wenn du die Indexing API bisher als Werkzeug verstanden hast, mit dem du Google schnell über neue oder entfernte URLs informieren kannst, bleibt die wichtigste Einschränkung weiterhin im Raum: Diese API war nie als allgemeiner Beschleuniger für jede beliebige Webseite gedacht. Sie richtet sich vor allem an Inhalte mit kurzer Lebensdauer, insbesondere Stellenanzeigen und Livestream-Videos mit entsprechendem strukturiertem Markup. Genau hier muss man vorsichtig sein. Einige Hinweise auf diese Einschränkung wurden an bestimmten Stellen entfernt, aber auf der zentralen Seite scheint die Begrenzung weiterhin vorhanden zu sein. Ich würde daraus nicht ableiten, dass die API plötzlich für alle Seitentypen freigegeben ist. Das wäre, ehrlich gesagt, eine gewagte Interpretation.
Was sich in der Dokumentation geändert hat
Überarbeitet wurden drei zentrale Bereiche der Dokumentation: der Schnellstart, die Anleitung zur Nutzung der API und die Informationen zu Quota und Preisen. Das klingt technisch und trocken, aber gerade diese drei Bereiche bilden normalerweise den Weg, den du als Entwickler oder SEO gehst, wenn du die API erstmals einrichtest. Du liest zuerst den Schnellstart, prüfst dann, wie du Requests sendest, und landest schließlich bei der Frage: Wie viele Anfragen darf ich eigentlich stellen, und brauche ich dafür eine Freigabe?
Genau an dieser Stelle wurde offenbar aufgeräumt. Google hat angegeben, die Quota-Seite aktualisiert zu haben, damit sie die aktuellen Quota-Limits und den aktuellen Prozess widerspiegelt. Außerdem wurde ein veraltetes Formular entfernt. Das klingt zunächst harmlos. Ein Formular war alt, also wird es entfernt. Fertig. Aber die entfernten Textstellen erzählen eine etwas größere Geschichte.
Früher stand sinngemäß in der Dokumentation, dass die Indexing API eine anfängliche Standard-Quota für Tests bereitstellt und dass für weitere Nutzung sowie für Ressourcenbereitstellung eine zusätzliche Genehmigung nötig sei. Außerdem wurde erklärt, dass du für Quota über diese anfängliche Standardgrenze hinaus ein Formular ausfüllen musstest. Dabei solltest du Details zu deinem Projekt in der Google Cloud Console kennen. Die Quota konnte je nach Qualität der Dokumente steigen oder sinken.
Diese Passagen wurden gestrichen. Und das ist nicht nur Kosmetik. Wenn ein Dokument sagt „du bekommst zunächst eine Standard-Quota und kannst dann eine Erhöhung beantragen“, entsteht ein klarer Erwartungsrahmen. Wenn dieser Satz verschwindet, weißt du plötzlich weniger. Gibt es die Standard-Quota nicht mehr? Gibt es sie technisch noch, aber Google will sie nicht mehr öffentlich so darstellen? Wird der Prozess jetzt vollständig über die Cloud Console abgewickelt? Oder will Google schlicht vermeiden, dass Nutzer die Indexing API als etwas verstehen, worauf man automatisch Anspruch hat?
Mein Bauchgefühl: Es geht hier nicht nur um Formulierungen. Google versucht vermutlich, die Erwartungshaltung rund um diese API zu schärfen. Viele SEOs haben die Indexing API in der Vergangenheit ziemlich kreativ interpretiert. Manche wollten damit alles Mögliche schneller indexieren lassen, auch Inhalte, die eindeutig nicht in den vorgesehenen Anwendungsbereich fallen. Wenn du lange genug im SEO-Bereich unterwegs bist, kennst du diesen Reflex: Gibt es irgendwo eine technische Schnittstelle, wird getestet, ob sie sich zweckentfremden lässt. Das ist nicht immer böse gemeint. Oft ist es einfach Neugier. Aber Google mag solche Grauzonen selten dauerhaft offenlassen.
Die entfernte Standard-Quota ist der spannendste Punkt
Die auffälligste Änderung betrifft die sogenannte Default Quota, also die Standard-Quota. Besonders die frühere Nennung von 200 Anfragen war für viele ein praktischer Orientierungspunkt. Du konntest davon ausgehen: Für das Onboarding und erste Tests gibt es einen kleinen Rahmen, mit dem du arbeiten kannst. Nicht riesig, aber genug, um die Integration zu prüfen.
Diese konkrete Angabe wurde entfernt. Auch die allgemeineren Sätze, dass es eine Standard-Quota für Tests gibt und dass du zur Nutzung der API Genehmigung und Quota beantragen musst, sind an mehreren Stellen verschwunden. Das verändert die Dokumentation spürbar. Früher führte sie dich stärker durch einen Prozess: testen, Genehmigung beantragen, Quota erweitern. Jetzt wirkt das Ganze weniger wie ein offener Onboarding-Pfad und mehr wie ein kontrollierter Dienst, dessen genaue Bedingungen nicht mehr so ausführlich erklärt werden.
Interessant wird es aber durch die Rückmeldungen aus der Praxis. Es wurde getestet, ob ein neuer Service Account weiterhin eine Standard-Quota von 200 erhält. Offenbar ist das zumindest in einigen Fällen weiterhin sichtbar. Das heißt: Die Dokumentation sagt weniger, die technische Oberfläche zeigt aber möglicherweise noch das alte Verhalten. Genau diese Diskrepanz solltest du nicht übersehen.
Aus meiner Erfahrung mit Google-Dokumentationen ist das kein seltener Zustand. Dokumentation, Konsole und tatsächliches Systemverhalten laufen manchmal ein paar Tage, Wochen oder sogar länger auseinander. Ein Entwickler sieht dann in der Cloud Console noch Werte, die offiziell nicht mehr beworben werden. Ein SEO liest in der Dokumentation bereits eine neue, schlankere Darstellung. Und irgendwo dazwischen sitzt du und fragst dich, worauf du dich verlassen sollst.
Die kurze Antwort: Verlass dich nicht blind auf eine sichtbare Standard-Quota. Wenn du die Indexing API für geschäftskritische Abläufe verwendest, solltest du nicht so planen, als seien 200 Requests dauerhaft garantiert. Wenn Google diese Zahl aus der Dokumentation entfernt, ist das ein Signal. Vielleicht bleibt sie technisch bestehen. Vielleicht nicht. Vielleicht gilt sie nur für bestimmte Projektzustände. Vielleicht wird sie nie vollständig abgeschaltet, aber Google möchte nicht mehr, dass daraus ein Anspruch abgeleitet wird.
Das mag kleinlich wirken, ist aber in der Praxis wichtig. Stell dir eine Jobplattform vor, die täglich mehrere tausend Stellenanzeigen aktualisiert und davon ausgeht, dass ein bestimmtes API-Kontingent verfügbar ist. Wenn dann plötzlich der Zugang anders begrenzt wird oder Requests zwar angenommen werden, aber nicht den gewünschten Effekt haben, kann das operative Folgen haben. Nicht unbedingt katastrophal, aber nervig genug. Und genau solche Dinge willst du nicht erst bemerken, wenn dein Monitoring rote Lampen zeigt.
Warum eine entfernte Zahl mehr sagt als viele neue Erklärungen
Bei Dokumentationen sind gestrichene Aussagen manchmal aussagekräftiger als hinzugefügte. Eine neue Erklärung kann PR sein, Klarstellung oder Produktpflege. Eine entfernte konkrete Zahl dagegen ist oft ein Zeichen dafür, dass der Anbieter sich nicht mehr darauf festnageln lassen will. Die frühere 200er-Quota war eine solche Zahl. Sie war greifbar. Du konntest intern sagen: „Für Tests haben wir 200 Requests.“ Jetzt ist diese Sicherheit weg.
Ich würde das nicht dramatisieren, aber ernst nehmen. Es ist ein Unterschied, ob Google sagt: „Du bekommst standardmäßig X“ oder ob du X nur zufällig in einer Konsole siehst. Das eine ist eine dokumentierte Erwartung, das andere ist ein beobachteter Zustand. In technischen Projekten ist dieser Unterschied größer, als er im Alltag klingt.
Die Sitemap-Empfehlung wurde ebenfalls entfernt
Ein zweiter wichtiger Punkt betrifft die Beziehung zwischen Sitemaps und der Indexing API. Im Schnellstart gab es bisher einen Abschnitt, der ungefähr erklärte: Für Websites mit vielen kurzlebigen Seiten, etwa Stellenanzeigen oder Livestream-Videos, empfiehlt sich die Indexing API statt nur Sitemaps, weil sie Googlebot schneller zum Crawlen anstoßen kann als eine aktualisierte Sitemap. Gleichzeitig wurde weiterhin empfohlen, eine Sitemap für die gesamte Website einzureichen.
Auch diese Passage wurde entfernt. Das finde ich persönlich fast genauso interessant wie die Quota-Änderung, weil sie die praktische Einordnung der API betrifft. Früher sagte die Dokumentation ziemlich klar: Die API ist für bestimmte schnelle Fälle besser geeignet als Sitemaps, aber Sitemaps bleiben wichtig für die Gesamtdeckung deiner Seite. Diese Aussage war nützlich. Sie half, die Indexing API nicht als Ersatz für saubere technische SEO zu missverstehen.
Nun fehlt dieser erklärende Kontext. Das bedeutet aber nicht automatisch, dass Sitemaps unwichtig geworden sind. Im Gegenteil. Wenn du eine größere Website betreibst, bleiben saubere Sitemaps weiterhin ein Basiswerkzeug. Die Indexing API ist kein universeller Ersatz für Crawling, interne Verlinkung, Canonicals, Statuscodes, strukturierte Daten und eine stabile Informationsarchitektur. Sie ist eher ein spezieller Kanal, mit dem du Google über bestimmte Ereignisse informierst.
Ein Beispiel aus der Praxis: Wenn du eine Jobbörse betreibst, auf der Stellenanzeigen nach 14 oder 30 Tagen ablaufen, möchtest du Google möglichst schnell mitteilen, wenn eine Anzeige neu ist oder nicht mehr verfügbar. Dafür kann die API grundsätzlich sinnvoll sein, sofern deine Inhalte und Markups in den vorgesehenen Rahmen passen. Deine Sitemap brauchst du trotzdem. Sie hilft Google, die Struktur und Breite deiner Website zu verstehen. Sie ist die Landkarte. Die API ist eher der kurze Zuruf: „Schau dir diese URL bitte zeitnah an.“ Beides miteinander zu verwechseln, führt selten zu guten Ergebnissen.
Dass Google die explizite Sitemap-Passage entfernt hat, könnte verschiedene Gründe haben. Vielleicht wollte man die Dokumentation straffen. Vielleicht war die Formulierung zu stark, weil sie den Eindruck erweckte, die API sei der bevorzugte Weg für alle schnelllebigen Inhalte. Vielleicht passt die Aussage nicht mehr exakt zum aktuellen Prozess. Sicher ist nur: Der klare Hinweis, wie API und Sitemap zusammenspielen, ist verschwunden. Und wenn du eine Implementierung planst, musst du diese Abwägung jetzt stärker selbst treffen.
Gilt die API weiterhin nur für JobPosting und BroadcastEvent?
Ein heikler Punkt ist die Zweckbindung der Indexing API. In der entfernten Quota-Passage stand ausdrücklich, dass die API nur genutzt werden kann, um Seiten mit JobPosting oder BroadcastEvent innerhalb eines VideoObject crawlen zu lassen. Genau diese Formulierung wurde an einigen Stellen entfernt. Auf der Hauptseite scheint die Einschränkung aber weiterhin vorhanden zu sein.
Das ist so eine Stelle, an der man schnell zu viel hineinliest. Manche würden sagen: Wenn Google die Einschränkung an mehreren Stellen entfernt, öffnet sich die API vielleicht für mehr Seitentypen. Ich wäre da sehr vorsichtig. Solange die Kernbeschreibung der API weiterhin auf Stellenanzeigen und Livestreams ausgerichtet ist, solltest du nicht davon ausgehen, dass jetzt plötzlich normale Blogposts, Produktseiten oder Kategorieseiten unterstützt werden.
Natürlich kannst du testen. Viele tun das. Aber testen heißt nicht, dass Google den Einsatz offiziell unterstützt oder dass ein Request tatsächlich den gewünschten Indexierungsprozess auslöst. Das ist ein wichtiger Unterschied. Ein API-Request kann technisch erfolgreich sein, also einen Status zurückgeben, der auf den ersten Blick gut aussieht. Trotzdem heißt das noch lange nicht, dass die URL effektiv in Googles Indexierungswarteschlange landet oder bevorzugt verarbeitet wird.
Genau dazu gab es auch eine interessante Beobachtung: Ein Testwerkzeug konnte offenbar einen erfolgreichen Status im Sandbox-Kontext validieren, während ein anschließender getMetadata-Aufruf einen 404 lieferte. Interpretiert wurde das so, dass die Anfrage möglicherweise gar nicht in der eigentlichen Indexierungswarteschlange ankommt. Das ist kein endgültiger Beweis für alle Fälle, aber es zeigt gut, warum du API-Antworten nicht zu oberflächlich lesen solltest.
Ein erfolgreicher Request ist noch keine Indexierung
Das ist vielleicht der wichtigste praktische Merksatz: Ein API-Erfolg bedeutet nicht automatisch, dass Google indexiert. Eigentlich wissen wir das auch aus anderen Bereichen. Eine URL in einer Sitemap bedeutet nicht, dass sie indexiert wird. Ein Crawling bedeutet nicht, dass sie rankt. Eine erfolgreiche technische Übermittlung bedeutet nicht, dass Google die URL für wertvoll hält.
Bei der Indexing API ist diese Unterscheidung besonders wichtig, weil das Wort „Indexing“ Erwartungen weckt. Es klingt so, als würdest du Google direkt sagen: „Bitte indexiere das.“ Tatsächlich meldest du Google aber eher eine URL-Aktualisierung oder Entfernung im Rahmen eines bestimmten Systems. Google entscheidet weiterhin selbst, was gecrawlt, verarbeitet und indexiert wird. Und wenn die URL nicht in den unterstützten Anwendungsbereich fällt, kann es gut sein, dass wenig oder nichts passiert, auch wenn dein Request technisch nicht komplett scheitert.
Ich habe in Projekten schon mehrfach gesehen, dass technische Teams APIs zu wörtlich nehmen. Da steht „success“, also gilt der Prozess als erfolgreich. Aus SEO-Sicht ist das gefährlich. Du musst immer die Wirkung prüfen: Wurde gecrawlt? Wurde die URL verarbeitet? Taucht sie im Index auf? Ändert sich etwas im Bericht? Und wenn nicht, liegt es an der API, am Inhalt, am Markup, am Timing oder an Googles Bewertung? Das ist mühsam, aber notwendig.
Was du jetzt praktisch daraus machen solltest
Wenn du die Indexing API gar nicht verwendest, musst du vermutlich nichts überstürzt tun. Trotzdem lohnt es sich, die Entwicklung im Hinterkopf zu behalten, besonders wenn du irgendwann automatisierte Indexierungssignale in deine technische SEO einbauen willst. Wenn du die API bereits nutzt, solltest du etwas genauer hinschauen.
Prüfe zuerst, ob deine Nutzung wirklich zum vorgesehenen Zweck passt. Arbeitest du mit Stellenanzeigen oder Livestream-Inhalten und hast du das passende strukturierte Markup sauber implementiert? Dann bist du näher am offiziellen Anwendungsfall. Nutzt du die API dagegen für andere Seitentypen, solltest du ehrlich zu dir sein: Das ist wahrscheinlich ein Graubereich oder sogar außerhalb der vorgesehenen Nutzung. Wenn es zufällig funktioniert, schön. Aber plane nicht so, als wäre das eine verlässliche Grundlage.
Dann solltest du deine Quota-Annahmen überprüfen. Wenn du irgendwo intern dokumentiert hast, dass es standardmäßig 200 Anfragen für Tests gibt, ist diese Aussage jetzt wackeliger geworden. Schreibe lieber: Derzeit kann in bestimmten Konfigurationen eine entsprechende Quota sichtbar sein, aber die öffentliche Dokumentation formuliert das nicht mehr so eindeutig. Klingt sperrig, ist aber näher an der Wahrheit.
Außerdem würde ich Monitoring einbauen, falls du das noch nicht hast. Nicht nur auf HTTP-Statuscodes, sondern auf die nachgelagerte Wirkung. Werden URLs tatsächlich zeitnah von Googlebot besucht? Verändert sich der Status in deinen eigenen Logs? Stimmen API-Aufrufe und Crawling-Aktivität ungefähr zusammen? Gerade bei kurzlebigen Inhalten ist Timing entscheidend. Wenn eine Stellenanzeige erst indexiert wird, wenn sie fast abgelaufen ist, bringt dir die schönste Integration wenig.
Und bitte vergiss nicht die Basics. Sitemaps, interne Verlinkung, Serverantworten, Canonicals, Robots-Regeln und strukturierte Daten bleiben entscheidend. Eine API kann keine schlechte technische Grundlage retten. Sie kann höchstens auf einer soliden Basis zusätzliche Signale liefern. Das klingt altmodisch, aber es stimmt. Ich habe noch keine API gesehen, die dauerhaft schlechte Informationsarchitektur kompensiert.
Mein vorsichtiger Blick auf die Änderung
Ich würde die Änderung nicht als große Öffnung der Indexing API verstehen. Eher im Gegenteil: Die entfernten Hinweise wirken auf mich wie eine Bereinigung alter Prozesse und eine Reduzierung konkreter Versprechen. Besonders die entfernte Standard-Quota und das verschwundene Formular deuten darauf hin, dass Google den Prozess anders darstellen oder enger kontrollieren möchte.
Gleichzeitig wäre es übertrieben zu sagen, dass sich technisch schon alles geändert hat. Es gibt Hinweise, dass neue Service Accounts weiterhin eine 200er-Quota sehen können. Vielleicht ist da nur die Dokumentation schneller als der Code. Vielleicht bleibt die Quota bestehen, wird aber nicht mehr offensiv erklärt. Vielleicht wird der Zugang künftig stärker über die Cloud Console gesteuert. Im Moment ist das Bild nicht ganz rund, und genau das solltest du in deine Entscheidungen einpreisen.
Für dich heißt das: Bleib pragmatisch. Nutze die Indexing API, wenn dein Anwendungsfall passt. Dokumentiere deine Annahmen. Teste das tatsächliche Verhalten. Und baue keine SEO-Strategie auf einer Zahl auf, die aus der offiziellen Beschreibung verschwunden ist.
Die wichtigste Einordnung in einem Satz
Die Überarbeitung der Dokumentation macht die Indexing API nicht automatisch nutzlos und auch nicht plötzlich universell einsetzbar. Sie nimmt aber einige frühere Sicherheiten aus dem Text heraus. Besonders die Aussagen zur Standard-Quota, zum Testkontingent von 200 Requests, zum alten Freigabeformular und zur Rolle der Sitemaps wurden entfernt oder deutlich entschärft.
Wenn du technisch verantwortlich bist, solltest du daraus keine Panik ableiten, sondern eine saubere Prüfung. Welche Requests sendest du? Für welche Seitentypen? Welche Quota siehst du tatsächlich? Was kommt bei Googlebot an? Und was davon ist dokumentiert, statt nur zufällig beobachtet?
Manchmal sind solche Dokumentationsänderungen nur ein kleines Aufräumen. Manchmal sind sie ein Vorzeichen. Hier würde ich sagen: Es ist mindestens ein Signal, genauer hinzusehen. Nicht hektisch, aber aufmerksam. Denn bei APIs, die direkt mit Googles Crawling- und Indexierungsprozessen verbunden sind, steckt der eigentliche Unterschied oft nicht in der großen Ankündigung, sondern in einem entfernten Satz, den vorher kaum jemand ernst genommen hat.
