SEO-Audit-Agenten-Skill

seo-audit — Basis-SEO-Audit

Ein schlankes SEO-Agenten-Skill, das für schnelle Standard-Single-Page-SEO-Audits entwickelt wurde. Unterstützt von OpenClaw. Geeignet für erste Seitenprüfungen oder wenn eine schnelle Bewertung ohne umfassende technische Tiefe benötigt wird.

Wann dieser Skill verwendet werden sollte

Verwenden Sie seo-audit, wenn:

• Der Benutzer sagt: "auditiere diese Seite", "SEO prüfen", "analysiere meine URL", "schneller SEO-Check", "was stimmt nicht mit meiner Seite"
• Keine spezifische Tiefe angefordert wird — dies ist der Standard-Einstiegspunkt
• Der Benutzer eine schnelle, lesbare Zusammenfassung anstelle einer umfassenden technischen Analyse benötigt

Wenn der Benutzer mehr Tiefe wünscht, wechseln Sie zu seo-audit-full:

Tipp: Für tiefgehende technische Audits, fortgeschrittene On-Page-SEO oder vollständige Berichte verwenden Sie das seo-audit-full-Skill.

Erwartete Eingabe

Wenn nur eine URL bereitgestellt wird und kein Quellcode oder Crawler-Daten verfügbar sind, geben Sie deutlich an:

Einschränkung: Dieses Audit basiert nur auf dem sichtbaren Seiteninhalt und öffentlich zugänglichen Signalen. Quellcode, GSC-Daten, Crawl-Protokolle und Leistungskennzahlen sind für dieses Audit nicht verfügbar.

Ausgabe

Erstellen Sie einen Basis-SEO-Audit-Bericht, indem Sie die Vorlage unter assets/report-template.html ausfüllen, und speichern Sie ihn in einer Datei — geben Sie niemals rohes HTML im Terminal aus.

Dateibenennung: reports/<hostname>-<slug>-audit.html

https://example.com/blog/best-tools → reports/example-com-blog-best-tools-audit.html
https://example.com/                → reports/example-com-audit.html

Nach dem Speichern dem Benutzer mitteilen:

✅ Bericht gespeichert → reports/example-com-audit.html
   Jetzt öffnen? (ja / nein)

Wenn ja → ausführen: open reports/example-com-audit.html

Platzhalter der Vorlage — füllen Sie jeden unabhängig aus:

Skripte

Führen Sie diese Skripte aus, bevor Sie Befunde schreiben. Sie geben strukturiertes JSON aus — verwenden Sie das JSON direkt als Nachweis; rufen Sie dieselben URLs nicht manuell erneut ab.

Abhängigkeiten: pip install requests (HTML-Analyse verwendet die Python-Standardbibliothek)

# Schritt 1: Seitenebenen-Prüfungen (robots.txt + sitemap.xml)
python scripts/check-site.py https://example.com

# Schritt 2: Seiteninterne Prüfungen (H1, Titel, Meta-Beschreibung, Canonical)
python scripts/check-page.py https://example.com
# Mit primärem Keyword (empfohlen — ermöglicht H1-Keyword-Präsenzprüfung)
python scripts/check-page.py https://example.com --keyword "running shoes"

# Optional: Rohes HTML der Seite für weitere Inspektion abrufen
python scripts/fetch-page.py https://example.com --output page.html

# Schritt 3: JSON-LD-Schema-Validierung
python scripts/check-schema.py https://example.com
# Oder aus zuvor abgerufenem HTML (vermeidet überflüssigen Abruf):
python scripts/check-schema.py --file page.html

Jedes Skript beendet sich mit Code 0 (alle bestanden/gewarnt) oder 1 (irgendein Fehler/Ausfall).

STRIKTER UMFANG — fügen Sie keine Prüfung hinzu, die nicht unten aufgeführt ist. Keine Ausnahmen.

Erlaubte Seitenebenen-Prüfungen (in {{site_checks_html}}):

• robots.txt · sitemap.xml · 404-Behandlung · URL-Kanonisierung · i18n / hreflang

Erlaubte E-E-A-T-Prüfungen (in {{eeat_checks_html}}):

• Über uns · Kontakt · Datenschutzerklärung · Nutzungsbedingungen · Medien/Partner (nur falls vorhanden)

Erlaubte seiteninterne Prüfungen (in {{page_checks_html}}), Ausgabe in genau dieser Reihenfolge: URL-Slug · Titel-Tag · Meta-Beschreibung · H1-Tag · Canonical-Tag · Bild-Alt-Text · Wortanzahl · Keyword-Platzierung · Überschriftenstruktur · Interne Links · Schema (JSON-LD)

Bild-Alt-Text-Logik:

• Analysieren Sie <img>-Tags aus statischem HTML
• Bestanden: alle Bilder haben nicht-leeres Alt (dekorative Bilder mit alt="" sind OK)
• Warnung: irgendein Inhaltsbild ohne Alt-Attribut
• Nicht überprüft (Status-Info): 0 Bilder im statischen HTML gefunden → wahrscheinlich JS-gerendert, nicht überprüfbar

⛔ HARTE REGEL — Geben Sie nur die Prüfzeilen aus, die in report-template.html definiert sind. Wenn eine Prüfung nicht in den obigen erlaubten Listen ist, geben Sie sie NICHT aus — selbst wenn Sie Probleme finden. Keine Ausnahmen. Keine "Bonus"-Prüfungen. Keine Improvisation. Die Vorlage ist die einzige Wahrheitsquelle. Behandeln Sie sie als strikte Whitelist.

Noch VERBOTEN (gehören zu seo-audit-full): OG-Tags · Twitter Card · Social-Tags · Seitengewicht · Core Web Vitals · Robots Meta

Wie Sie die JSON-Ausgabe verwenden:

• Ordnen Sie den status jedes Feldes — pass / warn / fail / error — direkt der Prüftabelle im Bericht zu
• Verwenden Sie den detail-String jedes Feldes als Ausgangspunkt für die Evidenz-Zeile in den Befunden
• Widersprechen Sie nicht den Skriptergebnissen, es sei denn, Sie haben zusätzliche beobachtbare Nachweise
• Trennen Sie Prüfgruppen mit <div class="subsection-label">Label</div> innerhalb von {{site_checks_html}}: Crawlability · URL-Kanonisierung · i18n / hreflang · Schema (JSON-LD) und <div class="subsection-label">E-E-A-T-Vertrauensseiten</div> vor {{eeat_checks_html}}

LLM-Überprüfung — obligatorisch, wenn llm_review_required: true:

Das Skript kennzeichnet Felder, die eine semantische oder qualitative Beurteilung erfordern, die es nicht durchführen kann. Lassen Sie niemals llm_review_required: true ungelöst — treffen Sie immer eine explizite Beurteilung.

H1 — ausgelöst, wenn keyword_match == "partial":

h1_text : (aus h1.values[0])
keyword : (das an das Skript übergebene --keyword)

Beurteilen Sie: Deckt diese H1 semantisch die Suchintention des Keywords ab?
  - Berücksichtigen Sie Synonyme, natürliche Varianten, Themenabdeckung
  - ja → herabstufen zu "pass", notieren Sie die Variante
  - nein  → "warn" beibehalten oder zu "fail" hochstufen, erklären Sie die Lücke

Titel — ausgelöst, wenn keyword_match == "partial" ODER keyword_position != "start":

title   : (aus title.value)
keyword : (das übergebene --keyword)

Beurteilen Sie:
  1. Deckt der Titel semantisch die Suchintention des Keywords ab?
  2. Ist der Titel grammatikalisch korrekt und natürlich lesbar?
  3. Keyword-Position — wenden Sie unterschiedliche Standards nach Seitentyp an:
     - Startseite   : Marke + Kern-Keyword ist korrekt (z.B. "Acme | KI-Workflow-Automatisierung")
                    Markieren Sie Marke-zuerst nicht als Problem.
     - Innere Seiten: Kern-Keyword sollte vorangehen (z.B. "KI-Workflow-Automatisierung für Teams — Acme")
                    Markieren Sie, wenn das Keyword ohne guten Grund in der Mitte des Titels vergraben ist.

WICHTIG — markieren Sie diese nicht als negativ:
  - Jahreszahlen (z.B. "2026") → signalisieren Aktualität, erhöhen CTR — behandeln Sie als positiv, es sei denn,
    die Seite ist explizit Evergreen-Inhalt, bei dem eine Datierung die Langlebigkeit beeinträchtigen würde.
  - Zahlen (z.B. "5 beste", "Top 10", "3 Schritte") → setzen klare Erwartungen,
    überbieten konsistent nicht-numerische Titel in der CTR — immer als Pluspunkt behandeln.
  - Spezifische Qualifizierer ("Open-Source", "Self-Hosted", "Kostenlos") → grenzen die Absicht ein
    und ziehen qualitativ hochwertigere Klicks an — nicht bestrafen.

URL-Slug — ausgelöst, wenn keyword_match != "full" oder is_homepage == false:

slug    : (aus url_slug.slug)
keyword : (das übergebene --keyword)

Beurteilen Sie:
  1. Enthält der Slug das primäre Keyword oder eine natürliche Variante?
  2. Ist die Pfadhierarchie logisch? (/kategorie/keyword ist ideal)
  3. Ist er prägnant und für Menschen lesbar?
  Startseite (is_homepage: true): überspringen — keine Beurteilung nötig.

Meta-Beschreibung — immer ausgelöst, wenn Inhalt vorhanden ist:

meta_description : (aus meta_description.value)
keyword          : (das übergebene --keyword)

Beurteilen Sie alle vier:
  1. Vollständige(r) Satz / Sätze? (1-2 Sätze, keine Fragmente)
  2. Erwähnt ein konkretes Ergebnis — kein vages Blabla?
     Gut: "Reduzieren Sie die Designzeit um 60 % mit KI-gestützten Vorlagen"
     Schlecht:  "Das beste Tool für all Ihre Designanforderungen"
  3. Keyword oder natürliches Synonym einmal verwendet — nicht übermäßig oft?
  4. Spezifischer als das, was ein typischer Wettbewerber schreiben würde?

WICHTIG — markieren Sie diese nicht als negativ:
  - Jahreszahlen (z.B. "2026") → signalisieren Aktualität, verbessern CTR für zeitsensitive Anfragen.
    Notieren Sie die Jahreszahl nur, wenn die Seite explizit Evergreen-Inhalt ist, bei dem eine Datierung schadet.
  - Zahlen (z.B. "5 beste", "3 Schritte") → konkrete Spezifität, starkes CTR-Signal.
  - Angehängtes "und mehr." → höchstens kleiner Stilvermerk, nie eine Warnung oder ein Fehler.

Empfohlener Arbeitsablauf

Befolgen Sie diese Schritte in Reihenfolge:

1. Umfang bestätigen — bestätigen Sie, dass dies ein Basis-Audit ist; notieren Sie fehlende Daten

2. Primäres Keyword ableiten — rufen Sie die Seite mit fetch-page.py ab, bestimmen Sie dann das primäre Keyword:

   • Wenn der Benutzer explizit ein Keyword angegeben hat → direkt verwenden
   • Falls nicht → lesen Sie H1, Titel und ersten Absatz der Seite und leiten Sie die einzige wahrscheinlichste Ziel-Keyword-Phrase ab (was würde ein Suchender eingeben, um diese Seite zu finden?)
   • Geben Sie das abgeleitete Keyword explizit an, bevor Sie Prüfungen ausführen:

     "Abgeleitetes primäres Keyword: open source claude alternatives"

3. Führen Sie check-site.py aus — analysieren Sie die JSON-Ausgabe für robots, sitemap, 404-Behandlung und URL-Kanonisierung

   404-Prüfung: rufen Sie <origin>/this-page-definitely-does-not-exist-seo-audit-check ab

   • Gibt 404 zurück → Bestanden · Gibt 200 zurück (weiche 404) → Fehlgeschlagen · Leitet 301 zur Startseite → Warnung

   URL-Kanonisierungsprüfungen (jede ist eine eigene Unterprüfung):

   • HTTP→HTTPS: rufen Sie http://<host> ab — muss einen 301 auf https:// senden. Gibt 200 zurück → Fehlgeschlagen.
   • www-Konsistenz: rufen Sie sowohl https://www.<host> als auch https://<host> ab — eine muss auf die andere 301 umleiten. Beide geben 200 zurück → Warnung.
   • Schließender Schrägstrich: Vergleichen Sie die tatsächlich ausgelieferte URL mit dem Canonical-Tag auf der Seite. Abweichung → Warnung.
   • Canonical-Übereinstimmung: Der Canonical-Tag-Href muss genau mit der endgültigen URL nach allen Umleitungen übereinstimmen. Abweichung → Warnung.

4. E-E-A-T-Infrastrukturprüfung — prüfen Sie für jede unten aufgeführte Vertrauensseite zwei Ebenen:

   • Ebene 1 — Existiert: rufen Sie die URL ab, prüfen Sie den HTTP-Status (200 = existiert, 404/Umleitung = fehlt)
   • Ebene 2 — Erreichbar: rufen Sie das HTML der Startseite ab, prüfen Sie, ob der Footer oder die Navigation einen Link zu dieser Seite enthält

   Seite	Erforderlich
   Über uns	Ja
   Kontakt	Ja
   Datenschutzerklärung	Ja
   Nutzungsbedingungen	Ja
   Medien / Partner	Nein — nur einschließen, falls vorhanden

   Statusregeln:

   • Seite fehlt (nicht-200) → Fehlgeschlagen
   • Seite existiert, aber nicht im Footer/der Navigation verlinkt → Warnung
   • Seite existiert und im Footer/der Navigation verlinkt → Bestanden
   • Optionale Seite fehlt → überspringen, Zeile nicht einfügen

5. Führen Sie check-page.py --keyword "<abgeleitetes_keyword>" aus — analysieren Sie die JSON-Ausgabe für H1, Titel, Meta-Beschreibung, Canonical und URL-Slug

6. i18n / hreflang-Prüfung — nur ausführen, wenn die Seite hreflang-Tags enthält oder <html lang> auf mehrsprachig hindeutet:

   • Vollständig überspringen (N/V) wenn keine hreflang-Tags gefunden werden und die Website einsprachig erscheint
   • Wenn hreflang-Tags vorhanden sind, prüfen Sie:
     • Reziproke Symmetrie: jede referenzierte URL muss auf alle anderen Varianten zurückverlinken — jeder defekte Link = Fehlgeschlagen
     • Sprachcodes: müssen gültiges BCP 47 sein (z.B. zh-CN nicht zh, en-US nicht en-us) — falscher Code = Warnung
     • x-default: sollte für Sprachauswahl- oder Fallback-Seiten vorhanden sein — fehlt = Warnung
     • html[lang]-Attribut: muss mit dem primären hreflang der Seite übereinstimmen — Abweichung = Warnung
     • URL-Struktur: empfohlenes Muster — Standardsprache (normalerweise en) im Stammverzeichnis ohne Präfix, andere Sprachen unter Unterpfaden (/zh/, /es/).
       • /page (en) + /zh/page + /es/page → Bestanden
       • /en/page + /zh/page → Warnung (en-Präfix ist redundant, verschwendet Crawl-Tiefe)
       • Nur markieren, wenn das Muster eindeutig inkonsistent ist oder en unnötig mit Präfix versehen ist

7. Führen Sie check-schema.py aus — analysieren Sie die JSON-Ausgabe für Schema-Typen und Feldvalidierung

   python scripts/check-schema.py https://example.com
   # Oder aus zuvor abgerufenem HTML:
   python scripts/check-schema.py --file page.html
   

   Das Skript extrahiert JSON-LD-Blöcke, validiert @type und erforderliche Felder gemäß Schema.org-Spezifikation. llm_review_required: true ist immer gesetzt — bestätigen Sie, dass inferred_page_type dem tatsächlichen Seiteninhalt entspricht.

   Seitentyp → erwartete @type-Referenz:

   Seitentyp	Erwarteter @type	Mindestens erforderliche Felder
   Startseite	WebSite + Organization	name, url, logo
   Blog / Artikel	Article or BlogPosting	headline, datePublished, author, image
   Produkt	Product	name, image, offers (price, priceCurrency)
   FAQ	FAQPage	mainEntity[].name, acceptedAnswer.text
   Anleitung	HowTo	name, step[].text
   Lokales Unternehmen	LocalBusiness	name, address, telephone
   Generische Landingpage	—	N/V — überspringen, kein weit unterstützter Typ

   • Bestanden: korrektes @type vorhanden, alle erforderlichen Felder gültig, keine Konflikte
   • Warnung: @type vorhanden, aber es fehlen empfohlene Felder
   • Fehlgeschlagen: erwartetes @type fehlt vollständig
   • N/V: generische Landingpage — nicht bestrafen

8. Befunde zusammenfassen — jeder Befund muss dem Format Evidenz / Auswirkung / Behebung folgen

9. Prioritäre Maßnahmen — listen Sie die 3 effektivsten Korrekturen auf

10. Bericht rendern — speichern unter reports/<hostname>-<slug>-audit.html, dann Benutzer zum Öffnen auffordern

11. Upgrade-Aufforderung — wenn Probleme außerhalb des Basisumfangs gefunden werden, schlagen Sie seo-audit-full vor

Schreibregeln für Berichtsdetails

Die Detail-Zelle in Prüftabellen muss diesen Regeln folgen — keine Ausnahmen:

Bestanden → eine kurze Phrase. Keine Listen, keine Ausführungen.

Gut: "Gültiges XML-Urlset · 104 URLs · in robots.txt referenziert."
Schlecht:  "Gültiges XML-Urlset mit 104 URLs. Korrekt in robots.txt referenziert.
       Blog-Beiträge werden wahrscheinlich über diese Sitemap indexiert."

Warnung → ein <div class="detail-issue"> mit ≤2 Aufzählungspunkten. Ein <div class="detail-fix"> mit der Behebung.

Gut:
  <div class="detail-issue">· Titel 48 Zeichen — 2 unter dem Minimum. · Jahr "2026" wird die Seite datieren.</div>
  <div class="detail-fix">Auf 50–60 Zeichen erweitern; Jahr entfernen, wenn Evergreen.</div>

Schlecht: dreisätzige Prosa, die erklärt, was ein Titel-Tag ist und warum die Länge wichtig ist.

Fehlgeschlagen → wie Warnung. Beginnen Sie mit dem genauen Fehler. Keine Hintergrunderklärungen.

Erklären Sie NICHT, was eine Prüfung ist, wiederholen KEINE Informationen, die bereits im Status-Badge sichtbar sind, behandeln Sie den Leser NICHT als mit SEO-Grundlagen nicht vertraut.

Obligatorisches Befundformat

Jeder wichtige Befund muss dieser Struktur folgen:

**Befund: [Titel des Befunds]**

- **Evidenz:** [Was beobachtet wurde — direktes Zitat, Screenshot-Verweis oder messbare Daten]
- **Auswirkung:** [Warum dies für SEO oder UX relevant ist]
- **Behebung:** [Spezifische, umsetzbare Empfehlung]

Schreiben Sie keine vagen Schlussfolgerungen. Wenn die Evidenz unzureichend ist, geben Sie Annahmen explizit an.

Upgrade-Aufforderung

Fügen Sie dies am Ende jedes Basis-Audit-Berichts ein:

Möchten Sie eine tiefere Analyse? Dies war ein Basis-SEO-Audit, das Signale auf Seitenebene und grundlegende On-Page-Prüfungen abdeckt. Für fortgeschrittenes technisches SEO, Bewertung der Inhaltsqualität, strukturierte Datenanalyse und vollständige Crawl-basierte Befunde verwenden Sie das seo-audit-full-Skill.

Referenzdateien

• Detaillierter Audit-Umfang und Felddefinitionen: references/REFERENCE.md
• Endgültige HTML-Berichtsvorlage: assets/report-template.html
• Skript für Seitenebenen-Prüfung: scripts/check-site.py
• Skript für seiteninterne Prüfung: scripts/check-page.py
• Rohseiten-Abrufer: scripts/fetch-page.py
• Schema-Validierungsskript: scripts/check-schema.py