Ik heb blogs van subdomains naar subdirectories gemigreerd meer keren dan ik kan tellen. Ik heb ook het omgekeerde gedaan -- hele app-secties naar subdomains verplaatst wanneer de architectuur dat eiste. En hier is wat ik heb geleerd na jaren van het zien van rankings verschuiven: het antwoord is niet zo eenvoudig als beide kampen je willen doen geloven.

Googleles officiële standpunt is niet veel veranderd -- ze zeggen dat ze 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 call moeten maken en met de gevolgen moeten leven. We behandelen de echte SEO-mechanica, de infrastructuurimplicaties, en de data die werkelijk telt in 2026.

Inhoudsopgave

Subdomain vs Subdirectory SEO: The Engineering Guide for 2026

Het Fundamentele Verschil

Laten we eerst de basis uit de weg ruimen. Een subdomain is een aparte hostname:

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

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

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

Vanuit DNS-perspectief zijn subdomains geheel 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 voorbijgaan: vanuit browser en HTTP perspectief zijn deze fundamenteel verschillend. Cookies, CORS, beveiligingsbeleid, en -- kritiek -- hoe zoekmachines crawl-budget toewijzen, verschillen allemaal tussen de twee benaderingen.

Hoe Zoekmachines Ze Verschillend Behandelen

Ondanks Googles geruststellingen, behandelen hun eigen systemen subdomains en subdirectories op verschillende manieren in meerdere meetbare opzichten:

  • Crawl-budget wordt per host toegewezen. blog.example.com krijgt zijn eigen crawl-budget apart 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 aggregeren).
  • Link equity van externe backlinks stroomt anders. Een link naar example.com/blog/great-post versterkt direct het rootdomein. Een link naar blog.example.com/great-post versterkt... het subdomain.

Wat Google Werkelijk Zegt (En Wat Niet)

John Mueller heeft meerdere keren gezegd dat Google beide kan hanteren en ze ruwweg gelijk behandelt. Hier is het exacte citaat dat rondgaat:

"Google Web Search is oké met het gebruik van subdomains of subdirectories."

Maar hier is wat ze niet zeggen: "gelijk" betekent niet "identiek." Googles eigen documentatie over site-verplaatsingen erkent dat het verplaatsen van een subdomain naar een subdirectory (of vice versa) wordt behandeld als een site-migratie -- dezelfde categorie als het verplaatsen naar een geheel nieuw domein.

Denk daar een seconde over na. Google behandelt blog.example.com → example.com/blog met dezelfde ernst als oldsite.com → newsite.com. Dat alleen al vertelt je dat deze niet equivalent zijn in Googles systemen.

Eind 2025-2026 maakt Googles nuttige content-systeem en site-level signalen dit nog belangrijker. Site-level kwaliteitsevaluaties lijken in veel gevallen te worden bepaald 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

Laat me direct zijn: voor de meeste websites zijn subdirectories de betere keuze voor SEO. Hier is waarom.

Domain Authority Consolidatie

Elke backlink die wijst naar een willekeurige pagina op example.com -- of het nu /blog/post, /products/widget, of /about is -- draagt bij aan de totale autoriteit van example.com. Dit is een vereenvoudiging van hoe PageRank werkt, maar het klopt richtingsgewijs.

Met subdomains splits je die autoriteit op. Je hoofdsite heeft misschien een Domain Rating van 65, maar blog.example.com zit misschien op 25 omdat het als een aparte entiteit wordt behandeld 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 met 72% toe in 90 dagen. De content veranderde niet. De interne linking veranderde nauwelijks. Wat veranderde was dat deze posts nu konden profiteren van de autoriteit van het bestaande domein.

Vereenvoudigde Interne Linking

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

Crawl-efficiëntie

Metalles onder één host kunnen Googlebot uw content efficiënter ontdekken en crawlen. Één robots.txt. Één sitemap structuur. Één crawl-budget pool. Voor grote sites met duizenden pagina's, maakt dit meer uit dan je zou denken.

Content Performance Data

Een 2024-studie door Ahrefs die 10.000+ sites analyseerde, ontdekte dat pagina's op subdirectories 60% van de tijd vergelijkbare subdomainpagina's rankte, controleren voor content kwaliteit en backlinks. Een soortgelijke analyse door Semrush begin 2025 toonde aan dat subdirectory blogposts gemiddeld 20-30% meer organisch verkeer hadden dan vergelijkbare subdomainblogposts.

Dit zijn geen kleine effecten. Ze zijn groot genoeg om je architectuurbeslissingen 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 zou zeggen "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 staat, hoeft het geen URL-structuur met je marketing site te delen. Er is geen SEO-voordeel aan het hebben van je dashboard op example.com/app -- Google mag het toch niet indexeren.

Verschillende Tech Stacks Die Geen Infrastructuur Kunnen Delen

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

Internationalisatie op Schaal

Voor werkelijk aparte regionale ervaringen -- verschillende content, verschillende teams, verschillende CMS-instanties -- kunnen subdomains zoals de.example.com of jp.example.com operationeel zin maken. Hoewel ik nog steeds 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 host (forums, communityruimten), het plaatsen ervan op een subdomain biedt een natuurlijke firewall. Als die content wordt geraakt door een spam-aanval of kwaliteitsproblemen, is de schade beperkt tot het subdomain in plaats van het kwaliteitssignaal van je hoofddomein te beïnvloeden.

Factor Subdirectory Subdomain
Link equity consolidatie ✅ Gedeeld over alle paden ❌ Apart per hostname
Crawl-budget ✅ Single pool ❌ Split over hosts
Setup complexiteit ✅ Eenvoudig ✅ Eenvoudig
Tech stack flexibiliteit ❌ Vereist reverse proxy voor meerdere stacks ✅ Elk subdomain kan onafhankelijk zijn
Google Search Console ✅ Single property ⚠️ Vereist aparte properties
Beveiligingsisolatie ❌ Gedeelde origin ✅ Aparte origin
Site-level kwaliteitssignalen ✅ Gedeelde positieve signalen ⚠️ May not inherit parent domain signals
Analytics eenvoud ✅ Zelfde property, makkelijk tracken ⚠️ Cross-domain tracking nodig
Deployment onafhankelijkheid ❌ Gekoppelde deployments ✅ Onafhankelijke deployments

Echte Migratiedata: Wat Gebeurt Er Wanneer Je Schakelt

Laat me een aantal patronen delen die ik van werkelijke subdomain-naar-subdirectory migraties heb gezien:

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 geneerde 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: Steady climb, bereikt 120% van pre-migratie verkeer
  • Maand 6: Gestabiliseerd op ~170% van pre-migratie verkeer

De 301 redirects waren schoon. Elke blog.company.com/slug herleidde naar company.com/blog/slug. Canonical tags werden bijgewerkt. De Google Search Console change of address tool werd gebruikt. Toch waren die eerste twee weken zenuwachtig.

De E-Commerce Documentatie Move

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

Resultaten: Gemiddelde rangschikking voor documentatiepagina's verbeterd met 4,2 posities binnen 60 dagen. Pagina's die op pagina 2 hebben gehangen, begonnen op pagina 1 voor concurrerende API-gerelateerde queries te verschijnen.

De Één Die Fout Liep

Een mediabedrijf probeerde hun hele forums-subdomain naar een subdirectory te verplaatsen. De forums hadden 2 miljoen+ pagina's met meestal laagwaardige door gebruikers gegenereerde content. Het verplaatsen van al dat naar het hoofddomein URL-structuur deedt eigenlijk pijn aan het kwaliteitssignaal van de hoofdsite. Ze rollen het terug binnen 30 dagen.

Les: verplaats niet blindelings laagwaardige content naar je maindomein's URL-structuur. De kwaliteit van de content is even belangrijk als de structuur.

Infrastructuurpatronen voor Elk Approach

Subdirectory met Monolithische Hosting

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

# Single Next.js application
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 veel voor Next.js development projecten waarbij de hele site in één codebase kan wonen.

Subdirectory met Reverse Proxy

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

# Nginx reverse proxy configuration
server {
    server_name example.com;
    
    # Main marketing site (Next.js on Vercel)
    location / {
        proxy_pass https://main-site.vercel.app;
        proxy_set_header Host example.com;
    }
    
    # Blog (Astro on Netlify)
    location /blog {
        proxy_pass https://blog-site.netlify.app;
        proxy_set_header Host example.com;
    }
    
    # Docs (Docusaurus on its own server)
    location /docs {
        proxy_pass https://docs-internal.example.com;
        proxy_set_header Host example.com;
    }
}

Je kunt dit ook doen aan de edge 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. Dit is hoe we het meeste headless CMS development projecten benaderen waarbij content in één systeem leeft maar de frontend-architectuur verschillende apps omvat.

Subdomain met DNS Routering

De eenvoudigste setup vanuit infrastructuurnicht-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. Makkelijk in te stellen, makkelijk te beheren, makkelijk in te implementeren. De trade-off is puur aan de SEO-kant.

Headless CMS en het Subdirectory Voordeel

Als je een headless CMS-setup voert -- en in 2026 zou je waarschijnlijk moeten -- sluit de subdirectory-benadering natuurlijk aan op hoe moderne frameworks werken.

Met tools zoals Astro, Next.js, of Nuxt, kun je content van je CMS (Sanity, Contentful, Strapi, je weet wel) ophalen en op elk URL-pad weergeven 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)
    ├── / (marketing pages)
    ├── /blog (CMS-driven blog)
    ├── /docs (CMS-driven documentation)
    └── /resources (CMS-driven resources)

Alles woont onder één domein. Één deployment. Één set van performance optimalisaties. Één domein autoriteits score.

Het mooie van deze benadering is dat je de content management flexibiliteit van een headless CMS krijgt met de SEO voordelen van een uniforme domeinstructuur. Het is een van de belangrijkste redenen waarom we clients naar headless architecturen pushen op Social Animal.

Het Reverse Proxy Patroon: Beide Krijgen

Laat me je door het patroon lopen dat we het meeste gebruiken voor mid-size tot enterprise-klanten die zowel onafhankelijke deployments als uniforme SEO nodig hebben.

Architectuur Overzicht

Cloudflare (Edge)
    ├── example.com/* → Vercel (Next.js marketing site)
    ├── example.com/blog/* → Vercel (Astro blog)
    ├── example.com/docs/* → Netlify (Docusaurus)
    └── app.example.com/* → AWS (React SPA - no SEO needed)

Merk op dat app.example.com nog steeds een subdomain is. Dat is opzettelijk -- het is een geverifieerde app die zoekmachines niet mag indexeren. Alles wat SEO sap nodig heeft, woont onder het hoofddomein.

Implementatie met Cloudflare Workers

// Cloudflare Worker for path-based routing
export default {
  async fetch(request, env) {
    const url = new URL(request.url);
    
    // Route /blog paths to the 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 paths to the 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,
        },
      });
    }
    
    // Default: main marketing site
    return fetch(request);
  },
};

Dit draait aan de edge, voegt minimale latentie toe (typisch <5ms), en geeft je volledige controle over routering. Elk team kan onafhankelijk implementeren terwijl je een uniforme domein aan zoekmachines presenteert.

Gotchas om Op Te Letten

  • Asset paden: Zorg ervoor dat de CSS, JS, en afbeeldingen van je blog relatieve paden gebruiken of worden bediend vanaf het juiste subdirectory-voorvoegsel.
  • Trailing slashes: Wees consequent. 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 voor het hoofddomein nodig. De backend-origins kunnen verschillende certs gebruiken.

Veelgemaakte Fouten Die Rankings Tanken

Fout #1: 301 Redirects Vergeten Tijdens Migratie

Dit klinkt voor de hand liggend, maar ik heb gezien dat het meer keren gebeurt dan ik graag zou willen. Elke enkele oude URL moet een 301-omleiding naar de nieuwe locatie hebben. Niet een 302. Niet een meta-vernieuwing. Een juiste 301.

Fout #2: Subdomain en Subdirectory Canonicals Mengen

Als blog.example.com/post en example.com/blog/post beide opgelost, heb je canonical tags nodig die naar een van beide wijzen. Als beide zonder canonicals live gaan, kiest Google er een, en het kan niet degene zijn die je wilt.

Fout #3: De Google Search Console Migratie Negeren

Wanneer je van een subdomain naar een subdirectory verplaatst, gebruik je het Change of Address tool in Search Console. Dit zegt Google expliciet over de move en versnelt het herindexeringsproces.

Fout #4: Laagwaardige Content Op Je Hoofddomein Verplaatsen

Zoals het voorbeeld van het mediabedrijf aantoonde, kan het consolideren van laagwaardige of dunne content op je hoofddomein eigenlijk schadelijk zijn. Controleer eerst de content kwaliteit. Verwijder of verbeter zwakke pagina's vóór migratie.

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

Besluitvormingsraamwerk voor 2026

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

Gebruik subdirectories wanneer:

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

Gebruik subdomains wanneer:

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

De hybride benadering (meest voorkomend):

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

Als je onzeker bent, standaard naar subdirectories. De engineering kosten van een reverse proxy zijn een eenmalige investering. Het SEO voordeel groeit in de loop der tijd.

Wil je hulp om de juiste architectuur voor je site uit te zoeken? We werken precies deze soort beslissingen door tijdens onze headless CMS en Next.js development engagements. Je kunt ook onze prijzen controleren of rechtstreeks bereiken om je specifieke situatie door te spreken.

FAQ

Behandelt Google subdomains als aparte websites?

Niet precies, maar bijna. Google heeft bevestigd dat subdomains als aparte hosts binnen 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 zoals ze doen binnen een single host's subdirectory structuur.

Is het waard mijn blog van een subdomain naar een subdirectory te migreren?

In de meeste gevallen, ja -- vooral als organisch zoeken een betekenisvol verkeer kanaal voor je is. Gegevens tonen consistent aan dat subdirectory blogs beter presteren in zoeken dan subdomain blogs, alles gelijk zijnde. De migratie zelf draagt echter korte termijn risico (2-4 weken verkeerfluctuatie), dus plan het zorgvuldig 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 proxyen naar een volledig aparte applicatie die ergens anders is hosted, en vanuit Googles perspectief ziet het er allemaal uit als een geünificeerde site.

Hoe lang duurt het voordat Google een subdomain-naar-subdirectory migratie herkent?

Typisch 2-8 weken voor de meeste URLs om op hun nieuwe locatie te worden hergeïndexeerd. Grotere sites met meer pagina's duren langer. Het gebruik van het Change of Address tool in Google Search Console en het indienen van een bijgewerkte sitemap kan dit versnellen. Verwacht een tijdelijk ranking dip 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 + port). Dus blog.example.com heeft volledig afzonderlijke CWV scores van example.com. Dit kan een voordeel zijn als je blog snel is maar je hoofdsite traag, of een nadeel als het omgekeerde waar is. Met subdirectories, dragen al je goede en slechte pagina's bij aan dezelfde origin CWV beoordeling.

Wat als ik zowel subdomains als subdirectories voor verschillende doeleinden gebruik?

Dit is eigenlijk het meest voorkomende en aanbevolen patroon in 2026. Zet alle SEO-kritieke content in subdirectories (/blog, /docs, /resources). Gebruik subdomains voor applicaties, staging omgevingen, en alle content die je expliciet niet wilt koppelen aan je maindomein's kwaliteitssignalen. De sleutel is opzettelijk zijn over welke content waar gaat.

Beïnvloedt de subdomain versus subdirectory keuze paginasnelheid?

Niet inherent. Paginasnelheid hangt af van je hosting, code optimalisatie, en asset delivery -- niet je URL structuur. Een subdirectory bediend door een reverse proxy voegt echter een kleine hoeveelheid latentie toe (typisch 1-10ms) voor de proxy hop. Dit is verwaarloosbaar in de praktijk. De grotere paginasnelheidsfactor is of je een passend framework gebruikt -- iets als Astro voor content-zware sites zal een zware SPA overtreffen ongeacht URL-structuur.

Wat zeggen de gegevens over subdomain versus subdirectory SEO prestaties in 2025-2026?

Meerdere grootschalige analyses wijzen in dezelfde richting. Ahrefs' 2024 studie van 10.000+ sites toonde subdirectory pagina's hebben equivalent subdomain pagina's 60% van de tijd ingeclassificeerd. HubSpots eigen wijd aangehaalde migratie van een subdomain blog naar een subdirectory resulteerde in een aanzienlijk organisch verkeer toename. Terwijl correlatie geen causaliteit is, is het patroon consistent genoeg over verschillende studies en case studies dat subdirectories de veiligere standaard zijn voor SEO-gefocuste content.