URLs mit „Discovered / Crawled – Currently Not Indexed" über den Hermes Agent reparieren

Ein Workflow, der die Indexierungsarbeit der Search Console an den Hermes Agent übergibt: Liste nicht indexierter URLs ziehen, jede Seite prüfen, die echte Ursache triagieren, die Reparatur-Warteschlange freigeben und nur die reparierten Seiten über die Google Indexing API einreichen.

„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:

  1. Der Loop ist mechanisch und lang: Inventar → Prüfen → Klassifizieren → Reparieren → Einreichen → Verifizieren. Woche für Woche.
  2. Er braucht einen Audit-Trail: Du brauchst eine Datei, die zeigt, welche URLs wann und warum eingereicht wurden.
  3. 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

  1. Hermes Agent installiert. Prüfe mit hermes chat, bevor es weitergeht.
  2. Ein GSC-Besitz, an dem du Eigentümer bist. Im Format sc-domain:example.com (nicht die vollständige URL).
  3. 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.
  4. 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.
  5. Python 3 und pip install google-auth google-api-python-client.
  6. Ein Projektordner. Zum Beispiel /hermes-seo-project mit context/, data/, qa/ und einer approval-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.

Workflow-Diagramm einer fünfstufigen Indexierungs-Pipeline mit menschlichem Freigabe-Gate vor der Einreichung

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.

Entscheidungsmatrix, die nicht indexierte URLs in „nach Reparatur einreichen" und „niemals einreichen" teilt

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:

bash
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.txt

Der 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- oder BroadcastEvent-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.

Dieses Thema erkunden

Folgen Sie derselben Wachstumslinie