Verzeichnis-Websites, die 28.000 Seiten ohne Thin-Content-Strafen überstehen.

Ziemlich jede Verzeichnisform, given eine strukturierte Datenquelle. In den letzten zwei Jahren zerfallen die Muster, die ich ausgeliefert habe, in vier breite Typen, und die meisten Client-Projekte sind eine Variation eines dieser.

Branchenverzeichnisse listen Unternehmen innerhalb einer Branche auf, segmentiert nach Kategorie, Standort, Größe und Funktionsumfang. HostList.io ist das kanonische Beispiel, das ich selbst betreibe — etwa achtundzwanzigtausend Web-Hosting-Unternehmen, aufgeteilt nach Hosting-Typ, Region, Preisband und Anwendungsfall. Käufer finden Anbieter, Anbieter erhalten Traffic, und das Verzeichnis selbst monetarisiert sich durch gesponserte Platzierungen, Affiliate-Links oder kostenpflichtige Premium-Listings je nachdem, was für die Branche passt.

Lokale und Standort-Verzeichnisse sind das zweite Muster. Restaurant-Führer, Pub-Führer, Zahnarzt-Verzeichnisse, Handwerker-Verzeichnisse. Jedes Listing trägt LocalBusiness-Schema mit Geokoordinaten, Öffnungszeiten und Bewertungen, falls du Datenrechte hast. Programmatic-City-and-Category-Seiten — „beste italienische Restaurants in Manchester" oder „Pubs in Stoke Newington" — liefern die meiste Long-Tail-SEO-Fläche auf diesen Seiten.

Tool- und Software-Verzeichnisse listen Softwareprodukte innerhalb einer Kategorie auf. CRM-Tools. Projektmanagement-Apps. No-Code-Plattformen. KI-Tools. Das Traffic-Triebwerk auf diesen ist Comparison Pages — Notion versus Linear versus ClickUp — und Feature-Matrix-Seiten, wo der Suchende die Namen bereits kennt und nur einen Tiebreaker braucht.

Menschen- und Dienstverzeichnisse sind das vierte Muster. Agenturen. Freelancer. Berater. Fotografen. Anwälte. Die Herausforderung damit ist, dass die meisten Personenverzeichnisse sterben, weil die Einträge veralten und niemand sie aktualisiert. Wir bauen Ablauf-Workflows und Self-Service-Profilbearbeitung vom ersten Tag des Projekts ein, anstatt sie später nachzurüsten.

HostList.io ist das Verzeichnis, das ich solo gebaut habe, um die gesamte Web-Hosting-Branche zu katalogisieren. Etwa achtundzwanzigtausend Hosting-Unternehmensseiten, live seit Frühjahr 2024, auf demselben Next.js-plus-Supabase-plus-Vercel-Stack, den wir jetzt für Client-Verzeichnis-Builds nutzen.

HostList katalogisiert jeden Web-Hosting-Anbieter, den wir verifizieren können, segmentiert nach Typ — shared, VPS, managed WordPress, cloud, dedicated, reseller — Region, Preisband und Use Case. Es gibt Vergleichsseiten zwischen spezifischen Hosts, Kategorieseiten für jedes Segment, eine Such- und Filter-UI, die den achtundzwanzigtausend-Zeilen-Datensatz ohne Query-Latenz handhabt, Schema-Markup auf jedem Eintrag und eine Streaming-Sitemap, weil die URL-Anzahl bereits über das hinausgeht, was eine einzelne sitemap.xml halten kann.

Drei Lektionen aus dem Betrieb prägen jetzt jeden Client-Verzeichnis-Build. Erstens ist Datenqualität das ganze Spiel. Seiten mit drei einzigartigen Datenpunkten über den Entity-Namen hinaus überleben Google-Updates; Seiten mit nur einem Namen und einer generischen Beschreibung werden aus dem Index entfernt. Zweitens ist internes Linking in diesem Maßstab wichtiger als Backlinks. Das Link-Graph zwischen Einträgen, Kategorien und Vergleichsseiten entscheidet, welche Leaf-Pages oft genug gecrawlt werden, um indexiert zu bleiben. Drittens bedeutet programmgesteuert nicht faul. Jede Seite braucht einen Grund zu existieren, und „wir haben eine Zeile in der Datenbank" ist kein Grund.

Wir hielten etwa fünfzehn Prozent der Datenbank aus dem Index zurück, weil die Unique-Data-Schwelle auf diesen Zeilen nicht erreicht wurde. Wir kürzten Kategorieseiten, die unter fünf starken Einträgen hatten, weil sie dünn wirkten, auch wenn das zugrunde liegende Schema korrekt war. Wir fügten Vergleichsseiten zwischen benannten Konkurrenten als separaten Seitentyp hinzu, und diese Vorlage wurde am Ende einiger der höchst konvertierenden Traffic auf der Website. Dieselbe Spielweise ist jetzt Standard auf jedem Verzeichnis, das wir für Clients ausliefern.

Mehr Verzeichnisse sterben, als überleben, und die Fehlermuster sind vorhersehbar genug, dass ich im Anruf normalerweise sagen kann, auf welches zu fahren ein Projekt unterwegs ist.

Thin-Content-De-Indexierung ist das häufigste Scheitern. Ein Verzeichnis wird mit fünftausend Einträgen gestartet, die Hälfte davon hat nur einen Namen und eine einzeilige Beschreibung, und Google indexiert die ersten fünfzehnhundert dann hört auf. Die Website liest sich wie ein Low-Effort-Scrape. Sechs Monate später werden die meisten indizierten Seiten in einem Core Update aus dem Index entfernt. Die Reparatur muss zur Datenerfassungszeit stattfinden — jede Zeile braucht drei einzigartige Datenpunkte, bevor sie sich für die Sitemap qualifiziert, nicht „wir werden es später ausfüllen".

Stale-Data-Drift ist das zweite Muster. Ein Verzeichnis, das 2023 genaue Unternehmen listete, listete 2026 halb-defekte Unternehmen, weil niemand die Zeilen aktualisierte, die Kontaktinformationen werden veraltet, die Websites führen zu Parking Pages, und das Verzeichnis verliert Vertrauenssignal sowohl bei Google als auch bei menschlichen Besuchern. Wir bauen entweder Crowd-Sourced-Editing-Flows ein, bei denen das aufgelistete Unternehmen sein Profil beanspruchen und bearbeiten kann, automatisierte Freshness-Checks, die tote Einträge deaktivieren, oder beides. Ohne einen Freshness-Layer altert das Verzeichnis aus der Relevanz unabhängig davon, wie gut die ursprünglichen Daten waren.

Kein Burggraben ist das dritte Muster. Drei konkurrierende Verzeichnisse decken dieselbe Branche mit ähnlichen Daten ab. Keines hat einzigartige Daten, also keines hat einen verteidigbaren Grund zu existieren. Marktanteile fragmentieren sich und keines von ihnen rankt. Die Lösung ist die redaktionelle Schicht – ursprüngliche Analysen, Bewertungen, Empfehlungen, Vergleichsrahmen – die die zugrunde liegenden Daten allein nicht bieten können. HostList konkurriert auf Basis seiner Bewertungsrubrik, nicht auf Basis seiner Hosting-Liste, denn die Hosting-Liste selbst ist nicht besonders verteidigbar.

Index-Überblähung durch Filter ist das vierte Muster. Ein Verzeichnis mit acht Filterdimensionen kann technisch Millionen von URL-Kombinationen erzeugen. Wenn jede Kombination indexierbar ist, flutets du Google mit dünnen Seiten und verdünnst die starken. Wir blockieren immer dünne Filterkombinationen vom Index – alles mit unter drei Einträgen bekommt noindex, alles ohne echte Suchintention wie Sortierungen oder Seite 2 und später bekommt noindex, und nur die kanonischen Filterkombinationen, die echten Suchen entsprechen, bleiben indexierbar.

Eine Referenzarchitektur für ein Verzeichnis wird mit fünf Schichten ausgeliefert. Jedes Projekt variiert die Spezifika, aber das Rückgrat wiederholt sich über alle Builds hinweg.

Die Datenschicht ist Postgres via Supabase oder selbst gehostet, mit richtigen Indizes auf jeder Facetten-Spalte. Es gibt eine dedizierte Listings-Tabelle pro Entity-Typ – Unternehmen, Produkte, Standorte, Personen – und Quality-Gate-Spalten neben dem Inhalt (Eindeutigkeitsscore, Vollständigkeitsprozentsatz, letzter Verifikationszeitstempel). Eine Sitemap-Eligibility-View filtert Reihen unterhalb des Quality-Schwellwerts automatisch heraus.

Die Seitentemplates teilen sich in eine Listing-Detail-Seite (vollständige Daten, verwandte Listings, Schema, Breadcrumb), eine Kategorieseite (paginierte Liste mit Filter-UI und ItemList-Schema), eine Vergleichsseite für Eins-zu-eins-Vergleiche zwischen benannten Entitäten, eine Standortseite mit Karteneinbettung und Geo-Schema wo Geographie relevant ist, sowie About- und Methodologie-Seiten, die das ursprüngliche redaktionelle Gewicht tragen, das die zugrunde liegenden Daten nicht bieten können.

Suche und Filter nutzen Postgres-Volltextsuche bis etwa zehntausend Listings, dann Algolia oder Meilisearch für größere Verzeichnisse mit niedriger Query-Latenz-Anforderungen. Server-gerenderete Filter-URLs geben jeder Filterkombination ein Canonical, und noindex bei dünnen oder doppelten Kombinationen verhindert Index-Überblähung. Einreichungen und Moderation bekommen ein öffentliches Einreichungsformular, wo das Modell crowd-gefüttert wird, eine Admin-Queue mit Quality-Gate-Scores für Moderator-Review, vorlagentierte Ablehnungs-E-Mails mit spezifischen Gründen, und einen Self-Service-Edit-Flow für gelistete Entitäten, um ihr eigenes Profil zu beanspruchen und zu aktualisieren.

SEO-Gerüst ist die Schicht, die entscheidet, ob das Verzeichnis überlebt. Streaming-Sitemap mit Chunk-pro-Template-Muster, schema.org Organization oder Product oder Place oder Service oder LocalBusiness auf jedem Listing wie passend, CollectionPage mit ItemList auf Kategorieseiten, BreadcrumbList überall, kanonische URL aus einer einzigen Wahrheitsquelle emittiert (die Datenbank, nicht das Template), und ein Build-Zeit-SEO-Linter, der den Build bei fehlendem H1, übergroßen Meta-Beschreibungen oder ungültigem JSON-LD fehlschlagen lässt.

Monetisierung kommt durch hervorgehobene Listings (ein boolean Flag hebt eine Reihe an die Spitze von Kategorieseiten), gesponserte Kategorie-Platzierungen (eine Marke besitzt die Spitze einer Kategorie für einen Abrechnungszeitraum), Affiliate-Link-Tracking mit richtiger rel="sponsored"-Zuordnung, und bezahlte Premium-Tiers für gelistete Entitäten, um bessere Platzierung, mehr Rich-Data-Felder und Analytics-Zugang zu bekommen.

Die einzelne größte Variable in einem Directory-Projekt ist die Datenquelle selbst. Die meisten Engagements stehen oder fallen auf die Antwort auf eine Frage: Woher kommen die Daten am ersten Tag, und wie bleiben sie nach dem Launch aktuell?

Manuelle redaktionelle Arbeit bedeutet, ein Team schreibt jeden Eintrag. Langsam, teuer, aber verteidigbar. Geeignet für unter tausend Einträge. Beispiele, die ich funktionieren sah: hochwertige Hotelführer, kuratierte Agenturverzeichnisse, Nischen-Editorialseiten, wo das Gelistetwerden selbst der Wert ist.

Strukturierter Import bedeutet, Sie bringen einen CSV- oder Datenbankexport von einer zuverlässigen Quelle, und wir bereinigen, deduplizieren, reichern an und importieren. Geeignet für ein- bis hunderttausend Einträge. Beispiele: Branchenverzeichnisse mit öffentlichen Daten, Importe von Behördenregistern, Exporte im Stil von Companies House.

Automatisiertes Scraping oder API bedeutet, Einträge werden von einer API eines Drittanbieters oder einer respektvollen Scraping-Pipeline bevölkert. Rechtlich und ethisch abhängig von der Quelle. Geeignet für zehntausend bis Millionen von Einträgen, wo die Daten an einem bekannten kanonischen Ort leben. Beispiele: Entwicklertools-Verzeichnisse von GitHub, Hosting-Bewertungen, die von öffentlichen Bewertungen auf den Firmenseiten selbst gescraped werden.

Von Nutzern eingereichte Einträge bedeuten, dass Listings von den Personen kommen, die gelistet werden. Billig zu starten, teuer zu moderieren. Am besten als Schicht auf redaktionellen Seed-Daten, nicht als einzige Quelle. Das Hybrid-Muster (redaktionelle Seeds plus strukturierter Import plus jährliche redaktionelle Überprüfung) ist das, was HostList betreibt und das, worauf die meisten echten Verzeichnisse am Ende hinauslaufen, ob geplant oder nicht.

Im ersten Gespräch werden wir fragen, welche Kombination Ihrer Datensituation entspricht. Wenn Sie keine klare Antwort haben, ist die Datenfrage selbst die erste Phase der Arbeit; der Build kommt danach.

Ehrliche Spannweiten basierend auf echten aktuellen Engagements statt aspirativer Preisgestaltung auf einem Sales Deck. Ein kleines redaktionelles Verzeichnis unter tausend Einträgen kostet achtzehn- bis fünfunddreißigtausend US-Dollar über sechs bis neun Wochen. Ein mittelgroßes Verzeichnis mit ein- bis zehntausend Einträgen mit strukturiertem Datenimport kostet dreißig- bis sechzigtausend über zehn bis vierzehn Wochen. Ein großes Verzeichnis mit zehn- bis hunderttausend Einträgen, programmatisch im Maßstab, kostet fünfzig- bis neunzigtausend über zwölf bis achtzehn Wochen. Eine Marketplace-Form — zweiseitig, mit Buchungen oder Transaktionen — kostet sechzig- bis einhundertfünfzigtausend über vierzehn bis zweiundzwanzig Wochen.

Alle Spannweiten beinhalten das SEO-Gerüst (Schema, Sitemap, Linter), die Such- und Filterschicht und ein grundlegendes Admin-Dashboard. Sie beinhalten nicht die Datenakquisition selbst (manuelle redaktionelle Arbeit, Scraping-Infrastruktur, Kosten für API von Drittanbietern), originale Brand- und Design-Arbeiten oder bezahlte Traffic-Akquisition. Care Plans für den laufenden Betrieb nach dem Launch kosten fünfhundert bis dreitausend US-Dollar pro Monat.