Anfang 2023 kam ein Reisekunde zu mir mit einem Setup, das wie ein Traum aussah. Er hatte 14.000 Locations-Seiten, jede Stadt, jeder Stadtteil, jede Postleitzahlregion im UK, alle automatisch aus einer Datenbank mit Hotel- und Restaurantdaten generiert. Saubere Vorlage. Anständige interne Verlinkung. Und es rankte. Etwa vier Monate lang.
Dann kam das Core-Update im März 2024. Sie verloren in sechs Wochen 71 % ihres organischen Traffic. Ich verbrachte drei Wochen mit der Forensik. Der Inhalt war nicht direkt falsch. Aber er war hohl. Jede Seite sagte das gleiche in drei Dingen in leicht durcheinander gewürfelter Reihenfolge, und Google hatte offensichtlich entschieden, dass es nicht wert war, es jemandem zu servieren. Wir rebuilteten die Pipeline mit ordentlichen Quality Gates und erholten uns auf 60 % des Spitzenwerts innerhalb von fünf Monaten. Nicht perfekt. Aber eine Lektion, die bei mir geblieben ist.
Programmatic SEO ist immer noch eines der mächtigsten Werkzeuge im Agency-Toolkit. Aber die Toleranz für Slop ist quasi weg.
Was „Quality Gate" in einer pSEO-Pipeline wirklich bedeutet
Leute werfen diesen Begriff locker herum, also lass mich präzise sein, wie ich ihn bei Seahawk nutze.
Ein Quality Gate ist eine geprüfte Regel oder ein Test, den eine Seite erfüllen muss, bevor sie veröffentlicht wird oder veröffentlicht bleibt. Es ist keine Gefühlsprüfung. Es ist ein spezifischer, messbarer Schwellenwert, der eine Seite entweder durchlässt oder zur Überarbeitung zurücksendet (oder sie ganz eliminiert).
Stell dir das wie Continuous Integration für Content vor. Entwickler pushen keinen Code, der Unit Tests nicht besteht. Du solltest keine Seiten veröffentlichen, die Content Tests nicht bestehen. Die Analogie ist nicht perfekt, aber nah genug, um nützlich zu sein.
Eine Pipeline ohne Quality Gates ist nur eine Content-Spam-Maschine. Und 2024 ist Googles Classifier gut genug, um das im großen Stil zu erkennen.
Die drei Schichten, in denen Gates leben müssen
Ich strukturiere Gates an drei Momenten:
- Pre-Generation, bevor ein einziges Wort geschrieben ist. Datenqualitätsprüfungen. Hat diese Entity genug einzigartige Attribute, um eine eigenständige Seite zu rechtfertigen?
- Post-Generation, nachdem die KI oder Vorlage Content produziert hat. Automatische Bewertung für Länge, Einzigartigkeit, Entity-Abdeckung.
- Post-Publish-Monitoring, laufend. Seiten, deren Impressionen oder Click-Through-Rate sinken, werden für menschliche Überprüfung gekennzeichnet.
Die meisten Teams bauen nur die mittlere Schicht. Deshalb werden sie reingeritten.
Das Data-Sufficiency-Problem (Das überspringen die meisten)
Hier ist das Problem: Die schlimmsten Probleme mit programmatischem Content entstehen, bevor ein Wort geschrieben wird. Sie entstehen in der Tabellenkalkulation.
Wenn deine Quelldaten 12 Attribute pro Entität haben und 9 davon sind bei 80% deiner Datensätze identisch, wirst du quasi-duplizierte Seiten produzieren, egal wie clever deine Prompts sind. Ich habe das bei einem Solicitors-Verzeichnis gelernt, das wir 2021 bei Seahawk gebaut haben. Wir hatten 6.000 Anwaltskanzlei-Einträge. Etwa 4.200 davon hatten nichts Besonderes außer einem Namen, einer Postleitzahl und einer Fachrichtung. Wir haben alle 6.000 veröffentlicht. Google hat vielleicht 1.800 indexiert.
Pre-Generation Gate: Data-Richness-Scoring. Ich fahre jeden Datensatz jetzt durch ein einfaches Python-Skript, bevor wir eine Vorlage anfassen. Es zählt die Anzahl der nicht-leeren, nicht-generischen Felder pro Datensatz und kennzeichnet alles unter einem Schwellenwert – typischerweise nutze ich 7 von 12 als Minimum. Datensätze, die es nicht schaffen, gehen in eine „Stub"-Kategorie, die eine dünne Seite mit noindex erhält, oder es gibt gar keine Seite.
Das ist nicht glamourös. Aber es ist die einzige Änderung, die die größte Auswirkung auf die Crawl-Effizienz in unseren Projekten hatte.
Uniqueness Scoring nach der Generierung
Deine Daten haben das erste Gate bestanden. Der Content wurde generiert. Und jetzt?
Veröffentliche nicht, bis du es auf Einzigartigkeit bewertet hast – nicht gegen das Web, sondern gegen deinen eigenen Seiten-Corpus. Nahezu identische interne Inhalte sind das häufigere Problem, und es ist das, das du direkter kontrollieren kannst.
Ich nutze eine Kombination aus zwei Tools dafür:
- [Copyscape's Batch API](https://www.copyscape.com/api.php) zum Kennzeichnen von Seiten, die zu ähnlich zu bestehenden indexierten URLs sind
- Ein custom Cosine-Similarity-Skript (mit sentence-transformers in Python), das jede neue Seite gegen die 50 strukturell ähnlichsten Seiten in der gleichen Template-Familie bewertet
Meine Schwelle liegt bei 0,82 Kosinus-Ähnlichkeit. Alles darüber geht zur manuellen Überprüfung. Alles über 0,91 wird gelöscht oder stark überarbeitet.
Ja, das fügt der Pipeline Reibung hinzu. Gut. Reibung ist genau der Punkt.
Was „Einzigartig" wirklich bedeuten muss
Genuinely unique bedeutet nicht nur umgeordnete Sätze. Es bedeutet, die Seite beantwortet eine Frage, die nur diese Entity beantworten kann. Für eine City-Landing-Page sind das hyperlokal Daten, echte Event-Listings, tatsächliche lokale Statistiken, ein spezifisches Zitat aus einer lokalen Quelle. Für eine Product-Comparison-Page sind das Datenpunkte, die diese zwei spezifischen Produkte differenzieren, nicht eine Boilerplate-Einleitung mit ausgetauschten Substantiven.
Goggles eigene Anleitung zu hilfreichen Inhalten hat das immer schon gesagt. Der Klassifizierer ist nur aggressive bei der Durchsetzung geworden.
Entity Coverage: Das Tor, das niemand anspricht
Das herauszufinden hat mich länger gedauert, und ich ärgere mich, dass es so lange gedauert hat.
Jede Seite in einem programmatischen Build handelt nominell "von" etwas – einem Ort, einem Produkt, einer Person, einem Service. Die Entität und ihre Attribute sollten konsistent durch explizite Erwähnungen, semantische Assoziationen und strukturierte Daten im Inhalt repräsentiert werden. Wenn das nicht der Fall ist, wirkt die Seite dünn, auch wenn sie 800 Wörter lang ist.
Ich führe jetzt einen leichtgewichtigen NLP-Pass mit spaCy auf jeder generierten Seite durch, um zu überprüfen, dass:
- Die primäre Entity in den ersten 100 Wörtern genannt wird
- Mindestens 4 semantisch verwandte Entitäten oder Attribute erscheinen im Haupttext
- Die Seite enthält mindestens ein Faktum, das einzigartig für die Entität ist (aus den Quelldaten gezogen, nicht vom Modell halluziniert)
Diese letzte Prüfung ist momentan manuell. Ich möchte sie automatisieren, aber ich habe noch keine zuverlässige Methode gefunden, um Cross-Reference-Validierung im großen Maßstab ohne zu viele falsch positive Ergebnisse durchzuführen. Falls du das gelöst hast, würde ich es wirklich gerne wissen.
The Thin-Page Trap: Wann man noindex setzt und wann man löscht
Nehmen wir an, eine Seite wird generiert, wirkt aber dennoch dünn bestückt. Vielleicht waren die Daten spärlich, die Entität ist obskur, und der Output ist technisch einzigartig, aber nicht besonders nützlich.
Was machst du?
Hier ist mein Entscheidungsbaum, vereinfacht, aber so denke ich grob darüber:
- Falls die Seite nach 90 Tagen in GSC null Suchimpressionen hat: löschen und 301 zur nächstgelegenen relevanten übergeordneten Seite weiterleiten.
- Falls die Seite Impressionen, aber unter 0,5% CTR und keine Backlinks hat: noindex setzen und in eine übergeordnete oder Kategorieseite konsolidieren.
- Falls die Seite Impressionen und anständige CTR (1%+) hat, aber niedrige durchschnittliche Position (40+): behalten, aber Inhaltsanreicherung priorisieren.
- Wenn die Seite funktioniert: Lass sie in Ruhe und zweifle nicht ständig an dir selbst.
Ich kann nicht sagen, wie oft ich schon gesehen habe, dass Agency-Owner Seiten auf noindex gesetzt haben, die leise konvertiert haben. Reparier nicht, was nicht kaputt ist.
Structured Data als Qualitätssignal (nicht nur für Rich Results)
Die meisten Leute fügen pSEO-Seiten Schema hinzu, um Rich Results zu bekommen. Fair genug. Aber ich habe angefangen, Schema-Vollständigkeit auch als Proxy-Qualitätstor zu behandeln.
Wenn ein Seiten-Schema mehr als 30 % Null- oder Platzhalterwerte hat, zeigt mir das, dass die zugrunde liegenden Daten zu spärlich sind, um eine nützliche Seite zu produzieren. Deshalb haben wir einen Schema-Validator in unsere Pipeline eingebaut, der erforderliche und empfohlene Eigenschaften gegen die Schema.org-Spezifikation für den jeweils verwendeten Typ prüft. Seiten, die diese Prüfung nicht bestehen, gehen zurück in die Enrichment-Warteschlange.
Nutzt Google Schema-Vollständigkeit als direktes Ranking-Signal? Fast sicher nicht auf einfache Weise. Aber Seiten mit vollständigem, genauen Schema sind typischerweise Seiten mit vollständigen, genauen Daten, und diese Seiten ranken tendenziell besser. Die Korrelation ist stark genug, dass ich Schema-Qualität als nützliches Diagnose-Tool behandle, auch wenn es nicht der Mechanismus selbst ist.
Überwachung nach Veröffentlichung: Das Tor, das weiterhin funktioniert
Ein Qualitätstor ist keine einmalige Sache. Seiten degradieren. Daten werden alt. Eine Seite, die im Januar in Ordnung war, könnte im Oktober dünn sein, weil die Welt sich bewegt hat und der Content nicht.
Ich führe monatlich einen Crawl mit Screaming Frog auf jeder großen pSEO-Property durch, die wir verwalten, und kennzeichne:
- Seiten unter 350 Wörtern (nach Boilerplate-Entfernung)
- Seiten, bei denen das Title-Tag mit mehr als 3 anderen Seiten der Website übereinstimmt
- Seiten ohne interne Links, die auf sie verweisen (Verwaistungsrisiko)
Ich kreuze diese mit GSC-Daten ab, die ich via API exportiere, und suche speziell nach Seiten, die in den letzten 60 Tagen mehr als 40 % ihrer Impressionen verloren haben. Diese Schnittmenge (von Screaming Frog markiert und in GSC rückläufig) ist die High-Priority-Review-Queue.
Ehrlich gesagt ist dieser Überwachungsschritt der Punkt, an dem die meisten Agenturen Ecken abschneiden, weil er auf offensichtliche Weise nicht abrechenbar ist. Aber genau das trennt einen pSEO-Aufbau, der Bestand hat, von einem, der nach dem nächsten Core Update zusammenbricht.
FAQ
Löst die Verwendung von KI zur Inhaltserstellung automatisch eine Google-Strafe aus?
Nein. Google hat explizit gesagt, dass KI-generierte Inhalte nicht gegen ihre Richtlinien verstoßen, unhilfreichr Inhalt ist das Problem – egal wie dieser entstanden ist. Das Signal ist Qualität, nicht Herkunft. Eine manuell geschriebene Seite, die dünn und dupliziert ist, wird genauso behandelt. Es geht darum, ob die Seite die Anfrage des Nutzers wirklich besser bedient als die Alternativen. Wenn nicht, ist die Produktionsmethode irrelevant.
Wie viele Seiten sind „zu viele" für einen programmatischen Aufbau, bevor Google misstrauisch wird?
Es gibt keine festgelegte Zahl, und jede spezifische Angabe, die du online gesehen hast, ist frei erfunden. Wichtig ist das Verhältnis von indexierten Seiten zu Seiten, die Rankings haben. Wenn du 20.000 Seiten hast und nur 400 Impressionen bekommen, ist das ein Crawl-Budget- und Qualitätsproblem. Google fängt an, den Rest zu ignorieren. Ich würde lieber 3.000 starke Seiten veröffentlichen als 20.000 mittelmäßige. Die Index-Abdeckungsrate ist die Metrik, auf die man achten sollte, nicht die absolute Seitenzahl.
Kann ich mich von der KI-Slop-Strafe erholen, wenn ich damit getroffen wurde?
Ja, aber es braucht Zeit und es verläuft nicht linear. Der Travel-Client, den ich oben erwähnt habe, erholte sich, aber es brauchte kontinuierliche Arbeit über fünf Monate: das Löschen der schlechtesten Seiten, das Konsolidieren mittelmäßiger, das Enrichen der Top-Performer. Die einzeln wirkungsvollste Maßnahme war die Reduzierung des Index von 14.000 auf etwa 4.200 Seiten. Kontraintuitiv, aber das zeigten die Daten.
Was ist der schnellste Weg, um zu identifizieren, welche Seiten in einem großen Build „Schrott" sind?
Ziehe deine vollständigen GSC-Performance-Daten der letzten 16 Wochen. Filtere nach Seiten mit mehr als 0 Impressions, aber weniger als 0,8 % CTR und durchschnittlicher Position schlechter als 35. Diese Kohort ist dein Problemset. Vergleiche mit Wortanzahl und Anzahl der internen Links. Die Überlappung von niedriger CTR, niedriger Wortanzahl und verwaisten Seiten ist fast immer der schwächste Teil eines jeden programmatischen Builds.
---
Im großen Maßstab zu bauen gibt dir nicht die Erlaubnis, schlecht zu bauen. Die Gates, die ich beschrieben habe, kosten bei einem neuen pSEO-Projekt vielleicht zwei bis drei Tage Setup-Zeit. Die Alternative, nach einem Core Update von vorne anzufangen, kostet deutlich mehr. Ich weiß das, weil ich beide Wege gegangen bin.