Programmatische SEO, die das „Helpful Content Update“ übersteht – entwickelt vom Betreiber von HostList.io.

Ich habe HostList Anfang 2024 als Nebenprojekt ins Leben gerufen. Die Idee war ganz einfach: alle Webhosting-Anbieter im Internet zu katalogisieren, jedem eine eigene Seite mit einer echten Bewertung zu widmen und den Nutzern die Möglichkeit zu geben, Hosts so zu vergleichen, wie sie es tatsächlich möchten. Zweieinhalb Jahre später gibt es etwa 28.000 Seiten auf der Website, von denen jede einzelne programmgesteuert aus einer strukturierten Datenquelle generiert wurde, und ich habe persönlich miterlebt, wie die Website jedes Google-Update überstanden hat, das „Helpful Content“ ihr zugemutet hat.

Was einem niemand sagt, wenn man eine programmatische Website startet, ist, dass die Arbeit größtenteils redaktioneller und nicht technischer Natur ist. Der Next.js-Teil ist in ein paar Wochen fertig. Das Supabase-Schema, die Ingest-Pipeline, die Streaming-Sitemap, der schema.org-Emitter – all das sind technische Herausforderungen, die gelöst sind. Was den Rest des Jahres in Anspruch nimmt, ist herauszufinden, welche deiner 28.000 Zeilen es tatsächlich verdienen, im Index zu stehen, und was du der Vorlage hinzufügen musst, damit diese Zeilen als echte Seiten erscheinen und nicht als Datenbankausdruck mit SEO-Ambitionen.

Ich bin zu der Erkenntnis gelangt, dass programmatisches SEO eine Disziplin des Weglassens ist. Der Standardansatz besteht darin, jede Zeile zu veröffentlichen. Der richtige Ansatz ist es, nur die Zeilen zu veröffentlichen, die sich einen Platz verdient haben, und sie dann in genügend redaktionellen Kontext einzubetten, sodass die Seite aus einem anderen Grund existiert als nur zur Auffüllung einer Sitemap. Wenn man diese beiden Dinge richtig macht, lässt Google einen bei Core-Updates in Ruhe. Macht man bei einem der beiden Punkte einen Fehler, verliert man innerhalb von zwei Quartalen den Großteil seiner indizierten Seiten.

Im Folgenden stelle ich das Konzept vor, das ich täglich bei HostList anwende und das ich in unveränderter Form auch bei der Arbeit für Kunden nutze. Es handelt sich nicht um ein Marketing-Argument, sondern um die tatsächliche Checkliste.

Die meisten Ideen, die mir als programmatisch präsentiert werden, sollten gar nicht programmatisch sein. Ich entscheide während des Gesprächs danach, ob der Datensatz wirklich interessant ist und ob die Suchanfragen tatsächlich über den Long Tail verteilt sind. Beides muss zutreffen. Wenn der Datensatz nur SEO-Köder ist und die Suchanfragen nicht wirklich in dem von Ihnen angenommenen Long Tail stattfinden, ist Programmatic der falsche Ansatz, und wenn Sie trotzdem weitermachen, werden Sie innerhalb von sechs Monaten Ihre indexierten Seiten verlieren.

Im Jahr 2026 funktionieren nur eine Handvoll Muster, und diese sind ziemlich eng gefasst. Vergleichsseiten funktionieren, weil der Suchende die betreffenden Namen bereits kennt und lediglich eine Entscheidungshilfe benötigt: Notion versus Linear, Stripe versus Adyen, Cloudways versus Kinsta. Standortseiten funktionieren, weil die lokale Suchabsicht grundsätzlich fragmentiert ist und fast niemand sie in großem Umfang manuell verfasst. Branchenverzeichnisse funktionieren, wenn die Kombination aus Entität und Filter Suchanfragen mit echtem Suchvolumen erzeugt; HostList selbst ist genau auf dieses Muster ausgerichtet, weshalb ich die Fehlerquellen aus eigener Erfahrung kenne. Glossarseiten funktionieren, wenn der Begriff so fachspezifisch ist, dass die vorhandenen Antworten im Internet unzureichend sind. Rechner-Seiten funktionieren, wenn die Berechnung selbst zusammen mit einer darunter liegenden Methodikseite den eigentlichen Mehrwert für den Suchenden darstellt.

Alles andere, was mir angeboten wird, ist die schlechte Variante. Die Variante „Wir wollen eine Million Seiten mit generischen Inhalten, auf denen unsere Marke erscheint“ – meist verpackt als Wachstumsexperiment, das den organischen Traffic innerhalb eines Quartals verzehnfachen soll. Google geht seit dem „Helpful Content Update“ Ende 2022 besonders aggressiv dagegen vor, und die Wellen der Deindexierung haben sich seitdem nur noch beschleunigt. Ich habe in den letzten zwei Jahren beobachtet, wie fünf verschiedene Teams diese faule programmatische Vorgehensweise ausprobiert haben; alle fünf haben innerhalb von zwei Quartalen den Großteil ihrer indexierten Seiten verloren. Ich lehne solche Aufträge mittlerweile ab, anstatt sie auszuführen – was bei Verkaufsgesprächen zwar unangenehm ist, langfristig aber für alle besser ist.

Drei Prüfschritte werden zur Erstellungszeit durchgeführt, bevor eine Seite in die Sitemap aufgenommen wird. Diese erfolgen automatisiert und nicht durch eine manuelle Überprüfung, da bei 30.000 URLs eine manuelle Überprüfung eigentlich keine echte Überprüfung darstellt und das Gegenteil vorzutäuschen lediglich die Deindexierung verzögert.

Kriterium eins sind einzigartige Daten. Nehmen wir eine Seite über das von Cloudways verwaltete WordPress-Hosting auf HostList als Beispiel. Sie muss mindestens drei für Cloudways spezifische Angaben enthalten: eine Preisspanne, eine Liste der Funktionen, eine Region, eine Muttergesellschaft und einen Anwendungsfall. Alles, was nicht auch auf Kinsta oder WP Engine zutrifft. Wenn die Seite nur einen Namen, ein Logo und eine allgemeine Beschreibung enthält, scheitert sie an dieser Hürde. Sie wird aus der Sitemap ausgeschlossen und im Quellcode mit „noindex“ versehen. Die Datenebene füllt sich schließlich, wenn das Team die Zeile ergänzt, und dann wird die Seite wieder in den Index aufgenommen. Auf HostList bleiben derzeit etwa fünfzehn Prozent der Datenbank genau aus diesem Grund aus der Sitemap heraus.

Die zweite Hürde ist der redaktionelle Mehrwert. Die Vorlage muss etwas leisten, was die Daten allein nicht können: Vergleiche, Bewertungen, Empfehlungen, Zusammenfassungen, Vor- und Nachteile. Eine Vorlage, die lediglich die Datenbankzeile in ansprechender Typografie darstellt, reicht nicht aus – selbst wenn die Typografie gut ist. Dies ist die Hürde, an der Teams in der Praxis am häufigsten scheitern. Sie entwickeln clevere Erfassungsmechanismen, vernachlässigen jedoch die redaktionelle Aufbereitung, veröffentlichen zweitausend Seiten, die unter dem jeweiligen Suchbegriff alle identisch aussehen, und wundern sich dann, warum Google sie sechs Monate später aus dem Index entfernt. Erst die redaktionelle Aufbereitung signalisiert Google, dass die Seite aus einem anderen Grund existiert als nur zur Auffüllung einer Sitemap.

Das dritte Kriterium ist die tatsächliche Suchabsicht. Jede URL muss einer Suchanfrage zugeordnet werden können, nach der jemand plausiblerweise sucht, und zwar mit ausreichendem Suchvolumen, damit sich eine Indizierung lohnt. Seiten, die auf Suchanfragen mit weniger als fünfzig Suchanfragen pro Monat abzielen, werden in der Regel nicht indiziert, selbst wenn sie die ersten beiden Kriterien erfüllen, da sie die Sitemap überladen und das Crawling-Budget für die starken Seiten derselben Domain verwässern. Der Schwellenwert variiert je nach Branche; wir passen ihn projektbezogen an, nachdem wir die Search-Console-Daten zu ähnlichen Websites derselben Branche ausgewertet haben.

Als Erstes habe ich den „dünnen Schwanz“ aus dem Index entfernt. Etwa fünfzehn Prozent der Datenbank bleiben aus der Sitemap heraus, da der Schwellenwert für eindeutige Daten nicht erreicht wurde. Eine Zeile, die lediglich einen Namen, ein Logo und eine einzeilige allgemeine Beschreibung enthält, ist keine Seite, von der Google wissen sollte; der Aufwand für das Crawlen übersteigt den Nutzen einer Indizierung. Kategorieseiten mit weniger als fünf aussagekräftigen Einträgen bleiben ebenfalls außen vor, da eine „dünne“ Kategorie als wenig aufwendig gewertet wird, selbst wenn das Schema technisch korrekt ist. Filterkombinationen mit weniger als drei Ergebnissen erhalten durch eine Überprüfung während der Erstellung automatisch den „noindex“-Attribut.

Was ich beibehalten und ausgebaut habe, war der Vergleich. Seiten mit direkten Vergleichen zwischen namentlich genannten Hosts erwiesen sich letztendlich als der Seitentyp mit der höchsten Konversionsrate auf der Website und generierten etwa dreißig Prozent aller Konversionen, obwohl sie weniger als fünf Prozent der URLs ausmachten. Ich fügte den Vergleich als separate Vorlage hinzu und skalierte ihn gezielt. Auch Kategorieseiten mit aussagekräftigen, einzigartigen Daten übertrafen die generischen Versionen bei weitem. Nicht einfach „bestes WordPress-Hosting“, sondern „bestes WordPress-Hosting für WooCommerce-Shops mit weniger als zehntausend Produkten“. Spezifisch. Suchorientiert. Nützlich. Je enger die Eingrenzung, desto besser schnitt die Seite in der Regel ab – was den meisten SEO-Ratschlägen widerspricht, die man online liest.

Die Seiten, die ich handschriftlich beibehalten habe, bildeten den Schwerpunkt. Etwa zweihundert der achtundzwanzigtausend Seiten sind vollständig von Hand verfasste redaktionelle Beiträge. Die Methodik-Seite. Die Bewertungsrubrik. Der Leitfaden „So wählen Sie einen Hosting-Anbieter aus“. Eine Handvoll starker Kategoriestartseiten. Sie lassen sich nicht programmatisch skalieren und waren auch nie dafür gedacht, doch sie haben ein überproportionales Gewicht im Themenautoritätsdiagramm, und jede Unterseite verweist auf sie zurück. Die 27.800 programmatisch generierten Seiten kreisen um diese 200. Das ist die Struktur, die ein Core-Update übersteht.

Die Datenschicht basiert auf Postgres – je nachdem, was das Team bereits einsetzt, entweder über Supabase oder selbst gehostet. Jede Facetten-Spalte ist ordnungsgemäß indiziert, da bei großem Datenvolumen Volltabellenscans bei Filterabfragen zum Engpass werden, noch bevor die Seite selbst langsam wird. Jeder Inhaltstyp erhält eine eigene Entitätstabelle mit Spalten zur Qualitätsprüfung neben dem eigentlichen Inhalt, dem Eindeutigkeitswert, dem Vollständigkeitsprozentsatz und dem Zeitstempel der letzten Überprüfung. Eine Ansicht zur Sitemap-Eignung filtert Zeilen, die unter dem Schwellenwert liegen, automatisch heraus, sodass die Sitemap und die zugrunde liegenden Daten synchron bleiben, ohne dass eine manuelle Kuratierung erforderlich ist.

Es gibt vier Arten von Vorlagen: Eine Detailvorlage pro Entitätstyp mit expliziten Feldern für eindeutige Daten sowie redaktionellen Rahmeninhalten; eine Vergleichsvorlage für den direkten Vergleich zwischen benannten Entitäten, mit angehängtem FAQPage-Schema, wobei niemals eine „AggregateRating“-Bewertung angezeigt wird, es sei denn, es liegen tatsächlich Bewertungen von Erstnutzern vor. Eine Kategorie- und Filtervorlage unter Verwendung von „CollectionPage“ mit einer „ItemList“ qualifizierter Entitäten, paginiert mit korrekter Kanonisierung, damit Filterkombinationen keine unendlichen doppelten URLs erzeugen. Und redaktionelle Vorlagen unter Verwendung des „Article“-Schemas, handverfasst, geringeres Volumen, höheres thematisches Gewicht, die eher als Rückgrat des Linkgraphen denn als dessen Endknoten behandelt werden.

SEO-Scaffolding ist der Teil, den die meisten Teams bei großen Projekten unterschätzen. Die Sitemap wird in Blöcken pro Vorlage generiert, da eine einzelne sitemap.xml-Datei maximal fünfzigtausend URLs enthalten darf und die meisten programmatischen Projekte diese Grenze bereits im ersten Jahr überschreiten. Die interne Verlinkung wird aus den Daten selbst generiert: Jede Unterseite verweist auf ihre Kategorie, ihren Standort, ihre namentlich genannten Wettbewerber und ähnliche Entitäten aufgrund von Funktionsüberschneidungen. Ein SEO-Linter, der während der Build-Phase läuft, überprüft bei jedem Deployment eine Stichprobe von Seiten und bricht den Build ab, sobald Anomalien bei der Anzahl der H1-Überschriften, Meta-Beschreibungen außerhalb des zulässigen Bereichs, Gültigkeitsfehler bei JSON-LD oder Probleme mit der Integrität des hreflang-Clusters auftreten. Nach dem Launch wird wöchentlich eine Zitierverfolgung über „AI Overview“ mittels Otterly oder Profound durchgeführt, um festzustellen, wann eine generative Suchmaschine beginnt, eine Seite der Domain zu zitieren, oder wann sie damit aufhört.

Jeder Bereich umfasst das Daten-Gerüst, die Vorlagen, den SEO-Linter und ein einfaches Admin-Dashboard für redaktionelle Anpassungen. Die Datenerfassung selbst ist nicht enthalten. Manuelle redaktionelle Bearbeitung, Scraping-Infrastruktur, Kosten für APIs von Drittanbietern sowie die Entwicklung eines eigenen Marken- und Designkonzepts werden separat abgerechnet. Die Akquise von bezahltem Traffic fällt ebenfalls nicht in den Leistungsumfang; programmatisches SEO ist ein organischer Ansatz, und wir bündeln keine bezahlten Medien in das Projekt. Die meisten Projekte liegen problemlos in der unteren Hälfte der jeweiligen Preisklasse; die obere Hälfte ist für wirklich komplexe Projekte vorgesehen, bei denen die Datenerfassung oder die redaktionelle Ebene ungewöhnlich aufwendig ist.