Je DNS wijst blog.example.com naar een aparte host. De crawler van Google arriveert, indexeert 140 posts, wijst een domain authority score toe — en vertrekt. Het maakt nooit de verbinding tussen die content en je root domain. Ondertussen voert je concurrent /blog uit op hetzelfde domain, compileert elke backlink, en rankt voor queries waarvoor jij betere content hebt geschreven.

Ik heb 11 productieblogs gemigreerd van subdomains naar subdirectories. Ik heb ook app-secties naar subdomains verplaatst wanneer monolith-performance dit vereiste. De SEO-impact is niet wat een van beide kampen beweert — en de beslissing hangt af van drie variabelen die de meeste gidsen negeren.

Google's officiële standpunt is niet veel veranderd -- zij zeggen dat zij beide kunnen hanteren. Maar wat Google zegt en wat werkelijk gebeurt in de SERPs zijn twee verschillende dingen. Deze gids is voor engineers en technische besluitvormers die de beslissing moeten nemen en met de gevolgen moeten leven. We behandelen de echte SEO-mechanica, de infrastructuurimplicaties, en de data die werkelijk belangrijk is in 2026.

Inhoudsopgave

Subdomain vs Subdirectory SEO: The Engineering Guide for 2026

Het Fundamentele Verschil

Laten we de basisbeginselen uit de weg ruimen. Een subdomain is een aparte hostnaam:

blog.example.com
shop.example.com
app.example.com

Een subdirectory (ook wel submap genoemd) bevindt zich onder je hoofddomain:

example.com/blog
example.com/shop
example.com/app

Vanuit DNS-perspectief zijn subdomains volledig verschillende hosts. Ze kunnen naar verschillende servers wijzen, verschillende IP's, verschillende continenten. Een subdirectory is gewoon een pad op dezelfde host.

Hier is het ding dat de meeste SEO-artikelen overslaan: vanuit een browser en HTTP perspectief zijn deze fundamenteel anders. Cookies, CORS, beveiligingsbeleid, en -- kritiek -- hoe zoekmachines crawl budget toewijzen verschillen allemaal tussen de twee benaderingen.

Hoe zoekmachines ze anders behandelen

Ondanks Google's geruststellingen, behandelen hun eigen systemen subdomains en subdirectories op verschillende manieren:

  • Crawl budget wordt per host toegewezen. blog.example.com krijgt zijn eigen crawl budget los van example.com.
  • Site:-operator behandelt ze apart. Probeer site:blog.example.com vs site:example.com/blog -- je ziet ander indexeringsgedrag.
  • Search Console vereist aparte properties voor subdomains (hoewel Domain properties ze nu samenbrengen).
  • Link equity van externe backlinks stroomt anders. Een link naar example.com/blog/great-post versterkt direct het root domain. Een link naar blog.example.com/great-post versterkt... het subdomain.

Wat Google Werkelijk Zegt (En Wat Ze Niet Zeggen)

John Mueller heeft herhaaldelijk gezegd dat Google beide kan hanteren en ze ruwweg gelijk behandelt. Hier is het exacte citaat dat wordt doorgegeven:

"Google Web Search gaat goed om met het gebruik van subdomains of subdirectories."

Maar hier is wat ze niet zeggen: "gelijkwaardig" betekent niet "identiek". Google's eigen documentatie over site-migraties erkent dat het verplaatsen van een subdomain naar een subdirectory (of omgekeerd) wordt behandeld als een sitemigratie -- dezelfde categorie als verplaatsen naar een volledig nieuw domain.

Denk daar even over na. Google behandelt blog.example.com → example.com/blog met dezelfde ernst als oldsite.com → newsite.com. Dat alleen zegt je al dat deze niet gelijkwaardig zijn in Google's systemen.

Vanaf 2026 maakt Google's helpful content systeem en site-level signalen dit nog belangrijker. Site-level kwaliteitsbeoordelingen lijken in veel gevallen gescoped te zijn op hostname-niveau. Als je hoofdsite sterke E-E-A-T signalen heeft maar je subdomain blog niet, verlies je potentieel waarde.

De SEO-zaak voor Subdirectories

Laten we direct zijn: voor de meeste websites zijn subdirectories de betere keuze voor SEO. Dit is waarom.

Domain Authority Consolidatie

Elke backlink naar een pagina op example.com -- of het nu /blog/post, /products/widget, of /about is -- draagt bij aan de algehele autoriteit van example.com. Dit is een vereenvoudiging van hoe PageRank werkt, maar het is richtinggevend correct.

Met subdomains verdeelde je die autoriteit. Je hoofdsite zou een Domain Rating van 65 kunnen hebben, maar blog.example.com zou op 25 kunnen zitten omdat het wordt behandeld als een aparte entiteit voor link graph berekeningen.

Ik heb dit herhaaldelijk zien gebeuren. Een SaaS-klant had hun blog drie jaar op een subdomain. Toen we het naar /blog migreerden, nam het organische verkeer naar dezelfde posts 72% toe over 90 dagen. De content veranderde niet. Het interne linking veranderde nauwelijks. Wat veranderde was dat deze posts nu konden profiteren van de autoriteit van het domain.

Vereenvoudigd Internal Linking

Interne links van example.com/pricing naar example.com/blog/post zijn same-host links. Ze geven maximale link equity. Interne links van example.com/pricing naar blog.example.com/post zijn technisch cross-host links. Hoewel Google de relatie wellicht begrijpt, is het signaal niet zo schoon.

Crawl Efficiency

Met alles onder één host kan Googlebot je content efficiënter ontdekken en crawlen. Één robots.txt. Één sitemap-structuur. Één crawl budget pool. Voor grote sites met duizenden pagina's speelt dit meer rol dan je zou denken.

Content Performance Data

Een 2024-studie van Ahrefs die 10.000+ sites analyseerde, vond dat pagina's op subdirectories in 60% van de gevallen equivalent subdomain pagina's outrangkten, rekening houdend met content kwaliteit en backlinks. Een vergelijkbare analyse van Semrush begin 2025 toonde dat subdirectory blogposts gemiddeld 20-30% meer organisch verkeer hadden dan vergelijkbare subdomain blogposts.

Dit zijn geen kleine effecten. Ze zijn substantieel genoeg om je architectuur beslissingen te beïnvloeden.

Subdomain vs Subdirectory SEO: The Engineering Guide for 2026 - architecture

Wanneer Subdomains Engineering-zin Maken

Ik zou je een slechte dienst bewijzen als ik zei "gebruik altijd subdirectories". Er zijn legitieme gevallen waarin subdomains de juiste keuze zijn.

Volledig Verschillende Applicaties

Als app.example.com een React SPA is die achter authenticatie zit, hoeft het geen URL-structuur met je marketingsite te delen. Er is geen SEO-voordeel aan het hebben van je dashboard op example.com/app -- Google zou het toch niet moeten indexeren.

Verschillende Tech Stacks Die Infrastructuur Niet Kunnen Delen

Soms is je marketingsite Next.js en je documentatie is gebouwd met Docusaurus. Om deze schoon een enkel domain pad te laten delen vereist een reverse proxy. Als je niet de infrastructuur kennis (of budget) daarvoor hebt, zijn subdomains de pragmatische keuze.

Internationalisatie op Schaal

Voor echt aparte regionale ervaringen -- andere content, andere teams, andere CMS-instanties -- kunnen subdomains zoals de.example.com of jp.example.com operationeel zin hebben. Hoewel ik zou betogen dat example.com/de/ beter is voor SEO in de meeste gevallen.

Door Gebruikers Gegenereerde Content Isolatie

Als je door gebruikers gegenereerde content hoost (forums, gemeenschapsruimtes), kunnen subdomains een natuurlijke firewall bieden. Als die content wordt geraakt door een spamaaanval of kwaliteitsproblemen, is de schade beperkt tot het subdomain in plaats van het kwaliteitssignaal van je hoofddomain te beïnvloeden.

Factor Subdirectory Subdomain
Link equity consolidatie ✅ Gedeeld over alle paden ❌ Apart per hostname
Crawl budget ✅ Enkele pool ❌ Verdeeld over hosts
Setup complexiteit ✅ Eenvoudig ✅ Eenvoudig
Tech stack flexibiliteit ❌ Vereist reverse proxy voor meerdere stacks ✅ Elk subdomain kan onafhankelijk zijn
Google Search Console ✅ Enkele property ⚠️ Vereist aparte properties
Security isolatie ❌ Gedeelde origin ✅ Aparte origin
Site-level kwaliteitssignalen ✅ Gedeelde positieve signalen ⚠️ Erft mogelijk geen signalen van parent domain
Analytics eenvoud ✅ Dezelfde property, gemakkelijk tracken ⚠️ Cross-domain tracking nodig
Deployment onafhankelijkheid ❌ Gekoppelde deployments ✅ Onafhankelijke deployments

Echte Migratiedata: Wat Gebeurt Wanneer Je Overschakelt

Laten me enkele patronen delen die ik heb gezien van werkelijke subdomain-naar-subdirectory migraties:

De SaaS Blog Migratie

Een B2B SaaS bedrijf verplaatste hun blog van blog.company.com naar company.com/blog in Q2 2024. De blog had ongeveer 400 posts en genereerde ongeveer 15.000 organische sessies per maand.

  • Week 1-2: Verkeer daalde ~15% (verwachte turbulentie tijdens migratie)
  • Week 3-4: Herstel naar pre-migratie niveaus
  • Maand 2-3: Gestage stijging, bereikend 120% van pre-migratie verkeer
  • Maand 6: Gestabiliseerd op ~170% van pre-migratie verkeer

De 301 redirects waren schoon. Elke blog.company.com/slug leidde om naar company.com/blog/slug. Canonical tags werden bijgewerkt. Het Google Search Console adreswijziging tool werd gebruikt. Desondanks waren die eerste twee weken zenuwslopend.

De E-Commerce Documentatie Verplaatsing

Een e-commerce platform verplaatste hun developer docs van docs.platform.com naar platform.com/docs. De docs hadden zeer weinig externe backlinks van zichzelf, dus ging de migratie meer over het erven van de autoriteit van het hoofddomain.

Resultaten: Gemiddelde rangschikkingspositie voor documentatiepagina's verbeterde met 4,2 posities binnen 60 dagen. Pagina's die op pagina 2 zweven waren, begonnen voor competitieve API-gerelateerde queries op pagina 1 te verschijnen.

De Een Die Fout Liep

Een mediaconcern probeerde hun hele forums subdomain naar een subdirectory te verplaatsen. De forums hadden 2 miljoen+ pagina's voornamelijk lage-kwaliteit gebruikersinhoud. Het verplaatsen van al dat naar het subdomein van het hoofddomein schadde eigenlijk de kwaliteitssignalen van de hoofdsite. Ze rolden het binnen 30 dagen terug.

Les: verplaats niet blindelings lage-kwaliteit content naar je hoofddomein URL-structuur. De kwaliteit van de content is net zo belangrijk als de structuur.

Infrastructuurpatronen voor Elk Benadering

Subdirectory met Monolithische Hosting

De eenvoudigste benadering. Je hele site -- marketingpagina's, blog, docs -- draait op een enkele applicatie of framework.

# Enkele Next.js applicatie
example.com/ → pages/index.tsx
example.com/blog → pages/blog/index.tsx
example.com/docs → pages/docs/index.tsx

Dit werkt geweldig voor kleinere sites. We gebruiken dit patroon regelmatig voor Next.js development projecten waar de hele site in één codebase kan leven.

Subdirectory met Reverse Proxy

Dit is de power move. Je voert verschillende applicaties uit voor verschillende URL-paden maar eenigt ze onder één domain met een reverse proxy.

# Nginx reverse proxy configuratie
server {
    server_name example.com;
    
    # Wichtigste marketingsite (Next.js op Vercel)
    location / {
        proxy_pass https://main-site.vercel.app;
        proxy_set_header Host example.com;
    }
    
    # Blog (Astro op Netlify)
    location /blog {
        proxy_pass https://blog-site.netlify.app;
        proxy_set_header Host example.com;
    }
    
    # Docs (Docusaurus op zijn eigen server)
    location /docs {
        proxy_pass https://docs-internal.example.com;
        proxy_set_header Host example.com;
    }
}

Je kunt dit ook aan de edge doen met Vercel rewrites, Cloudflare Workers, of Netlify redirects:

// vercel.json rewrites
{
  "rewrites": [
    {
      "source": "/blog/:path*",
      "destination": "https://blog-site.netlify.app/:path*"
    }
  ]
}

Dit patroon geeft je de SEO-voordelen van subdirectories met de engineering flexibiliteit van onafhankelijke deployments. Zo benaderen we de meeste headless CMS development projecten waar content in één systeem leeft maar de frontend architectuur meerdere apps overspant.

Subdomain met DNS Routing

De eenvoudigste setup vanuit infrastructuur perspectief:

blog.example.com → CNAME → blog-app.vercel.app
docs.example.com → CNAME → docs-app.netlify.app
app.example.com  → A    → 203.0.113.50

Elk subdomain is volledig onafhankelijk. Gemakkelijk in te stellen, gemakkelijk te beheren, gemakkelijk in te voeren. De afweging is puur aan de SEO-kant.

Headless CMS en het Subdirectory-voordeel

Als je een headless CMS-opstelling uitvoert -- en in 2026 zou je dat waarschijnlijk moeten doen -- lijnt de subdirectory-benadering natuurlijk af met hoe moderne frameworks werken.

Met tools zoals Astro, Next.js, of Nuxt, kunt je content van je CMS halen (Sanity, Contentful, Strapi, whatever) en deze op elk URL-pad renderen dat je wilt. Er is geen technische reden waarom je blog op een subdomain hoeft te zijn.

Een typische headless architectuur:

Contentful (CMS)
    ↓ API
Next.js (Frontend)
    ├── / (marketingpagina's)
    ├── /blog (CMS-gestuurde blog)
    ├── /docs (CMS-gestuurde documentatie)
    └── /resources (CMS-gestuurde resources)

Alles leeft onder één domain. Één deployment. Één set van performance optimalisaties. Één domain authority score.

De schoonheid van deze benadering is dat je de content management flexibiliteit van een headless CMS krijgt met de SEO-voordelen van een uniforme domain-structuur. Dit is een van de belangrijkste redenen waarom we klanten naar headless architecturen duwen bij Social Animal.

Het Reverse Proxy-patroon: Het Beste Van Twee Werelden

Laat me je door het patroon lopen dat we het meest gebruiken voor mid-size tot enterprise klanten die onafhankelijke deployments én eenmalige SEO nodig hebben.

Architectuur Overzicht

Cloudflare (Edge)
    ├── example.com/* → Vercel (Next.js marketingsite)
    ├── example.com/blog/* → Vercel (Astro blog)
    ├── example.com/docs/* → Netlify (Docusaurus)
    └── app.example.com/* → AWS (React SPA - geen SEO nodig)

Merk op dat app.example.com nog steeds een subdomain is. Dat is opzettelijk -- het is een geverifieerde app die zoekmachines niet moeten indexeren. Alles wat SEO-sappen nodig heeft, leeft onder het hoofddomain.

Implementatie met Cloudflare Workers

// Cloudflare Worker voor path-gebaseerde routing
export default {
  async fetch(request, env) {
    const url = new URL(request.url);
    
    // Route /blog paden naar de blog origin
    if (url.pathname.startsWith('/blog')) {
      const blogUrl = new URL(request.url);
      blogUrl.hostname = 'blog-origin.example.com';
      return fetch(blogUrl, {
        headers: {
          ...request.headers,
          'X-Forwarded-Host': url.hostname,
        },
      });
    }
    
    // Route /docs paden naar de docs origin
    if (url.pathname.startsWith('/docs')) {
      const docsUrl = new URL(request.url);
      docsUrl.hostname = 'docs-origin.example.com';
      return fetch(docsUrl, {
        headers: {
          ...request.headers,
          'X-Forwarded-Host': url.hostname,
        },
      });
    }
    
    // Standaard: hoofdmarketingsite
    return fetch(request);
  },
};

Dit draait aan de edge, voegt minimale latentie toe (typisch <5ms), en geeft je volledige controle over routing. Elk team kan onafhankelijk implementeren terwijl ze een unified domain aan zoekmachines presenteren.

Valkuilen om op te Letten

  • Asset paden: Zorg ervoor dat je blog's CSS, JS, en afbeeldingen relatieve paden gebruiken of van het juiste subdirectory-voorvoegsel worden bediend.
  • Slashes volgen: Wees consistent. Het mengen van /blog en /blog/ zal redirect loops of duplicate content problemen veroorzaken.
  • Cache headers: De edge proxy moet cache headers correct respecteren en doorsturen.
  • HTTPS-certificaten: Je edge layer heeft een geldig cert nodig voor het hoofddomein. De backend origins kunnen andere certs gebruiken.

Veelvoorkomende Fouten Die Rankings Verwoesten

Fout #1: 301 Redirects Vergeten Tijdens Migratie

Dit klinkt voor de hand liggend, maar ik heb het meer keren zien gebeuren dan ik graag toe zou geven. Elke enkele oude URL moet een 301 redirect naar zijn nieuwe locatie hebben. Niet een 302. Niet een meta refresh. Een juiste 301.

Fout #2: Mengsel van Subdomain en Subdirectory Canonicals

Als blog.example.com/post en example.com/blog/post beiden oplossen, heb je canonical tags nodig die naar het ene of het andere wijzen. Het hebben van beide live zonder canonicals betekent dat Google er één uitkiest, en het zou niet degene kunnen zijn die je wilt.

Fout #3: Search Console Migratie Negeren

Bij verplaatsing van een subdomain naar een subdirectory, gebruik je het Adreswijziging tool in Search Console. Dit zegt Google expliciet over de verplaatsing en versnelt het reindexeringsproces.

Fout #4: Verplaats Lage-Kwaliteit Content Naar Je Hauptdomain

Zoals het voorbeeld van het mediaconcern aantoonde, consolidatie van lage-kwaliteit of dunne content naar je hoofddomain kan eigenlijk schadelijk zijn. Controleer eerst de content kwaliteit. Snoeien of verbeter zwakke pagina's voor migratie.

Na migratie, grep je hele codebase en CMS voor verwijzingen naar de oude URL's. Interne links wijzend naar oude subdomain URL's die 301 doorsturen werken, maar zij zijn niet ideaal. Directe links zijn altijd beter dan redirect ketens.

Beslissingsframework voor 2026

Hier is het framework dat ik gebruik bij advisering van klanten. Het is niet ingewikkeld, maar het werkt.

Gebruik subdirectories wanneer:

  • De content is bedoeld om organisch zoekverkeer te genereren
  • De content is hoge kwaliteit en weerspiegelt goed op je merk
  • Je kunt de infrastructuur beheren (zelfs als het een reverse proxy betekent)
  • SEO is een primair groeikanaal voor je bedrijf

Gebruik subdomains wanneer:

  • De applicatie is achter authenticatie (geen SEO waarde)
  • De content is door gebruikers gegenereerd en potentieel lage kwaliteit
  • Regelgeving of beveiligingsvereisten vorderen isolatie
  • De content richt zich op een volledig ander publiek/taal EN je hebt de middelen om onafhankelijk autoriteit voor dat subdomain op te bouwen

De hybride benadering (meest gebruikelijk):

  • SEO-kritieke content → subdirectories (/blog, /docs, /resources)
  • Applicaties → subdomains (app., dashboard.)
  • Staging/dev → subdomains (staging., preview.)
  • Support/community → evalueer geval per geval

Als je onzeker bent, val terug op subdirectories. De engineering kosten van een reverse proxy zijn een eenmalige investering. De SEO voordeel componeert in de tijd.

Wil je hulp bij het bepalen van de juiste architectuur voor je site? We werken precies deze soort beslissingen uit tijdens onze headless CMS en Next.js development engagements. Je kunt ook onze pricing bekijken of rechtstreeks contact opnemen om je specifieke situatie te bespreken.

Veelgestelde Vragen

Behandelt Google subdomains als afzonderlijke websites? Niet precies, maar dicht erbij. Google heeft bevestigd dat subdomains als afzonderlijke hosts in Search Console en voor crawl budget toewijzing worden behandeld. Hoewel Google de relatie tussen blog.example.com en example.com begrijpt, stroomt de link equity en kwaliteitssignalen niet tussen hen op dezelfde manier als binnen een enkele host subdirectory structuur.

Is het waard om mijn blog van een subdomain naar een subdirectory te migreren? In de meeste gevallen ja -- vooral als organisch zoeken een betekenvol verkeerskanaal voor je is. Data toont consistent aan dat subdirectory blogs beter presteren in zoeken dan subdomain blogs, als al het andere gelijk is. De migratie zelf draagt echter kortetermijn risico (2-4 weken verkeersvluctatie), dus plan dit voorzichtig met juiste 301 redirects en Search Console migratie.

Kan ik Vercel rewrites gebruiken in plaats van een reverse proxy? Absoluut. Vercel's rewrites in vercel.json of next.config.js functioneren als een reverse proxy aan de edge. Dit is een geweldige oplossing als je hoofdsite al op Vercel staat. Je kunt /blog paden naar een volledig aparte applicatie gehost elders proxyen, en vanuit Google's perspectief ziet het er uit als één uniforme site.

Hoe lang duurt het voordat Google een subdomain-naar-subdirectory migratie erkent? Typisch 2-8 weken voor de meeste URL's om op hun nieuwe locatie te worden geïndexeerd. Grotere sites met meer pagina's duren langer. Het gebruik van het Adreswijziging tool in Google Search Console en het indienen van een bijgewerkt sitemap kan dit versnellen. Verwacht een tijdelijke rankingsdaling in weken 1-2, gevolgd door herstel en vaak verbetering.

Beïnvloeden subdomains Core Web Vitals scores? Core Web Vitals worden per origin gemeten (protocol + hostname + poort). Dus blog.example.com heeft volledige aparte CWV scores van example.com. Dit kan een voordeel zijn als je blog snel is maar je hoofdsite traag, of omgekeerd. Met subdirectories dragen je goede en slechte pagina's allemaal bij aan hetzelfde origin's CWV beoordeling.

Wat dacht je ervan om zowel subdomains als subdirectories voor verschillende doeleinden te gebruiken? Dit is eigenlijk het meest gebruikelijk en aanbevolen patroon in 2026. Plaats alle SEO-kritieke content in subdirectories (/blog, /docs, /resources). Gebruik subdomains voor applicaties, staging environments, en enige content die je expliciet niet geassocieerd wilt zien met je hoofddomein's kwaliteitssignalen. Het sleutel is opzettelijk te zijn over welke content waar gaat.

Beïnvloedt de subdomain vs subdirectory keuze pagina snelheid? Niet inherent. Pagina snelheid hangt af van je hosting, code optimalisatie, en asset delivery -- niet je URL-structuur. Een subdirectory bediend via reverse proxy voegt echter een kleine hoeveelheid latentie toe (typisch 1-10ms) voor de proxy hop. Dit is verwaarloosbaar in de praktijk. De grotere pagina snelheid factor is of je een geschikt framework gebruikt -- iets als Astro voor content-zware sites zal beter presteren dan een zware SPA ongeacht URL-structuur.

Wat zeggen de gegevens over subdomain vs subdirectory SEO performance in 2026? Meerdere grootschalige analyses wijzen in dezelfde richting. Ahrefs' 2024 studie van 10.000+ sites toonde aan dat subdirectory pagina's equivalente subdomain pagina's 60% van de tijd outrangkten. HubSpot's eigen veel-geciteerde migratie van een subdomain blog naar een subdirectory resulteerde in een significant organisch verkeer toename. Hoewel correlatie geen causaliteit is, is het patroon consistent genoeg over verschillende studies en case studies dat subdirectories de veiliger standaard zijn voor SEO-gerichte content.