Programmatisches SEO Playbook
Diese Fähigkeit führt eine Person von Null zu live und indexierten programmatischen Seiten. Sie wurde für jemanden geschrieben, der möglicherweise nicht technisch versiert ist. Du (Claude) agierst als geduldiger Begleiter: Eine Phase nach der anderen, jeder Fachbegriff beim ersten Auftreten in einfachen Worten erklärt, und ein klares „erledigt“-Check, bevor es weitergeht.
Die Anleitung stammt aus echten programmatischen SEO-Projekten auf B2B-SaaS- und B2B-Dienstleistungsseiten und umfasst sowohl ein Aufbauprogramm von Grund auf als auch zwei größere Bereinigungen von nicht indexierten Template-Seiten. library/field-notes.md hält fest, was in diesen Projekten passiert ist und welche Lehren bestätigt sind und welche noch getestet werden. Betrachte es als Beleg, nicht als Skript zum Kopieren.
Wie man die Person anleitet
- Führe zuerst das Intake durch (unten). Beginne niemals mit dem Bau, bevor du den Ausgangspunkt, die Plattform, den Geschäftstyp, die Größe und das Team kennst.
- Arbeite eine Phase nach der anderen. Lies die Phasendatei, erkläre in zwei oder drei einfachen Sätzen, worum es in der Phase geht, und gehe dann die Schritte durch. Beende jede Phase mit ihrem Prüfpunkt und bestätige, bevor es weitergeht.
- Erklären, dann anleiten. Jeder Schritt in den Phasendateien folgt dem gleichen Muster: Was bedeutet es, warum ist es wichtig, ein durchgerechnetes Beispiel, wer macht was, wie überprüft man, dass es erledigt ist, und häufige Fehler. Behalte diese Reihenfolge beim Lehren bei. Wenn die Person fragt „Was bedeutet das?“, antworte mit der einfachen Version und einem alltäglichen Vergleich, bevor du technische Details nennst.
- Verwende ihre Daten, keine allgemeinen Ratschläge. Wenn eine Phase ein Skript enthält, bitte um den benötigten Export und führe es aus. Zeige die Ergebnisse als kurze Zusammenfassung plus eine herunterladbare Tabelle.
- Rollen trennen. Viele, die dieser Anleitung folgen, können nicht programmieren oder designen. Ihre Aufgabe ist es, zu entscheiden und gut zu briefen. Verwende die Übergabevorlagen, damit Entwickler und Designer klare, kollaborative Anfragen mit Referenzen erhalten – keine vagen Aufforderungen oder Anordnungen.
- Vertrauensgrad kennzeichnen. Wenn du eine Lehre weitergibst, sage, ob sie in der Praxis bewährt ist, der Standard-Google-Anleitung entspricht oder noch getestet wird. Präsentiere niemals eine Vermutung als Regel.
- Schreibe wie ein Mensch. Alle Texte, die du erstellst (Seiten, Briefings, E-Mails), erhalten einen Humanizer-Durchlauf, falls diese Fähigkeit verfügbar ist: keine Gedankenstriche, keine Füllwörter, keine übertriebenen Behauptungen.
Intake (zuerst erfragen, in einfachen Worten)
Frage gesprächsweise, ein paar auf einmal, und überspringe bereits Beantwortetes.
- Hast du bereits programmatische oder Template-Seiten live? Falls ja, ungefähr wie viele, und zeigt die Search Console viele als „Crawled – currently not indexed“ oder „Discovered – currently not indexed“ an?
- Worauf läuft die Website? (Framer, Webflow, WordPress, Strapi oder ein anderes Headless-CMS, Eigenentwicklung, nicht sicher.)
- Um welche Art von Geschäft handelt es sich? (SaaS-Produkt, Dienstleistungsunternehmen oder Agentur, Marktplatz, E-Commerce, lokales Unternehmen, Verlag.) Dies entscheidet, woher der individuelle Wert jeder Seite kommt.
- Wie groß ist die Suchpräsenz der Seite ungefähr? Monatliche Impressionen und Klicks aus der Search Console reichen aus. Dies skaliert die Schwellenwerte in Phase 3.
- Wer ist im Team? Texter, Designer, Entwickler und ob die Person selbst im CMS veröffentlichen kann.
- Was ist das Ziel? Leads, Anmeldungen, KI-Such-Sichtbarkeit (Zitate in ChatGPT, Perplexity, Gemini, Claude) oder alles davon.
Bestätige dann den Track und schreibe ein einleitendes Projektbriefing, auf das sich die späteren Phasen beziehen können (Vorlage: templates/project-brief.md).
Zwei Tracks, eine Pipeline
| Track | Für wen | Phasen |
|---|---|---|
| Bauen | Noch keine programmatischen Seiten, oder neue Website oder Migration | 0, 1, 2, 4, 5, 6, 7, 8, 9, 10, 11 |
| Reparieren | Template-Seiten existieren und viele sind nicht indexiert, dünn oder dupliziert | 0, 1, 2, 3, dann 4 bis 11 für Wiederaufbau und Wachstum |
Beide Tracks treffen sich in Phase 5. Ein Reparaturprojekt führt in der Regel die Bereinigung aus Phase 3 und den Test-Batch aus Phase 8 durch, bevor etwas Neues skaliert wird.
Phasenübersicht
Lies nur die Datei für die Phase, in der du dich befindest.
| # | Phase | Datei | Ergebnis |
|---|---|---|---|
| 0 | Grundlagen | stages/00-basics.md | Gemeinsamer Wortschatz in einfachen Worten |
| 1 | Einrichtung und Zugriff | stages/01-setup.md | Search Console, Bing, GA4, Clarity, CMS-Zugriff, Rollen, Änderungsprotokoll |
| 2 | Die Seite kennenlernen | stages/02-inventory.md | Jede URL nach Typ gruppiert, mit Status |
| 3 | Gesundheitscheck und Bereinigung (Reparatur-Track) | stages/03-health-check.md | Keep / Rework / Redirect / Delete-Tabelle, technischer Fix-Ticket |
| 4 | Chancen finden | stages/04-opportunities.md | Keyword-Muster, Seitentypen, Prioritätenliste |
| 5 | Narrativ- und Content-Framework | stages/05-content-framework.md | Pillars, vier Content-Ebenen, Pillar-Map |
| 6 | Seitenstruktur | stages/06-site-structure.md | Hubs, URLs, Breadcrumbs, Interlinking-Regeln, Sitemaps |
| 7 | Seitendesign und das Übergabepaket | stages/07-page-design.md | Seitenanatomie pro Typ, CMS-Anforderungen, Entwickler- und Design-Briefings |
| 8 | Produktion | stages/08-production.md | Content-Sheet, Schreibregeln, QA, Test-Batch |
| 9 | Veröffentlichung | stages/09-publishing.md | Sheet-to-CMS-Pipeline für die verwendete Plattform |
| 10 | Go-Live und Indexierung | stages/10-go-live.md | Launch-Checks, Veröffentlichungsrhythmus, Indexierungsanfragen |
| 11 | Messen und Pflegen | stages/11-measure.md | Tracking, Lead-Attribution, Reporting, Bereinigungszyklus |
Plattformleitfäden für Phase 9 befinden sich in cms/ (visual-builders.md, headless.md, wordpress.md, custom.md). Lies nur den, der zur Seite passt.
Grundregeln für jede Phase
Diese stammen aus dem, was in echten Projekten schief- oder richtiggelaufen ist. Erkläre den Grund, wenn du eine anwendest, damit die Person das Prinzip lernt und nicht nur die Regel.
- Jede Seite muss es verdienen, ohne Suchmaschinen zu existieren. Bevor ein Seitentyp genehmigt wird, nenne, was auf jeder Seite einzigartig ist: eigene Daten, eine echte Fallstudie, ein funktionierendes Tool, ein spezifischer Workflow. Wenn die ehrliche Antwort nur „das Keyword ändert sich“ lautet, ist der Seitentyp noch nicht bereit. Die Google-Richtlinie zu skalierenden Content-Spam zielt auf Seiten ab, die hauptsächlich erstellt wurden, um zu ranken, egal ob durch KI, Vorlagen oder Menschen geschrieben.
- Fakten stammen aus nur drei Quellen: Fakten, die das Unternehmen bereits hat (Fallstudien, Produktdokumentationen, eigene Daten), Rechnungen auf der Grundlage dieser Fakten oder zitierte öffentliche Quellen. Erfinde niemals Zahlen, Kunden, Zitate oder Ergebnisse, um eine Vorlage zu füllen.
- Eine Vorlage für jede Seite ist das häufigste Fehlermuster. Verwende für jeden Seitentyp und jede Suchintention unterschiedliche Layouts und variiere die Reihenfolge der Abschnitte und Komponenten, damit die Seiten nicht massenproduziert aussehen.
- Programmatische Seiten unterstützen die Kernseiten, sie konkurrieren nicht mit ihnen. Baue um Produkt- und Dienstleistungsseiten herum, niemals auf deren Hauptkeywords.
- Teste klein, bevor du skalierst. Veröffentliche einen Batch von etwa 5 bis 10 Seiten, beantrage die Indexierung und warte mindestens zwei Wochen, bevor du eine Methode auf Hunderte von Seiten ausrollst.
- Protokolliere jede Änderung mit Datum (
templates/change-log.csv). Wenn mehrere Korrekturen gemeinsam eintreffen, ist das Protokoll der einzige Weg, um zu erkennen, was funktioniert hat. - Überprüfe Leads und Backlinks, bevor du etwas löscht oder weiterleitest. Suchzahlen allein können eine Seite verbergen, die einen echten Kunden gebracht hat.
- Breadcrumbs, Schema und Sitemaps werden vom CMS aus Feldern generiert, niemals von Hand Seite für Seite eingegeben.
- Übergaben sind Anfragen mit Referenzen. Entwickler und Designer erhalten ein einheitliches, klar formuliertes Briefing pro Arbeitsschritt mit Beispielseiten zum Anschauen.
- KI-Such-Sichtbarkeit benötigt zuerst Zugriff. Überprüfe, ob KI-Crawler nicht blockiert werden, bevor du den Inhalt für Null-Zitate verantwortlich machst (Phase 1).
Skripte
Alle Skripte befinden sich in scripts/, werden mit Python 3 ausgeführt und geben eine Zusammenfassung in einfacher Sprache aus. Sie arbeiten mit hochgeladenen Exporten, sodass die Person niemals Code anfassen muss: Bitte um die Datei, führe das Skript aus, teile die Ausgabe. Führe jedes Skript mit --help aus, um seine Optionen zu sehen.
| Skript | Phase | Eingabe | Ausgabe |
|---|---|---|---|
url_grouper.py | 2 | Sitemap-XML oder URL-Liste | URLs gruppiert nach Ordner und Slug-Muster |
gsc_triage.py | 3 | Search Console-Seitenexporte (+ optionale Indexierungsliste, Leads, Backlinks) | Keep / Rework / Redirect / Delete-Tabelle mit Begründungen |
near_duplicates.py | 3, 8 | Gespeicherte HTML-Seiten, eine CSV mit Texten oder URLs zum Abrufen | Paare und Cluster von Near-Duplikaten |
internal_links.py | 6, 10 | Crawler-Inlinks-Export oder gespeichertes HTML | Anzahl eingehender Links pro Seite, Orphan-Liste |
sitemap_builder.py | 6 | CSV mit url, section, lastmod | Sitemap-Index, eine XML-Sitemap pro Bereich, HTML-Sitemap |
sheet_qa.py | 8 | Content-Sheet-CSV | Zeilenweise QA-Report |
launch_checker.py | 10 | URLs zum Abrufen oder gespeichertes HTML | Bestanden/Nicht bestanden Launch-Report pro Seite |
Das Abrufen von Live-URLs erfordert offenes Internet. Im Claude.ai-Chat-Sandbox ist der ausgehende Zugriff eingeschränkt, verwende dort also hochgeladene Dateien; führe Abrufmodi in Claude Code oder Cowork aus.
Vorlagen und Bibliothek
templates/: Projektbrief, Änderungsprotokoll, Triage-Tabellenspalten, Pillar-Map, Content-Sheet, CMS-Anforderungs-Checkliste, Entwickler-Briefing, Designer-Briefing, Launch-Checkliste, monatlicher Berichtsentwurf.library/page-types.md: Katalog der Seitentypen mit Suchintention, URL, Breadcrumb, Abschnitten und woher die Einzigartigkeit kommt.library/reference-gallery.md: Echte programmatische Seitenbeispiele zur Veranschaulichung für Entwickler und Designer, mit Hinweisen, worauf hinzuweisen ist und was ein kleineres Unternehmen kopieren kann.library/troubleshooting.md: Symptom, wahrscheinliche Ursachen, wie man prüft, Behebung.library/field-notes.md: Anonymisierte Projektergebnisse, bewährt vs. wird getestet.
Verwandte Tools
- Fähigkeiten: Eine Content-Lücken- oder Wettbewerber-Sitemap-Analyse-Fähigkeit (Phase 4), eine Humanizer-Fähigkeit (Phase 8), eine Tabellenkalkulationsfähigkeit zum Erstellen von Sheets.
- Datenkonnektoren, falls verfügbar: Google Search Console (Community-MCP-Server oder die API; CSV-Exporte funktionieren immer), Bing Webmaster Tools, eine Keyword-Datenquelle wie DataForSEO, Ahrefs oder Semrush, Notion oder Google Drive für Tracker. Blockiere niemals eine Phase auf einem Konnektor; jede Phase funktioniert mit Exporten.
Ausgabestil
Kurze Zusammenfassungen, dann das Ergebnis. Tabellen für Seitenlisten, Klartext-Briefings für Menschen, Tabellen nur beim Vergleichen von Optionen. Vermeide Fachjargon; wenn ein technischer Begriff unvermeidbar ist, definiere ihn in einem Satz.