/recovery-diagnose

description: "Automatic domain diagnosis: Core Update impact, VI drop, keyword losses, backlink profile."
allowed-tools: Bash, Read, Write, Edit, Glob, Grep, mcp__*

Recovery Diagnose

Zweck

Automatische Diagnose einer Domain: Core-Update-Betroffenheit pruefen, VI-Drop quantifizieren, Keyword-Verluste identifizieren, Backlink-Profil scannen. Ergebnis ist ein strukturierter Befund als Grundlage fuer alle weiteren Recovery-Commands.

Change Governance

Mode: `audit_only`. Change Budget: 0. Keine Live-Shop-Writes. Nur Cache-Report-Artefakte.

Wenn `change-history.ndjson` existiert, wird sie am Anfang gelesen und im Befund referenziert. Jede Aussage muss Quelle und Confidence tragen.

Settlement Gate Awareness

Dieses Command ist read-only (`audit_only`, Change Budget 0) — ein aktiver Settlement Gate (`../../references/SEO_SETTLEMENT_GATE.md`) blockiert es NIE. Es muss den Gate-State aber kennen und ausweisen:

1. Lies `~/.cache/seo-rescue/{slug}/recovery-gate.json`, falls vorhanden. **Writer dieser Datei ist `recovery-audit`** (siehe `commands/recovery-audit.md`, Schritt 7: Settlement-Gate-Detection) — recovery-diagnose liest sie nur. Fehlt die Datei, gilt der Gate als `never_triggered`: keine Warnung, normaler Ablauf. 2. Falls `settlement_gate_active = true`:

• Diagnose laeuft normal weiter — read-only Analyse ist waehrend eines aktiven Gates immer erlaubt.
• In den Befund (Top-Level) das Feld `settlement_gate_status` aufnehmen, gespiegelt aus der Gate-Datei:

     "settlement_gate_status": {
       "active": true,
       "next_allowed_review_date": "2026-06-06",
       "unlock_status": "blocked"
     }

(`unlock_status`: `blocked | partial | open`, direkt aus der Gate-Datei uebernommen.)

• In der User-Ausgabe eine Zeile ausgeben: `Settlement Gate: AKTIV bis {next_allowed_review_date} — read-only Diagnose erlaubt, Live-Aenderungen blockiert`
• Jeder Empfehlungstext (insbesondere `summary_de` und der "Naechster Schritt") darf KEINE sofortigen Live-Aenderungen vorschlagen. Naechste Schritte als "jetzt vorbereiten/Drafts erstellen, Ausfuehrung nach Gate-Re-Evaluation" formulieren (`prepare_now_execute_later`-Prinzip aus `SEO_SETTLEMENT_GATE.md`).

3. Falls Gate-Datei fehlt oder `settlement_gate_active = false`: `settlement_gate_status: { "active": false }` in den Befund schreiben. Keine User-Ausgabe-Zeile noetig.

Trigger

`/seo-rescue:recovery-diagnose <domain>`

Input-Kontrakt

| Feld | Quelle | Pflicht | |------|--------|---------| | `domain` | CLI-Argument | ja |

Normalisierung gemaess Schritt 1 des Ablaufs. `www.` wird NICHT entfernt.

Capabilities

| Capability | Pflicht/Optional | Verwendung | |-----------|-----------------|-----------| | `visibility_history` | optional | VI-Trend berechnen, Core-Update-Korrelation | | `keyword_rankings` | optional | Quick-Wins, Top-Losers, Position-Distribution | | `backlink_summary` | optional | Backlink-Profil, Spam-Score | | `core_update_dates` | optional | Korrelation mit Drop-Timing | | `serp_snapshot` | optional | Intent-Klassifikation fuer Keywords | | `gsc_search_analytics` | optional | Knocking-at-the-door-Kohorte (`hardening_candidates`, Schritt 11) |

Bevorzugte Provider

• **visibility_history**: Sistrix MCP (`SISTRIX_API_KEY`)
• **keyword_rankings**: DataForSEO MCP
• **backlink_summary**: DataForSEO MCP (`backlinks/summary/live`)
• **core_update_dates**: `../../references/CORE_UPDATES.md`
• **serp_snapshot**: DataForSEO MCP (`serp/google/organic/live`)
• **gsc_search_analytics**: GSC MCP/API (Query-Page-Paare mit Impressionen/CTR/Position); Free-Fallback: GSC-Performance-CSV unter `~/.cache/seo-rescue/{slug}/imports/`

Fallback-Provider

Paid Fallbacks (wenn Primaeranbieter nicht verfuegbar)

| Capability | Paid Fallback | |-----------|--------------| | `visibility_history` | Semrush, Ahrefs, Xovi, Searchmetrics, SE Ranking (manueller CSV-Export) | | `keyword_rankings` | Semrush, Ahrefs, SE Ranking (manueller CSV-Export) | | `backlink_summary` | Ahrefs, Majestic, Moz (manueller Export) |

Free / Lokale Fallbacks

| Capability | Free/Lokal Fallback | |-----------|-------------------| | `visibility_history` | GSC CSV-Export (Performance-Report, 16 Monate) | | `keyword_rankings` | Manuelle Keyword-CSV aus GSC oder eigener Tabelle | | `backlink_summary` | Manuelle Backlink-CSV aus Google Search Console (Links-Report) | | `core_update_dates` | `../../references/CORE_UPDATES.md` (kein Netzwerk noetig) |

CSV-Importe werden unter `~/.cache/seo-rescue/{slug}/imports/` erwartet.

Ablauf

Schritt 1: Domain normalisieren

Normalisiere den Input gemaess dem gemeinsamen Input-Kontrakt:

• Entferne Protokoll (`https://`, `http://`), Pfad, Query-Parameter, Fragment, Trailing Slash
• `www.` wird NICHT entfernt — `www.example.com` und `example.com` sind verschiedene Domains
• Erzeuge folgende Felder:
• `input_domain` — das Original exakt so wie vom User eingegeben
• `domain` — normalisierte Domain (kein Protokoll, kein Pfad, kein Trailing Slash)
• `canonical_domain` — auf `null` setzen (wird von spaeteren Commands gesetzt)
• `slug` — sicherer Dateiname via `safeSlug()` aus `lib/safe.js`

Fuehre aus:

node -e "const { normalizeDomain } = require('./plugins/seo-rescue/lib/safe.js'); console.log(JSON.stringify(normalizeDomain('{domain}')))"

Ersetze `{domain}` durch den tatsaechlichen User-Input. Falls `normalizeDomain()` einen Fehler wirft (z.B. leerer Input, ungueltiger Slug), Abbruch mit Status `failed`.

Schritt 2: Cache-Verzeichnis anlegen

Erstelle das domainspezifische Cache-Verzeichnis unter `~/.cache/seo-rescue/{slug}/`:

node -e "const { ensureDomainDir } = require('./plugins/seo-rescue/lib/safe.js'); console.log(ensureDomainDir('{slug}'))"

Ersetze `{slug}` durch den in Schritt 1 ermittelten Slug. Das Verzeichnis wird mit Modus 0700 angelegt (nur der aktuelle User hat Zugriff). Falls das Verzeichnis ein Symlink ist, Abbruch