Programmatic SEO, das die Helpful Content Update übersteht — gebaut vom Operator hinter HostList.io.

Ich habe HostList Anfang 2024 als Nebenprojekt gestartet. Die Idee war einfach genug: jeden Web-Hosting-Anbieter im Internet katalogisieren, jeder eine echte Seite mit einer echten Bewertung geben, und Leuten die Möglichkeit geben, Hosts so zu vergleichen, wie sie es wirklich tun wollen. Zweieinhalb Jahre später gibt es etwa achtundzwanzigtausend Seiten auf der Website, jede einzelne programmatisch aus einer strukturierten Datenquelle generiert, und ich habe persönlich zugesehen, wie die Website jede Google-Update durchlebt hat, die Helpful Content auf sie geworfen hat.

Das, was dir niemand erzählt, wenn du eine programmatische Website startest, ist, dass die Arbeit zu großen Teilen redaktionell ist, nicht technisch. Die Next.js-Seite kommt in ein paar Wochen zusammen. Das Supabase-Schema, die Ingestion-Pipeline, die Streaming-Sitemap, der schema.org Emitter — das ist alles gelöste Ingenieursarbeit. Was den Rest des Jahres dauert, ist herauszufinden, welche deiner achtundzwanzigtausend Zeilen tatsächlich einen Platz im Index verdienen, und was du dem Template hinzufügen musst, bevor eine dieser Zeilen als echte Seite anstatt als Datenbankausdruck mit SEO-Ambitionen gelesen wird.

Ich bin dazu gekommen, Programmatic SEO als die Disziplin der Subtraktion zu sehen. Der Standardzug ist, jede Zeile zu veröffentlichen. Der richtige Zug ist, nur die Zeilen zu veröffentlichen, die sich einen Platz verdient haben, und sie dann in genug redaktionellen Kontext zu verpacken, dass die Seite aus einem Grund existiert, der über das Füllen einer Sitemap hinausgeht. Wenn du diese beiden Dinge richtig machst, lässt Google dich in Core Updates in Ruhe. Wenn du eines falsch machst, verlierst du innerhalb von zwei Quartalen die meisten deiner indizierten Seiten.

Was folgt, ist das Playbook, das ich jeden Tag auf HostList laufe, angewendet auf Client-Arbeit in der gleichen Form. Es ist kein Marketing-Pitch. Es ist die tatsächliche Checkliste.

Die meisten Ideen, die mir als programmatic gepitcht werden, sollten es nicht sein. Wie ich es im Call sortiere: Ob der Datensatz wirklich interessant ist und ob die Suchanfragen wirklich fragmentiert über den Long Tail verteilt sind. Beides muss wahr sein. Wenn der Datensatz nur SEO-Köder ist und die Suchanfragen nicht wirklich im Long Tail stattfinden, den du dir vorstellst, ist programmatic die falsche Form, und weitermachen wird dir die indexierten Seiten innerhalb von sechs Monaten kosten.

Eine Handvoll Muster funktioniert 2026, und sie sind ziemlich eng. Vergleichsseiten funktionieren, weil der Suchende die involvierten Namen bereits kennt und nur einen Tiebreaker braucht: Notion versus Linear, Stripe versus Adyen, Cloudways versus Kinsta. Locationseiten funktionieren, weil lokale Suchintention fundamental fragmentiert ist und fast niemand das in großem Maßstab manuell schreibt. Branchenverzeichnisse funktionieren, wenn die Entity-mal-Filter-Kombination Abfragen mit echtem Suchvolumen produziert; HostList selbst ist genau um diese Form herum gebaut, weshalb ich die Fehlermodi aus dem Betrieb kenne. Glossar-Seiten funktionieren, wenn der Begriff technisch genug ist, dass die bestehenden Antworten im Web schlecht sind. Rechner-Seiten funktionieren, wenn die Berechnung selbst plus eine Methodik-Seite darunter der eigentliche Wert für den Suchenden ist.

Alles andere, das mir gepitcht wird, ist die schlechte Version. Die „wir wollen eine Million Seiten mit generischem Content und unserem Brand drauf"-Version, meist verpackt als Growth-Experiment, das den organischen Traffic in einem Quartal um das Zehnfache steigern soll. Google ist seit dem Helpful Content Update Ende 2022 besonders aggressiv dabei gewesen, und die De-Indexing-Wellen sind seitdem nur noch schneller geworden. Ich habe in den letzten zwei Jahren fünf verschiedene Teams das faule programmatic Spiel versuchen sehen; alle fünf verloren den Großteil ihrer indexierten Seiten innerhalb von zwei Quartalen. Ich lehne die Arbeit jetzt ab, anstatt sie zu liefern, was auf dem Sales Call unangenehm ist, aber auf lange Sicht kinder zu allen.

Drei Gates laufen zur Build-Zeit, bevor eine Seite in die Sitemap kommt. Sie sind automatisiert und nicht manuell geprüft, weil eine manuelle Überprüfung bei dreißigtausend URLs keine echte Überprüfung ist und vorzutäuschen, dass es eine ist, verzögert nur die De-Indexierung.

Gate eins ist eindeutige Daten. Nimm eine Seite über Cloudways verwaltetes WordPress-Hosting auf HostList. Sie braucht mindestens drei Dinge, die spezifisch für Cloudways sind. Eine Preisband. Eine Feature-Liste. Eine Region. Ein Mutterunternehmen. Ein Use Case. Alles, das nicht auch auf Kinsta oder WP Engine wahr ist. Wenn die Seite nur einen Namen, ein Logo und eine generische Beschreibung hat, fällt sie durch das Gate. Bleibt aus der Sitemap. Wird noindexed in der Quelle. Der Data Layer wird irgendwann gefüllt, wenn das Team die Zeile anreichert, dann verdient sich die Seite ihren Platz zurück in den Index. Auf HostList bleiben im Moment ungefähr fünfzehn Prozent der Datenbank genau aus diesem Grund aus der Sitemap raus.

Gate zwei ist redaktioneller Mehrwert. Das Template muss etwas tun, das die Daten allein nicht können. Vergleich. Bewertung. Empfehlung. Aggregation. Vor- und Nachteile. Ein Template, das nur die Datenbankzeile in schöner Typographie rendert, ist nicht genug, auch wenn die Typographie gut ist. Dieses Gate scheitern Teams am meisten in der Praxis. Sie bauen clevere Erfassung, verpassen die redaktionelle Hülle, verschiffen zweitausend Seiten, die alle identisch unter dem Keyword aussehen, und fragen sich dann, warum Google sie sechs Monate später de-indexiert. Die Hülle ist das, was Google signalisiert, dass die Seite aus einem Grund existiert, der über das Füllen einer Sitemap hinausgeht.

Gate drei ist echte Suchintention. Jede URL muss auf eine Abfrage abgebildet werden, die jemand plausiblerweise sucht, mit genug Volumen, um indexiert zu werden. Seiten, die auf Abfragen mit unter fünfzig monatlichen Suchanfragen abzielen, werden normalerweise noindexed, auch wenn sie die ersten zwei Gates bestehen, weil sie die Sitemap verschmutzen und das Crawl-Budget für die starken Seiten auf derselben Domain verdünnen. Der Schwellenwert ist flexibel je nach Industrie; wir kalibrieren ihn pro Projekt nach Ansicht der Search Console Daten auf benachbarten Seiten in derselben Vertikale.

Das Erste, das ich aus dem Index entfernt habe, war der dünne Schwanz. Etwa fünfzehn Prozent der Datenbank bleibt aus der Sitemap heraus, weil die Schwelle für eindeutige Daten nicht erfüllt wurde. Eine Zeile mit nur einem Namen, einem Logo und einer einzeiligen generischen Beschreibung ist keine Seite, die Google kennen sollte; die Kosten für das Crawlen sind höher als der Wert, sie indexiert zu haben. Kategorieseiten mit weniger als fünf starken Einträgen bleiben auch heraus, weil eine dünne Kategorie als wenig Aufwand wirkt, selbst wenn das Schema technisch korrekt ist. Filterkombinationen mit weniger als drei Ergebnissen erhalten automatisch noindex durch eine Prüfung zur Build-Zeit.

Was ich behalten und ausgebaut habe, war der Vergleich. Head-to-Head-Seiten zwischen benannten Hosting-Anbietern erwiesen sich als der konversionsfreudigste Seitentyp auf der Website und generierten etwa dreißig Prozent aller Konversionen, obwohl sie weniger als fünf Prozent der URL-Anzahl ausmachten. Ich habe Vergleiche als separates Template hinzugefügt und gezielt skaliert. Kategorieseiten mit starken eindeutigen Daten übertrafen auch die generischen Versionen um Längen. Nicht nur „bestes WordPress-Hosting", sondern „bestes WordPress-Hosting für WooCommerce-Shops mit weniger als zehntausend Produkten". Spezifisch. Abfragbar. Nützlich. Je enger der Qualifier, desto besser schnitt die Seite ab, was gegen den meisten SEO-Ratschlägen spricht, die du online liest.

Die Seiten, die ich von Hand geschrieben hielt, waren das Gravitationszentrum. Etwa zweihundert der achtundzwanzigtausend sind vollständig von Menschen geschriebene Redaktion. Die Methodologie-Seite. Die Bewertungsrubrik. Der Leitfaden „Wie man einen Hosting-Anbieter auswählt". Eine Handvoll starker Kategorielanding-Seiten. Sie skalieren nicht programmgesteuert und waren es nie, aber sie tragen überproportionales Gewicht im Topic-Authority-Graph und jede Blattseite verlinkt zurück auf sie. Die siebenundzwanzigtausendachthundert programmgesteuerten Seiten kreisen um die zweihundert. Das ist die Struktur, die ein Core Update übersteht.

Die Datenschicht sitzt auf Postgres, entweder über Supabase oder selbst gehostet, je nachdem, was das Team bereits nutzt. Jede Facettenspalte ist richtig indexiert, denn bei großem Maßstab werden vollständige Tabellenscans bei einer Filterabfrage zum Engpass, bevor die Seite selbst langsam wird. Jeder Content-Typ bekommt eine dedizierte Entities-Tabelle mit Quality-Gate-Spalten neben dem eigentlichen Inhalt — Eindeutigkeitswert, Vollständigkeitsprozentsatz, Zeitstempel der letzten Verifikation. Eine Sitemap-Eligibility-View filtert Zeilen unterhalb der Schwelle automatisch heraus, sodass Sitemap und zugrunde liegende Daten ohne manuelle Kuration synchron bleiben.

Templates gibt es in vier Formen. Ein Detail-Template pro Entity-Typ mit expliziten Slots für eindeutige Daten plus das redaktionelle Wrapping. Ein Vergleichs-Template für Head-to-Head zwischen benannten Entities, FAQPage-Schema angehängt, niemals AggregateRating, es sei denn, First-Party-Bewertungen existieren wirklich. Ein Kategorie- und Filter-Template mit CollectionPage und ItemList qualifizierender Entities, paginiert mit korrekter kanonischer Handhabung, sodass Filterkombinationen keine unendlichen doppelten URLs erzeugen. Und redaktionelle Templates mit Article-Schema, von Hand geschrieben, niedriges Volumen, höheres topisches Gewicht, behandelt als das Rückgrat des Link-Graphen und nicht als die Blätter.

SEO-Scaffolding ist der Teil, den die meisten Teams im großen Maßstab unterschätzen. Die Sitemap streamt in Chunks pro Template, denn eine einzelne sitemap.xml maxiert bei fünfzigtausend URLs und die meisten programmatischen Projekte überschreiten das im ersten Jahr. Internes Linking wird aus den Daten selbst generiert — jede Blattseite verlinkt zu ihrer Kategorie, ihrem Ort, ihren benannten Konkurrenten und ähnlichen Entities nach Feature-Überlappung. Ein SEO-Linter zur Build-Zeit sampelt einen Teil der Seiten bei jedem Deploy und stoppt den Build bei jeder H1-Zählanomalie, Meta-Description außerhalb des Bereichs, JSON-LD-Validitätsfehler oder hreflang-Cluster-Integritätsproblem. Nach dem Launch läuft AI-Overview-Citation-Tracking über Otterly oder Profound wöchentlich, um zu erkennen, wenn eine generative Suchmaschine beginnt, eine Seite der Domain zu zitieren oder aufhört.

Ehrliche Spannweiten, aus echten kürzlichen Engagements und nicht aus aspirativen Preisen auf einer Verkaufspräsentation. Ein kleiner programmatischer Build unter eintausend Entities kostet achtzehn bis dreizigtausend US-Dollar über sechs bis neun Wochen. Mittlere Arbeit zwischen eintausend und zehntausend Entities mit einem strukturierten Datenimport kostet dreizig bis sechzigtausend über acht bis vierzehn Wochen. Größere Projekte zwischen zehntausend und einhunderttausend Entities mit einer benutzerdefinierten Ingestion-Pipeline gegen eine externe API oder Scraping-Quelle kosten fünfzig bis neunzigtausend über zwölf bis achtzehn Wochen. Care Plans für laufende Operationen, Content-Aktualisierung und Quality-Gate-Wartung kosten fünfhundert bis dreitausend Dollar pro Monat nach dem Launch.

Jede Spannweite umfasst das Data Scaffolding, die Templates, den SEO-Linter und ein einfaches Admin-Dashboard für redaktionelle Overrides. Sie beinhalten nicht die Datenbeschaffung selbst. Manuelle Redaktion, Scraping-Infrastruktur, Drittanbieter-API-Kosten und ursprüngliche Brand- und Designarbeiten sind alle separate Posten. Die Akquisition von bezahltem Traffic liegt auch außerhalb des Geltungsbereichs; programmatische SEO ist ein organisches Spiel und wir bündeln bezahlte Medien nicht in das Engagement. Die meisten Projekte befinden sich bequem in der unteren Hälfte jeder Spannweite; die obere Hälfte existiert für wirklich komplexe Builds, bei denen die Datenaufnahme oder die redaktionelle Schicht ungewöhnlich umfangreich ist.