Een directorywebsite bouwen: waarom CMS-tools haperen bij 10.000 vermeldingen

Ik heb dit minstens een dozijn keer zien gebeuren. Iemand bouwt een directory op Webflow of WordPress, het werkt prachtig bij 500 vermeldingen, nog steeds goed bij 2.000, en ergens rond de 8.000-10.000 items begint het hele ding naar adem te snakken. Zoekopdrachten kruipen voort. Filters time-out. Bouwprocessen strekken zich uit over minuten. De CMS die in maand één zo perfect voelde, wordt in maand acht het knelpunt waaruit je wanhopig probeert te ontsnappen.

Het kernprobleem? CMS-tools waren ontworpen voor inhoud -- blogberichten, landingspagina's, misschien een productcatalogus met enkele honderden SKU's. Een directorywebsite is een fundamenteel ander beest. Het vereist complexe filtering, facetgericht zoeken, geolocatiequeries, door gebruikers gegenereerde inhoud en pagineerpatronen die databaseaanvragen per paginaweergave met orden van grootte vermenigvuldigen. Een directory als een blog met meer berichten behandelen is een architectonische fout die sneller op je afkomt dan je zou verwachten.

Ik zal je exact uitleggen waarom dit gebeurt, wat de werkelijke technische grenzen in 2025 zijn, en wat je in plaats daarvan zou moeten bouwen als je serieus bent over schaling naar meer dan 10.000 vermeldingen.

Een directorywebsite bouwen: waarom CMS-tools haperen bij 10.000 vermeldingen

Inhoudsopgave

Een directory is geen blog

Dit klinkt voor de hand liggend, maar hier gaan de meeste projecten in de planningsfase fout. Een blogbericht is een enkel document. Je haalt het op via slug, render het, klaar. Een directorylijstpagina doet iets totaal anders: het voert query uit op mogelijk duizenden records, past meerdere filters tegelijk toe (categorie, locatie, prijsklasse, rating, beschikbaarheid), sorteert de resultaten, pagineert ze en render een pagina -- vaak met kaartmarkers, afstandsberekeningen en aggregaattellingen voor elke filteroptie.

Hier volgt een snelle vergelijking van databasebewerkingen per paginaweergave:

Bewerking Blogberichtpagina Directorylijstpagina
Primaire query 1 (ophalen via slug) 1 (gefilterd, gesorteerd, gepagineerd)
Gerelateerde queries 2-3 (auteur, categorieën, gerelateerde berichten) 5-15 (filtertellingen, geoberekeningen, beoordelingen, beschikbaarheid)
Indexzoekopdrachten 1-2 10-50+ (per filterfacet)
Gescande rijen 1-5 100-10.000+
Typische responstijd 5-50ms 200-2.000ms (niet geoptimaliseerd)
Complexiteit van cache-invalidatie Laag (enkel document) Hoog (elke vermeldingswijziging beïnvloedt meerdere pagina's)

Wanneer je een traditionele CMS gebruikt, gaat elk van deze bewerkingen via dezelfde database, dezelfde query-engine, dezelfde server die ook je homepage, je over-pagina en je admin-paneel serveert. Bij 500 vermeldingen maakt het niet uit. Bij 10.000 is het van groot belang.

Waar de grote CMS-platforms tegen hun grenzen aanlopen

Laten we specifiek zijn over wat breekt en waar.

Webflow

Webflow handhaaft een harde limiet van 10.000 CMS-items per collectie op hun Business-plan. Dit is geen zacht richtlijn -- het is een muur. Bereik het en je kunt letterlijk geen andere vermelding toevoegen. Het Webflow-team heeft in hun communityforums bevestigd dat deze limiet bestaat om "prestatieredenen" en niet wordt opgeheven.

Maar hier is wat de meeste mensen missen: de prestaties verslechteren al voor je 10K raakt. Wanneer je voorbij de 5.000-6.000 items gaat met complexe collectieaanbiedingen en filters, zul je merken dat bouwprocessen voorbij de 10 minuten strekken en paginabeladingen trager worden. Webflows CMS was niet gebouwd voor facetgericht zoeken. Er is geen native manier om een "toon me alle restaurants binnen 5 kilometer die nu open zijn en vegaanse opties hebben" query uit te voeren.

Vanaf maart 2026 kost Webflows Business-plan $39/maand (jaarlijkse facturering). Wil je opschalen naar 20.000 items met add-ons? Dat kost je $124/maand -- meer dan drie keer de basisprijs voor het dubbele aantal items. Enterprise-prijzen voor 100K+ items beginnen in het bereik van $15.000-$50.000/jaar.

WordPress

WordPress heeft geen harde itemlimiet, maar iets erger: onvoorspelbare degradatie. Een standaard WordPress-installatie met een directory-plugin zoals Directorist of Business Directory Plugin zal rond 10.000 vermeldingen op typische shared of VPS-hosting beginnen te worstelen. De schuldige is MySQL-queryprestatie.

WordPress slaat alles op -- berichten, aangepaste velden, taxonomieën, metagegevens -- in een handvol databasetabellen. Een directoryvermelding met 20 aangepaste velden betekent 20 rijen in wp_postmeta per vermelding. Bij 10.000 vermeldingen zijn dat 200.000 rijen alleen in postmeta, en WordPress houdt ervan om JOIN queries uit te voeren over deze tabellen. Voeg WooCommerce of een ander plugin toe dat ook gegevens in postmeta opslaat en je hebt een echt probleem.

Ik heb WordPress directory-sites gezien die goed werken bij 10K vermeldingen -- maar alleen na significante optimalisatie: Redis-objectcaching, Elasticsearch voor zoeken, een dedicated databaseserver, en zorgvuldige query-optimalisatie. Op dat moment geef je $200-500/maand uit aan hostinginfrastructuur en vecht je in feite tegen het platform in plaats van ermee te werken.

Airtable / Notion / Google Sheets als "backend"

Ik zie dit patroon voortdurend in de indie hacker-gemeenschap. Gebruik Airtable als je database, leid het door een staticSite-generator of Webflow, en je hebt een directory. Het werkt! Tot het niet meer werkt.

De Airtable-API retourneert maximaal 100 records per verzoek. Hun gratis plan is beperkt tot 1.200 records per base. Zelfs op hun Business-plan ($20/gebruiker/maand) loop je tegen snelheidsgrenzen van 5 verzoeken per seconde per base aan. Probeer een directorylijstpagina met 10.000 vermeldingen weer te geven en je doet 100 opeenvolgende API-oproepen voordat een enkele pagina laadt. Dat is geen directory -- dat is een laadscherm.

Een directorywebsite bouwen: waarom CMS-tools haperen bij 10.000 vermeldingen - architectuur

De technische realiteit: waarom 10K het breekpunt is

De drempel van 10.000 vermeldingen is niet willekeurig. Het vertegenwoordigt een faseovergang in hoe databases zich gedragen onder veelgebruikte CMS-configuraties.

Querycomplexiteit explodeert

Bij 10K vermeldingen moet een typische gefilterde directoryquery:

  1. Een potentieel groot deel van de tabel (of index) scannen om filters toe te passen
  2. Aggregaattellingen voor resterende filteropties berekenen ("Hotels (247), Restaurants (1.832)")
  3. Resultaten sorteren op relevantie, afstand of rating
  4. Pagineren en een subset retourneren
  5. Gerelateerde gegevens samenvoegen (afbeeldingen, beoordelingen, categorieën)

Op een goed geïndexeerde PostgreSQL-database met juist schemaontwerp duurt dit 10-50ms. Op WordPress's wp_posts + wp_postmeta schema met EAV pattern queries? Gemakkelijk 500-2.000ms. Op Webflows interne datalayer die voor inhoudspagina's is ontworpen? Dat is waarom ze de limiet handhaven.

Bouwprocessen verwoesten de ontwikkelarenervaring

Staticsite-generators -- die zowel Webflow als veel headless-installaties gebruiken -- moeten voor elke vermelding, elke categoriepagina, elke gefilterde combinatie een pagina bouwen. Bij 10.000 vermeldingen met 50 categoriepagina's bouw je minimaal 10.050+ staticpagina's. Met Webflow kunnen builds meer dan 20 minuten duren. Met Next.js via getStaticPaths wacht je 15-30 minuten op een volledige rebuild, tenzij je Incremental Static Regeneration (ISR) gebruikt.

// De naïeve benadering: alle 10K pagina's bij buildtijd bouwen
export async function getStaticPaths() {
  const listings = await fetchAllListings(); // 10.000 items
  return {
    paths: listings.map(l => ({ params: { slug: l.slug } })),
    fallback: false // Bouw ALLE pagina's vooraf
  };
}

// De slimme benadering: bouwen op aanvraag
export async function getStaticPaths() {
  // Bouw alleen de top 100 meest bezochte vermeldingen vooraf
  const topListings = await fetchTopListings(100);
  return {
    paths: topListings.map(l => ({ params: { slug: l.slug } })),
    fallback: 'blocking' // Bouw anderen bij eerste aanvraag, cache dan
  };
}

Zoeken wordt het echte probleem

Volledig zoeken via 10.000+ vermeldingen met meerdere velden (naam, beschrijving, tags, locatie, categorie) is waar de meeste CMS-tools volledig instorten. Het standaard WordPress-zoeken is een LIKE %term% query -- het scant letterlijk elke rij. Het native filteren van Webflow ondersteunt volledig zoeken helemaal niet.

Echt directory-zoeken heeft nodig:

  • Fuzzy matching (vinden "pizza" wanneer iemand "piza" typt)
  • Gewogen relevantie (titels matchen hoger dan beschrijvingmatches)
  • Facettellingen (hoeveel resultaten per categorie/filter)
  • Geo-afstandsortering
  • Sub-200ms-responstijden

Je hebt een zoekmachine nodig hiervoor. Elasticsearch, Meilisearch, Typesense, of Algolia. Geen van deze zijn ingebouwd in een traditionele CMS.

Wat daadwerkelijk werkt: architectuur voor schaling

Als je een directory bouwt die 10.000+ vermeldingen moet verwerken, moet je je aandachtsgebieden van dag één scheiden.

De juiste gegevenslaag

Je vermeldingen horen in een juiste database met een schema dat is ontworpen voor je specifieke querypatronen. Niet in een CMS-inhoudsmodel, niet in een spreadsheet, niet in een generieke posts tabel met metagegevens eraan geplakt.

-- Een doelgebouwde vermeldingstabel
CREATE TABLE listings (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  name TEXT NOT NULL,
  slug TEXT UNIQUE NOT NULL,
  description TEXT,
  category_id UUID REFERENCES categories(id),
  location GEOGRAPHY(POINT, 4326), -- PostGIS voor geoquery's
  price_range INT CHECK (price_range BETWEEN 1 AND 4),
  rating DECIMAL(3,2),
  is_verified BOOLEAN DEFAULT false,
  created_at TIMESTAMPTZ DEFAULT NOW(),
  updated_at TIMESTAMPTZ DEFAULT NOW()
);

-- Juiste indexen voor directory querypatronen
CREATE INDEX idx_listings_category ON listings(category_id);
CREATE INDEX idx_listings_location ON listings USING GIST(location);
CREATE INDEX idx_listings_rating ON listings(rating DESC);
CREATE INDEX idx_listings_search ON listings USING GIN(
  to_tsvector('english', name || ' ' || COALESCE(description, ''))
);

PostgreSQL met PostGIS verwerkt 100.000+ vermeldingen zonder problemen. Supabase geeft je dit out of the box met een ruim gratis niveau en schaalt naar miljoen rijen. Dit is het soort gegevensarchitectuur dat we implementeren in onze headless-CMS-ontwikkelingprojecten -- de CMS handelt redactionele inhoud af terwijl de database gestructureerde gegevens op schaal handelt.

Zoeken scheiden van opslag

Laat je primaire database niet voor zoeken zorgen. Synchroniseer je vermeldingen naar een speciale zoekenservice:

Zoekenservice Gratis niveau Prijzen bij 10K+ records Latentie Best voor
Algolia 10K zoeken/mnd $1/1K verzoeken + $0,40/1K records <50ms Maximale snelheid, faceting
Typesense Self-hosted (gratis) Cloud: $29,50/mnd (tot 500K records) <50ms Budget-vriendelijk, open source
Meilisearch Self-hosted (gratis) Cloud: $30/mnd (1M documenten) <50ms Eenvoudige setup, geweldige defaults
Elasticsearch Self-hosted (gratis) Elastic Cloud: ~$95/mnd <100ms Complexe query's, volwassen ecosysteem

Typesense en Meilisearch zijn beide in 2025 significant rijper geworden. Voor de meeste directoryprojecten onder 100K vermeldingen geeft Typesense Cloud op $29,50/maand je instant zoeken met faceting, geo-zoeken en spelvervangingstolerantie. Het is ongelooflijk snel.

De headless-benadering voor directorywebsites

Hier is de architectuur die ik zou aanbevelen voor elke directory die meer dan 10.000 vermeldingen verwacht:

  1. Frontend: Next.js of Astro voor de openbare website
  2. CMS: Sanity, Contentful, of Payload voor redactionele inhoud (homepage, over, blog, helponderwerpen)
  3. Database: PostgreSQL (via Supabase of Neon) voor vermeldingsgegevens
  4. Zoeken: Typesense of Meilisearch voor zoeken en filtering
  5. Admin-interface: Aangepast dashboard of Retool voor vermeldingsbeheer

Dit is het soort stack dat we regelmatig voor klanten bouwen. Het frontend-framework handelt rendering en routing af. De CMS handelt inhoud af die redacteurs moeten beheren. De database handelt gestructureerde, high-volume vermeldingsgegevens af. De zoekmachine handelt de querypatronen af die directories eisen.

Met Next.js krijg je ISR voor vermeldingsdetailpagina's (bouwen op aanvraag, cache aan de rand, herevalueren bij wijziging) en server-side rendering voor zoek/filterpagina's (altijd verse resultaten, snelle reacties). Met Astro krijg je nog sneller staticpagina's voor vermeldingen die niet vaak veranderen, met eilanden van interactiviteit voor zoeken en filteren.

// Next.js App Router: ISR voor vermeldingspagina's
export async function generateStaticParams() {
  // Bouw alleen de top vermeldingen vooraf voor instant laadt
  const topListings = await db
    .select({ slug: listings.slug })
    .from(listings)
    .orderBy(desc(listings.pageviews))
    .limit(500);
  
  return topListings.map(l => ({ slug: l.slug }));
}

export const revalidate = 3600; // Herevalueer elk uur

export default async function ListingPage({ params }) {
  const listing = await db
    .select()
    .from(listings)
    .where(eq(listings.slug, params.slug))
    .limit(1);
  
  if (!listing[0]) notFound();
  
  return <ListingDetail listing={listing[0]} />;
}

Waarom niet gewoon de CMS voor alles gebruiken?

Omdat CMS-platforms optimaliseren voor redactionele workflows, niet gegevensbewerkingen. Een CMS geeft je rich-text editing, concept/publiceer-workflows, inhoudsplanning, lokalisering en op rollen gebaseerde machtigingen. Deze zijn essentieel voor blogberichten en marketingpagina's.

Een directoryvermelding heeft niets van dat nodig. Het heeft bulkimport/export nodig, gestructureerde validatie (is dit een geldig telefoonnummer?), deduplicatie, geautomatiseerde verrijking (pull Google Places-gegevens), en het vermogen om 500 gelijktijdige schrijven af te handelen wanneer je een gegevensbron scrapt. Dit zijn databasebewerkingen, niet inhoudsoperaties.

De fout is inhoudbeheer met gegevensbeheer verwarren. Dit zijn verschillende problemen met verschillende oplossingen.

Kostenvergelijking: CMS vs. Headless vs. Custom

Laten we kijken naar werkelijke maandelijkse kosten voor het uitvoeren van een directory met 25.000 vermeldingen:

Kostencategorie Webflow (Enterprise) WordPress (Geoptimaliseerd) Headless (Next.js + Supabase) Volledig Custom
Hosting/Platform $1.250-$4.166/mnd $100-300/mnd (managed WP) $20/mnd (Vercel Pro) $200-500/mnd (cloud infra)
Database Inbegrepen (beperkt) Inbegrepen (MySQL) $25/mnd (Supabase Pro) $50-200/mnd (managed PG)
Zoeken Niet native beschikbaar $0-95/mnd (Elasticsearch) $29,50/mnd (Typesense Cloud) $95-300/mnd (Elasticsearch)
CMS Inbegrepen Gratis (WP core) $0-99/mnd (Sanity/Payload) N/A
CDN/Edge Inbegrepen $0-20/mnd Inbegrepen (Vercel) $20-50/mnd
Totaal maandelijks $1.250-$4.166 $100-415 $75-175 $365-1.050
Bouwkosten $5K-15K $3K-10K $15K-40K $50K-150K+

De headless-benadering heeft zeker hogere eenmalige bouwkosten dan WordPress plugin eraan plakken, zonder twijfel. Maar de lopende kosten zijn dramatisch lager dan Webflow Enterprise, en de architectuur ondersteunt daadwerkelijk groei. Wanneer je van 25K naar 100K vermeldingen gaat, verhoog je je Supabase-plan en je zoekenlaag. Dat is het. Geen herontwerp, geen migratiepaanique.

Als je evalueert wat dit voor je specifieke project zou kosten, geeft onze prijzenpagina onze engagementmodellen uiteen, of je kunt rechtstreeks contact opnemen om je directory's vereisten door te spreken.

Migratiepad in de praktijk

Als je al vast zit bij het CMS-plafond, hier volgt een praktische migratievolgorde:

Fase 1: Je gegevens extracten (Week 1-2) Exporteer alles uit je CMS. Webflows API en CSV-exports werken. WordPress heeft wp-cli export. Zet je vermeldingen in een schoon CSV- of JSON-formaat.

Fase 2: De nieuwe gegevenslaag opzetten (Week 2-3) Importeer in PostgreSQL met juist schemaontwerp. Zet Typesense op en synchroniseer je gegevens. Verifieer zoekingskwaliteit en queryprestatie.

Fase 3: De nieuwe frontend bouwen (Week 3-8) Herbouw zoeken, filtering, vermeldingsdetailpagina's en categoriepagina's tegen de nieuwe backend. Dit is waar Next.js of Astro schittert -- je kunt je bestaand design herhalen terwijl je de gegevensarchitectuur onderin volledig verandert.

Fase 4: Houd de CMS voor waar het goed in is (Voortdurend) Gebruik je CMS voor homepageinhoud, blogberichten, helponderwerpen en redactionele inhoud. Laat de database vermeldingen afhandelen. Ze bestaan friedevol naast elkaar.

Fase 5: Omleiden en lanceren (Week 8-10) Stel 301-omleidingen van oude URL's in, verifieer met Google Search Console, en controleer. Als je URL-structuur hetzelfde blijft (wat het zou moeten), behoud je je SEO-waarde.

Veelgestelde vragen

Kan Webflow daadwerkelijk een grote directorywebsite afhandelen? Webflow werkt goed voor directories onder 5.000 vermeldingen. Tussen 5K en 10K voel je de prestatiesdip op bouwprocessen en paginabeladingen. Bij 10.000 raakt je de harde limiet. Als je directory klein blijft en je waardeert Webflows visuele designtools, dan is het oké. Als je groei verwacht, begin met een andere architectuur.

Wat is de goedkoopste manier om een directory met 10.000+ vermeldingen te bouwen? WordPress met Directorist op kwaliteitsgemanaged hosting (zoals Cloudways of SpinupWP) kost ongeveer $30-50/maand en kan 10K-50K vermeldingen aan met juiste caching en optimalisatie. Het is het goedkoopste pad. De afweging is voortdurende onderhoudsproblemen, pluginconflicten en een zoekervaring die oké is in plaats van geweldig.

Is Supabase goed genoeg voor een directorydatabase? Absoluut. Supabase draait PostgreSQL met PostGIS-ondersteuning, Row Level Security, en real-time subscripties. Hun Pro-plan op $25/maand handelt honderdduizenden rijen af zonder problemen. Voor de meeste directoryprojecten onder 500K vermeldingen is het de beste waar voor je geld. Je krijgt een juiste relationele database met een aardig admin-UI en API-laag ingebouwd.

Hoe handel ik zoeken en filtering af voor een grote directory? Gebruik je primaire database niet voor zoeken. Synchroniseer je vermeldingen naar Typesense, Meilisearch of Algolia. Deze services zijn speciaal gemaakt voor instant, facetgericht, spelfouttolerante zoeken. Typesense Cloud begint op $29,50/maand en handelt tot 500K records af. De zoekervaring zal dramatisch beter zijn dan wat een CMS natively verleent.

Zou ik een static site generator of server-side rendering voor een directory gebruiken? Voor vermeldingsdetailpagina's, gebruik staticgeneratie met ISR (Incremental Static Regeneration) -- pagina's bouwen op eerste bezoek en cachen aan de rand. Voor zoek- en filterpagina's, gebruik server-side rendering zodat resultaten altijd vers zijn. Next.js App Router ondersteunt beide patronen in hetzelfde project. Astro met server islands is een ander sterk alternatief als je directory meer read-heavy is.

Hoe importeer ik 10.000+ vermeldingen in mijn directory? Bouw een importpipeline, geen handmatig proces. Schrijf een script dat je CSV/JSON-bron leest, elk record valideert, dubbels tegen bestaande entries wegfilters, en batchgewijze in je database invoegt. PostgreSQL's COPY commando of Supabase's bulk insert API kunnen 10K records in seconden afhandelen. Activeer dan een synchronisatie naar je zoekenindex. Ik heb gezien dat mensen dit via een CMS admin-UI proberen te doen -- niet doen. Het zal eeuwig duren en waarschijnlijk time-out.

Wat zit er voor SEO in directorywebsites met duizenden pagina's? Directory-SEO vereist juiste XML-sitemaps (opgesplitst in chunks van max 50K URL's per sitemapbestand), unieke metabeschrijvingen per vermelding, gestructureerde gegevens (LocalBusiness- of Product-schema), en interne linking tussen categorieën en vermeldingen. De headless-benadering helpt hier daadwerkelijk omdat je volledige controle hebt over elke metatag en schemamarkering. Een CMS beperkt vaak wat je per-pagina op schaal kunt aanpassen.

Wanneer heeft het zin om volledig custom te gaan in plaats van headless? Volledig custom (alles van nul af aan bouwen inclusief de CMS/admin-laag) heeft zin wanneer je voorbij 100K vermeldingen bent, complexe matchingalgoritmen nodig hebt (zoals een tweetalig marketplace), real-time datafeeds vereist, of unieke bedrijfslogica hebt die geen bestaande tool handelt. Eronder geeft een headless-architectuur met een juiste database je 90% van het voordeel op 20% van de kosten. De meeste directoryprojecten die we zien hebben geen volledig custom nodig -- ze hebben een goed gestructureerde headless build nodig.