Programmatic SEO: So erstellen Sie Seiten im großen Maßstab (ohne zu spammen)

TL;DR: Programmatic SEO ist ein Template plus ein strukturierter Datensatz, mit dem viele keyword-gezielte Seiten erzeugt werden. Es funktioniert nur, wenn jede Variation echte Suchnachfrage hat und jede Seite einen echten Mehrwert liefert. Fehlt eines davon, produzieren Sie „thin pages“, die Google möglicherweise als skalierte Content-Fehlverwendung (Scaled-Content-Abuse) einordnet.

Frage	Sichere Antwort	Warnsignal
Hat jede Anfrage Nachfrage?	Sie haben den Nachweis, dass Menschen genau diese Variation suchen.	Sie haben jede mögliche Kombination generiert, weil die Daten es zuließen.
Ist jede Seite materiell unterschiedlich?	Die zugrunde liegenden Daten, Ergebnisse, das Inventar oder die Utility ändern sich.	Es ändert sich nur ein Städtename, ein App-Name, eine Währung oder eine Kategorie.
Passt das Format zur Suchintention?	Rechner, Tabellen, Vergleiche oder Listen decken ab, was in den Rankings steht.	Für jede Query-Art wird ein generisches Artikel-Template genutzt.
Ist die Datengrundlage belastbar (defensible)?	Sie ist proprietär, lizenziert, nutzergeliefert oder öffentliche Daten mit zusätzlichem Nutzen.	Sie wird von Wettbewerberseiten abgeschrapt und nur leicht umformuliert.
Kann Google die Seiten entdecken?	Die Seiten verlinken auf relevante Geschwisterseiten und übergeordnete Hub-Seiten.	Die generierten URLs existieren nur in einer XML-Sitemap.
Soll jede Variation indexiert werden?	Nur sinnvolle Kombinationen mit Nachweis für Nachfrage werden veröffentlicht.	Das gesamte kartesische Produkt wird ungefiltert in den Index geschoben.

Programmatic SEO ist ein Publishing-System – keine Content-Strategie

Ahrefs definiert Programmatic SEO als „die Erstellung von keyword-gezielten Seiten auf eine automatische (oder nahezu automatische) Weise“. In Builder-Sprache: Sie verbinden ein Seiten-Template mit einem Spreadsheet, einer Datenbank oder einer API und füllen es Zeile für Zeile.

Das Query-Muster sieht normalerweise aus wie [Head-Term] + [Modifier]. Die Liste der Modifier wird zum Datensatz:

• [Währung A] in [Währung B] umrechnen
• [App A] + [App B] Integration
• Gehalt für [Jobtitel] in [Stadt]
• Die beste [Kategorie] in [Stadt]

Sie recherchieren das Muster einmal, bauen das Template einmal und erzeugen dann Hunderte oder Tausende zielgerichtete URLs. Mechanisch ist das relativ unkompliziert. Ein Entwickler kann 50.000 Routen abliefern, bevor die Mittagspause beginnt, wenn niemand die Tastatur wegnimmt (und ja, ich war schon die Person, bei der man die Tastatur wegnehmen musste).

Die schwierige Frage lautet jedoch, ob diese Routen auch zu indexierbaren Seiten werden sollten.

Früher habe ich der technischen Eleganz des Systems zu viel Kredit gegeben. Google sieht weder Ihr sauberes Schema noch Ihre clevere Queue oder den schön typisierten API-Client. Google sieht die entstehenden URLs und bewertet, ob sie der Person helfen, die dort landet.

Die klare Grenze: Nachfrage und einzigartiger Mehrwert

Eine defensible programmatic Seite braucht beides – gleichzeitig:

1. Echte Nachfrage für die konkrete Suchanfrage.
2. Reale einzigartige Value auf der resultierenden Seite.

Wenn Sie eine der beiden Bedingungen verfehlen, arbeitet das Skalieren gegen Sie.

Nachfrage muss auf der Variations-Ebene existieren

Nachfrage für den Head-Term reicht nicht. Dass Menschen nach „currency converter“ suchen, beweist noch lange nicht, dass jede mögliche Währungskombination eine indexierbare URL verdient.

Das ist Keyword-Research auf Muster-Ebene. Starten Sie mit der wiederholbaren Query-Struktur und validieren Sie dann repräsentative Modifier sowohl im Head als auch im Long Tail. Keyword-Volumen-Tools lösen nicht jede exotische Variation auf. Kombinieren Sie daher deren Schätzungen mit Daten aus der Search Console, mit Produktnutzung, Kundenformulierung und der Zusammensetzung der Suchergebnisseite.

Veröffentlichen Sie nicht standardmäßig die komplette Datenbank.

Wenn eine Tabelle 200 Entitäten enthält, wirkt das Erzeugen jedes Paares automatisch „vollständig“ und befriedigend. Produktlogik mag komplette Matrizen. Suchnachfrage verhält sich selten so sauber (nervig, aber wichtig). Ein Datensatz mit 200 Elementen kann 39.800 gerichtete Paare erzeugen – aber nur ein Bruchteil davon entspricht echten Fragen.

Definieren Sie vor der Generierung eine Eligibility-Regel. Eine Seite kann messbare Nachfrage, ausreichende zugrunde liegende Daten, ein aktives Inventar-Element oder eine etablierte Produktbeziehung erfordern. Zeilen, die nicht passen, sollten Daten bleiben – nicht URLs werden.

Der Datensatz muss die Antwort verändern

Das Template ist nur der Rahmen. Der Datensatz muss für jede URL ein inhaltlich sinnvoll anderes Ergebnis liefern.

Wise’s Währungsseiten sind ein gutes Modell: Eine konkrete Paar-Kombination kann ihren eigenen Wechselkurs, Verlauf und Rechner mitbringen. Zapier’s App-Pair-Seiten können eine echte Verbindung zwischen zwei benannten Tools beschreiben und ermöglichen. Tripadvisor-artige Location-Seiten enthalten jeweils anderes Inventar, andere Reviews, andere Verfügbarkeit und andere Preise.

Vergleichen Sie das mit 5.000 Location-Seiten, bei denen sich nur Folgendes ändert:

„Sie suchen den besten Buchhalter in [Stadt]? Unsere Plattform hilft Unternehmen in [Stadt], Buchhalter zu finden.“

Das ist kein lokaler Mehrwert. Das ist ein Find-and-Replace.

Mein bevorzugter Review-Check ist der Strip-the-variable-Test: Entfernen Sie bei zwei generierten Seiten die Stadt, die Währung, die App oder die Kategorie – und vergleichen Sie, was übrig bleibt. Wenn die Seiten auf dieselbe Antwort zusammenschrumpfen, ist der einzigartige Mehrwert zu dünn. Es gibt keine veröffentlichte Prozentzahl für „Einzigartigkeit“, die eine URL automatisch sicher macht. Das ist Product Judgment, keine Linter-Regel.

Ein stärkerer Test ist: Was würde verloren gehen, wenn die Seite verschwände? Wenn die Antwort nur „ein weiterer Weg zu unserem Signup-Formular“ ist, existiert die Seite wahrscheinlich mehr fürs Akquirieren als für die Utility.

Google interessiert nicht, wie die Seiten erstellt wurden

Google Search Advocate John Mueller hat das „Execution“-Problem deutlich drastischer beschrieben als die meisten SEO-Guides:

„Programmatic SEO ist oft nur ein schicker Banner für Spam.“

Dieser Satz stammt aus Muellers eigenem Post, nicht aus einem offiziellen Policy-Dokument. Trotzdem ist er eine nützliche Warnung: Die Technik ist neutral – die häufige Umsetzung aber nicht.

Google hat die relevante Policy im März 2024 formell konkretisiert. Die aktualisierten Spam-Richtlinien führten „scaled content abuse“ ein und verschoben den Fokus weg von der Frage, wie Content erstellt wurde. Bei der Ankündigung sagte Google, die Änderungen – kombiniert mit früheren Arbeiten – sollten nach eigener Erwartung dazu führen, dass „low-quality, unoriginal content“ in den Suchergebnissen um 40% reduziert wird. Das war Googles erklärte Erwartung, kein gemessener Post-Rollout-Outcome.

Das begleitende Core Update startete am 5. März 2024 und lief 45 Tage, abgeschlossen etwa um den 19. April. Das Spam Update begann am selben Tag und lief 14 Tage und 21 Stunden. Die ungewöhnlich lange Core-Rollout-Phase ist weniger entscheidend als die Policy, die nach dem Update übrig blieb.

„Scaled content abuse liegt vor, wenn viele Seiten hauptsächlich generiert werden, um Suchrankings zu manipulieren – und nicht um Nutzern zu helfen.“

Googles Spam Policies in Search Central nennen explizit das Nutzen generativer KI, um viele Seiten zu produzieren, ohne Mehrwert hinzuzufügen – sowie das Scrapen von Feeds, Suchergebnissen oder anderem Content, um Seiten zu erzeugen, bei denen nur wenig Value geliefert wird.

Die Policy ist methodenagnostisch. KI, Templates, Automatisierung und menschliche Autor:innen können alle nützliche Seiten erstellen. Sie können aber auch alle Spam erzeugen. Ein menschlicher Freigabeprozess rettet keine Seite, die trotzdem keinen Mehrwert liefert.

Google sagt außerdem: „Seiten, die gegen unsere Richtlinien verstoßen, können in den Ergebnissen niedriger platziert werden oder ganz aus den Ergebnissen verschwinden.“ Nutzen Sie das als Risiko-Modell. Low-Value programmatic SEO ist nicht zwingend ein isoliertes Experiment; wenn Sie es auf Ihrer Hauptdomain veröffentlichen, kann es das gesamte Site-Profil belasten.

Doorway-Abuse ist die zweite Falle

Auch schlechte Projekte für Location-Seiten können in Doorway-Abuse kippen. Google definiert Doorway-Abuse als Seiten, die „erstellt werden, um für bestimmte, ähnliche Suchanfragen zu ranken“ und Nutzer dann zu Zwischen-Seiten führen, die weniger hilfreich sind als das finale Ziel.

Ein bekanntes Beispiel: Eine Reihe nahezu identischer City-Seiten, die alle Besucher in dieselbe generische Service-Seite umleiten. Die URL verspricht etwas Konkretes für Bristol, Hamburg oder Prag. Die Seite bietet jedoch kein lokales Inventar, keine lokalen Belege, keine lokale Verfügbarkeit, keine Preise und auch keinen operativen Unterschied.

Automatisierung an sich ist nicht das Problem. Ich würde sogar gerne eine Million wirklich nützlicher Ergebnisse automatisieren. Aber ich würde keine 1.000 Boilerplate-Seiten veröffentlichen, nur weil sich die kleinere Anzahl weniger verdächtig anfühlt. Google nennt keine sichere Seitenanzahl.

Ein praxistauglicher Workflow für Programmatic SEO

1. Finden Sie ein endliches, wiederholbares Query-Muster

Starten Sie mit einem Head-Term und einer begrenzten Modifier-Set. Städte, Währungen, App-Namen, Produktkategorien, Jobtitel und technische Integrationen funktionieren, weil die Entitäten strukturiert abgebildet werden können.

Beginnen Sie nicht mit „Wie können wir 10.000 Seiten generieren?“ Beginnen Sie mit „Welche wiederkehrenden Fragen können unsere Daten besser beantworten als eine einzige generische Seite?“ Die zweite Frage kann am Ende vielleicht nur 600 eligible URLs produzieren. Das ist okay. Seitenanzahl ist ein Output, kein Ziel.

Erstellen Sie eine Kandidaten-Tabelle mit Query, Modifier, erwarteter Suchintention, verfügbaren eindeutigen Feldern, Aktualisierungsfrequenz und Publikationsstatus. Geben Sie jeder Zeile ein explizites Eligibility-Ergebnis. Das macht auch das Pruning rückgängig machbar: Eine unterdrückte Zeile kann später veröffentlichbar werden, wenn Nachfrage oder Datenqualität sich verbessern.

2. Intention über repräsentative Queries prüfen

Überprüfen Sie populäre, mittelgroße und eher unbekannte Variationen. Wenn die Ranking-Seiten Rechner sind, bauen Sie einen Rechner. Wenn es Vergleichstabellen sind, ist ein generisches 1.500-Wörter-Artikel-Template wahrscheinlich die falsche Oberfläche. Wenn Ergebnisse vom live Inventar abhängen, kann statischer Text die gleiche Anforderung nicht erfüllen.

Verlassen Sie sich nicht auf eine einzelne Beispiel-Results-Page. Ein Muster kann „brechen“. „Software für Dentists“ und „Software für Entwickler“ teilen zwar ein grammatisches Template, brauchen aber möglicherweise unterschiedliche Evidenzen, Filter, Produktfeatures und Kaufkriterien. Ihr System muss die Option haben, keine Seite zu generieren.

Dokumentieren Sie diese Intention-Klassen im Datenmodell. Ein Query-Muster kann statt nur einem unendlich flexiblen Container möglicherweise zwei oder drei Templates benötigen.

3. Sichern Sie die Daten, bevor Sie das Template designen

Proprietäre Daten sind die stärkste Grundlage, weil Wettbewerber sie nicht reproduzieren können, indem sie nur Ihre URL-Struktur kopieren. Öffentliche oder lizenzierte Datensätze können ebenfalls funktionieren, wenn Sie zusätzlich Berechnungen, Filter, Vergleiche, Historie, Normalisierung oder ein besseres Interface einbauen.

Wettbewerberseiten zu scrapen und ihren Text zu „synonymisieren“ ist das Gegenteil von defensible. Es wird außerdem explizit in Googles Beispielen zu scaled-content-abuse genannt.

Planen Sie für fehlende und veraltete Felder. Wenn eine Seite einen Preis, ein Messwert, eine Verbindung oder einen Inventar-Record benötigt, damit sie nützlich ist, sollte eine leere Zeile nicht stillschweigend auf vier Absätze Boilerplate zurückfallen. Unterdrücken Sie die Seite, geben Sie einen passenden Status zurück oder konsolidieren Sie sie in eine sinnvolle übergeordnete Parent-Seite, bis der erforderliche Value vorhanden ist.

4. Bauen Sie eine vollständige Seite – nicht nur eine flexible „Shell“

Mappe Titel, Hauptüberschrift, Beschreibung, Schema, Body-Module, Navigation und verwandte Links auf explizite Felder. Gehen Sie dann mit einer repräsentativen Seite einmal durch Design, Rendering, QA und Indexierungs-Checks, bevor Sie die Bulk-Generierung aktivieren.

Testen Sie zuerst sperrige Datensätze: lange Namen, fehlende optionale Felder, null Ergebnisse, ungewöhnliche Zeichensätze, überlappende Labels, veraltete Timestamps und Entitäten ohne passende „Geschwister“. Der Happy-Path-Record macht jedes Template „fertig“ wirken.

Konsistenz ist wichtig, aber Konsistenz ist nicht Gleichheit. Titel und strukturelle Elemente können Regeln folgen. Die Antwort, Daten, Utility, Beispiele und Beziehungen müssen sich entsprechend der Query verändern.

5. Erzeugen Sie den Internal-Link-Graph anhand der Seiten

Generierte URLs haben nicht automatisch einen sinnvollen Platz in Ihrer Architektur. Eine Sitemap kann sie zwar Crawlern sichtbar machen – aber sie kann nicht erklären, wie sie mit dem Rest der Website zusammenhängen.

Normalerweise möchte ich drei Link-Ebenen:

• Hub-Links: Jede Detailseite läuft in eine nützliche Kategorie oder Topic-Hub-Seite zusammen.
• Sibling-Links: Seiten verlinken zu wirklich verwandten Variationen.
• Kontextuelle Links: Editorial-Seiten verweisen auf relevante programmatic Ergebnisse.

Eine USD-zu-EUR-Seite könnte nach oben zu einem Währungs-Hub und seitlich zu relevanten USD- oder EUR-Paaren verlinken. Eine Integrationsseite kann sowohl zu beiden App-Hubs verlinken als auch zu angrenzenden Workflows, die eine ähnliche Aufgabe lösen.

Das ist eine skalierbare Form von Content-Silo-Architektur. Speichern Sie die Beziehungen im Datenmodell, statt nach dem Launch noch „related pages“-Widgets dranzubauen.

Aus dem, was wir bei Websites sehen, die SEOJuice nutzen, sind Sitemap-only-Inventories ein wiederkehrender Schwachpunkt. Die generierten Seiten, die sinnvolle Hub-, Sibling- und kontextuelle Links bekommen, haben eine viel klarere Route in die Site als Seiten, die hinter einem Sitemap-Eintrag „schweben“. Das ist qualitative Operator-Erfahrung – kein Versprechen, dass das Hinzufügen von fünf Links automatisch Indexierung erzwingt.

6. Crawl und Indexierung steuern

Eine saubere XML-Sitemap unterstützt die Entdeckung, aber sie macht schwache Seiten nicht automatisch indexierenswert. Google kann entscheiden, nicht jede generierte URL zu crawlen oder zu indexieren.

Beobachten Sie in der Search Console „Discovered – currently not indexed“ und „Crawled – currently not indexed.“ Große Cluster in diesen Zuständen verdienen eine Untersuchung nach Template und Seitentyp, nicht URL-für-URL-Panik. Prüfen Sie Nachfrage, Duplikate, interne Links, Rendering, Canonical-Regeln, Datenvollständigkeit und Serverperformance.

Beim ersten Mal, als ich gesehen habe, dass Tausende generierter URLs außerhalb des Index bleiben, ging ich von einem technischen Bug aus. Es gab tatsächlich einen – aber das Fixen löste nicht das Indexierungsproblem. Die verbliebenen Seiten boten einfach nicht genug Value.

Prunen Sie Zero-Demand-Kombinationen, Duplikatszustände, leere Listings, facettierte Varianten und Seiten, die ihre versprochene Utility nicht liefern können. Unser Guide zu crawl budget optimization behandelt die Mechanik, wie Sie ein großes URL-Inventar kontrollieren.

Ich bevorzuge gestaffelte Releases statt eines einzigen großen Launches. Das ist eine operative Entscheidung, keine Googles Vorgabe. Kleinere Batches machen kaputte Canonical-Tags, dünne Seitentypen, schlechte Links und fehlende Daten leichter erkennbar, bevor sie sich vervielfachen.

Was erfolgreiche programmatic Sites gemeinsam haben

Ahrefs-Snapshot-Schätzungen zeigen, wie groß nützliche Implementierungen werden können:

Site	Ahrefs geschätztes Scale	Value pro Seite
Zapier	Ungefähr 800.000 Seiten	Eine nutzbare Verbindung zwischen einem konkreten Paar von Apps
Wise	Ungefähr 14.900 Seiten	Kurse, Historie und Konvertierungs-Utility für ein Währungspaar
Nomadlist	Ungefähr 25.000 City-Seiten	Standardisierte City-Daten wie Kosten, Internet, Wetter und Sicherheit
Webflow	Ungefähr 31.000 Template- und Showcase-Seiten	Eindeutige, nutzergenerierte Designs

Das sind Ahrefs-Schätzungen, keine dauerhaften Live-Zählstände. Sie werden sich verändern, und es ist nicht besonders hilfreich, Ihr geplantes Inventar mit der Seitenanzahl von Zapier zu vergleichen.

Der gemeinsame Vorteil: Der Datensatz unterscheidet die Seiten. Zapier ist ein starkes SEO-für-SaaS-Beispiel, weil jede „viable“ generierte Seite auf eine Produktfähigkeit gemappt wird. Das Wise-Ergebnis ändert sich mit dem Währungspaar. Nomadlist’s City-Record enthält city-spezifische Messwerte. Webflow’s Seiten zeigen unterschiedliche, von Nutzer:innen erstellte Arbeiten.

Scale folgt in diesen Beispielen dem Value. Er ersetzt ihn nicht.

Fehlerszenarien, die ich vor dem Launch blockieren würde

• Thin pages: Der Großteil der sichtbaren Seite ist Template-Content mit wenig query-spezifischer Information.
• Beinahe Duplikate: Entfernt man die eingespritzte Variable, sind mehrere Seiten faktisch identisch.
• Zero-Demand-Kombinationen: Jede mögliche Datenkombination wird generiert, ohne dass es den Nachweis gibt, dass Menschen danach suchen.
• Gescrafter oder „synonymisierter“ Content: Andere Sites liefern die Substanz, die Automatisierung verschleiert das Ganze nur.
• Leere Result-Foren: Die URL verspricht Inventar, Daten oder ein Ergebnis, das die Seite nicht liefern kann.
• Indexierungs-Blähung (bloat): Tausende URLs gehen live ohne Eligibility-Regeln, Pruning oder nützliche interne Beziehungen.

Diese Systeme können intern beeindruckend aussehen. Job erledigt. Die Sitemap enthält 50.000 URLs. Der Deployment-Graph ist gestiegen. Nichts davon beweist, dass die Seiten nützlich sind, entdeckt werden oder indexiert werden.

Seitenanzahl ist hier eine Eitelkeitsmetrik. Die echten Assets sind nach Nachfrage geprüfte Seiten, die ihre spezifischen Queries erfüllen.

Wo SEOJuice passt – und wo nicht

SEOJuice generiert keine programmatic Page Sets. Es wird nicht entscheiden, welche Währungspaare Seiten verdienen, keine proprietären Daten „erfinden“ und kein dünnes Template retten.

Seine Rolle beginnt erst, wenn nützliche Seiten bereits existieren. SEOJuice zeigt auf eine Live-Site und wendet kontinuierlich kontextuelle interne Links, Meta-Titel und -Beschreibungen, Schema-Markup sowie Image-Alt-Text an. In einem großen generierten Inventar werden diese Aufgaben überraschend schnell repetitiv und inkonsistent, insbesondere für ein Team wie unseres mit zwei Personen.

Beim internen Linking passt es am besten. Das System kann helfen, live generierte Seiten kontextuell zu verbinden, während die breitere Automatisierung die wiederkehrenden On-Page-Elemente vollständig hält. Die Eligibility-Regeln, Datenqualität, das Template, die Canonical-Logik und die Entscheidung, jede Seitentyp-Klasse zu indexieren, bleiben weiterhin in Ihrer Verantwortung.

Wenn das Pflegen des generierten Inventars langsam zum Engpass wird, gibt es bei SEOJuice einen kostenlosen Plan ohne Kreditkarte. Wenn die Suche nach passenden Kandidaten-Modifiern das frühere Problem ist, probieren Sie unseren AI Keyword Extractor und behandeln Sie dessen Output als Research-Seed, nicht als Freigabe, jede Phrase zu publizieren, die er findet.

Häufig gestellte Fragen

Was ist Programmatic SEO?

Programmatic SEO ist die Erstellung vieler keyword-gezielter Seiten aus einem Template und einem strukturierten Datensatz – zum Beispiel aus einem Spreadsheet, einer Datenbank oder einer API. Das Template wird zeilenweise befüllt, um wiederholbare Query-Muster wie „[Währung A] in [Währung B] umrechnen“ gezielt anzusteuern.

Steht Programmatic SEO im Widerspruch zu den Google-Richtlinien?

Nein. Die Produktionsmethode an sich ist nicht verboten. Googles Policy zu scaled content abuse richtet sich gegen Seiten, die primär dazu erstellt werden, Rankings zu manipulieren, statt Nutzern zu helfen. Nützliche Automatisierung ist etwas anderes als das Erzeugen dünner, nahezu identischer Seiten im großen Maßstab.

Kann Programmatic SEO meine Site deindexieren?

Ja, schlecht umgesetztes programmatic SEO kann ein Risiko auf Site-Ebene erzeugen. Google sagt, dass Websites gegen seine Spam-Richtlinien verstoßen können und dann niedriger ranken oder gar nicht in den Ergebnissen erscheinen. Behandeln Sie low-value generierte Seiten nicht wie ein harmloses Experiment auf einer ansonsten wertvollen Domain.

Woran erkennt man, ob eine programmatic Seite „thin“ oder spammy ist?

Nutzen Sie den strip-the-variable Test. Wenn das Entfernen von Stadt, Währung, App oder Kategorie zwei Seiten nahezu identisch macht, sind sie überwiegend Boilerplate. Gescrafter Content, leere Ergebnisse und Seiten, die für Queries ohne echte Nachfrage erstellt wurden, sind weitere Warnsignale.

Was sind gute Beispiele für Programmatic SEO?

Typische Beispiele sind Zapier’s App-Integrationsseiten, Wise’s Seiten zur Währungsumrechnung, Nomadlist’s City-Seiten sowie große Reise-Marktplätze mit ortsbezogenem Inventar. Jede dieser Implementierungen kombiniert ein wiederholbares Query-Muster mit Daten oder Utility, die sich auf jeder Seite materiell ändern.

Wie viele Seiten kann ich sicher programmatic veröffentlichen?

Google liefert keine feste „sichere“ Zahl. Die praktische Grenze ist die Anzahl der Query-Variationen mit echter Nachfrage, für die Sie einzigartigen Mehrwert liefern können. Zehntausend nützliche Seiten können vertretbar sein; eine deutlich kleinere Sammlung nahezu identischer Seiten kann trotzdem gegen Googles Richtlinien verstoßen.