Wie ein 3-Layer Quality Gate programmatische SEO skalierbar macht
Die Ausgangssituation (Modellszenario)
Angenommen, ein DACH-Dienstleister will für eine große Zahl eng verwandter Long-Tail-Keywords organisch sichtbar sein. Die Keyword-Matrix besteht aus mehreren tausend Kombinationen aus Service, Region und Use Case. Jede dieser Kombinationen hat ein echtes Suchvolumen — aber einzeln zu klein, um eine manuell geschriebene Landing Page zu rechtfertigen.
Die Rechnung: 2.000 geplante Seiten × 45 Minuten pro manuell geschriebene Seite = 1.500 Stunden reine Schreibzeit. Ein unrealistisches Budget — und selbst wenn es verfügbar wäre: Bis die letzte Seite geschrieben ist, ist die erste veraltet.
Die Herausforderung
Die naheliegenden Lösungen scheitern alle an einem anderen Punkt:
- LLM schreibt alles: Google stuft massenhaft erzeugte Inhalte ohne eigenen Mehrwert als Spam ein („scaled content abuse“) – unabhängig davon, ob Mensch oder KI sie geschrieben hat. Nutzer springen ab, weil Inhalte austauschbar wirken.
- Template mit Platzhaltern: Wenn sich nur Stadtnamen und Zahlen ändern, ist das für Google praktisch derselbe Artikel. Gleiches Ergebnis wie oben.
- Manuell schreiben: Wirtschaftlich nicht darstellbar bei Seitenanzahlen jenseits einiger hundert.
Das eigentliche Problem ist kein Generierungs-, sondern ein Qualitätssicherungs-Problem. Generieren kann jedes moderne Sprachmodell in Sekunden. Die Frage ist: Wie sortiere ich aus, was Google als Wertstoff erkennt — und was als Füllmaterial?
Die Lösung: Ein dreistufiges Quality Gate
Statt einen einzigen teuren Prüfschritt durchzuführen, läuft jede generierte Seite durch drei Filter mit absteigender Durchlässigkeit und aufsteigendem Kostenaufwand:
Layer 1 — Regex-Vorfilter (Kosten: ~0 €)
Strukturelle Mindestanforderungen: Existieren alle Pflichtfelder? Ist die Wortanzahl im erwarteten Fenster? Enthält der Output keine typischen LLM-Artefakte („Als KI-Sprachmodell…“, leere Platzhalter, abgeschnittene Sätze)? Diese Prüfung läuft in Millisekunden und erwischt bereits einen spürbaren Teil der Rohausgaben.
Layer 2 — Claude Haiku Smart Check (Kosten: wenige Zehntelcent pro Prüfung)
Ein günstiges Sprachmodell prüft mit einem eng gefassten Prompt auf inhaltliche Plausibilität: Stimmt die behauptete Ortsangabe mit den Kontextdaten? Sind die Claims konsistent? Wiederholt sich der Text innerhalb der Seite? Haiku ist schnell, günstig und für diese Art von Binärentscheidungen ausreichend präzise. Diese Stufe fängt einen weiteren Teil ab.
Layer 3 — Claude Sonnet Deep Review (Kosten: ~0,02 € pro Prüfung)
Nur Grenzfälle aus Layer 2 werden an das teurere, leistungsfähigere Modell weitergegeben. Sonnet prüft auf subtilere Qualitätskriterien: Liest sich der Text natürlich? Bringt er über den Template-Kern hinaus echten Mehrwert? Liefert er Informationen, die ein vergleichbarer menschlicher Redakteur akzeptieren würde? Nur ein kleiner Teil der Seiten erreicht diese Stufe — der Rest ist bereits vorher abgelehnt oder durchgewunken.
Das Ergebnis: Eine dreistufige Pipeline, in der die meisten Prüfungen extrem günstig sind und der teure Schritt nur dort greift, wo er gebraucht wird.
Der technische Stack
Die Orchestrierung läuft über eine self-hosted n8n-Instanz. Die Einzelbausteine:
- Workflow-Engine: n8n (self-hosted via Docker)
- Generierung: Claude API (Sonnet-Stufe für Content, Haiku-Stufe für Quality Checks)
- Pre-Filter: Regex-Modul, in n8n als Code-Node
- Daten-Enrichment: Externe APIs für Geo-, Struktur- und Branchendaten, die jede Seite mit echten, faktisch korrekten Infos anreichern
- Publishing: WordPress REST API mit authentifizierten Requests
- Internal Linking: selbstentwickeltes WP-Plugin, das Beziehungen zwischen verwandten Seiten automatisch setzt
- Sitemap-Generierung: ebenfalls eigenes Plugin, weil die Standard-Lösungen bei 1.000+ Seiten an Grenzen stoßen
Die bewusste Entscheidung gegen All-in-One pSEO-Tools hat zwei Gründe: volle Kontrolle über jeden Pipeline-Schritt und Datenhoheit — die Inhalte laufen nicht durch fremde SaaS-Server, sondern über eigene Infrastruktur.
Was sich erreichen lässt
- Seiten live: eine große Anzahl indexierbarer Landing Pages
- Kosten pro Seite: gering, inklusive aller Quality-Gate-Stufen und der Generierung
- Zeitaufwand pro Seite: kurz, inklusive Quality Gate und Publishing
- Near-Duplicate-Rate: niedrig, weil das Quality Gate austauschbare Seiten aussortiert
- Ablehnungsquote gesamt: ein Teil der Roh-Generierungen wird ausgefiltert, bevor sie eine URL erreichen
Wichtiger als einzelne Zahlen ist, dass das System skalierbar ist. Eine Erweiterung der Keyword-Matrix, etwa durch eine zusätzliche Branchenvariante, erfordert typischerweise nur eine Konfigurationsänderung und einen Batch-Run über Nacht, statt eines großen Arbeitsaufwands.
Worauf es in der Umsetzung ankommt
Das Quality Gate ist wichtiger als das Generieren. Die eigentliche Engineering-Arbeit liegt nicht darin, ein LLM zum Schreiben zu bringen — das beherrschen moderne Sprachmodelle längst. Die Arbeit liegt darin, schlechte Outputs zuverlässig auszusortieren. Wer bei pSEO am Quality Gate spart, produziert skalierbaren Spam.
Regex und ein günstiges Sprachmodell fangen den Großteil der Probleme ab. Teure Modelle sollten nur dort laufen, wo günstigere versagen. Das ist keine Sparmaßnahme, sondern gute Systemarchitektur: Jeder Schritt hat seine Stärken, und man sollte ihn nur dort einsetzen.
Template-Diversität schlägt Template-Perfektion. Drei unterschiedliche Seitentypen, jeder davon ordentlich, wirken weniger austauschbar als ein perfekter Seitentyp in tausendfacher Kopie.
Echte Daten sind der Unterschied zwischen pSEO und Spam. Eine Seite zu „Region X“ muss tatsächlich etwas über Region X sagen, das nicht auch für Region Y gilt. Dafür braucht es eine Enrichment-Pipeline, die Fakten liefert — nicht ein LLM, das Fakten halluziniert.
Wann der Ansatz passt
pSEO mit Quality Gate ist sinnvoll, wenn:
- Eine Keyword-Matrix mit mindestens mehreren hundert Kombinationen existiert (Service × Region, Industry × Use Case, Produkt × Anwendungsgebiet)
- Jede Kombination echtes, wenn auch kleines Suchvolumen hat
- Strukturierte Datenquellen verfügbar sind, die jede Seite einzigartig machen können (nicht nur Platzhalter-Text)
- Die Zielgruppe Long-Tail-Anfragen stellt, nicht primär generische Broad-Match-Keywords
Typische Kandidaten: B2B-Dienstleister mit regionalem Fokus, Marktplätze, Vergleichsportale, SaaS-Anbieter mit breiter Branchenabdeckung, Franchise-Unternehmen. Mehr dazu unter Content-Autopilot.
Ein verwandter Ansatz für Eingangs-Dokumente statt Ausgangs-Seiten findet sich in unserem Beitrag zur automatisierten Dokumentenverarbeitung — gleicher Pipeline-Gedanke, andere Richtung.
Haben Sie eine Keyword-Matrix, die sich für pSEO eignen könnte? Die kostenlose Analyse prüft das Potenzial in 60 Sekunden.