URLs mit „Discovered / Crawled – Currently Not Indexed" über DeepSeek Harness reparieren

DeepSeek Harness (dsh) führt Agents aus, die echte Arbeit erledigen – und kaum eine SEO-Aufgabe passt besser dazu als die Pipeline für nicht indexierte URLs: Liste lesen, jede URL prüfen, klassifizieren, auf Freigabe warten, einreichen, verifizieren. Jede Stufe ist ein Befehl oder eine Datei, genau das, worin Harness-Agents stark sind.

Zwei Fragen entscheiden, wie du es aufsetzt. Willst du einen Einmal-Batch, den du scripten und in cron legen kannst? Dann headless. Willst du zusehen, Fragen beantworten und Batch für Batch im Chat freigeben? Dann das Web-UI. Dieser Leitfaden zeigt beide Pfade; die Pipeline darunter ist in beiden gleich. Für die tiefe Erklärung der beiden Status (inklusive der Frage, warum Google manche Seiten crawlt und andere nicht) haben wir die Hermes-Agent-Version dieses Workflows ausführlich behandelt. Hier fokussieren wir die dsh-Ausführung.

Pfad wählen

Batches headless, das erste Setup im Web-UI. Die Pipeline darunter ist dieselbe.

Beide Pfade teilen eine Regel: Der Schreib-Schritt (das Einreichen bei Google) bleibt hinter einem menschlichen Freigabe-Gate. Im Headless-Modus heißt das: Du prüfst die vom Agent erzeugten Dateien, bevor du ihn die submit-Befehle ausführen lässt. Im Web-Modus gibst du im Chat frei.

Was du danach hast

Einen indexing/-Projektordner mit: URL-Inventar, klassifizierten Listen (to-submit.txt, skip.txt, needs-fix.txt), freigegebener Einreich-Warteschlange und Ausführungs-Logs. Bei jeder Ausführung erzeugt dsh einen kurzen Report: wie viele eingereicht, wie viele übersprungen und warum, was sich seit dem letzten Mal geändert hat. Erst-Setup 60–90 Minuten (meist Google-Zugangsdaten), wöchentliche Ausführung 15 Minuten.

Bevor du anfängst

• dsh installiert und eingerichtet. Bei Bedarf mit npx @deepseek-ai/dsh@latest web auf die aktuelle Version aktualisieren. API-Key und Einstellungen liegen in ~/.dsh/ (profiles, sessions, settings.yaml); dsh web startet oder eine Headless-Aufgabe gelingt = Installation bestätigt.
• Ein GSC-Besitz, an dem du Eigentümer bist, im Format sc-domain:example.com.
• Lese-Zugangsdaten: OAuth-Client für die Search Console API (Client-ID + Secret).
• Schreib-Zugangsdaten: Google-Cloud-Projekt mit aktivierter Indexing API, Service-Account-JSON-Key, und die Service-Account-E-Mail als Eigentümer unter GSC → Einstellungen → Nutzer und Berechtigungen. 403 beim Einreichen = dieser Schritt ist fehlgeschlagen.
• Zwei GSC-Skriptordner im Workspace: der Lese-Skill (Sitemaps, Search Analytics, URL-Prüfung) und der Indexing-Skill (index_submit.py). Python 3 und pip install google-auth google-api-python-client.
• Ein Projektordner, z. B. ~/gsc-indexing-project mit data/, scripts/, logs/.

Die Google-Seite des Setups ist für jeden Agenten gleich; die gsc-indexing-Skill-Doku führt dich durch die Cloud-Console-Schritte: Indexing API aktivieren, Service Account anlegen, Key herunterladen, als Eigentümer hinzufügen.

Pfad A: Einmaliger Headless-Lauf

Der Headless-Modus ist dsh --profile headless "Aufgabe": eine Aufgabe, eine Antwort, Ende. Du packst die ganze Pipeline in einen Prompt oder teilst sie zum Debuggen auf mehrere Läufe auf.

Erster Lauf (im Projektordner):

dsh --profile headless "Führe Stufe 1 der GSC-Indexierungs-Pipeline aus. Liste mit dem gsc_query.py-Skript die Sitemaps von sc-domain:example.com auf, ziehe alle URLs mit lastmod, dedupliziere und schreibe sie nach data/url-inventory.csv. Melde die Gesamtzahl."

Gute Ausgabe heißt: eine echte CSV mit einer zur GSC-Sitemap-Übersicht passenden Anzahl und keine erfundenen Spalten. Qualitätscheck: Datei öffnen und fünf URLs stichprobenartig prüfen. Meldet der Agent einen Authentifizierungsfehler, den GSC-OAuth-Flow neu durchlaufen und erneut versuchen; das Lese-Skript braucht einen frischen Token.

Stufe 2:

dsh --profile headless "Prüfe die URLs in data/url-inventory.csv über die URL Inspection API und teile sie in data/to-submit.txt, data/skip.txt (mit einzeiliger Begründung) und data/needs-fix.txt. Nimm nur URLs mit lastmod in den letzten 90 Tagen."

Der Agent führt die Prüf-Skripte in Batches aus (die API hat Rate Limits pro Property; aktuelles Kontingent im Google Cloud Console prüfen). Prüfe die Aufteilung: Die Skip-Liste sollte von noindex, canonical-Abweichungen und Duplikaten dominiert sein. Bleibt needs-fix bei einer Website mit Tausenden URLs leer, vergrößere das Eingabezeitfenster.

Stufe 3 ist das Freigabe-Gate – niemals unbemannt ausführen:

dsh --profile headless "Lies data/needs-fix.txt und data/skip.txt. Entwirf die Reparatur- und Einreich-Warteschlange als Tabelle: URL, vermutete Ursache (keine internen Links, Duplikat, canonical, noindex, dünn, Soft 404), Beweis, empfohlene Aktion, Risikostufe. Reiche nichts ein."

Prüfe die Tabelle im Report, kürze data/to-submit.txt auf die von dir freigegebenen URLs und führe Stufe 4 aus:

dsh --profile headless "Reiche die URLs aus data/approved-urls.txt über das Indexing-Skript ein (index_submit.py submit --urls-file data/approved-urls.txt). Führe zuerst check-auth aus. Protokolliere jedes Ergebnis in logs/submissions.log."

Erwartete Ausgabe: pro URL eine Zeile mit dem Benachrichtigungsergebnis, kein 403. Wiederherstellung: 403 heißt, der Service Account ist nicht Eigentümer der Property; 429 heißt, du hast das Kontingent von 200/Tag oder 600/Minute erreicht – teile die Liste auf Tage auf. Stirbt der Lauf unterwegs, nimm mit dsh --profile headless --resume <session> wieder auf.

Pfad B: Web-UI und wöchentlicher Zeitplan

dsh web öffnet die Browser-UI unter 127.0.0.1:3080. Gleiche Stufen, aber per Chat und interaktiv: Der Agent fragt nach Bestätigung der Klassifizierungslisten und noch einmal vor jedem submit-Befehl. Dieser Live-Freigabe-Flow ist der Hauptgrund, beim ersten Setup diesen Pfad zu wählen: Du siehst, was der Agent mit deiner Google-Property vorhat, bevor er es tut.

Läuft die Pipeline, kommt der Rhythmus dazu. Das Schedule-Plugin von dsh registriert schedule_create und wiederholt Aufgaben per Timer in der Live-Session:

schedule_create: every 7 days, run "Inspect data/url-inventory.csv, classify new and changed URLs, and draft the submission queue. Do not submit."

Lädt dein Profil das Schedule-Plugin nicht, erreichst du dasselbe mit einer cron-Zeile um den Headless-Befehl:

0 9 * * 1 cd ~/gsc-indexing-project && dsh --profile headless "Führe die wöchentliche GSC-Indexierungs-Prüfung aus und entwirf die Einreich-Warteschlange." >> logs/weekly.log 2>&1

Der Zeitplan fährt die ersten drei Stationen; die Einreichung bleibt im menschlichen Gate.

Setze den Einreich-Schritt nicht in den Zeitplan. Wöchentliche Prüfung, Klassifizierung und Warteschlangen-Entwurf können unbemannt laufen; das Einreichen wartet auf einen Menschen.

Die Triage-Regeln, die der Agent anwendet

Klassifizierung und Warteschlange hängen an einer kleinen Tabelle. Lege sie in den Projektordner, damit jeder Lauf dieselben Regeln benutzt:

Die tiefe Lesart der beiden Status (inklusive der Frage, warum Google manche Seiten crawlt und andere nicht) steht im Hermes-Agent-Leitfaden. Die Ursachen sind dieselben, egal welcher Harness die Pipeline ausführt.

Verifizieren und warten

Prüfe nach jedem Batch den status der Benachrichtigung: Er beweist nur, dass Google Metadaten zu der URL hat, nicht dass die Seite indexiert ist. Prüfe die eingereichten URLs 3–7 Tage später erneut und vergleiche die Status. Ein gesundes Muster ist discovered → crawled → indexed über 1–2 Wochen. GSC-Daten laufen 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 Inhaltsqualitäts-Urteil, kein Einreich-Problem. Die Logdatei macht das sichtbar: Datum, URL, Benachrichtigungstyp, Prüfstatus beim nächsten Lauf. Das ist die Messgröße: Die Nicht-indexiert-Liste schrumpft über die Zeit – nicht die Zahl der Benachrichtigungen.

Ehrliche Grenzen

• Die Indexing API ist offiziell für JobPosting- und BroadcastEvent-Seiten dokumentiert. Normale Seiten einzureichen ist gängige Praxis, aber Google gibt weder Garantie noch Support-Zusage für jeden Seitentyp.
• Der „Indexierung anfragen"-Button der Search Console hat keine öffentliche API. Die Indexing API ist der nächstgelegene skriptbare Kanal, kein Button-Klon.
• Automatisierung schafft keine Priorität. Bleibt eine Seite nach Reparatur und Einreichung nicht indexiert, ist der nächste Schritt Content-Arbeit – kein weiterer Zeitplan-Lauf.

FAQ

Kann ich ausschließlich headless laufen lassen, ohne das Web-UI? Ja. dsh --profile headless "Aufgabe" führt eine Aufgabe aus und endet. Die Zugangsdaten bleiben in ~/.dsh/ und die Lese-Skripte funktionieren unverändert. Verifiziere die Pipeline einmal end-to-end im Web-UI, bevor du sie scriptest.

Wenn ein Lauf stirbt – verliere ich die Arbeit? Nein. Nimm mit dsh --profile headless --resume <session> wieder auf und führe das Einreich-Skript erneut aus; es dedupliziert URLs, also ist das erneute Senden bereits benachrichtigter URLs aus demselben Batch harmlos.

Ich verwalte mehrere GSC-Properties. Muss ich das pro Website neu aufbauen? Die Skripte akzeptieren ein --site sc-domain:...-Argument, also kann ein Workspace Inventare und Logs mehrerer Properties halten. Halte pro Property eine Freigabe-Warteschlangen-Datei und einen Einreich-Befehl; ein Kontingentfehler einer Website blockiert die anderen nicht.

Autor: Camille Rhodes, Architektin von 300+ AI-Content-Workflows bei Auspia. Schreibt über Content-Automatisierung, Publishing-Systeme und Workflows, die AI-Agents in zuverlässige Wachstums-Operationen verwandeln.