Verzeichnis-Websites, die 28.000 Seiten umfassen, ohne wegen dürftiger Inhalte abgestraft zu werden.

So gut wie jede Verzeichnisstruktur, vorausgesetzt, es liegt eine strukturierte Datenquelle vor. In den letzten zwei Jahren lassen sich die von mir bereitgestellten Muster in vier große Kategorien einteilen, und die meisten Kundenprojekte entsprechen in irgendeiner Form einer dieser Kategorien.

Branchenverzeichnisse listen Unternehmen einer bestimmten Branche auf, unterteilt nach Kategorie, Standort, Größe und Leistungsumfang. HostList.io ist das Paradebeispiel, das ich selbst betreibe: Es umfasst etwa 28.000 Webhosting-Anbieter, unterteilt nach Hosting-Art, Region, Preisklasse und Anwendungsfall. Käufer finden Anbieter, Anbieter erhalten Besucher, und das Verzeichnis selbst generiert Einnahmen durch gesponserte Platzierungen, Affiliate-Links oder kostenpflichtige Premium-Einträge – je nachdem, was für die jeweilige Branche am besten geeignet ist.

Lokale Verzeichnisse und Standortverzeichnisse bilden das zweite Muster. Restaurantführer, Kneipenführer, Zahnarztverzeichnisse, Handwerkerverzeichnisse. Jeder Eintrag enthält das „LocalBusiness“-Schema mit GEO-Koordinaten, Öffnungszeiten und Bewertungen, sofern Sie über die entsprechenden Datenrechte verfügen. Programmatisch generierte Seiten nach Stadt und Kategorie, wie „Die besten italienischen Restaurants in Manchester“ oder „Kneipen in Stoke Newington“, machen den größten Teil der Long-Tail-SEO-Fläche auf diesen Websites aus.

Tool- und Softwareverzeichnisse listen Softwareprodukte innerhalb einer Kategorie auf. CRM-Tools. Projektmanagement-Apps. No-Code-Plattformen. KI-Tools. Der Haupttreiber für den Traffic auf diesen Seiten sind Vergleichsseiten – beispielsweise „Notion vs. Linear vs. ClickUp“ – sowie Funktionsübersichten, bei denen der Suchende die Namen bereits kennt und lediglich eine Entscheidungshilfe benötigt.

Das vierte Muster sind Personen- und Dienstleistungsverzeichnisse. Agenturen. Freiberufler. Berater. Fotografen. Rechtsanwälte. Die Herausforderung hierbei besteht darin, dass die meisten Personenverzeichnisse irgendwann aussterben, weil die Einträge veralten und niemand sie aktualisiert. Wir integrieren daher bereits am ersten Tag des Projekts Ablaufprozesse und die Möglichkeit zur selbstständigen Profilbearbeitung, anstatt diese Funktionen erst später nachzurüsten.

HostList.io ist das Verzeichnis, das ich im Alleingang erstellt habe, um die gesamte Webhosting-Branche zu erfassen. Es umfasst etwa 28.000 Seiten von Hosting-Anbietern, ist seit Frühjahr 2024 online und basiert auf demselben Stack aus Next.js, Supabase und Vercel, den wir mittlerweile auch für die Erstellung von Kundenverzeichnissen nutzen.

HostList katalogisiert alle Webhosting-Anbieter, die wir überprüfen können, und unterteilt sie nach Typ (Shared Hosting, VPS, Managed WordPress, Cloud, Dedicated Server, Reseller), Region, Preisklasse und Anwendungsfall. Es gibt Vergleichsseiten für bestimmte Hosting-Anbieter, Kategorieseiten für jedes Segment, eine Such- und Filteroberfläche, die den Datensatz mit 28.000 Zeilen ohne Abfragelatenz verarbeitet, Schema-Markup für jeden Eintrag sowie eine Streaming-Sitemap, da die Anzahl der URLs bereits die Kapazität einer einzelnen sitemap.xml-Datei übersteigt.

Drei Erkenntnisse aus der Umsetzung prägen heute den Aufbau jedes Kundenverzeichnisses. Erstens: Die Datenqualität ist entscheidend. Seiten mit drei eindeutigen Datenpunkten zusätzlich zum Namen der Entität überstehen Google-Updates; Seiten, die nur einen Namen und eine allgemeine Beschreibung enthalten, werden aus dem Index entfernt. Zweitens: Interne Verlinkung ist in dieser Größenordnung wichtiger als Backlinks. Das Verlinkungsnetz zwischen Einträgen, Kategorien und Vergleichsseiten entscheidet darüber, welche Blattseiten oft genug gecrawlt werden, um im Index zu bleiben. Drittens: Programmatisch bedeutet nicht faul. Jede Seite braucht einen Grund für ihre Existenz, und „wir haben einen Eintrag in der Datenbank“ ist kein Grund.

Wir haben etwa fünfzehn Prozent der Datenbank vom Index ausgeschlossen, da der Schwellenwert für eindeutige Daten bei diesen Zeilen nicht erreicht wurde. Wir haben Kategorieseiten mit weniger als fünf aussagekräftigen Einträgen entfernt, da sie den Eindruck von mangelhaftem Inhalt vermittelten, obwohl das zugrunde liegende Schema korrekt war. Wir haben Vergleichsseiten zwischen namentlich genannten Wettbewerbern als separaten Seitentyp hinzugefügt, und diese Vorlage gehörte schließlich zu den Seiten mit der höchsten Konversionsrate auf der Website. Das gleiche Vorgehensmodell ist nun Standard bei jedem Verzeichnis, das wir für unsere Kunden bereitstellen.

Es scheitern mehr Verzeichnisse, als überleben, und die Scheiterursachen sind so vorhersehbar, dass ich meist schon beim ersten Anruf erkennen kann, in welche Richtung ein Projekt steuert.

Die Deindexierung aufgrund von „Thin Content“ ist der häufigste Fehler. Ein Verzeichnis geht mit 5.000 Einträgen online, von denen die Hälfte nur einen Namen und eine einzeilige Beschreibung enthält, und Google indexiert die ersten 1.500 Einträge und hört dann auf. Die Website wirkt wie ein mit geringem Aufwand erstelltes Scraping-Projekt. Sechs Monate später werden die meisten der indexierten Seiten im Rahmen eines Core-Updates aus dem Index entfernt. Die Lösung muss bereits bei der Datenerfassung erfolgen: Jede Zeile benötigt drei eindeutige Datenpunkte, bevor sie für die Sitemap in Frage kommt – nicht nach dem Motto „Das füllen wir später aus“.

Das zweite Muster ist die Drift veralteter Daten. Ein Verzeichnis, das im Jahr 2023 noch korrekte Unternehmen auflistete, enthält im Jahr 2026 nur noch halbwegs existierende Unternehmen, weil niemand die Einträge aktualisiert hat: Die Kontaktdaten sind veraltet, die Websites führen zu Parkseiten, und das Verzeichnis verliert sowohl bei Google als auch bei menschlichen Besuchern an Vertrauenswürdigkeit. Wir integrieren entweder Crowdsourcing-Bearbeitungsabläufe, bei denen die aufgeführten Unternehmen ihr Profil beanspruchen und bearbeiten können, automatisierte Aktualitätsprüfungen, die nicht mehr existierende Einträge deaktivieren, oder beides. Ohne eine Aktualitätsschicht verliert das Verzeichnis mit der Zeit an Relevanz, unabhängig davon, wie gut die ursprünglichen Daten waren.

Das dritte Muster ist das Fehlen eines Wettbewerbsvorteils. Drei konkurrierende Verzeichnisse decken dieselbe Branche mit ähnlichen Daten ab. Keines verfügt über einzigartige Daten, sodass keines einen stichhaltigen Grund für seine Existenz hat. Die Suchanteile sind fragmentiert, und keines der Verzeichnisse erreicht eine gute Platzierung. Die Lösung liegt in der redaktionellen Ebene: originäre Analysen, Bewertungen, Empfehlungen und Vergleichsrahmen, die die zugrunde liegenden Daten allein nicht liefern können. HostList konkurriert mit seiner Bewertungsrubrik, nicht mit seiner Hosting-Liste, da die Hosting-Liste an sich nicht besonders stichhaltig ist.

Das vierte Muster ist die Indexaufblähung durch Filter. Ein Verzeichnis mit acht Filterdimensionen kann technisch gesehen Millionen von URL-Kombinationen erzeugen. Wenn jede Kombination indexierbar ist, überschwemmen Sie Google mit „Thin Pages“ und verwässern die aussagekräftigen Seiten. Wir blockieren stets „Thin Pages“-Filterkombinationen für den Index: Alles mit weniger als drei Einträgen erhält ein „noindex“, alles ohne echte Suchabsicht wie Sortierreihenfolgen oder Seiten ab Seite 2 erhält ein „noindex“, und nur die kanonischen Filterkombinationen, die echten Suchanfragen entsprechen, bleiben indexierbar.

Eine Referenzarchitektur für ein Verzeichnis umfasst fünf Ebenen. Jedes Projekt weist zwar spezifische Besonderheiten auf, doch die Grundstruktur bleibt über alle Builds hinweg gleich.

Als Datenschicht dient Postgres über Supabase oder als selbst gehostete Lösung, wobei jede Facetten-Spalte mit entsprechenden Indizes versehen ist. Für jeden Entitätstyp – Unternehmen, Produkte, Standorte, Personen – gibt es eine eigene Listentabelle sowie Spalten zur Qualitätsprüfung neben den Inhaltsdaten (Eindeutigkeitswert, Vollständigkeitsprozentsatz, Zeitstempel der letzten Überprüfung). Eine Ansicht zur Sitemap-Eignung filtert Zeilen, die unterhalb der Qualitätsschwelle liegen, automatisch heraus.

Die Seitenvorlagen lassen sich unterteilen in eine Detailseite für Einträge (vollständige Daten, verwandte Einträge, Schema, Breadcrumb), eine Kategorieseite (paginierte Liste mit Filter-Benutzeroberfläche und „ItemList“-Schema), eine Vergleichsseite für den direkten Vergleich zwischen benannten Entitäten, eine Standortseite mit eingebetteter Karte und GEO-Schema, wo geografische Aspekte eine Rolle spielen, sowie „Über uns“- und „Methodik“-Seiten, die den ursprünglichen redaktionellen Stellenwert vermitteln, den die zugrunde liegenden Daten nicht bieten können.

Für die Suche und Filterung wird die Postgres-Volltextsuche für bis zu etwa zehntausend Einträge verwendet; bei größeren Verzeichnissen mit hohen Anforderungen an die Abfragelatenz kommen Algolia oder Meilisearch zum Einsatz. Durch serverseitig gerenderte Filter-URLs erhält jede Filterkombination eine kanonische URL, und die Einstellung „noindex“ für seltene oder doppelte Kombinationen verhindert eine übermäßige Indexausdehnung. Für die Einreichung und Moderation stehen ein öffentliches Einreichungsformular zur Verfügung, über das das Modell durch Crowdsourcing ergänzt wird, eine Admin-Warteschlange mit Qualitätsbewertungen zur Überprüfung durch Moderatoren, vorgefertigte Ablehnungs-E-Mails mit konkreten Begründungen sowie ein Self-Service-Bearbeitungsablauf, über den gelistete Unternehmen ihr eigenes Profil beanspruchen und aktualisieren können.

Das SEO-Gerüst ist die Ebene, die darüber entscheidet, ob das Verzeichnis bestehen bleibt. Eine dynamisch generierte Sitemap nach dem „Chunk-per-Template“-Muster, bei jedem Eintrag je nach Bedarf die Schema.org-Typen „Organization“, „Product“, „Place“, „Service“ oder „LocalBusiness“, eine „CollectionPage“ mit „ItemList“ auf Kategorieseiten, überall eine „BreadcrumbList“, kanonische URLs, die aus einer einzigen zuverlässigen Quelle (der Datenbank, nicht der Vorlage) stammen, sowie ein SEO-Linter, der bereits während der Erstellung den Build abbricht, wenn H1-Überschriften fehlen, Meta-Beschreibungen zu lang sind oder das JSON-LD-Schema ungültig ist.

Die Monetarisierung erfolgt über hervorgehobene Einträge (ein boolescher Flag hebt eine Zeile an den Anfang der Kategorieseiten hervor), gesponserte Platzierungen in Kategorien (eine Marke belegt für einen Abrechnungszeitraum den obersten Platz in einer Kategorie), die Nachverfolgung von Affiliate-Links mit korrekter „rel=‘sponsored‘“-Kennzeichnung sowie kostenpflichtige Premium-Stufen für gelistete Unternehmen, um eine bessere Platzierung, umfangreichere Datenfelder und Zugriff auf Analysedaten zu erhalten.

Die wichtigste Variable bei einem Verzeichnisprojekt ist die Datenquelle selbst. Der Erfolg oder Misserfolg der meisten Projekte hängt von der Antwort auf eine einzige Frage ab: Woher stammen die Daten am ersten Tag, und wie wird sichergestellt, dass sie auch nach dem Start stets aktuell bleiben?

Unter „manueller redaktioneller Bearbeitung“ versteht man, dass ein Team jeden Eintrag einzeln verfasst. Das ist langsam und teuer, aber vertretbar. Geeignet für weniger als tausend Einträge. Beispiele, die ich gesehen habe und die gut funktionieren: Hochwertige Hotelführer, kuratierte Verzeichnisse von Agenturen, redaktionelle Nischen-Websites, bei denen bereits die Aufnahme in das Verzeichnis an sich den Wert darstellt.

Unter „strukturiertem Import“ versteht man, dass Sie eine CSV-Datei oder einen Datenbankexport aus einer zuverlässigen Quelle bereitstellen und wir diese Daten bereinigen, deduplizieren, anreichern und in unser System einlesen. Geeignet für ein bis hunderttausend Einträge. Beispiele: Branchenverzeichnisse mit öffentlichen Daten, Importe aus behördlichen Registern, Exporte im Stil des „Companies House“.

Automatisiertes Scraping oder die Nutzung von APIs bedeutet, dass Einträge aus einer API eines Drittanbieters oder einer seriösen Scraping-Pipeline bezogen werden. Die rechtliche und ethische Zulässigkeit hängt von der Quelle ab. Geeignet für 10.000 bis Millionen von Einträgen, bei denen die Daten an einem bekannten, kanonischen Ort gespeichert sind. Beispiele: Verzeichnisse von Entwickler-Tools, die von GitHub abgerufen werden, oder Hosting-Bewertungen, die aus öffentlichen Bewertungen auf den Unternehmenswebsites selbst extrahiert werden.

„Von Nutzern eingereicht“ bedeutet, dass die Einträge von den dort aufgeführten Personen stammen. Die Einrichtung ist kostengünstig, die Moderation jedoch aufwendig. Am besten eignet sich dieses Modell als Ergänzung zu redaktionellen Ausgangsdaten, nicht als einzige Quelle. Das Hybridmodell (redaktionelle Ausgangsdaten plus strukturierter Import plus jährliche redaktionelle Überprüfung) wird von HostList angewendet und ist das, was die meisten echten Verzeichnisse letztendlich tun, unabhängig davon, ob sie dies geplant haben oder nicht.

Beim ersten Gespräch werden wir Sie fragen, welche Kombination Ihrer Datenrealität entspricht. Falls Sie keine klare Antwort darauf haben, ist die Datenfrage selbst bereits der erste Arbeitsschritt; die Umsetzung folgt erst danach.

Diese Preise spiegeln tatsächlich abgeschlossene Verträge wider und nicht bloße Verkaufsprospekte. Ein kleines redaktionelles Verzeichnis mit weniger als tausend Einträgen kostet ab 8.000 US-Dollar und dauert sechs bis neun Wochen. Bei einem Umfang von ein- bis zehntausend Einträgen mit strukturiertem Datenimport liegt der Preis bei ab 13.000 US-Dollar über einen Zeitraum von zehn bis vierzehn Wochen. Ein großes Verzeichnis mit zehn- bis hunderttausend programmatischen Einträgen kostet ab 22.000 US-Dollar und dauert zwölf bis achtzehn Wochen. An der Spitze steht der zweiseitige Marktplatz, der Buchungen oder Transaktionen abwickelt, ab 27.000 US-Dollar über einen Zeitraum von vierzehn bis zweiundzwanzig Wochen.