Google Indexing API für Stellenanzeigen: Voraussetzungen, Quoten und der teuerste Fehler

Die Google Indexing API darf ausschließlich für Seiten mit JobPosting-Auszeichnung oder mit einem BroadcastEvent in einem VideoObject verwendet werden – für alle anderen Seitentypen ist sie nicht vorgesehen. Das steht so in der Dokumentation und wird in der Praxis regelmäßig ignoriert, mit Folgen bis zum Entzug des API-Zugriffs.

Für Unternehmen mit hoher Stellenfrequenz ist die Schnittstelle trotzdem sinnvoll: Sie meldet neue und entfernte Anzeigen direkt an Google, statt auf den nächsten Crawl zu warten. Was sie dagegen nicht liefert, ist eine Zusage, wann indexiert wird. Dieser Text nennt die dokumentierten Voraussetzungen, Quoten und Pflichtfelder – und den Fehler, der als einziger eine manuelle Maßnahme nach sich ziehen kann.

Geprüft: 18. Juli 2026 · Nächste Prüfung: Q1 2027

Wofür darf die Indexing API verwendet werden?

Ausschließlich für Seiten mit JobPosting-Auszeichnung oder mit einem BroadcastEvent innerhalb eines VideoObject. Die Dokumentation formuliert das als Einschränkung, nicht als Empfehlung: Die Schnittstelle könne nur für das Crawling von Seiten mit einem dieser beiden Typen verwendet werden.

Das ist deshalb wichtig, weil die API in der Praxis häufig zweckentfremdet wird – als vermeintliche Abkürzung für die Indexierung beliebiger Seiten. Google weist darauf hin, dass alle Einreichungen einer Spam-Prüfung unterliegen und dass Versuche, die Schnittstelle zu missbrauchen oder Kontingente über mehrere Konten zu umgehen, zum Entzug des Zugriffs führen können. Eine Aussage, dass daraus ein Ranking-Nachteil entsteht, gibt es nicht – wohl aber die klare Ansage zum Zugriffsentzug.

Wer den generellen Indexierungsstand seiner Website verbessern will, findet die wirksamen Ansatzpunkte ohnehin an anderer Stelle – bei Crawlbarkeit, interner Verlinkung und Seitenqualität, wie sie die SEO-Grundlagen beschreiben.

Für alle anderen Seitentypen bleiben die dokumentierten Wege: das URL-Prüftool für wenige einzelne Adressen und die Sitemap für viele Adressen auf einmal. Beim Attribut lastmod gilt dabei die Einschränkung, dass Google es nur verwendet, wenn es durchgängig und nachprüfbar korrekt ist – eine aktualisierte Jahreszahl im Impressum zählt ausdrücklich nicht als wesentliche Änderung.

Wie schnell indexiert die API wirklich?

Google macht keine Zeitzusage. Die Dokumentation sagt, die Indexing API veranlasse den Googlebot, Seiten früher zu crawlen als eine Sitemap-Aktualisierung, und eine erfolgreiche Antwort bedeute, dass Google versuchen könne, die Adresse bald erneut zu crawlen. Verbreitete Angaben wie „innerhalb von Stunden statt Tagen" finden sich in keiner offiziellen Quelle.

Verstärkt wird das durch eine Einschränkung bei der Statusabfrage: Sie zeigt lediglich, ob die Übermittlung erfolgreich war – nicht, wann Google indexiert oder entfernt. Wer also ein Dashboard bauen möchte, das die Indexierungsdauer misst, kann das nicht über die API tun, sondern nur über die Beobachtung in der Search Console.

Die ehrliche Erwartungshaltung lautet deshalb: Die API ist ein Meldeweg, der schneller ist als das Warten auf den nächsten regulären Crawl. Ein Zeitversprechen gegenüber der Personalabteilung sollte man daraus nicht ableiten – wohl aber die berechtigte Erwartung, dass frisch gemeldete Stellen früher erfasst werden als ohne Meldung.

Welche Quoten gelten?

Das Standard-Kontingent beträgt laut Dokumentation 200 Publish-Anfragen pro Tag und Projekt, wobei sowohl Aktualisierungen als auch Löschungen zählen. Die Tagesquote setzt sich um Mitternacht pazifischer Zeit zurück, sodass neues Kontingent bis zu 24 Stunden brauchen kann. Die Nutzung der API ist kostenfrei.

Kontingent	Standardwert	Hinweis
Publish-Anfragen pro Tag	200	Aktualisierungen und Löschungen zusammen
Metadaten-Anfragen pro Minute	180	Statusabfragen
Anfragen pro Minute gesamt	380	Projektbezogen
Aufrufe je Batch-Anfrage	100	Kontingent wird auf URL-Ebene gezählt

Eine Erhöhung lässt sich über ein Formular beantragen. Bemerkenswert ist die Begründungslogik, die Google dafür nennt: Das Kontingent könne sich abhängig von der Dokumentqualität erhöhen oder verringern. Wer also viele dünne oder abgelaufene Anzeigen einreicht, riskiert nicht nur eine Ablehnung des Erhöhungsantrags, sondern potenziell weniger Kontingent als zuvor.

Ein häufiges Missverständnis betrifft die Batch-Funktion: Sie spart HTTP-Aufrufe, aber kein Kontingent. Da auf URL-Ebene gezählt wird, verbrauchen 100 gebündelte Meldungen genauso viel Tageskontingent wie 100 einzelne. Für sehr große Stellenportale ist das die eigentliche Planungsgröße.

Voraussetzungen und Einrichtung

Die Einrichtung umfasst laut Dokumentation vier Schritte: ein Projekt in der Google Cloud Console anlegen, ein Dienstkonto erstellen, dieses Dienstkonto als Inhaber der Website hinzufügen und ein Zugriffstoken abrufen. Für den Schlüssel des Dienstkontos empfiehlt Google das JSON-Format.

Der Schritt, an dem es in der Praxis am häufigsten hakt, ist der dritte: Die Website muss in der Search Console bestätigt sein, und die E-Mail-Adresse des Dienstkontos muss dort als Inhaber eingetragen werden. Diese Adresse endet auf iam.gserviceaccount.com und wirkt für Personen, die sie zum ersten Mal sehen, wie ein Fremdzugriff – entsprechend oft wird sie von IT- oder Marketing-Teams zunächst abgelehnt. Es lohnt sich, diesen Schritt vorab zu erklären, statt ihn kommentarlos anzufordern. Wer die Property-Struktur in der Search Console ohnehin überprüft, findet im Search-Console-Leitfaden die passenden Grundlagen dazu.

Die vier Aktionen der Schnittstelle

Die API kennt vier Operationen: eine Adresse als aktualisiert melden, eine Adresse als entfernt melden, den Status einer Anfrage abrufen und mehrere Anfragen bündeln. Für Löschmeldungen gilt eine Bedingung, die gern übersehen wird: Die Adresse muss vorher tatsächlich einen 404- oder 410-Statuscode liefern oder die Seite muss eine noindex-Anweisung enthalten. Eine Löschmeldung für eine weiterhin erreichbare Seite ist damit wirkungslos.

JobPosting: Pflichtfelder und die häufigsten Fehler

Fünf Felder sind im JobPosting-Markup verpflichtend: datePosted, description, hiringOrganization, jobLocation und title. Die Search-Central-Dokumentation nennt dazu Anforderungen, die über die reine Anwesenheit hinausgehen – und genau dort entstehen die meisten Beanstandungen.

Feld	Anforderung	Häufiger Fehler
title	Der Titel der Stelle, nicht der Titel der Anzeige	Stellencodes, Orte, Daten, Gehälter oder Firmennamen im Titel
description	Vollständige Darstellung der Stelle, mit HTML-Formatierung	Identisch mit dem Titel oder nur ein Satz
datePosted	Datum im ISO-8601-Format	Freitextdatum oder fehlende Aktualisierung bei Neuveröffentlichung
hiringOrganization	Name des Unternehmens, nicht des Standorts	Filial- oder Abteilungsbezeichnung statt Unternehmensname
jobLocation	Muss addressCountry enthalten	Land fehlt; bei reiner Remote-Arbeit falsches Feld verwendet

Eine Klarstellung zu einem oft als Pflicht bezeichneten Feld: validThrough ist nur dann erforderlich, wenn die Anzeige ein Ablaufdatum hat. Google weist ausdrücklich darauf hin, dass die Eigenschaft nicht angegeben werden soll, wenn eine Stelle nie abläuft oder der Ablaufzeitpunkt unbekannt ist. Wer sie prophylaktisch mit einem Fantasiedatum füllt, erzeugt genau das Problem, das er vermeiden wollte.

Bei vollständig ortsunabhängigen Stellen greift eine eigene Regelung: Dort ist jobLocationType zu verwenden, und jobLocation entfällt, sofern applicantLocationRequirements gesetzt ist. Diese Kombination sauber umzusetzen, gehört zu den Punkten, die bei einer technisch sauberen Implementierung von strukturierten Daten am ehesten schiefgehen.

Abgelaufene Stellen: das Risiko einer manuellen Maßnahme

Google erlaubt abgelaufene Stellenanzeigen nicht und weist ausdrücklich darauf hin, dass ein Versäumnis bei der rechtzeitigen Behandlung zu einer manuellen Maßnahme führen kann. Das ist der einzige Punkt dieses Themas mit echtem Risiko – und er betrifft ausgerechnet den Prozessschritt, der in vielen Unternehmen niemandem zugeordnet ist.

Drei Wege sind laut Dokumentation zulässig: die Eigenschaft validThrough mit einem Datum in der Vergangenheit befüllen, die Seite vollständig entfernen, sodass sie 404 oder 410 liefert, oder die JobPosting-Auszeichnung von der Seite entfernen. Anschließend soll Google über die Indexing API informiert werden.

Genau hier liegt der eigentliche Wert der Schnittstelle, und er wird meist übersehen: Sie ist für das Entfernen mindestens so nützlich wie für das Melden neuer Stellen. Ein Karriereportal, das Stellen zuverlässig meldet, aber besetzte Positionen wochenlang stehen lässt, sammelt genau die Risiken an, vor denen die Dokumentation warnt – und verärgert zusätzlich Bewerber, die sich auf längst vergebene Stellen bewerben.

Ist Google for Jobs in Deutschland verfügbar?

Ja. Die Dokumentation listet Deutschland unter den Ländern, in denen die Job-Suchfunktion verfügbar ist. Eine Ankündigung zur Einstellung oder zu einer Anpassung wegen des Digital Markets Act gibt es nicht: Die Compliance-Mitteilungen von Google zum DMA behandeln Shopping, Flüge, Hotels und Restaurants, nicht Stellenanzeigen.

Diese Klarstellung ist nützlich, weil im Zuge der DMA-Debatte regelmäßig vermutet wird, Google werde Job-Ergebnisse in Europa zurückfahren. Für eine solche Erwartung gibt es derzeit keine dokumentierte Grundlage. Wer die Verfügbarkeit im Blick behalten will, prüft die Länderliste in der Dokumentation – sie wurde in der Vergangenheit nachweislich angepasst, als ein Land aus der Liste entfernt wurde.

Einführung in vier Schritten

Schritt drei entscheidet darüber, ob die Einführung im Alltag trägt. Eine Meldung, die manuell ausgelöst werden muss, wird in der zweiten Woche vergessen. Sinnvoll ist die Kopplung an das Redaktions- oder Bewerbermanagementsystem: Wird eine Stelle veröffentlicht, geht die Meldung automatisch raus; wird sie auf „besetzt" gesetzt, folgt die Löschmeldung. Erst dann ist der Prozess robust gegen Urlaub, Wechsel und Zeitdruck.

Zur Kontrolle gehört ein Blick in die Berichte der Search Console, weil die API selbst keinen Aufschluss über den Indexierungsstand gibt. Wie sich Indexierungsprobleme dort systematisch lesen lassen, behandelt der Beitrag zum Indexierungsbericht der Search Console.

Häufig gestellte Fragen

Wofür darf die Indexing API verwendet werden?

Ausschließlich für Seiten mit JobPosting-Auszeichnung oder mit einem BroadcastEvent in einem VideoObject. Für andere Seitentypen ist sie laut Dokumentation nicht vorgesehen.

Wie schnell wird über die API indexiert?

Google macht keine Zeitzusage. Die Dokumentation spricht davon, dass ein Crawling früher angestoßen wird als über eine Sitemap-Aktualisierung. Konkrete Zeitangaben sind nicht dokumentiert.

Welche Quoten gelten?

Standardmäßig 200 Publish-Anfragen pro Tag und Projekt, 180 Metadaten-Anfragen pro Minute und 380 Anfragen pro Minute insgesamt. Eine Erhöhung ist über ein Formular beantragbar, die Nutzung ist kostenfrei.

Spart eine Batch-Anfrage Kontingent?

Nein. Bis zu 100 Aufrufe lassen sich bündeln, das Kontingent wird aber auf URL-Ebene gezählt. Gebündelte Meldungen sparen HTTP-Aufrufe, kein Tageskontingent.

Welche Felder sind im JobPosting-Markup Pflicht?

datePosted, description, hiringOrganization, jobLocation und title. Das Feld validThrough ist nur erforderlich, wenn die Anzeige ein Ablaufdatum hat.

Was passiert mit abgelaufenen Stellenanzeigen?

Google erlaubt sie nicht. Zulässig sind ein Datum in der Vergangenheit bei validThrough, das Entfernen der Seite mit 404 oder 410 oder das Entfernen der Auszeichnung. Ein Versäumnis kann laut Dokumentation eine manuelle Maßnahme nach sich ziehen.

Ist Google for Jobs in Deutschland verfügbar?

Ja, Deutschland ist in der Dokumentation als verfügbares Land gelistet. Eine Ankündigung zur Einstellung oder DMA-bedingten Änderung gibt es nicht.

Fazit: Der Ablaufprozess ist wichtiger als das Tempo

Die Indexing API ist ein enger, gut dokumentierter Spezialweg – nicht die Abkürzung zur schnellen Indexierung, für die sie häufig gehalten wird. Sie gilt für zwei Inhaltstypen, sie liefert kein Zeitversprechen, und ihr Kontingent ist mit 200 Meldungen pro Tag für große Portale spürbar begrenzt.

Wer sie einführt, sollte deshalb die Prioritäten umdrehen: Zuerst das Markup in Ordnung bringen, dann den Prozess für abgelaufene Stellen verbindlich regeln, und erst danach über die Beschleunigung neuer Veröffentlichungen nachdenken. Diese Reihenfolge entspricht dem tatsächlichen Risiko – denn eine unentdeckte Lücke im Ablaufmanagement kostet mehr als ein paar Stunden späterer Indexierung.