Programmatic SEO ohne Thin Content: Stadt-Landingpages richtig bauen

Doorway-Pages versus echte Local Pages

Doorway-Pages sind laut Google Search Central Seiten oder Sites, die für ähnliche Suchanfragen gebaut werden und Nutzer auf Zwischen- oder Sammelseiten führen, die weniger nützlich sind als das eigentliche Angebot. Typische Merkmale: viele Städte, nahezu identischer Inhalt, schwache oder fehlende Navigation aus dem Rest der Site, Funnel auf eine einzige Kontaktseite.

Eine echte Local Page beantwortet die Suche am Ort der Anfrage. Wer „Webdesign Nürnberg“ sucht, landet auf einer Seite, die Nürnberg ernst nimmt: Distanz zum Sitz, Branchen der Region, belegbare Arbeitgeber oder Institutionen als Anker, FAQs mit Ortsbezug, Verweise auf Referenzen in der Metropolregion. Der Nutzer muss nicht weiterklicken, um zu verstehen, ob das Angebot passt.

Der Unterschied ist nicht „handgeschrieben versus generiert“. Generierte Seiten können stark sein, handgeschriebene dünn. Entscheidend ist das Unique Local Signal — der Teil, der ohne die Stadt sinnlos wird. Fehlt er, bleibt Doorway. Sitzt er nur im Title-Tag, aber nicht im Body, bleibt Doorway mit besserem Snippet.

Hub-and-Spoke: maximal drei Klicks

Hub-and-Spoke ist das Verlinkungsmuster hinter skalierbaren Local-SEO-Sites. Der Hub ist die Übersichts- oder Leistungsseite (zum Beispiel Webentwicklung oder Standorte). Die Spokes sind die Stadtseiten. Von der Startseite aus erreicht man jede Money-Page in maximal drei Klicks: Home → Hub → Spoke — optional noch ein verwandter Spoke oder eine Branchenseite.

Wichtig ist die Achsentrennung. Service × Stadt und Service × Branche sind zwei URL-Familien. Eine dritte Achse „Branche × Stadt“ oder „Service × Branche × Stadt“ multipliziert dünne Varianten und erzeugt genau das Muster, das Google als Doorway-ähnlich beschreibt: viele nahezu gleiche Seiten ohne browsebare Hierarchie. Auf hirnworx.de und bavariansigns.de bleiben die Achsen getrennt; Querverweise laufen über Links, nicht über kombinatorische URLs.

Praktisch heißt das: Jede Stadtseite verlinkt zurück auf den Service-Hub, auf die Standorte-Übersicht, auf Nachbarstädte derselben Region und auf passende Branchen- oder Kostenseiten. Der Hub listet eine Auswahl der Spokes, nicht alle tausend auf einmal in einem unlesbaren Block. So entsteht eine Site, die Menschen und Crawler navigieren können — kein Archiv isolierter Landingpages.

Die drei-Klick-Regel ist eine Informationsarchitektur-Regel, keine Designspielerei. Seiten, die nur über die Sitemap oder über bezahlte Anzeigen erreichbar sind, beantwortet Google in den Doorway-Leitfragen ausdrücklich negativ: Existieren die Seiten als Insel? Sind Links zu ihnen nur für Suchmaschinen gesetzt? Hub-and-Spoke ist die Antwort darauf — browsebare Hierarchie statt Suchergebnis-Attrappe.

Indexierbarkeits-Gate: Unique Intro und lokaler Fakt

Nicht jede technisch erzeugbare Stadt-URL gehört in den Index. Ein Indexierbarkeits-Gate prüft vor Sitemap und Robots-Meta, ob genug eigener Inhalt vorliegt. In der Praxis, die wir für Landingpage-Systeme und das Bavarian-Signs-Muster nutzen, gilt: Das unique Intro muss mindestens 180 Zeichen tragen (Konstante CITY_INTRO_MIN), und zusätzlich braucht die Seite ein lokales Signal — etwa einen Marktfakt, verifizierte Anker-Arbeitgeber oder eine ortsbezogene FAQ.

Auf hirnworx.de sind die Stadtseiten bewusst so gebaut, dass das Gate greifen könnte, aber derzeit alle veröffentlichten Kombinationen indexierbar sind: Der Content wird aus Stammdaten, Marktcontext und Hooks so zusammengesetzt, dass dünne Varianten erst gar nicht entstehen. Das ist der andere Weg: Qualität vor dem Build erzwingen, statt nachträglich massenhaft noindex zu setzen. Beides ist legitim — noindex ohne Inhaltspflege ist jedoch nur Schadensbegrenzung.

Was das Gate nicht ist: ein Freibrief für leere Seiten mit einem langen Dummy-Absatz. 180 Zeichen Floskeln ohne Stadtbezug erfüllen die Zahl, nicht den Sinn. Der Test ist: Entfernt man den Stadtnamen, bleibt der Absatz sinnlos — dann war das Signal lokal. Bleibt er austauschbar, war es Boilerplate.

Faktenblatt pro Stadt: was in die Datenschicht gehört

Jede Stadt braucht ein kurzes Faktenblatt, bevor das Template läuft. Ohne diese Schicht erzeugt Programmatic SEO nur Layout. Die Felder auf hirnworx.de und in vergleichbaren Systemen folgen einem klaren Muster — ehrlich beschrieben, ohne die bestehenden Seiten hier umzuschreiben.

Zum Stammsatz gehören Name, Slug, Region, Bundesland, Einwohnerzahl wo sinnvoll, Stadtteile, Branchen-Schwerpunkte und Distanz zum echten Sitz (bei uns Langenzenn). Der Marktcontext ergänzt Wirtschaft in einem Satz, digitalen Bedarf in einem Satz und optionale Anker — verifizierbare Arbeitgeber oder Institutionen. City-Hooks liefern service-spezifische Absätze und eine optionale lokale FAQ. Tier-A-Städte (Heimatmarkt) bekommen zusätzlich Hand-Overrides: längere Intros, Projektreferenzen, eigene Leistungs-Karten.

Arbeitgeber und Institutionen nur nennen, wenn sie öffentlich und korrekt sind. Erfundene „Top-Arbeitgeber“ oder geratene Cluster sind schlimmer als fehlende Anker: Sie zerstören Vertrauen und erzeugen faktisch falschen Unique Content. Lieber kürzer und belegt als lang und spekulativ.

Template-Felder versus Unique Body

Ein Template darf Struktur und wiederkehrende Bausteine tragen. Es darf nicht den gesamten sichtbaren Nutzen ersetzen. Typische Template-Felder: Meta-Title-Muster, H1-Schema („Webdesign & Webentwicklung in {Stadt}“), Breadcrumbs, Schema-Gerüst, CTA-Block, Kosten-Verweis, Prozesskurzfassung. Diese Teile sind absichtlich ähnlich — sie halten die Site konsistent.

Der Unique Body entsteht aus dem Faktenblatt: vier Intro-Absätze (Nähe, Markt, Service-Winkel, Region), lokale FAQs, Industry-Note, lokale Offerings und Projektliste. In Bavarian Signs und auf hirnworx.de ist genau diese Trennung der Kern: Das Layout skaliert, der Text nicht als leere Variable.

Wer Programmatic SEO budgetiert, sollte den Aufwand dort verorten. Das Template ist der kleinere Posten. Die Datenschicht — Recherche, Verifikation, Overrides für Top-Städte — ist der größere. Deshalb liegen SEO-Landingpage-Systeme in der Webentwicklung-Kalkulation typisch höher als eine Corporate Website gleicher Seitenoptik.

Interne Verlinkung und Schema LocalBusiness

Interne Links sind die Lesbarkeit der Architektur. Jede Stadtseite sollte den Service-Hub, /standorte, passende /branchen-Einträge, Kosten- und Ratgeber-Seiten sowie Nachbarstädte erreichen. Referenzen mit Ortsbezug (zum Beispiel Lightvertise-SEO / Bavarian Signs für Nürnberg und Fürth) gehören auf die Spoke, nicht nur in ein globales Portfolio.

Strukturierte Daten machen denselben Sachverhalt maschinenlesbar. Für Stadt-Landingpages eignet sich ein LocalBusiness-Signal mit ehrlichem Sitz und areaServed = Zielstadt — nicht mit erfundenen Filialadressen. Ergänzend: FAQPage für die lokalen Fragen, BreadcrumbList, Service-Schema wo passend. Das Local-Pack in Google Maps entsteht über das Google Business Profile am echten Standort, nicht über hundert Schein-NAP-Blöcke.

Schema ersetzt keinen Inhalt. Es beschreibt, was auf der Seite steht. Fehlt das Unique Local Signal, ist korrektes Markup nur sauber etikettierter Thin Content.

Messung in der Google Search Console

Ohne Search Console ist Programmatic SEO Blindflug. Nach dem Launch zählen drei Dinge: Welche URLs sind indexiert? Welche haben Impressionen? Welche erzeugen Fehler (Soft-404, Duplicate, Crawl-Probleme)?

Sinnvolle Checks: Abdeckung der Stadt-Spokes gegen die Sitemap, Vergleich „indexiert“ versus „gefunden, nicht indexiert“, Seiten mit Impressionen aber ohne Klicks (Snippet und Intent prüfen), und Core Web Vitals aus Felddaten. IndexNow oder Sitemap-Pings beschleunigen das Entdecken — sie ersetzen keine Index-Qualität.

Ein praktikabler Rhythmus nach dem Go-Live: in den ersten zwei Wochen täglich Abdeckung und Fehler, danach wöchentlich die Spokes mit Impressionen, quartalsweise ein Abgleich „welche Städte haben keinen Nutzen und gehören auf noindex oder in die Redaktionsschlange“. Ohne diesen Rhythmus sammelt Programmatic SEO still tote URLs.

Was Sie hier nicht finden sollten: Versprechen über Traffic-Sprünge oder Positionsgarantien. Die Architektur schafft die Voraussetzung für Sichtbarkeit; die Messung zeigt, ob Seiten leben oder tot im Index liegen. Tote Seiten mit Thin Content belasten die Domain — dann greift das Gate oder die manuelle Nacharbeit.

Next.js SSG als technische Basis

Static Site Generation erzeugt HTML zur Build-Zeit. Der Crawler bekommt fertige Seiten, keine leere React-Shell. Metadaten, Canonicals und Schema kommen aus typisierten Daten — eine Quelle der Wahrheit. Deployment über ein CDN hält Time to First Byte niedrig, weil zur Laufzeit keine Datenbank für den Content befragt wird.

Für Core Web Vitals gelten die Schwellen von web.dev: Largest Contentful Paint gut bei ≤2,5 Sekunden, Interaction to Next Paint gut bei ≤200 Millisekunden (75. Perzentil). SSG hilft beim LCP, weil das Hauptcontent früh als HTML da ist. INP bleibt eine Frage des JavaScript-Budgets — Page-Builder mit schweren Bundles reißen den Wert auch auf statischen Hosts.

Next.js ist nicht magisch. Dieselbe Architektur mit leeren Textvariablen produziert nur schnellere Doorways. Der Stack löst Crawlability und Performance; die Datenschicht löst Thin Content. Auf hirnworx.de und bavariansigns.de ist SSG deshalb die Auslieferungsform der Hub-and-Spoke-Inhalte — nicht der Ersatz für Marktkontext und lokale FAQs.

Fehlerkatalog: was Stadtseiten-Projekte regelmäßig ruinieren

Die folgenden Fehler treten in Agentur- und Inhouse-Projekten immer wieder auf. Sie sind unabhängig vom Framework — und genau deshalb lohnt die Liste vor dem ersten Build.

Wann Sie Programmatic SEO lassen sollten

Unter etwa zehn wirklich relevanten Städten reicht oft eine manuelle Seite pro Ort — günstiger, schneller, weniger Governance. Wenn Sie keine Zeit für Faktenblätter und Overrides haben, skaliert nur das Template, nicht der Nutzen.

Wenn Ihr Angebot nicht regional suchbar ist (rein nationales SaaS ohne Ortsintent), sind Stadtseiten die falsche Achse. Wenn Sie keine ehrliche Standortgeschichte haben und mit Scheinadressen arbeiten wollen: lassen Sie es — das ist kein SEO-Projekt, sondern ein Compliance- und Vertrauensrisiko.

Wenn Sie skalieren wollen: Planen Sie Datenschicht, Gate, Hub-and-Spoke und Search-Console-Monitoring von Tag eins. Bavarian Signs, Lightvertise und hirnworx.de zeigen, dass das Muster trägt — als Architektur mit Inhalt, nicht als Trick mit Ortsnamen.