Anfang 2023 kam ein Travel-Client zu mir mit dem, was wie ein Traum-Setup aussah. Sie hatten 14.000 Standort-Seiten — jede Stadt, jeder Bezirk, jeder Postleitzahlenbezirk im Vereinigten Königreich — alle automatisch generiert aus einer Datenbank von Hotel- und Restaurantdaten. Sauberes Template. Anständige interne Verlinkung. Und es ranked. 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 Quality Gate ist eine Kontrollpunkt-Regel oder ein Test, den eine Seite bestehen muss, bevor sie veröffentlicht wird — oder bevor sie veröffentlicht bleibt. Es ist kein Vibe Check. Es ist ein spezifischer, messbarer Schwellenwert, der eine Seite entweder durchlässt oder zur Überarbeitung zurücksendet (oder sie ganz blockiert).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 irgendwelche Inhalte geschrieben werden. 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 Inhalte produziert hat. Automatisierte Bewertung für Länge, Eindeutigkeit, 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 Überprüfung durch Menschen 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 Problem – die schlimmsten programmgesteuerten Content-Probleme entstehen, bevor ein einziges 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: Datenreichtums-Scoring. Ich führe 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 unterhalb eines Schwellwerts – ich verwende typischerweise 7 von 12 als Minimum. Datensätze, die das nicht erfüllen, fallen in eine „Stub"-Kategorie, die eine dünne Seite mit noindex erhält 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 ihn auf Einzigartigkeit bewertet hast – nicht gegen das Web, sondern gegen deinen eigenen Page-Corpus. Quasi-duplizierter interner Content ist 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 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 dieses Unternehmen beantworten kann. Für eine Stadtlandingpage sind das hyperlokale Daten — echte Veranstaltungsauflistungen, tatsächliche lokale Statistiken, ein spezifisches Zitat aus einer lokalen Quelle. Für eine Produktvergleichsseite sind es Datenpunkte, die diese beiden spezifischen Produkte unterscheiden, nicht eine Boilerplate-Einleitung mit vertauschten 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 Entity und ihre Attribute sollten durchgehend im Inhalt durch benannte Erwähnungen, semantische Assoziationen und strukturierte Daten dargestellt sein. 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: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 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.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 zugrunde liegenden Daten zu spärlich sind, um eine brauchbare Seite zu produzieren. Daher haben wir einen Schema-Validator in unsere Pipeline eingebaut — er prüft erforderliche und empfohlene Eigenschaften gegen die Schema.org-Spezifikation für den Typ, den wir verwenden. Seiten, die diesen Check 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 einfache Weise. Aber Seiten mit vollständiger, genauer Schema haben tendenziell auch vollständige, genaue Daten — und diese Seiten ranken. Die Korrelation ist stark genug, dass ich Schema-Qualität als nützliches Diagnose-Tool 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 gleiche diese mit GSC-Daten ab, die über die 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 rückläufig) ist meine Überprüfungs-Warteschlange mit hoher Priorität.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-generierte Inhalte gegen ihre Richtlinien sind — das Problem ist unhilfreich erstellter Inhalt, unabhängig davon, wie er produziert wurde. Das Signal ist Qualität, nicht Herkunft. Eine manuell geschriebene Seite, die dünn und dupliziert ist, wird genauso behandelt. Es kommt darauf an, ob die Seite die Anfrage des Nutzers wirklich besser erfüllt als die Alternativen. Falls 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 konsequente Arbeit über fünf Monate: das Löschen der schlechtesten Seiten, das Zusammenfassen von mittelmäßigen, die Anreicherung der Top-Performer. Die einzelne wirkungsvollste Maßnahme war die Reduzierung des Index von 14.000 Seiten auf etwa 4.200. Kontraintuitiv, aber das ist, was die Daten gezeigt haben.
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.
---
Bauen im großen Maßstab gibt dir nicht die Erlaubnis, schlecht zu bauen. Die Gates, die ich beschrieben habe, fügen vielleicht zwei bis drei Tage Setup-Zeit zu einem neuen pSEO-Projekt hinzu. Die Alternative — nach einem Core Update wieder aufbauen — kostet viel mehr als das. Ich weiß es, weil ich es auf beide Arten getan habe.