Serhii LypiiEen veel onderschat probleem in domein-migraties: staging-omgevingen die per ongeluk in Google’s index belanden. Onderzoek van Ahrefs en andere SEO-tooling laat zien dat een aanzienlijk deel van de subdomeinen die als staging. of dev. worden ingezet, ergens onbedoeld door Google geïndexeerd is. Soms jarenlang. En als je dan besluit om “echt” naar je hoofddomein te gaan, krijg je dubbele content, gespreide autoriteit en in het ergste geval een penalty.
Subdomein naar hoofddomein verhuizen klinkt eenvoudig (je verplaatst bestanden, je zet redirects), maar de SEO-laag is precair. Een paar gemiste stappen en je verliest maandenlange ranking. Niet om dramatisch te doen, maar omdat ik het in de praktijk regelmatig opruim.
In dit artikel beschrijf ik de werkwijze die ik aanhoud bij elke subdomein-naar-hoofddomein-migratie. De Search Console-instellingen, de redirect-map, canonical-fixes, robots.txt-opschoning en wat je controleert na de overstap.
Wanneer dit een goede stap is
Niet elke subdomein verdient een verhuizing. Een paar typische gevallen waarin het wel zin heeft.
Een blog op een subdomein (blog.bedrijf.nl) terwijl de rest op het hoofddomein staat. Google behandelt subdomeinen vaak als deels apart, waardoor je content op een eiland staat. Onderbrengen onder bedrijf.nl/blog/ consolideert de autoriteit.
Een aparte campagne-site die in de hoofdsite moet opgaan. campagne.bedrijf.nl verhuizen naar bedrijf.nl/campagne/ als de campagne een permanente plek krijgt.
Een oude staging-omgeving die per ongeluk live is geweest en die je nu netjes wilt afsluiten met redirects naar de echte productiepagina’s.
Wanneer het niet handig is: als het subdomein bewust een aparte entiteit is (bijvoorbeeld een aparte branding, ander land, of een productlijn met eigen logica). Dan is consolideren juist een verlies.
Stap 1: Inventarisatie en risicobepaling
Voor ik iets aanraak, breng ik in kaart wat er op het subdomein staat.
Wat ik bekijk:
- Welke pagina’s zijn er, en hoeveel
- Welke URLs ranken op welke zoekwoorden (via Search Console en/of Ahrefs)
- Hoeveel externe backlinks wijzen naar het subdomein
- Of er staging-restjes in de index zitten (via een
site:-zoekopdracht in Google) - Hoe de huidige robots.txt eruitziet, en of er een sitemap actief is
Vooral het aantal backlinks is bepalend voor het risico. Een subdomein met 100 externe backlinks verhuizen vraagt meer aandacht dan een subdomein met twee.
Stap 2: Search Console “Adreswijziging” instellen
Een onderschat hulpmiddel. Google biedt in Search Console een tool genaamd “Change of Address” (Adreswijziging). Daarmee geef je Google formeel door dat content van het ene domein naar het andere is verhuisd.
Belangrijke voorwaarde: de tool werkt alleen tussen geverifieerde properties, en alleen bij volledige domein-migraties (host naar host). Voor verhuizingen tussen een subdomein en een pad onder het hoofddomein werkt de Change of Address-tool niet altijd. Dan vertrouw je op de 301-redirects om Google het verhaal te vertellen.
Wat de tool wel doet als hij past:
- Versnelt de overdracht van autoriteit
- Geeft Google een duidelijk signaal dat de verhuizing definitief is
- Voorkomt verwarring over duplicate content
Wat hij niet doet:
- 301-redirects vervangen
- Externe backlinks updaten
De redirects blijven dus hoe dan ook nodig.
Stap 3: 301-redirect-map per URL
Het belangrijkste technische werk. Een 301-redirect vertelt browsers en zoekmachines: “Deze URL is permanent verhuisd naar daar.” Ranking en autoriteit volgen mee.
Wat ik maak: een spreadsheet met drie kolommen.
- Kolom A: oude subdomein-URL (
https://blog.bedrijf.nl/over-ons) - Kolom B: nieuwe hoofddomein-URL (
https://bedrijf.nl/blog/over-ons) - Kolom C: status na implementatie (200, 301, 404)
Per URL handmatig (of via crawl van de oude sitemap) bepalen wat de overeenkomende nieuwe URL wordt. Wat ik daarbij let:
- Een 1-op-1-match maken waar mogelijk (geen omleiding naar de homepage als de inhoud bestaat)
- Een 301-redirect (permanent), geen 302 (tijdelijk)
- Geen redirect-ketens (
/oud→/tussenstop→/nieuwis slecht voor SEO) - Geen redirect-loops
Implementatie kan op meerdere niveaus.
In de webserver-config (Nginx of Apache): de schoonste en snelste route. Vooral voor honderden URLs. Vraagt toegang tot de server-config.
In WordPress via een plugin zoals Redirection: makkelijk te beheren via een interface, geschikt voor kleinere aantallen URLs (tot een paar honderd).
In een .htaccess-bestand (op Apache): solide alternatief, vraagt geen plugin. Iets minder overzichtelijk bij veel regels.
Stap 4: Canonical-tags rechtzetten
Een veelvergeten stap. Op de oude subdomein-pagina’s stond een canonical-tag die naar zichzelf wees (bijvoorbeeld <link rel="canonical" href="https://blog.bedrijf.nl/post">). Op de nieuwe hoofddomein-pagina’s hoort die canonical naar de nieuwe URL te wijzen.
Wat ik controleer:
- Alle nieuwe pagina’s hebben een correcte canonical naar zichzelf op het hoofddomein
- Geen achtergebleven canonical naar het oude subdomein
- Geen kruislingse canonicals (twee pagina’s die naar elkaar wijzen)
Dit vergt vaak een korte aanpassing in het thema of in de SEO-plugin (Yoast, Rank Math). Bij een complete site-migratie wordt de canonical automatisch goed gezet, mits de plugin correct is geconfigureerd.
Stap 5: Robots.txt en sitemap opschonen
Twee bestanden die een eigen leven leiden.
Robots.txt op het subdomein. Na de verhuizing wil je daar in feite niets meer hebben dat Google verleidt om alsnog te crawlen. Mijn aanpak: laat de 301-redirects hun werk doen, en zet eventueel een Disallow: / in robots.txt op het oude subdomein nadat alle redirects een paar maanden zijn gerund. Direct disallowen verhindert dat Google de redirects ziet en zal de overdracht juist vertragen.
Robots.txt op het hoofddomein. Zorg dat de nieuwe URLs hier toegestaan zijn. Een achtergebleven Disallow: /blog/ uit de tijd dat het subdomein leefde is een veelvoorkomende fout.
Sitemap op het hoofddomein. Voeg de nieuwe URLs toe en dien de bijgewerkte sitemap in via Search Console. Verwijder de oude sitemap van het subdomein.
Voor de DNS-kant van de migratie zie DNS-overstap bij website-migratie. Voor het bredere migratie-draaiboek WordPress verhuizen naar andere hosting zonder downtime.
Stap 6: Noindex- en hreflang-checks
Twee specifieke valkuilen.
Noindex. Subdomeinen worden vaak gebruikt voor staging of testomgevingen, en die hebben standaard een noindex meta-tag. Bij de verhuizing wil je zeker zijn dat de nieuwe URLs op het hoofddomein géén noindex hebben. Een kleine vergissing in het thema of de SEO-plugin houdt de nieuwe pagina’s onzichtbaar voor Google.
Hreflang. Voor meertalige sites met taalvarianten op subdomeinen (en.bedrijf.nl, de.bedrijf.nl) is hreflang complex. Hreflang-aanduidingen moeten ofwel allemaal subdomeinen blijven, of allemaal mee verhuizen naar het hoofddomein. Een mismatch hier veroorzaakt rare ranking-effecten in andere talen.
Stap 7: Wat ik in de eerste weken monitor
De eerste 4 tot 8 weken na een subdomein-migratie controleer ik actief.
In Search Console:
- Crawl-statistieken voor zowel oud subdomein als nieuw pad
- Aantal pagina’s in de index voor beide
- Aantal 404-fouten op het oude subdomein (wijst op gemiste redirects)
- Ranking-bewegingen voor de top-pagina’s
Wat je verwacht ziet:
- De crawl op het subdomein neemt geleidelijk af
- De crawl op het nieuwe pad neemt toe
- Ranking-bewegingen in de eerste week, daarna stabilisatie binnen 4 tot 6 weken
- 404-meldingen die je oplost door extra redirects toe te voegen
Wat je niet verwacht ziet:
- Verlies van meer dan 10 tot 20 procent in zichtbaarheid (tijdelijk)
- Een complete crash naar nul (wijst op een grote fout in redirects of canonicals)
Wat dit kost
Een subdomein-naar-hoofddomein-migratie reken ik tegen 95 euro per uur, het migratie- en servertarief. Een typische klus voor een mkb-site met een blog op een subdomein (50 tot 150 URLs) kost 6 tot 12 uur. Dat omvat:
- Inventarisatie en risicobepaling
- Opstellen en testen van de redirect-map
- Implementatie in de webserver of via plugin
- Canonical, robots.txt en sitemap opschonen
- Search Console-instellingen
- Eerste twee weken monitoring
Voor grotere sites (500+ URLs) of meertalige opstellingen loopt het op. Een vooraf afgesproken urenraming met bovengrens houdt het voorspelbaar.
Multi-stack: hetzelfde geldt voor Drupal-, Joomla- of Laravel-installaties. De redirect-techniek is dezelfde, de implementatie kan verschillen. Voor Shopify is dit soort migratie meestal niet aan de orde, omdat het hosten op aparte subdomeinen daar minder gangbaar is.
Verbeteren boven herbouwen: een subdomein-verhuizing is geen herbouw. Je content blijft, de URL-structuur verandert. Wel een goed moment om meteen te kijken naar pagina’s die de aandacht missen.
