Anfang 2023 kam ein Reisekunde zu mir mit einem Setup, das wie ein Traum aussah. Er hatte 14.000 Standortseiten -- jede Stadt, jeder Bezirk, jeder Postleitzahlenbereich im Vereinigten Königreich -- alle automatisch aus einer Datenbank mit Hotel- und Restaurantdaten generiert. Sauberes Template. Ordentliche 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.March 2024 core update hit. They lost 71% of their organic traffic in six weeks. I spent three weeks doing the forensics. The content wasn't wrong exactly. But it was hollow. Every page said the same three things in slightly shuffled order, and Google had clearly decided it wasn't worth serving to anyone. We rebuilt the pipeline with proper quality gates and recovered to 60% of peak within five months. Not perfect. But a lesson that's stayed with me.
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 Qualitätsgate ist eine kontrollierte Regel oder ein Test, den eine Seite bestehen muss, bevor sie veröffentlicht wird -- oder bevor sie veröffentlicht bleibt. Es ist keine Bauchentscheidung. Es ist ein spezifischer, messbarer Schwellwert, der eine Seite entweder durchlässt oder zur Überarbeitung zurückschickt (oder sie ganz eliminiert).checkpointed rule or test that a page must pass before it gets published, or before it stays published. It's not a vibe check. It's a specific, measurable threshold that either lets a page through or sends it back for revision (or kills it entirely).
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 überhaupt Content geschrieben wird. Datenqualitätsprüfungen. Hat diese Entity genug einzigartige Attribute, um eine eigenständige Seite zu rechtfertigen?, before any content is written. Data quality checks. Does this entity have enough unique attributes to support a distinct page?
- Post-Generation -- nachdem die KI oder das Template den Content produziert hat. Automatische Bewertung von Länge, Einzigartigkeit, Entity-Abdeckung., after the AI or template has produced content. Automated scoring for length, uniqueness, entity coverage.
- Post-Publish-Monitoring -- laufend. Seiten, deren Impressionen oder Click-Through-Rate sinken, werden zur manuellen Überprüfung gekennzeichnet., ongoing. Pages that drop in impressions or click-through rate get flagged for human review.
Die meisten Teams bauen nur die mittlere Schicht. Deshalb werden sie reingeritten.
Das Data-Sufficiency-Problem (Das überspringen die meisten)
Hier ist das Ding -- die schlimmsten Probleme mit programmatischem Content entstehen, bevor ein Wort geschrieben wird. Sie entstehen im Spreadsheet.
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: Daten-Reichhaltigkeits-Scoring. Ich fahre jetzt jeden Datensatz durch ein einfaches Python-Skript, bevor wir ein Template anfassen. Es zählt die Anzahl der nicht-leeren, nicht-generischen Felder pro Datensatz und kennzeichnet alles unter einem Schwellwert -- ich verwende normalerweise 7 von 12 als Minimum. Datensätze, die das nicht schaffen, gehen in eine "Stub"-Kategorie, die eine dünne Seite mit noindex bekommt, oder gar keine Seite. I now run every dataset through a simple Python script before we touch a template. It counts the number of non-null, non-generic fields per record and flags anything below a threshold, I typically use 7 out of 12 as a minimum. Records that don't clear it go into a "stub" category that gets a thin page with noindex, or no page at all.
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 dein eigenes Seiten-Corpus. Near-Duplicate-Inhalte innerhalb deiner Site sind das häufigere Problem, und es ist das, das du mehr 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 for flagging pages that are too similar to existing indexed URLs
- 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
Wirklich einzigartig bedeutet nicht nur durcheinander gewürfelte Sätze. Es bedeutet, dass die Seite eine Frage beantwortet, die nur diese Entity beantworten kann. Für eine City-Landing-Page sind das hyperlokal Daten -- echte Event-Listings, echte lokale Statistiken, ein spezifisches Zitat aus einer lokalen Quelle. Für eine Produkt-Vergleichsseite sind es Datenpunkte, die diese zwei spezifischen Produkte differenzieren, nicht eine Boilerplate-Einleitung mit getauschten Substantiven.this entity can answer. For a city landing page, that's hyper-local data, real event listings, actual local statistics, a specific quote from a local source. For a product comparison page, it's data points that differentiate these two specific products, not a boilerplate intro with swapped nouns.
Goggles eigene Anleitung zu hilfreichen Inhalten hat das immer schon gesagt. Der Klassifizierer ist nur aggressive bei der Durchsetzung geworden. has always said this. The classifier just got aggressive about enforcing it.
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 im Content durch benannte Erwähnungen, semantische Assoziationen und strukturierte Daten repräsentiert werden. Wenn das nicht der Fall ist, wirkt die Seite dünn, selbst 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:spaCy to check that:
- 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 ungefähr so denke ich darüber:
- Falls die Seite nach 90 Tagen in GSC null Suchimpressionen hat: löschen und 301 zur nächstgelegenen relevanten übergeordneten Seite weiterleiten.delete and 301 to the nearest relevant parent.
- Falls die Seite Impressionen, aber unter 0,5% CTR und keine Backlinks hat: noindex setzen und in eine übergeordnete oder Kategorieseite konsolidieren.noindex and consolidate into a parent or category page.
- Falls die Seite Impressionen und anständige CTR (1%+) hat, aber niedrige durchschnittliche Position (40+): behalten, aber Inhaltsanreicherung priorisieren.keep, but prioritise for content enrichment.
- Wenn die Seite funktioniert: Lass sie in Ruhe und zweifle nicht ständig an dir selbst.leave it alone and stop second-guessing yourself.
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 das Schema einer Seite mehr als 30% leere oder Platzhalter-Werte hat, sagt mir das, dass die zugrundeliegenden Daten zu spärlich sind, um eine nützliche Seite zu produzieren. Deshalb haben wir einen Schema-Validator in unsere Pipeline eingebaut – er prüft erforderliche und empfohlene Properties gegen die Schema.org-Spezifikation für den Typ, den wir verwenden. Seiten, die diese Prüfung nicht bestehen, gehen zurück in die Enrichment-Queue.Schema.org spec for whatever type we're using. Pages that fail this check go back into the enrichment queue.
Nutzt Google Schema-Vollständigkeit als direktes Ranking-Signal? Fast sicher nicht auf simple Weise. Aber Seiten mit vollständigem, genauem Schema sind normalerweise Seiten mit vollständigen, genauen Daten – und diese Seiten ranken tendenziell besser. Die Korrelation ist stark genug, dass ich Schema-Qualität als nützliche Diagnose behandle, auch wenn es nicht der Mechanismus ist.those pages tend to rank. The correlation is strong enough that I treat schema quality as a useful diagnostic even if it's not the mechanism.
Ü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:Screaming Frog on every large pSEO property we manage, flagging:
- 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 vergleiche diese mit GSC-Daten, die via API exportiert werden – speziell auf der Suche nach Seiten, die in den letzten 60 Tagen mehr als 40% ihrer Impressionen verloren haben. Diese Schnittmenge (von Screaming Frog gekennzeichnet und in GSC fallend) ist die High-Priority-Review-Queue.and declining in GSC) is the 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-generierter Content nicht gegen ihre Richtlinien verstößt – unhilfreiches Content ist das Problem, unabhängig davon, wie es produziert wurde. Das Signal ist Qualität, nicht Herkunft. Eine manuell geschriebene Seite, die dünn und dupliziert ist, wird gleich behandelt. Was zählt, ist, ob die Seite die Suchanfrage des Nutzers wirklich besser bedient als die Alternativen. Wenn nicht, ist die Produktionsmethode irrelevant.unhelpful content that's the problem, regardless of how it was produced. The signal is quality, not origin. A manually written page that's thin and duplicative will get treated the same way. What matters is whether the page genuinely serves the user's query better than the alternatives. If it doesn't, the method of production is 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 ist nicht linear. Der Travel-Client, den ich oben erwähnt habe, hat sich erholt – aber es brauchte konstante Arbeit über fünf Monate: die schlechtesten Seiten löschen, mittelmäßige konsolidieren, Top-Performer anreichern. Die einzeln wirkungsvollste Maßnahme war die Reduzierung des Index von 14.000 auf etwa 4.200 Seiten. Kontraintuitiv, aber das ist das, was die Daten zeigten.
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, addieren vielleicht zwei bis drei Tage Setup-Zeit für ein neues pSEO-Projekt hinzu. Die Alternative – nach einem Core Update wieder aufzubauen, das dich auslöscht – kostet deutlich mehr als das. Ich weiß es, weil ich es beide Wege gemacht habe.