„Discovered – currently not indexed" und „Crawled – currently not indexed" sind die beiden häufigsten Zeilen im Bericht „Seitenindexierung" der Search Console – und die am meisten missverstandenen. Sie sehen aus wie ein technischer Fehler, sind aber in Wirklichkeit eine Prioritäts- und Qualitätsentscheidung, die Google über deine Seiten getroffen hat. Härteres Einreichen ändert daran nichts. Die Ursache zu beheben schon.
Dieser Leitfaden ist ein kompletter Loop, den du komplett an den Hermes Agent abgeben kannst: URL-Liste ziehen, jede Seite prüfen, die echte Ursache triagieren, die Reparatur-Warteschlange freigeben und nur die Seiten, die es wert sind, indexiert zu werden, über die Google Indexing API einreichen. Am Ende hast du eine wiederholbare wöchentliche Pipeline – keine einmalige Klick-Session.
Was du danach hast
- Eine klassifizierte Inventarliste: URLs, die in „discovered" hängen, gecrawlte, aber nicht indexierte URLs und URLs, die du nie hättest einreichen sollen
- Eine freigegebene Liste für die Indexing API und eine Skip-Liste mit Begründung
- Ein Verifikationsschritt, der zeigt, ob dein Einreichen wirklich gewirkt hat
Was du brauchst: einen installierten, funktionierenden Hermes Agent (hermes chat startet eine Session. Aktuelle Installationsschritte: offizielle Doku unter hermes-agent.nousresearch.com/docs), einen Search-Console-Besitz, an dem du Eigentümer bist, und zwei Sätze Google-Zugangsdaten (einer zum Lesen der GSC, einer für die Indexing API). Erst-Setup etwa 60–90 Minuten, danach etwa 15 Minuten pro Woche. „Fertig" bedeutet: Deine eingereichten URLs zeigen innerhalb von zwei Wochen eine echte Statusänderung in der Inspection API – oder du hast belastbare Beweise, warum nicht.
Die beiden Status richtig lesen
Google steckt nicht an deiner Website fest. Es hat eine Entscheidung getroffen – und der Status sagt dir, welche.
Status | Was es wirklich bedeutet | Häufige Ursachen | Wann einreichen |
|---|---|---|---|
Discovered – currently not indexed | Google kennt die URL (aus Sitemap oder Links), hat sie aber noch nicht gecrawlt | Niedrige Crawl-Priorität, schwache oder fehlende interne Links, Crawl-Budget-Druck auf großen Seiten, neue Website, langsames/schweres JS-Rendering, häufig wechselnde Sitemaps | Einmal einreichen, nachdem du die Prioritätssignale verbessert hast (vor allem interne Links) |
Crawled – currently not indexed | Google hat die URL abgerufen, aber entschieden, sie nicht zu indexieren | Duplikat oder Fast-Duplikat, dünner Inhalt, canonical auf andere URL, noindex zum Crawl-Zeitpunkt, Soft 404, als geringwertig eingestuft | Nur wenn du tatsächlich etwas geändert hast: Inhalt, canonical oder noindex |
Indexed | Ist im Index | — | Nicht einreichen |
Excluded | Gecrawlt und absichtlich ausgeschlossen (noindex, canonical, Duplikat-Auswahl, Blockierung) | — | Nicht einreichen; prüfen, ob der Ausschluss beabsichtigt ist |
In einem Satz: Reiche nur URLs ein, die du tatsächlich geändert hast oder die einen zweiten Blick verdienen. Die Indexing API ist ein Benachrichtigungskanal, kein Ranking-Override. Eine dünne Seite zehnmal einzureichen liefert zehnmal dasselbe Urteil.
Warum es ein Agent machen soll
Der „Indexierung anfragen"-Button der GSC hat keine öffentliche API – es gibt also keinen offiziellen Weg, ihn per Skript zu drücken. Die nächstliegende Automatisierung ist die Google Indexing API, die URL-Benachrichtigungen direkt annimmt. Ein Agent ist hier aus drei Gründen wertvoll:
- Der Loop ist mechanisch und lang: Inventar → Prüfen → Klassifizieren → Reparieren → Einreichen → Verifizieren. Woche für Woche.
- Er braucht einen Audit-Trail: Du brauchst eine Datei, die zeigt, welche URLs wann und warum eingereicht wurden.
- Er braucht ein Freigabe-Gate: Der Teil, der auf Google schreibt, gehört von einem Menschen geprüft. Hermes ist genau um diese Trennung herum gebaut – mit Skills, Projektordnern und Freigaberegeln.
Was du vorher brauchst
- Hermes Agent installiert. Prüfe mit
hermes chat, bevor es weitergeht. - Ein GSC-Besitz, an dem du Eigentümer bist. Im Format
sc-domain:example.com(nicht die vollständige URL). - Lesezugriff: Ein Google-Cloud-OAuth-Client (Client-ID + Secret) für die Search Console API. Die GSC-Skill-Skripte nutzen ihn für Sitemaps, Search Analytics und URL-Prüfung.
- Schreibzugriff: Ein Google-Cloud-Projekt mit aktivierter Indexing API und ein Service-Account-JSON-Key. Füge die Service-Account-E-Mail unter GSC → Einstellungen → Nutzer und Berechtigungen als Eigentümer hinzu. Wenn das Einreichen 403 liefert, fehlt genau dieser Schritt.
- Python 3 und
pip install google-auth google-api-python-client. - Ein Projektordner. Zum Beispiel
/hermes-seo-projectmitcontext/,data/,qa/und einerapproval-rules.md, die festschreibt, dass der Einreich-Schritt immer eine menschliche Unterschrift braucht.
Schritt 1: URL-Inventar aufbauen
Kopiere die beiden GSC-Skills in Hermes' Skill-Verzeichnis (~/.hermes/skills): den Lese-Skill (Sitemaps, Search Analytics, URL-Prüfung) und den Indexing-Skill (Einreich-Skript). Wenn der Harness Skills katalogisiert, kannst du sie auch über skill_view laden.
Bitte Hermes dann in einer Chat-Session im Projektordner:
Liste alle Sitemaps von sc-domain:example.com auf, ziehe jede URL mit ihrem lastmod und schreibe sie in data/url-inventory.csv. Markiere jede Sitemap, deren Abruf fehlschlägt.
Hermes führt die Sitemap-Befehle über das Terminal-Tool aus und schreibt die CSV. Gute Ausgabe: eine deduplizierte CSV mit URL, lastmod und Quell-Sitemap. Qualitätscheck: Fünf Zeilen stichprobenartig prüfen und die Gesamtzahl mit dem Sitemap-Bericht der GSC abgleichen. Wenn die Liste leer ist oder die Authentifizierung fehlschlägt, den GSC-Auth-Flow erneut durchlaufen; das Lese-Skript braucht einen frischen OAuth-Token.
Schritt 2: Prüfen und klassifizieren
Jetzt prüft der Agent die Inventarliste in Batches über die URL Inspection API und holt für jede Seite den aktuellen Coverage-Status. Bitte ihn um die nächste Stufe:
Prüfe jede URL in data/url-inventory.csv. Teile sie in drei Dateien: data/to-submit.txt (nicht indexiert und eine Einreichung wert), data/skip.txt (mit einer Begründung pro URL) und data/needs-fix.txt (nicht indexiert und an etwas hängend, das wir ändern können).
Die Inspection API hat Rate Limits pro Property (aktuelles Kontingent im Google Cloud Console prüfen; mehrere Tausend pro Tag, aber nicht unendlich). Bei großen Websites begrenze diese Runde auf URLs mit dem neuesten lastmod – also die, die du dieses Quartal wirklich verändert hast. Qualitätscheck: Stichprobe aus der Skip-Liste. Sie sollte überwiegend aus noindex, auf andere URLs zeigenden canonicals und Duplikaten bestehen – nicht aus Seiten, die dir wichtig sind. Wenn bei einer Website mit Tausenden URLs needs-fix leer bleibt, hat die Inventar-Stufe wahrscheinlich Seiten verpasst. Vergrößere den Eingabebereich.
Schritt 3: Vor dem Einreichen triagieren
Der Schritt, den alle überspringen. Ordne die hängenden URLs Ursache und Reparatur zu – in dieser Reihenfolge:
Ursache | Reparatur | Nach der Reparatur einreichen? |
|---|---|---|
Die Seite hat keinen einzigen internen Link | Kontextuell passende Links von indexierten Seiten ergänzen | Ja |
Neue Website oder neue Seite | Nichts zu reparieren; einmal einreichen und 1–2 Wochen warten | Ja, genau einmal |
Durch robots.txt blockiert | Blockade für den Pfad aufheben | Ja |
Gecrawlt, aber Duplikat oder dünn | Umschreiben, zusammenführen oder löschen | Nur nach echter Inhaltsänderung |
canonical zeigt auf andere URL | canonical korrigieren, wenn falsch; bewusst gesetzt: diese URL nicht mehr einreichen | Nur nach Korrektur |
noindex zum Crawl-Zeitpunkt | noindex entfernen und Google neu crawlen lassen | Ja, nach dem Entfernen |
Soft 404, wertlose Pagination/Archive | Seite reparieren oder löschen | Nein – dauerhaft überspringen |
Lass Hermes die Reparatur-Warteschlange als Tabelle vorbereiten: URL, vermutete Ursache, Beweis (Prüfergebnis oder Inhaltscheck), empfohlene Aktion, Risikostufe. Gib jede Zeile im Chat frei. Deine approval-rules.md sollte das zur Pflicht machen: Der Agent bereitet vor, du gibst frei, und nichts über niedrigem Risiko wird ohne Unterschrift eingereicht.

Das Freigabe-Gate trennt die Vorarbeit des Agents vom Schreib-Schritt.
Die Reparaturen selbst sind normale SEO-Arbeit: Inhalte umschreiben, canonicals bereinigen, interne Links setzen. Diese Pipeline übernimmt die Einreich-Hälfte. Die Reparatur-Hälfte behandeln die Audit- und Refresh-Artikel der Hermes-Serie.

Die Einreich-Liste ist die Schnittmenge aus „reparierbar" und „indexierungswürdig".
Schritt 4: Über die Indexing API einreichen
Sobald die Warteschlange freigegeben ist, lege die URLs in data/approved-urls.txt und lass Hermes den Indexing-Skill ausführen:
python3 ~/.hermes/skills/gsc-indexing/scripts/index_submit.py check-auth
python3 ~/.hermes/skills/gsc-indexing/scripts/index_submit.py submit --urls-file data/approved-urls.txtDer Standard-Benachrichtigungstyp ist URL_UPDATED, gedacht für neue oder geänderte Seiten. Drei Zahlen zum Merken: Das Standard-Kontingent ist 200 URLs pro Tag, 600 Requests pro Minute – und 403 bedeutet, der Service Account ist nicht Eigentümer der Property. Wenn die freigegebene Liste 200 überschreitet, teile auf mehrere Tage auf; die restlichen Batches kann Hermes planen.
Reiche niemals bereits indexierte Seiten oder die Skip-Liste ein. Verschwendete Benachrichtigungen verbrennen nur Kontingent und erzeugen Rauschen.
Schritt 5: Verifizieren und warten
Der status direkt nach dem Einreichen sagt dir nur, ob Google Metadaten zu der Benachrichtigung hat – nicht, ob die Seite indexiert ist. Die echte Bestätigung kommt Tage später.
Bitte Hermes 3–7 Tage nach dem Batch:
Prüfe die URLs in data/approved-urls.txt erneut und melde Statusänderungen gegenüber der letzten Ausführung.
Ein gesunder Verlauf ist discovered → crawled → indexed. So sieht das über Wochen aus: Die Nicht-indexiert-Liste schrumpft, und deine tatsächlichen Reparaturen (neue interne Links, umgeschriebener Text) tauchen im Index auf. Denk daran: GSC-Daten laufen einige Tage nach, und Google re-crawlt nach eigenem Zeitplan. URLs, die nach echten Reparaturen 10–14 Tage in „Crawled – currently not indexed" bleiben, sind ein Qualitätssignal, kein Einreich-Problem – eskaliere sie zur Content-Arbeit.
Den Loop am Laufen halten
Mach die Pipeline zur Wochenroutine: Seit dem letzten Lauf neue oder aktualisierte URLs → Prüfen → Klassifizieren → Triagieren → Freigeben → Einreichen → Protokollieren. Hermes kann den read-only Teil (Inventar, Prüfung, Klassifizierung) per Zeitplan ohne Aufsicht laufen lassen und dir die Warteschlange jeden Montag präsentieren. Der Einreich-Schritt bleibt hinter dem Freigabe-Gate, mit einem laufenden Log in qa/indexing-log.md: Einreichdatum, URL, Benachrichtigungstyp, Ergebnis. Sechs Monate Log sind die einzige ehrliche Messung, ob die Pipeline funktioniert.
Ehrliche Grenzen
- Google dokumentiert die Indexing API für Seiten mit
JobPosting- oderBroadcastEvent-Structured Data. Sie für normale Seiten zu nutzen, ist verbreitete SEO-Praxis, aber Google garantiert für keinen Seitentyp Indexierung oder Support. - Der „Indexierung anfragen"-Button hat keine öffentliche API. Die Indexing API ist die nächstliegende Automatisierung, nicht derselbe Button.
- Einreichen schafft keine Priorität. Bleibt eine Seite nach Reparieren, Einreichen und Warten nicht indexiert, ist die nächste Antwort die Inhaltsqualität – nicht eine weitere Benachrichtigung.
FAQ
Funktioniert die Indexing API für normale Seiten? Sie nimmt jede URL an, die du schickst. Die offizielle Google-Dokumentation richtet sich an JobPosting- und BroadcastEvent-Seiten, also behandle normale Einreichungen als Best-Effort: hilfreich, üblich, aber nie garantiert.
Warum bleibt es nach dem Einreichen bei „Discovered – currently not indexed"? Dieser Status bedeutet meist Crawl-Priorität, kein Scheitern. Prüfe interne Links auf die Seite, ob robots.txt den Pfad blockiert und ob die Seite stark von JavaScript abhängt. Dann warte: Bei neuen Websites kann die Entdeckung bis zum Crawl 1–2 Wochen dauern.
Reichen 200 URLs pro Tag? Für die meisten Websites ja – du solltest ohnehin nur tatsächlich geänderte URLs einreichen. Wenn es regelmäßig mehr sind, priorisiere nach Geschäftswert und beantrage eine Kontingenterhöhung im Google Cloud Console.
Macht die Indexing API Rankings schneller? Nein. Sie meldet Google nur, dass sich eine URL geändert hat. Das Ranking ist ein separates Urteil der Google-Systeme und hängt nicht von der Anzahl deiner Benachrichtigungen ab.
Worin unterscheidet es sich vom „Indexierung anfragen"-Klick in der Search Console? Gleiche Absicht, anderer Mechanismus. Der Button ist reine UI ohne öffentliche API; die Indexing API ist der skriptbare Kanal. Beide überschreiben nicht Googles Urteil darüber, ob eine Seite in den Index gehört.
Autor: Julian Mercer, Technical-SEO-Praktiker bei Auspia mit 14 Jahren Erfahrung. Schreibt über Crawlbarkeit, Indexierung, Schema und die technische Basis, die Websites für Google- und KI-Systeme gleichermaßen lesbar macht.












