SEO-Playbook

Was macht SEO-Playbook?

Dieser Skill verwandelt SEO in einen wiederholbaren Engineering-Workflow: Finden Sie Suchanfragen, die die Website tatsächlich gewinnen kann, geben Sie jeder Seite einen klaren Job, platzieren Sie die richtigen Wörter in den richtigen HTML-Elementen, stellen Sie sicher, dass Google crawlen, rendern und indexieren kann, bauen Sie Links auf, messen Sie und iterieren Sie.

Er destilliert, was funktioniert hat (und was stillschweigend kaputt ging), während eine junge Next.js-Tools-Site von null auf Platz-eins-Rankings für Long-Tail-Suchanfragen gebracht wurde. Die Lektionen lassen sich auf jeden Stack verallgemeinern.

Die Denkweise in fünf Sätzen

1. Rankings folgen der Gewinnbarkeit, nicht den Wünschen. Eine junge Domain wird dieses Jahr nicht die Top 5 für einen Head-Begriff wie "QR-Code-Generator" erreichen; sie kann innerhalb von Wochen für "kostenloser QR-Code-Generator ohne Anmeldung" oder "Geburtstagswunsch-Link mit Name" ranken. Zielen Sie zuerst auf den Long Tail und lassen Sie die thematische Autorität später den Head-Begriff anheben.
2. Eine Seite, eine Suchintention, ein primäres Keyword. Zwei Seiten, die auf dieselbe Suchanfrage abzielen, verwässern die Signale (Cannibalisierung); eine Seite, die zwei Intentionen anspricht, dient keiner davon.
3. Google rankt das HTML, das es erhält, nicht die App, die der Benutzer sieht. Wenn Inhalt, H1, FAQ-Antworten oder Links erst nach Ausführung von JavaScript erscheinen, gehen Sie davon aus, dass sie nicht existieren. Überprüfen Sie jedes Mal die rohe Serverantwort.
4. Indexierungsfehler wiegen schwerer als Textarbeit. Ein Soft 404, ein falscher Canonical oder ein von einem Layout geerbtes noindex können Monate der Inhaltsarbeit ohne Fehlermeldung zunichtemachen. Überprüfen Sie Statuscodes, Canonicals und Robots auf jedem Seitentyp, den Sie bearbeiten.
5. Messen Sie mit der Search Console, nicht mit Intuition. Impressionen auf Position 8–20 sind die billigsten Gewinne; Position 50+ bedeutet ein Autoritäts- oder Intonationsproblem, das mehr On-Page-Tuning nicht beheben wird.

Setzen Sie die Erwartungen des Benutzers ehrlich: Erste Impressionen für Long-Tail-Seiten erscheinen normalerweise in 2–6 Wochen; Head-Begriffe brauchen Monate und Backlinks. "Schnelle" SEO bedeutet, Kämpfe auszuwählen, die die Website gewinnen kann.

Wählen Sie zuerst die Tiefe

Die meisten SEO-Anfragen sind klein. Wählen Sie den Modus, bevor Sie etwas tun, denn der vollständige Workflow kostet ein Vielfaches der Zeit und Tokens einer kleinen Änderung.

Schnellmodus ist für Bearbeitungen an ein oder zwei Seiten, bei denen das Keyword bekannt oder offensichtlich ist: Umbenennen einer Seite, Schreiben einer Meta-Beschreibung, Hinzufügen von FAQs, Beheben eines gemeldeten Problems oder Hinzufügen einer Seite zu einem Projekt, das bereits ein zu kopierendes SEO-Muster hat. Im Schnellmodus:

• Lesen Sie die Referenzdateien nicht und recherchieren Sie nicht das Live-SERP, es sei denn, eine der folgenden Prüfungen schlägt fehl oder Sie können sich wirklich nicht entscheiden.
• Folgen Sie dem bestehenden SEO-Muster des Projekts: seinem Metadaten-Helper, seiner Content-Konfiguration und seinen Schema-Komponenten.
• Führen Sie die Änderung durch und führen Sie dann die folgende Schnellcheckliste für das Ergebnis aus. Wenn gebautes oder ausgeliefertes HTML vorhanden ist, führen Sie einmal scripts/seo_check.py darauf aus.
• Berichten Sie in wenigen Zeilen. Erwähnen Sie etwas Größeres, das Ihnen aufgefallen ist, als einzeiligen "Auch lohnenswert", ohne es zu untersuchen.

Schnellcheckliste (nur die geänderte Seite):

1. Titel ist einzigartig, beginnt mit dem Keyword, ≤ 60 Zeichen. Beschreibung ist 120–160 Zeichen und enthält nur wahre Behauptungen.
2. Genau ein H1, und der Haupttext, H1 und FAQ-Antworten sind im Server-HTML enthalten (nicht clientseitig, nicht opacity:0, nicht unmontiert).
3. Die Seite setzt ihren eigenen Canonical, ist indexierbar und befindet sich in der Sitemap. Versteckte Seiten verwenden noindex und sind nicht in der robots.txt verboten.
4. 3–5 ausgehende interne Links und mindestens ein eingehender Link.
5. Strukturierte Daten passen zum sichtbaren Inhalt, ohne Bewertungen, die nicht von der eigenen Website stammen.

Vollmodus ist der folgende Workflow. Verwenden Sie ihn für:

• eine neue Website, eine neue Seitengruppe oder ein neues Cluster
• die Auswahl von Keywords, wenn das richtige Ziel unklar ist
• die Diagnose "Warum rankt das nicht" oder "Der Traffic stagniert"
• ein Pre-Launch- oder siteweites Audit
• einen Off-Page-Plan

Eine Schnellprüfung kann ein siteweites Problem aufdecken, z. B. einen geerbten Canonical, ein Soft-404-Muster oder erfundene Bewertungen. Erweitern Sie den Auftrag nicht stillschweigend: Beenden Sie die angeforderte Änderung, setzen Sie das Problem an den Anfang Ihres Berichts mit einer Zeile, warum es wichtig ist, und bieten Sie den vollständigen Durchlauf an. Der Benutzer entscheidet, ob er dafür bezahlen möchte. Die Ausnahme ist, wenn die angeforderte Änderung ohne die Behebung nicht funktionieren kann, z. B. wenn die von Ihnen bearbeitete Seite kein serverseitig gerendertes H1 enthält. Beheben Sie in diesem Fall das Nötigste und sagen Sie es.

Workflow (Vollmodus)

Führen Sie die Phasen der Reihe nach für eine neue Website oder Seitengruppe aus. Für eine einseitige Änderung führen Sie mindestens die Phasen 3, 4 und 6 durch. Lesen Sie die verlinkte Referenzdatei, wenn Sie eine Phase erreichen – jede enthält die detaillierte Checkliste und Vorlagen.

Skalieren Sie die Arbeit auf die Anfrage. Eine Seitenüberprüfung ist eine Seitenüberprüfung; eine Keyword-Map ist eine Keyword-Map. Erledigen Sie die angeforderte Aufgabe gründlich und setzen Sie angrenzende Möglichkeiten (Keywords, Off-Page-Ideen) in eine kurze "Auch lohnenswert"-Liste, anstatt vollständige Zusatzpläne zu erstellen, die niemand angefordert hat. Zusätzliche Deliverables verwässern das, was der Benutzer braucht, und kosten Zeit.

Überprüfen Sie, bevor Sie behaupten. Überprüfen Sie Fakten, die Sie überprüfen können (das Live-SERP, ob der Markenname bereits vergeben ist, was eine Seite tatsächlich enthält, was eine Funktion tatsächlich tut). Wenn Sie etwas nicht überprüfen können – eine Seite, die Sie nur über die URL kennen, eine Website, die nicht lädt, ein Feature, das Sie nicht gesehen haben – sagen Sie, dass es eine Annahme ist, und teilen Sie dem Benutzer mit, was er bestätigen soll. Selbstbewusste Vermutungen über die Website eines anderen sind der häufigste Weg, wie SEO-Ratschläge falsch laufen.

Die Skripte sind für Sie da. Führen Sie scripts/*.py selbst aus. Beschreiben Sie in Anweisungen, die für den Benutzer geschrieben sind, die Prüfung in einfachen Worten oder geben Sie einen Befehl, den er ohne dieses Skill ausführen kann (curl, Search Console-Schritte). Verweisen Sie auf die Skriptpfade des Skills nur, wenn Sie wissen, dass der Benutzer das Skill installiert hat.

Phase 1 – Erkundung (vor jeder Änderung)

• Identifizieren Sie den Stack und wie Seiten gerendert werden (SSR, SSG, SPA, Hybrid). Lesen Sie für Framework-Fallen den entsprechenden Abschnitt von references/technical-seo.md (Next.js App Router hat einen eigenen Abschnitt).
• Erfassen Sie, was existiert: wie Metadaten gesetzt werden, wo Seiteninhalte leben, Sitemap- und Robots-Generierung, strukturierte Daten-Komponenten, Analysen. Verwenden Sie bestehende Muster wieder, anstatt parallele hinzuzufügen.
• Rufen Sie eine repräsentative Seite jedes Typs als Googlebot ab und erfassen Sie die Basislinie: python3 <skill-dir>/scripts/seo_check.py <url> [<url> ...] Es meldet Status, Titel-/Beschreibungslängen, Canonical, Robots-Meta und X-Robots-Tag, H1-Anzahl, sichtbare Wortanzahl, JSON-LD-Typen, OG-Bild und rote Flaggen wie ein "Loading…"-Hauptelement.
• Wenn Search Console-Daten verfügbar sind (ein Export, ein API-Helper oder das seo-google-Skill, falls installiert), ziehen Sie 90 Tage Abfrage+Seiten-Zeilen und führen Sie scripts/gsc_opportunities.py aus (siehe Phase 6). Vorhandene Impressionen verraten Ihnen, was Google bereits mit der Website assoziiert.
• Suchen Sie nach Projekt-SEO-Dokumenten oder Gedächtnisnotizen aus früheren Audits und bauen Sie darauf auf.

Phase 2 – Keyword-Recherche und die Keyword-Map

Lesen Sie references/keyword-research.md. Kurz zusammengefasst:

1. Starten Sie vom Produkt: Was die Seite tut, wer sie verwendet, die Wörter, die Benutzer eingeben, wenn sie genau das wollen.
2. Erweitern Sie mit kostenlosen Signalen: Google Autocomplete und "Leute fragen auch", verwandte Suchanfragen, Konkurrententitel, GSC-Abfragen, Reddit/Quora-Formulierungen. Verwenden Sie kostenpflichtige APIs nur, wenn das Projekt sie hat (z. B. die Skills seo-dataforseo oder seo-ahrefs, falls installiert).
3. Klassifizieren Sie die Absicht (tun / wissen / gehen / kaufen) und sehen Sie sich das Live-SERP für jeden Kandidaten an. Wenn Seite eins voller großer Marken oder eines anderen Seitentyps ist (z. B. Listen, wenn Sie ein Tool haben), ist das Keyword für diese Seite noch nicht gewinnbar.
4. Bewerten Sie die Gewinnbarkeit: Schwache Konkurrenten (dünne Indie-Seiten, Foren, GitHub-Repos, *.vercel.app-Seiten) auf Seite eins ist das stärkste Signal.
5. Überprüfen Sie den Markennamen: Suchen Sie ihn nackt, plus npm/PyPI/GitHub/App-Stores, wo relevant. Wenn er vergeben ist, empfehlen Sie, konsequent die Domain-Form ("Marke.app") zu verwenden.
6. Erstellen Sie eine Keyword-Map: Eine Zeile pro URL mit primärem Keyword, 3–8 sekundären/Long-Tail-Begriffen, Absicht und wo jeder Begriff platziert wird (Titel, H1, H2, Einleitung, FAQ). Kein primäres Keyword erscheint in zwei Zeilen, und jede Zeile in jeder Tabelle hat eine Absicht.

Volumenzahlen ohne ein kostenpflichtiges Tool sind Richtwerte (sehr hoch / hoch / mittel / niedrig). Sagen Sie das in Ihrer Ausgabe, anstatt Zahlen zu erfinden.

Phase 3 – On-Page-Implementierung

Lesen Sie references/on-page.md für die vollständige Checkliste und das Seiteninhaltsmodell. Die wesentlichen Dinge für jede indexierbare Seite:

• Titel: Einzigartig, primäres Keyword zuerst, idealerweise ≤ 60 Zeichen inklusive etwaiger Markensuffixe, und so geschrieben, dass er den Klick gewinnt.
• Meta-Beschreibung: Einzigartig, 120–160 Zeichen, gibt an, was der Benutzer bekommt, und das Unterscheidungsmerkmal ("kostenlos, keine Anmeldung, läuft in Ihrem Browser") nur, wenn es wahr ist.
• Genau ein H1 im Server-HTML, der der primären Absicht der Seite entspricht (eine enge Variante des Titels, keine Kopie).
• Haupttext: Beantworten Sie die Suchanfrage im ersten Absatz, fügen Sie dann Tiefe hinzu, die einer Konkurrenzseite fehlt: Schritt-für-Schritt-Anleitungen, ausgearbeitete Beispiele, häufige Probleme mit Lösungen, Einschränkungen, FAQs. Jeder Abschnitt existiert, weil ein Suchender ihn braucht, nicht um eine Wortanzahl zu erreichen.
• FAQs sichtbar im HTML (nicht nur in collapsed, unmontierten Akkordeons und nicht nur in JSON-LD), formuliert als echte Suchanfragen.
• Interne Links: 3–5 kontextbezogene Links zu verwandten Seiten und mindestens ein Link in die Seite von einem relevanten Hub oder Artikel aus. Keine verwaisten Seiten.
• Strukturierte Daten, die zum sichtbaren Inhalt passen: Siehe references/structured-data.md für Typen, die immer noch Rich Results erhalten.
• Vertrauen: Echter Autor oder Organisation, genaue Behauptungen, Datum der letzten Überprüfung, das sich ändert, wenn sich der Inhalt ändert, Quellen für Zahlen. Veröffentlichen Sie niemals Platzhalter-Bewertungen oder Testimonials – Google behandelt sie als Falschdarstellung.

Speichern Sie SEO-Inhalte von Seiten als Daten (ein typisiertes Konfigurationsobjekt oder CMS-Felder), anstatt Zeichenfolgen über JSX zu verstreuen. Das ermöglicht Einzigartigkeitsprüfungen, Längentests und Massenüberprüfungen.

Phase 4 – Technische Prüfungen (nicht überspringen)

Lesen Sie references/technical-seo.md. Bevor Sie eine Seite als erledigt betrachten, bestätigen Sie im gebauten oder bereitgestellten HTML:

• Status 200 für echte Seiten und ein echter 404 (kein 200 mit "nicht gefunden"-Text) für unbekannte URLs.
• Selbstreferenzierender absoluter Canonical und kein Canonical/Robots, der versehentlich von einem übergeordneten Layout geerbt wurde.
• Indexierbare Seiten sind in der Sitemap mit einem ehrlichen lastmod; noindex-Seiten sind nicht darin.
• Seiten, die Sie versteckt halten möchten, verwenden noindex (Meta oder X-Robots-Tag) und sind nicht in der robots.txt blockiert, sonst kann Google das noindex nie lesen.
• Hauptinhalt, H1, FAQ-Antworten und interne Links sind im rohen HTML vorhanden (seo_check.py Wortanzahl- und H1-Prüfung).
• Ein bevorzugter Host (https, www oder apex) mit Single-Hop-301-Weiterleitungen von den anderen.
• Core Web Vitals sind nicht zurückgegangen (LCP ≤ 2,5 s, INP ≤ 200 ms, CLS ≤ 0,1). Für Felddaten verwenden Sie PageSpeed Insights / CrUX oder die Skills seo-performance / seo-google, falls installiert.

Phase 5 – Off-Page und Distribution

Lesen Sie references/off-page.md. On-Page-Arbeit macht eine Seite qualifiziert; Links und Markennachfrage entscheiden darüber, wie hoch sie bei wettbewerbsfähigen Themen kommt. Planen Sie den Linkaufbau parallel zur Seite, nicht hinterher:

• Bauen Sie ein verlinkbares Asset pro Cluster (kostenloses Tool, Vorlagen-Repo, Datentabelle, origineller Leitfaden).
• Reichen Sie die Seite bei den wenigen Verzeichnissen und Launch-Plattformen ein, die zum Publikum passen, geschrieben als echte Beiträge.
• Nutzen Sie visuelle Plattformen (Pinterest, YouTube Shorts) für visuelle Nischen; GitHub für Entwicklerzielgruppen.
• Richten Sie Bing Webmaster Tools und IndexNow ein (Bings Index speist ChatGPT Search und Copilot).
• Kaufen Sie niemals Links, beteiligen Sie sich an Linkprogrammen oder reichen Sie Massen-Submissions bei Junk-Verzeichnissen ein.

Wenn Sie die Off-Page-Arbeit nicht selbst erledigen können, erstellen Sie ein gebrauchsfertiges Kit für den Benutzer: Zielliste, Beitragsentwürfe, E-Mail-Entwürfe für die Öffentlichkeitsarbeit und einen Kalender.

Phase 6 – Überprüfen, ausliefern, überwachen

Lesen Sie references/measurement.md.

• Führen Sie seo_check.py erneut gegen die gebauten oder bereitgestellten Seiten aus und vergleichen Sie mit der Basislinie aus Phase 1. Nehmen Sie bei Änderungen an gemeinsam genutzten Layouts oder Komponenten ein Diff von jedem Seitentyp vor, nicht nur von dem, den Sie bearbeitet haben – eine siteweite Änderung kann stillschweigend Seiten verändern, die bereits ranken.
• Nach dem Deployment: Reichen Sie die Sitemap erneut ein, fordern Sie die Indexierung nur für die wichtigsten neuen URLs an, pingen Sie IndexNow an.
• Nach 2–4 Wochen: Führen Sie python3 <skill-dir>/scripts/gsc_opportunities.py <gsc-export.json|csv> aus, um Suchanfragen in Schlagdistanz, Seiten mit niedriger CTR und Cannibalisierung aufzulisten, und iterieren Sie dann an Titeln, Abschnitten und internen Links für diese.

Hart erarbeitete Regeln

Diese stammen aus echten Regressionen. Jede hat Rankings oder die Indexierung gekostet, bevor sie gefunden wurde.

• Überprüfen Sie, was Crawler tatsächlich empfangen. Ein route-level Lade-Spinner, ssr: false dynamische Importe oder ein Fade-In, das bei opacity: 0 startet, können das Server-HTML nur mit "Loading…" hinterlassen, während der Browser perfekt aussieht. KI-Crawler führen überhaupt kein JavaScript aus.
• Eingangsanimationen verstecken das Hero. Animationsbibliotheken (framer-motion initial={{ opacity: 0 }}, AOS, GSAP) rendern ihren Startzustand serverseitig, daher werden H1 und Einleitung unsichtbar bis zur Hydratisierung ausgeliefert, was LCP verzögert. Verwenden Sie initial={false} oder reine CSS-Animation für alles above the fold; greppen Sie das gebaute HTML nach opacity:0.
• CMS-Textkörper fügen ein zweites H1 hinzu. Markdown, das mit # Titel unter einem seitenweiten H1 beginnt, dupliziert es. Stufen Sie H1s im Textkörper im Renderer auf H2 zurück.
• Soft 404s durch Streaming SSR. Sobald eine gestreamte Antwort begonnen hat, kann ein späteres notFound() die 200 nicht mehr ändern. Lehnen Sie unbekannte Slugs ab, bevor Sie rendern (statische Parameter mit deaktivierten dynamischen Parametern), oder geben Sie ein explizites noindex aus dem Metadaten-Miss-Zweig zurück.
• Geerbte Canonicals. Ein Canonical in einem Root-Layout wird auf jede Seite übertragen, die keinen eigenen setzt. Ein Soft 404, der es erbt, wird zu einem indexierbaren Duplikat einer echten Seite.
• "API down" ist nicht "keine Ergebnisse". Code, der über notFound() oder noindex entscheidet, muss einen fehlgeschlagenen Fetch von einem leeren Ergebnis unterscheiden, sonst entindexiert ein Ausfall echte Seiten.
• Versteckter Inhalt. Akkordeons, die geschlossene Panels aushängen, entfernen FAQ-Antworten aus dem HTML. Halten Sie sie montiert (hidden="until-found" oder CSS), damit sie crawljbar und durch die interne Suche auffindbar sind.
• Gemeinsam genutzte Komponenten sind eine Blast Radius. Wenn eine Seite gut rankt, ändern Sie gemeinsam genutzte SEO-Komponenten hinter Opt-in-Props und difffen Sie das gebaute HTML der anderen Seiten vorher und nachher.
• Erfundene soziale Signale. Platzhalter-Autorenseiten, gefälschte Produktbewertungen und konstruierte "Zitierungen" sind nachweisbare Falschdarstellungen. Bauen Sie echte Autorität auf oder lassen Sie es.
• Die Suchergebnisseite ändert sich. Das Live-SERP zum Zeitpunkt der Erstellung entscheidet. Eine Keyword-Map kann nach dem Go-Live obsolet sein. Teilen Sie dem Benutzer mit, ob Sie diese Prüfung übersprungen haben.

Wie Sie diesen Skill verwenden

1. Stellen Sie fest, ob der Schnellmodus ausreicht. Wenn Sie eine einzelne Seite bearbeiten und das Keyword kennen, sagen Sie "Quick mode" und verwenden Sie die Schnellcheckliste.
2. Wenn nicht, sagen Sie "Full mode" und beachten Sie die Phasen in der obigen Reihenfolge: Erkundung → Keywords → On-Page → Technik → Off-Page → Überprüfung.
3. Verweisen Sie auf die Referenzdateien, wenn Sie Hilfe benötigen: references/keyword-research.md, references/on-page.md, references/technical-seo.md, references/off-page.md, references/measurement.md, references/structured-data.md.
4. Führen Sie die Skripte selbst aus, wenn möglich. Sagen Sie dem Benutzer, wo die Ausgabe zu finden ist.
5. Kommunizieren Sie Annahmen und Unsicherheiten.