Programmatic SEO: Funktionsweise, Beispiele und die Grenze zu Spam

Am 9. September 2026 habe ich wie jeden Morgen beim Kaffee die SEO-News durchgeschaut. Dabei bin ich über einen Beitrag von John Mueller zu Programmatic SEO gestolpert. Der ist hängengeblieben.

Nicht wegen der Grundaussage. Dass Google massenhaft erzeugte Seiten kritisch sieht, weiß die Branche seit Jahren. Hängengeblieben ist eine Stelle mitten im Absatz, die beim schnellen Lesen durchrutscht: Mueller spricht nicht über Seiten, sondern über die Website.

Daraus ist dieser Überblick entstanden. Der erste Teil erklärt Begriff, Funktionsweise, Beispiele und Umsetzung. Der zweite Teil zeigt, wo Google die Grenze zieht und was Mueller im September 2026 dazu gesagt hat.

Einen Tag später habe ich mir die 16 Top-Seiten zu „programmatic seo“ in Deutschland und den USA im Volltext angesehen. 15 davon ließen sich abrufen. Risiken erwähnen alle. Die Regel „scaled content abuse“ nennen zwei davon beim Namen, die Doorway-Regel drei, die Rater Guidelines keine. Genau dort setzt dieser Artikel an.

Programmatic SEO ist das Erzeugen vieler Seiten aus drei Zutaten: einem Keyword-Muster für die Auswahl der Seiten, einem Datensatz mit dem Inhalt jeder einzelnen Seite und einer für alle gleich aufgebauten Vorlage. Es ist ein Branchenbegriff: In Googles Spam-Policies in der Fassung vom 28. August 2026 kommt er nicht vor.

Das Muster besteht aus einem festen und einem wechselnden Teil, in der Branche Head Term und Modifier genannt. „Wetter“ plus Ortsname, „Elektriker“ plus Stadt, „EUR to USD“ plus das nächste Währungspaar: Jede Kombination wird zu einer eigenen URL.

Der Unterschied zum klassischen Artikel liegt nicht in der Qualität, sondern im Verhältnis von Aufwand zu Seite. Ein Artikel entsteht einzeln am Schreibtisch. Eine programmatische Seite entsteht als Zeile in einer Tabelle. Aus hundert Zeilen werden hundert Seiten.

Programmatic SEO und klassisches SEO im Vergleich

So ordne ich die beiden Bauweisen ein:

Technisch ist Programmatic SEO simpel. Du nimmst eine Liste von Städten und eine Liste von Branchen und bekommst durch Multiplizieren für jede Kombination eine Seite: 50 Städte mal 20 Branchen ergeben 1.000 URLs ohne eine einzige geschriebene Zeile Text.

Genau darin liegen Stärke und Problem zugleich. Die Vorlage sorgt dafür, dass alle Seiten gleich ordentlich aussehen. Sie sorgt nicht dafür, dass auf jeder Seite etwas Eigenes steht. Das kommt allein aus dem Datensatz: aus Kursen, Vorhersagen, Einträgen, Preisen oder Bewertungen für genau diese eine Kombination.

Drei Bausteine entscheiden über die Qualität einer Seitenfamilie:

• Der Datensatz. Eigene, lizenzierte oder öffentliche Daten in sinnvoll aufbereiteter Form. Je weniger eine Zeile enthält, desto dünner wird die Seite.
• Die Vorlage. Sie legt fest, welche Felder wo erscheinen. Strukturierte Daten kann sie gleich mit erzeugen. Was strukturierte Daten leisten und was nicht, steht in Sind strukturierte Daten dein Vorteil.
• Die Hierarchie. Übersichtsseiten zur Gliederung der einzelnen Seiten nach Region oder Kategorie. In seinen Spam-Policies nennt Google als Doorway-Missbrauch unter anderem sehr ähnliche Seiten, die eher Suchergebnissen gleichen als einer klaren und durchsuchbaren Hierarchie. Wie so eine Struktur aussehen kann, habe ich im Hub-and-Spoke-Modell beschrieben.

Beispiele beim Namen zu nennen ist leicht. Aussagekräftiger ist der direkte Vergleich. Deshalb habe ich mir aus fünf Seitenfamilien jeweils zwei Geschwisterseiten angesehen und notiert, was gleich bleibt und was sich ändert.

Zapier führt sein App-Verzeichnis im eigenen Blog ausdrücklich als Beispiel für Programmatic SEO. Bei den anderen vier beschreibe ich nur die offen sichtbare Bauweise.

Was alle fünf gemeinsam haben: Jede Seite hat etwas Eigenes gegenüber ihrer Geschwisterseite, etwa ein anderes Währungspaar, einen anderen Ort oder andere Einträge. Der Nutzen steckt in den Daten der Zeile, nicht in der Vorlage.

Drei Bedingungen prüfe ich, bevor ich eine Seitenfamilie überhaupt baue. Die Liste ist meine Einschätzung und keine Vorgabe von Google.

• Es gibt Daten mit eigenem Wert. Kurse und Vorhersagen, Preise und Bewertungen, Verfügbarkeiten oder eigene Messwerte. Ein Ortsname allein ist kein Datensatz.
• Es gibt Nachfrage pro Kombination. Suchen Menschen nach genau dieser Verbindung aus Head Term und Modifier? Ein Kreuzprodukt erzeugt zuverlässig auch Kombinationen ohne messbare Nachfrage.
• Jede Seite besteht den Nachbarschaftstest. Zwei Seiten nebeneinander und alles Gemeinsame gestrichen: Der Rest muss für sich einen Grund zum Aufrufen liefern.

Die Vorteile ergeben sich aus der Bauweise: Ein einmal gebautes System bedient viele Suchanfragen auf einmal, Aktualisierungen laufen über den Datensatz statt über hunderte Einzeltexte und neue Kombinationen kosten technisch wenig. Die Datenpflege bleibt trotzdem Arbeit.

Die Nachteile sind die Kehrseite derselben Eigenschaft. Ein Fehler in der Vorlage steckt sofort in allen Seiten, dünne Daten werden tausendfach dünn. Ein schlechter Datensatz lässt sich außerdem nicht durch mehr Seiten ausgleichen.

1. Muster festlegen. Head Term und Modifier bestimmen, wie viele Seiten es geben kann. Schreib die Liste der Modifier vollständig auf, bevor du irgendetwas baust. Dann siehst du die Größe des Vorhabens schwarz auf weiß.

2. Nachfrage prüfen. Hol dir Suchvolumina für eine Stichprobe der Kombinationen und streiche alles ohne messbare Nachfrage. Für diesen Artikel habe ich das am Head Term selbst gemacht: „programmatic seo“ liegt nach meiner Abfrage über DataForSEO in Deutschland bei rund 90 Suchen im Monat und in den USA bei rund 590. Beides sind Schätzwerte des Werkzeugs.

3. Datensatz aufbauen. Die Qualität jeder Seite entscheidet sich in ihrer Zeile. Mach den Nachbarschaftstest deshalb schon am Datensatz: Zwei beliebige Zeilen nebeneinander zeigen dir, ob am Ende zwei verschiedene Seiten entstehen oder dieselbe mit anderem Namen.

4. Vorlage und Hierarchie bauen. Eine Vorlage für alle Seiten und dazu Übersichtsseiten zum Durchsuchen der Familie. Einer nur über die Suche erreichbaren Seite fehlt genau diese Hierarchie.

5. Gestaffelt veröffentlichen. Starte mit einem Teil der Seiten statt mit allen. Reiche sie per Sitemap ein und beobachte im Bericht zur Seitenindexierung die Reaktion von Google. Die Einreichung ist laut Google nur ein Hinweis und garantiert nicht, dass Google die Sitemap zum Crawlen nutzt. Eine einzelne Sitemap fasst laut Google höchstens 50 MB unkomprimiert oder 50.000 URLs. Größere Mengen verteilst du auf mehrere Sitemaps.

Den Leitfaden zum Crawl-Budget richtet Google vor allem an drei Gruppen: Websites ab einer Million Seiten mit wöchentlichen Änderungen, Websites ab 10.000 Seiten mit täglichen Änderungen und Websites mit einem großen Anteil an URLs im Search-Console-Status „Gefunden - zurzeit nicht indexiert“. Die dritte Gruppe betrifft aus meiner Sicht gerade Seitenfamilien. Für alle anderen reichen laut Google eine aktuelle Sitemap und der regelmäßige Blick in den Bericht zur Seitenindexierung.

6. Beobachten und aufräumen. Miss je Gruppe das Verhältnis von eingereichten zu indexierten Seiten und sieh dir die Impressionen an. Gruppen ohne Indexierung oder ohne Impressionen legst du zusammen oder löschst sie. Wie ich dabei vorgehe, steht weiter unten unter Was du machst, wenn es dich betrifft.

Werkzeuge nach Aufgabe

Konkrete Produkte empfehle ich hier bewusst nicht. Die Wahl des Werkzeugs ist aus meiner Sicht zweitrangig, solange diese vier Aufgaben abgedeckt sind:

• Daten halten: eine Tabellenkalkulation oder eine Datenbank, in der jede Zeile eine Seite ist
• Seiten erzeugen: ein CMS mit Vorlagen und Datensammlungen oder ein statischer Seitengenerator
• Daten synchron halten: eine Automatisierung, die Änderungen im Datensatz in die Seiten überträgt
• Prüfen: ein Crawler für Titel, Duplikate und Statuscodes sowie die Google Search Console für Indexierung und Leistung

Googles Spam-Policies beschreiben Praktiken, keine Methoden. Zwei davon sind für Programmatic SEO besonders wichtig. Eine dritte Quelle zeigt Googles Bewertungsmaßstab für solche Seiten.

Scaled content abuse

Die Regel kam im März 2024 dazu. In der aktuellen Fassung der Spam-Policies vom 28. August 2026 lautet die Definition:

„Scaled content abuse is when many pages are generated for the primary purpose of manipulating search rankings and not helping users.“

Als Beispiele nennt Google unter anderem diese fünf Praktiken:

• mit generativer KI oder ähnlichen Werkzeugen viele Seiten erzeugen, ohne Nutzern etwas hinzuzufügen
• Feeds, Suchergebnisse oder andere Inhalte abgreifen und daraus viele Seiten machen, auch per automatischem Umformulieren oder Übersetzen
• Inhalte verschiedener Seiten zusammenfügen, ohne Mehrwert zu schaffen
• mehrere Websites betreiben, um das skalierte Vorgehen zu verschleiern
• viele Seiten erzeugen, die für Leser kaum Sinn ergeben, aber Suchbegriffe enthalten

Wie der Inhalt entsteht, spielt dabei keine Rolle. Die Regel gilt laut Google „no matter whether content is produced through automation, human efforts, or some combination of human and automated processes“. Wer solche Inhalte auf seiner Website hat, soll sie laut Google aus der Suche ausschließen. Wie Google KI-Texte darüber hinaus einordnet, steht in Straft Google KI-Texte ab.

Dazu passt eine Frage aus Googles Leitfaden zu hilfreichen Inhalten: „Are you using extensive automation to produce content on many topics?“ Im selben Leitfaden fragt Google, ob man auf eine bestimmte Wortzahl hinschreibt. Die Antwort steht gleich dabei: „(No, we don’t.)“

Die Folgen stehen ebenfalls in Googles Ankündigung von 2024: Websites mit Verstößen gegen die Spam-Policies können schlechter ranken oder gar nicht mehr erscheinen. Bei einer manuellen Maßnahme kommt eine Nachricht in der Search Console und danach lässt sich eine erneute Prüfung beantragen. Wie sich ein Spam-Update im Zeitverlauf zeigt, kannst du am August 2026 Spam Update nachlesen.

Doorway abuse

Die zweite Regel ist für Programmatic SEO mindestens so wichtig. In meiner Auswertung vom 10. September nennen sie drei von 15 Seiten, alle nur als Schlagwort. Googles Definition lautet:

„Doorway abuse is when sites or pages are created to rank for specific, similar search queries.“

Zwei der Beispiele in der Regel lesen sich wie eine Beschreibung schlecht gebauter Seitenfamilien:

• „Having multiple domain names or pages targeted at specific regions or cities that funnel users to one page“
• „Creating substantially similar pages that are closer to search results than a clearly defined, browseable hierarchy“

Aus meiner Sicht fallen Städteseiten mit dem einzigen Zweck einer Weiterleitung auf dasselbe Kontaktformular sehr nah an das erste Beispiel. Eine Seitenfamilie aus sehr ähnlichen Seiten ohne Übersichtsseiten rückt in die Nähe des zweiten.

Was die Rater Guidelines dazu sagen

Google verweist in seiner Dokumentation zu KI-Inhalten selbst auf Abschnitt 4.6.5 der Search Quality Rater Guidelines. In der Fassung vom 11. September 2025 heißt es dort:

„Pages and websites made up of content created at scale with no original content or added value for users, should be rated Lowest, no matter how they are created.“

Bemerkenswert ist der Satz danach. Rater sollen die schlechteste Bewertung auch ohne Wissen über die Entstehung der Inhalte vergeben, sofern sie scaled content abuse „after looking at several pages on the website“ stark vermuten. Der Blick geht also über mehrere Seiten einer Website und nicht über eine einzelne.

Der Anlass ist eine öffentliche Anfrage auf Bluesky: Ein Betreiber beschreibt dort seine im April gestartete Website, ein Verzeichnis für Tech-Stacks nach dem Vorbild von BuiltWith. Nach eigener Angabe wurden zunächst viele Seiten indexiert und fielen danach wieder heraus. Daraufhin hat er sie auf noindex gesetzt. Seitdem stehen nach seiner Schilderung auch die Kernseiten monatelang auf „Crawled - currently not indexed“, darunter die schlichte Über-uns-Seite.

Muellers Antwort beginnt mit einer Diagnose der Bauweise:

„it sounds like a programmatic SEO play, where you iterate through a large list of domain names, technologies, and attributes - finding all possible combinations.“

Das ist die Beschreibung eines Kreuzprodukts: Liste A mal Liste B mal Liste C und für jede Kombination fällt eine eigene URL heraus. Technisch ist das eine Schleife. Redaktionell ist es nichts.

Dann kommt der Satz, der zitiert wird:

„Programmatic SEO like this often leads to a site that’s either spam, borderline spam, or low quality. It’s easy to spin something up with many pages, it’s hard to provide real value to users. Our systems have possibly lost faith in your site providing good value to users based on the old pages.“

Lies die ersten drei Wörter noch einmal. Programmatic SEO like this. Mueller verurteilt nicht die Methode als solche, sondern die eine Umsetzung aus seiner eigenen Beschreibung zwei Beiträge vorher. Drei Wiedergaben habe ich dazu gelesen. SEO Südwest übersetzt die Einschränkung mit („Programmatic SEO wie das beschriebene“), Seroundtable lässt sie in der eigenen Rahmung weg. Search Engine Journal macht sie zum Punkt: „Mueller did not say all programmatic SEO is spam.“

Neu ist diese Haltung bei ihm übrigens nicht. Schon am 25. Juli 2023 schrieb Mueller auf X, Programmatic SEO sei „often a fancy banner for spam“. Seroundtable dokumentiert vom selben Tag einen zweiten relativierenden Beitrag („To be fair, programmatic SEO is not always spam“). Den habe ich über vier Wege gesucht: direkt bei X, über zwei Proxy-APIs, im Internet Archive. Über keinen dieser Wege mehr abrufbar. Der erste Beitrag kommt über denselben Weg zurück, an der Methode liegt es also nicht.

Hier liegt der eigentliche Befund und er ist der teuerste Punkt für jeden mit einem großen generierten Verzeichnis. Die übliche Vorstellung von dünnen Seiten ist eine Rechnung pro Seite: eine schwache Seite rankt nicht, eine starke rankt und beide stehen unabhängig voneinander nebeneinander.

Muellers Formulierung beschreibt etwas anderes als diese vertraute Rechnung von Seite gegen Seite. Er schreibt „Our systems have possibly lost faith in your site“ auf Basis der alten Seiten: Das Objekt der Bewertung ist die Website, der Auslöser sind Seiten, die es in dieser Form längst nicht mehr gibt.

Das ist meine Lesart dieser Formulierung und nicht die Beschreibung eines Mechanismus durch Google. Eine gespeicherte Website-Bewertung beschreibt der Thread nicht, so liest es auch Search Engine Journal. Einen Namen für ein solches System nennt Mueller an keiner Stelle.

Genau das passt zu dem geschilderten Fall. Die generierten Seiten stehen nach Angabe des Betreibers auf noindex und sind aus dem Index verschwunden. Draußen bleibt trotzdem die Über-uns-Seite ohne jede Automatisierung.

Meine Folgerung für die Praxis: Der Aufwand für die guten Inhalte zahlt sich womöglich nicht isoliert aus. Ein starker Ratgeber auf einer Domain mit zwanzigtausend Kombinationsseiten startet dann nicht bei null, sondern hinter dem Eindruck dieser Domain. Springt ein objektiv guter Text auf deiner Domain nicht an, ist seine Nachbarschaft deshalb eine Spur. Wie Google überhaupt entscheidet, was in den Index kommt, habe ich in Crawling und Indexierung auseinandergenommen.

Dieser Abschnitt ist mir wichtiger als der davor, weil hier die Wiedergaben kippen. Aus einem vorsichtigen Satz wird eine Mechanik und in der nächsten Wiedergabe klingt die Mechanik wie Dokumentation.

Vier Dinge stehen nicht im Thread:

• Kein Name. Mueller nennt kein Ranking-System, kein Signal, keinen Klassifikator.
• Kein Wert. Es gibt keinen Score und keine Note und keine Schwelle für einen Kipppunkt.
• Keine Strafe. Eine manuelle Maßnahme ist etwas anderes und kommt mit einer Nachricht in der Search Console. Davon ist nirgends die Rede.
• Keine Dauer. Er schreibt „tends to take time“. Das ist keine Frist, das ist eine Erwartung.

Dazu das Wörtchen „possibly“ aus Muellers eigener Feder. Er beschreibt eine Möglichkeit für einen Fall aus vier kurzen Beiträgen. Search Engine Journal formuliert das trocken und richtig: Der Thread beschreibe keine gespeicherte Website-Bewertung und sage auch nicht, dass der Effekt dauerhaft sei.

Warum ich darauf herumreite: Die Vorstellung einer heimlichen Domain-Note ist verführerisch, weil sie alles erklärt, auch dann noch, wenn die Ursache in Wahrheit ganz woanders liegt. Ein Text ohne Nachfrage rankt nicht, weil ihn niemand sucht. Eine Seite ohne interne Links findet Google schwerer. Beides sieht von außen aus wie verlorenes Vertrauen. Der Selbsttest auf austauschbaren Content stellt die Frage von der anderen Seite: Was auf dieser Seite steht, das sonst nirgends steht.

Vier Prüfungen, in dieser Reihenfolge, zusammen eine Stunde Arbeit: der Nachbarschaftstest, der Indexierungsschnitt, die Nachfrageprobe und der Blick auf die Crawl-Verteilung.

1. Der Nachbarschaftstest. Öffne zwei zufällige Seiten aus derselben generierten Gruppe nebeneinander. Streiche alles, was auf beiden steht. Was übrig bleibt, ist der Wert der Seite. Bleiben davon nur der Titel und zwei Zahlen und eine Zeile Fließtext übrig, hast du deine Antwort.

2. Der Indexierungsschnitt. Zieh dir in der Search Console den Bericht zur Seitenindexierung und sieh auf das Verhältnis. Sind von 12.000 eingereichten URLs 900 indexiert, deutet das eher auf eine Auswahl durch Google hin als auf eine technische Panne. Eine Diagnose ist das allein noch nicht. Der Status „Gecrawlt - zurzeit nicht indexiert“ ist dabei aus meiner Sicht der brauchbarste, weil Google die Seite dafür schon abgerufen haben muss.

3. Die Nachfrageprobe. Nimm zwanzig Keywords aus deinem generierten Bestand und lass dir echte Suchvolumina dazu geben. Existiert die Suchanfrage überhaupt? Ein Kreuzprodukt erzeugt zuverlässig Kombinationen ohne messbare Nachfrage.

4. Der Crawl-Blick. Sieh dir die Verteilung der Crawl-Aktivität über deine Bereiche an. Entfällt der größte Teil auf die generierten Verzeichnisse und kommen die redaktionellen Seiten selten dran, kann das dieselbe Ursache haben. Die Hebel dafür stehen in Crawl Budget optimieren.

Ich sage vorweg, was ich nicht sagen kann: Ob eine bestimmte Maßnahme eine bestimmte Website zurückbringt, weiß niemand. Mueller behauptet es ausdrücklich auch nicht. Er verweist auf den Aufwand, den andere für Spam- und Core-Update-Probleme betreiben. Und er stellt klar: Er nennt die Website nicht Spam. Das ist ein Maßstab für die Größenordnung und keine Anleitung.

Was ich für sinnvoll halte, in meiner Reihenfolge:

• Entscheiden statt verstecken. Noindex verbirgt die Seiten. Löschen oder Zusammenlegen entfernt sie. Bietet eine Gruppe von 8.000 Kombinationsseiten nichts über 40 gute Seiten hinaus, dann sind es 40 Seiten. Das Verfahren dafür habe ich in Content Audit und Pruning beschrieben. Vorher lohnt der Blick auf die anderen Ursachen für „Gecrawlt - zurzeit nicht indexiert“ oben unter „Was Mueller nicht gesagt hat“.
• Die Nachfrage prüfen vor dem Neubau. Seiten für nicht existierende Suchanfragen sind auch in kleiner Zahl wertlos.
• Einen echten Beleg für Wert schaffen. Eigene Daten oder eine eigene Auswertung oder ein Vergleich ohne Vorbild. Etwas außerhalb der Reichweite eines Kreuzprodukts.
• Geduld einplanen. Muellers „tends to take time“ ist die einzige Zeitangabe in diesem ganzen Thread und eine genauere Frist nennt er an keiner Stelle.

Die Technik ist schnell erklärt: Muster, Datensatz, Vorlage und fertig ist die Seitenfamilie. Schwierig ist nicht das Bauen, sondern die Frage nach dem Eigenen jeder Seite gegenüber ihrer Geschwisterseite.

Googles Regeln beantworten diese Frage nicht mit einer Zahl, sondern mit Zweck und Nutzen. Muellers Antwort vom September 2026 zeigt die mögliche Ebene dafür: Er schreibt über die Website und nicht über die einzelne Seite. Mehr als ein „possibly“ steht dazu im Thread allerdings nicht. System, Score und Frist fehlen.