Design wechseln

Was ist programmatisches SEO: Grenzen und Anti-Spam-Richtlinien

Easton editorial illustration: publishing momentum dashboard

Die E-Mail aus der Google Search Console war da.

Manuelle Strafe. Der gesamte Traffic der Website fiel in drei Tagen um 96 %.

Das ist keine erfundene Geschichte. So lief es 2024 bei einer Anwalts-Website: programmatisches SEO mit 42.000 Stadtseiten – pro Seite nur ein anderer Stadtname, sonst identischer Inhalt. Acht Monate später kam die Seite aus der Strafe zurück.

„Programmatisches SEO“ klingt verlockend. Wer möchte nicht mit einem Template und einer Datenbank tausende rankende Seiten erzeugen? Die zentrale Frage lautet: Wo liegt Googles rote Linie heute – und welche Praktiken triggern sofort eine Strafe?


Was ist programmatisches SEO?

Zuerst eine kurze Definition.

Programmatisches SEO (Programmatic SEO) nutzt Templates, strukturierte Daten und Automatisierung, um SEO-Seiten in Serie zu erzeugen. Statt jede Seite von Hand zu schreiben, „füllt“ ein System die Vorlage aus.

Ein Beispiel.

Wise (der grenzüberschreitende Transferdienst) hat für jedes Währungspaar eine Umrechnungsseite angelegt: USD to EUR, JPY to CNY, GBP to USD … Hunderte Seiten, jede mit:

  • Live-Umrechnungstool
  • Kursverlauf der letzten 30 Tage
  • kurzer Währungseinleitung
  • Links zu verwandten Paaren

Diese Seiten ranken gut. Warum? Jede löst ein echtes Problem: „Ich will jetzt Dollar in Euro tauschen – wie ist der Kurs?“

Aber nicht jeder Fall endet so.

Ein E-Commerce-Shop erzeugte 18.000 Kombinationsseiten: „Produkt + Einsatz + Preissegment“, z. B. „Laufschuhe + Alltagstraining + 500–800 Yuan“. Klingt plausibel – wurde aber algorithmisch bestraft.

Der Unterschied? Hat jede Seite wirklich eigenständigen Wert?


Wo liegt Googles rote Linie?

Im März 2024 führte Google ein neues Konzept ein: Skalierter Content-Missbrauch (Scaled Content Abuse).

So steht es in den Richtlinien:

"Massenhaft sehr ähnliche Seiten erzeugen, deren Hauptzweck Ranking-Manipulation ist – nicht Nutzerhilfe."

Beachten Sie „Hauptzweck“. Google verbietet nicht programmatischen Content an sich, sondern Seiten ohne echten Mehrwert, die nur fürs Ranking existieren.

Konkret sind vier Verhaltensweisen verboten:

1. Doorway Pages (Türseiten)

Ein altes Thema: Seiten, die nur ranken sollen und Nutzer dann woanders hinschicken.

Typisch: eine Anwalts-Website mit 42.000 Stadtseiten, Titel „[Stadt] + Anwalt“. Keine echten Anwaltsprofile, keine Fälle, keine Bewertungen – nur ein generisches Kontaktformular.

Nutzer klicken, finden nichts Nützliches, müssen erneut zur Hauptseite. Schlechte Erfahrung.

2. Scaled Content Abuse (skalierter Content-Missbrauch)

Neue Kategorie seit 2024. Ziel: „Template-Tausch“-SEO.

Ein Template, nur Keywords (Stadt, Produkt) austauschen, Rest identisch. Google nennt z. B.:

  • „plumber in [Stadt]“ → 1.000 Seiten
  • nur der Stadtname wechselt
  • keine echten Installateur-Infos, Bewertungen oder Cases

Das gilt jetzt als skalierter Content-Missbrauch.

3. Thin Content at Scale (dünner Content in Masse)

Einzelne Thin-Content-Seiten lösen nicht immer eine Strafe aus. Viele davon triggern aber das Helpful Content System.

Es bewertet, ob Ihre Site „primär für Suchmaschinen“ existiert. Wenn ja, leidet das gesamte Ranking – nicht nur die dünnen Seiten.

4. Automatically Generated Content (Missbrauch automatisch erzeugter Inhalte)

Gemeint ist nicht „KI schreibt“ an sich, sondern Auto-Content ohne eigenen Wert.

Beispiel: KI erzeugt Massenartikel, nur Keywords in Templates, ohne Faktencheck, ohne eigene Sicht, ohne echte Daten – das zählt als Spam.


Echte Fälle: Wer wurde bestraft – und warum?

Fall 1: Anwalts-Website und die Doorway-Falle

Hintergrund: Marketing für Anwälte, landesweite Abdeckung.

Vorgehen: 42.000 Stadtseiten, Titel „[Stadt] Personenschaden-Anwalt“.

Probleme:

  • keine echten Anwaltsprofile
  • keine Fälle, Bewertungen, Erfolgsquoten
  • Inhalt fast identisch, nur Stadtname anders
  • Absprungrate: 89 %
  • Verweildauer: 11 Sekunden

Folge:

  • manuelle Strafe per Search Console
  • Traffic −96 %
  • Recovery 8 Monate, 42.000 Seiten gelöscht

Lehre: Wenn Ihr „Einzigartiges“ nur der Stadtname ist, bauen Sie Doorways.

Fall 2: E-Commerce und die Template-Falle

Hintergrund: mehr Suchbegriffe abdecken.

Vorgehen: 18.000 Kombinationsseiten „Produkttyp + Einsatz + Preissegment“.

Probleme:

  • viele Kombinationen ohne Suchvolumen (z. B. „Golfschuh + Pendeln + 100–200 Yuan“)
  • stark duplizierter Inhalt
  • keine echten Empfehlungen oder Vergleiche
  • Nutzer finden kaum Nutzbares

Folge:

  • algorithmische Strafe (keine manuelle)
  • Ranking-Einbruch
  • indexierte Seiten von 18.000 auf 3.000

Lehre: Nicht Seiten für Keywords bauen. Fragen Sie: Was will jemand, der so sucht, wirklich finden?

Fall 3: SaaS und die Skalierungsfalle

Hintergrund: SEO-Traffic schnell skalieren.

Vorgehen: über Nacht 12.000 Seiten „Produktkategorie + Stadt“.

Kurzfristig: Rankings und Traffic stiegen.

Probleme:

  • nur ~150 Wörter pro Seite
  • stark templatisiert, wenig Eigenwert
  • keine echten Kunden-Cases oder Daten

Folge: drei Monate später Core-Update – Traffic −87 %.

Lehre: Programmatisches SEO ist kein Schnell-Reichtum. Google erkennt fehlenden Wert immer besser.


Programmatisches SEO sicher umsetzen

Nach all den Risiken die gute Nachricht: Es geht – wenn jede Seite echten Mehrwert hat.

Kernprinzip: wertgetrieben

Nicht „datengetrieben“, sondern wertgetrieben.

Nicht reichen „wir haben Daten“ – fragen Sie: Was hilft dem Nutzer damit?

Bei Zillow pro Immobilie z. B.:

  • echte Listing-Daten (Preis, Fläche, Zimmer)
  • viele Fotos
  • Preishistorie
  • Quartier (Schulen, Kriminalität, Pendeln)
  • Nutzerfragen und Bewertungen

Wer „[Stadt] + Immobilienpreise“ sucht, will genau das. Das ist programmatisches SEO mit Substanz.

Compliance-Checkliste

Vor dem Publish jeder programmatischen Seite:

1. Einzigartige Kerndaten pro Seite?

Nicht „eine Variable anders“, sondern 3–5 echte, unterschiedliche Datenfelder.

2. Einzigartiger Nutzen für den Besucher?

Würde diese Seite allein stehend als hilfreich gelten?

3. Manuelle Prüfung?

Vollautomatischer Content ist riskant – mindestens Stichproben-Review.

4. Echte Nutzerbeteiligung?

Kommentare, Ratings, Q&A – UGC erhöht Einzigartigkeit stark.

Automatisiertes Qualitäts-Monitoring

Ab ~1.000 Seiten ist manuelles Monitoring unrealistisch – automatisieren.

Kern-KPIs:

  • Absprungrate: über 70 % → Qualitätsproblem
  • Verweildauer: unter 30 Sek. → Nutzer findet nichts Relevantes
  • Index-Quote: nur 50 % indexiert → schwaches Qualitätssignal
  • Ranking-Verteilung: viele Seiten auf Seite 5–10 → nachschärfen

Risiko-Minderung

1. In Wellen launchen

Nicht tausende Seiten auf einmal. Start mit 100–500, 2–4 Wochen beobachten, dann erweitern.

2. Qualität vor Menge

Lieber 500 starke Seiten als 5.000 dünne – schwache Seiten ziehen die ganze Domain runter.

3. Review-Prozess

  • vor Publish: Stichproben manuell
  • nach Publish: KPIs überwachen
  • quartalsweise: schlechteste 10 % löschen oder verbessern

4. Notfallplan

Bei Straf-Hinweis:

  • sofort keine neuen Seiten
  • Strafart klären (manuell vs. algorithmisch)
  • problematische URLs löschen oder noindex
  • bei manueller Strafe: Reconsideration Request

Grenzen: Wann lohnt sich programmatisches SEO?

Geeignete Szenarien

1. Viel strukturierte Daten

z. B. Immobilien, E-Commerce, Reise, Tools (Währung, Einheiten) – jeder Datensatz muss Nutzen stiften.

2. Klare Suchintention

„USD to EUR“ = Kurs + Umrechnung – klar erfüllbar.

„Bester Anwalt“ ist vage (Anwalt suchen? Kosten? Cases?) – schwer mit rein programmatischen Seiten.

3. Einzigartige Daten oder Tools

Zillow gewinnt nicht nur mit Listings, sondern mit Preishistorie, Zestimate, Quartiersdaten.

Ungeeignete Szenarien

1. Nur „mehr Keywords abdecken“

„5.000 Long-Tails schnell bedienen“ ohne Wert – hohes Straf-Risiko.

2. Keine eigene Datenquelle

Nur öffentliche, überall verfügbare Infos – kaum Differenzierung.

3. Zu simples Template

„Titel + Absatz + Kontaktformular“ – fast sicher Thin Content.


Fazit

Programmatisches SEO ist nicht per se schlecht.

Google bestraft nicht die Methode, sondern Seiten ohne echten Nutzen, nur fürs Ranking.

Eine Regel: Jede Seite muss ein echtes Nutzerproblem lösen.

Dann ist programmatisches SEO ein effizientes Skalierungs-Werkzeug. Sonst eine Zeitbombe.

Drei Schritte:

  1. Selbstcheck: Laufende Projekte an der Checkliste messen – Absprungrate und Verweildauer zuerst.
  2. Verbessern: Schwache Seiten löschen/noindex oder mit echtem Mehrwert aufwerten.
  3. Monitoring: automatisieren – nicht erst bei der Straf-Mail reagieren.

SEO lebt kurzfristig von Taktik, langfristig von Wert. Programmatisches SEO auch.


FAQ

Wird programmatisches SEO von Google bestraft?
Nein. Google bestraft Seiten ohne echten Mehrwert – nicht die programmatische Methode an sich. Entscheidend ist, ob jede Seite einzigartigen Nutzen bietet: echte Daten, Tools oder Nutzerbeteiligung.
Was ist Skalierter Content-Missbrauch (Scaled Content Abuse)?
Seit 2024 eine neue Verstoß-Kategorie: massenhaft sehr ähnliche Seiten, bei denen nur Keywords (z. B. Stadt- oder Produktname) getauscht werden – Hauptziel Ranking-Manipulation, nicht Nutzerhilfe. Das löst Strafen aus.
Wie prüfe ich, ob meine programmatischen Seiten compliant sind?
Vier Fragen: Hat jede Seite einzigartige Kerndaten (mind. 3–5 Felder)? Bekommt der Nutzer echten Mehrwert? Wurde der Inhalt manuell geprüft? Gibt es echte Nutzerbeteiligung (Kommentare, Bewertungen)? Wenn überall ja – in der Regel compliant.
Welche erfolgreichen Beispiele für programmatisches SEO gibt es?
Zillow (Immobilien mit echten MLS-Daten, Fotos, Preishistorie), Wise (Währungsumrechnung mit Live-Kursen und Charts), TripAdvisor (Orte mit echten Bewertungen, Fotos, Preisvergleichen). Gemeinsam: jede Seite hat echten Mehrwert.
Wie erholt man sich nach einer Strafe bei programmatischen Seiten?
Sofort keine neuen Seiten mehr veröffentlichen, Strafart analysieren (bei manueller Strafe: Reconsideration Request), problematische Seiten löschen oder noindex setzen, Restqualität verbessern. Im Anwalts-Fall: 8 Monate Recovery, 42.000 Seiten gelöscht.

6 Min. Lesezeit · Veröffentlicht am: 26. März 2026 · Aktualisiert am: 14. Juli 2026

Kommentare

Melde dich mit GitHub an, um einen Kommentar zu hinterlassen

Easton BlogEaston Blog