SEO-problemen oplossen na een WordPress-migratie: begin met URL-integriteit

TL;DR: Je WordPress-migratie heeft SEO vermoedelijk niet “kapotgemaakt”. De keten tussen oude URL’s, nieuwe URL’s, redirects, canonicals, sitemaps, interne links en nu ook AI-citations is gebroken. De oplossing begint dus bij URL-waarheid, niet bij nog een plug-in-audit.

De migratie heeft je SEO niet gedood. Het gebroken URL-verhaal wel.

De meeste mensen onderzoeken wordpress migration seo-problemen vanaf de verkeerde kant. Ze vragen of WordPress, het nieuwe thema, de host of de SEO-plug-in de daling veroorzaakte. Soms speelt één daarvan mee, meestal omdat de URL-continuïteit sneuvelde.

Bij mindnow heb ik WordPress-migraties gezien waarbij de content intact was maar de rankings toch kelderden omdat 600 oude URL’s stilletjes naar de homepage wezen. Dat controleer ik nu vóór ik iets bekijk op seojuice.io of vadimkravcenko.com.

De snelste winst is meestal saai: oude URL, nieuwe URL, statuscode, canonical, indexeerbaarheid, sitemap-opname en interne links. In díe volgorde — niet titles, niet schema, niet Core Web Vitals.

Joost de Valk, oprichter van Yoast SEO, vatte succesvolle domeinmigraties samen als “ongeveer 90% voorbereiding en 10% uitvoering”. Die uitspraak is ook na een mislukte lancering bruikbaar. Als de voorbereiding vóór de live-gang ontbrak, is het herstel gewoon te laat begonnen voorbereiding doen.

De taak is bewijzen of Google oude vraag nog steeds met nieuwe bestemmingen kan verbinden. Als dat niet kan, is copy herschrijven toneelspel.

Classificeer eerst de daling vóór je iets repareert

Niet elke traffic-daling na migratie heeft dezelfde oorzaak. Een host-move, domeinwissel, permalink-wijziging, thema-rebuild, CMS-import en SEO-plug-in-swap kunnen allemaal dezelfde grafiek opleveren: organische sessies omlaag, iedereen nerveus.

De eerste diagnose-splitsing is simpel. Verloor Google de URL, wantrouwde het de nieuwe URL of begreep het de relatie verkeerd?

Herschrijf geen content totdat je weet of Google de nieuwe URL kan bereiken, begrijpen en vertrouwen. Een post met een noindex-tag heeft geen betere headline nodig. Een productcategorie gecanoniseerd naar het oude domein heeft geen extra copy nodig. Een doorgestuurde landingspagina die nu op de homepage uitkomt heeft geen schema-mark-up nodig.

Eerst classificeren. Dan repareren.

Bouw de URL-map opnieuw op, ook al is de migratie al gebeurd

John Mueller gaf het meest bondige advies hierover tijdens een Google SEO Office Hours-sessie, gerapporteerd door Search Engine Journal:

“Ik denk dat het belangrijkste echt is om de individuele URL’s te volgen, zodat je een helder overzicht hebt van wat er eerder was en wat het in de toekomst moet zijn.”

“Individuele URL’s” is cruciaal in WordPress. Dat zijn niet alleen posts en pagina’s. WordPress creëert surface-URL’s via thema’s, plug-ins, archieven, mediagedrag, filters en oude permalink-fallbacks. Als je alleen het zichtbare menustructuur migreerde, miste je waarschijnlijk de helft.

WordPress-URL-surfaces die men vergeet

• Berichten en pagina’s
• WooCommerce-product-URL’s, productcategorieën en de /shop-basis
• Categorieën, tags en custom taxonomieën
• Auteursarchieven
• Datumarchieven als ze indexeerbaar waren
• Attachment-pagina’s en media-URL’s
• Custom post type-archieven
• Gepagineerde archieven
• Feed-URL’s
• Oude ?p=123-permalink-fallbacks (ja, die resolven nog op oudere installs)
• Varianten met en zonder trailing slash
• HTTP- naar HTTPS-varianten
• www- naar non-www-varianten
• Oude staging- of tijdelijke host-URL’s die gelekt zijn

Begin met bewijs, niet met geheugen. Exporteer landingspagina’s uit analytics. Exporteer toppagina’s uit Google Search Console. Crawl de huidige site. Haal een pre-migratie-crawl erbij als die bestaat. Voeg backlink-URL’s toe uit je linkindex als je toegang hebt. Merge alles tot één oud-naar-nieuw-map.

Ja, dit is het saaie spreadsheet-deel — het is ook waar de meeste recoveries beginnen (de audits die ik bij mindnow redde kwamen altijd uit op een ontbrekende kolom in andermans sheet). Gebruik kolommen voor oude URL, nieuwe URL, HTTP-status, redirect-doel, canonical-doel, indexeerbaarheid, sitemap-opname en notities. Bestaat er geen equivalente bestemming, noteer dat. Verstop het niet achter een homepage-fallback.

Voor grotere sites: prioriteer URL’s met backlinks, omzet, organische kliks, conversies of AI-citations. Een dode tag-archive uit 2017 kan wachten. Een productcategorie die non-brand sales dreef niet.

Fix redirects voordat je titles, copy of schema aanraakt

Google’s officiële documentatie voor site-moves zegt:

“Houd de redirects zo lang mogelijk in stand, over het algemeen minimaal 1 jaar.”

Die regel hoort boven elke WordPress-migratiechecklist te hangen. Redirects verdwijnen op saaie manieren. Iemand verwijdert het .htaccess-blok. Een redirect-plug-in wordt uitgezet tijdens opschoning. Een host-migratie dropt Nginx-regels. Cloudflare-pagerules worden vervangen. Het oude domein verloopt. Het staging-domein wordt verwijderd. Niemand merkt iets tot Search Console op een misdaadscene lijkt.

Een redirect is alleen nuttig als de bestemming dezelfde intent beantwoordt. Oude blogpost naar nieuwe blogpost. Oud product naar equivalent product. Oude categorie naar equivalent categorie. Oude servicepagina naar de dichtstbijzijnde overlevende servicepagina. Als de bestemming irrelevánt is, redt de technische 301 de SEO-waarde niet.

Heb je een proces nodig, gebruik dit:

1. Crawl je oude URL-lijst en noteer elke statuscode.
2. Markeer elke 3xx-keten langer dan één hop.
3. Markeer elke oude URL die op de homepage landt.
4. Controleer of de eindbestemming indexeerbaar is.
5. Bevestig dat de eindpagina naar zichzelf of de bedoelde canonical canoniseert.
6. Verplaats high-value redirects uit kwetsbare plug-in-regels naar server- of edge-regels waar mogelijk.

Gebruik je een plug-in, exporteer dan eerst de regels voordat je iets wijzigt. Redirection, Rank Math, Yoast Premium en host-level redirect-panelen kunnen allemaal werken. Het probleem is meestal eigenaarschap. Niemand weet welke laag leidend is.

De homepage-redirect is geen vangnet

Google’s site-move-documentatie waarschuwt tegen het redirecten van veel oude URL’s naar één irrelevante bestemming, zoals de homepage, omdat dat als soft 404 kan gelden. In WordPress komt deze fout vaak voor. Een admin ziet honderden 404’s in een plug-in en maakt een globale fallback naar /. Het dashboard oogt schoner — de zoektraffic wordt slechter.

De oplossing is trager maar veiliger. Map oude URL’s naar de dichtstbijzijnde equivalente bestemming. Bestaat er geen equivalent, geef een echte 404 of 410. Laat dode URL’s eerlijk sterven. Bewaar de pagina’s die ertoe doen met één-op-één-redirects.

Dit is extra pijnlijk bij e-commerce-migraties. Een uitverkocht product verdient misschien een redirect naar een vervangend product of hoofdcategorie. Een verwijderd product zonder vervanger verdient een 410. Een verwijderd product dat naar de homepage redirect leert Google niets.

Let op het 180-dagen Change of Address-venster

De Change of Address-tool in Google Search Console helpt Google een site-move te verwerken, maar vervangt redirects niet. In Search Console Help staat dat de migratie-acties 180 dagen doorgaan nadat je de migratie start (het tool verwerkt signalen zo lang, niet voor altijd).

Na dat venster ziet Google oud en nieuw domein niet meer als gerelateerd als het oude domein nog live en crawlbaar is. De les: redirects moeten langer leven dan het Change of Address-venster. Als de oude host in maand vijf werd uitgezet, heb je een afgrond gecreëerd.

Controleer de WordPress-instellingen die stilletjes herstel blokkeren

WordPress breekt zelden één pagina tegelijk. Het breekt templates. Diagnoseer per paginatype, niet via willekeurige URL-steekproeven.

Begin met de overduidelijke instelling want die richt nog steeds schade aan: Instellingen → Lezen → Zoekmachines ontmoedigen deze site te indexeren. Staging-sites hebben dit vaak aan. Een gehaaste lancering kan het meenemen naar productie. Hetzelfde geldt voor noindex-regels in een SEO-plug-in die van staging zijn gekopieerd.

Controleer daarna canonicals. Een thema-rebuild of plug-in-import kan canonical-tags achterlaten die naar het oude domein, de tijdelijke host of de verkeerde taalversie wijzen. Inspecteer de gerenderde HTML, niet alleen het plug-in-veld. Cache kan verouderde tags serveren nadat het admin-scherm “goed” lijkt.

Sitemaps verdienen hetzelfde wantrouwen. WordPress-SEO-plug-ins splitsen sitemaps per posttype en taxonomie. Na migratie heb je misschien schone post-URL’s in de ene sitemap en oude-domein-categorie-URL’s in een andere. Dien de sitemap-index in en open daarna handmatig de child-sitemaps.

Robots.txt is een andere stille killer. Het blokkeren van /wp-content/ kan Google belemmeren CSS, JavaScript of afbeeldingen te laden die nodig zijn om de pagina te begrijpen. Het blokkeren van een template-pad kan hele groepen raken. Het blokkeren van de hele site gebeurt nog steeds na staging-lanceringen. Ik heb het meer dan eens gezien.

Permalinks zijn erger omdat ze lijken op een contentbeslissing. Overstappen van /%postname%/ naar /blog/%postname%/ zonder redirects creëert een URL-migratie ín de migratie. Hetzelfde geldt voor categorie-bases wijzigen, trailing slash verwijderen of WooCommerce-productbases aanpassen.

Controleer ook redirect-volgorde, CDN-regels, output van meertalige plug-ins, hreflang-doelen, WooCommerce-filter-URL’s, attachment-pagina-gedrag, paginering, breadcrumbs en custom post type-archieven. Eén fout template kan honderden URL’s onderdrukken.

Voelt dit als een technische SEO-auditchecklist? Mooi. Post-migratie-herstel ís een technische audit met een timestamp en een verdachtenlijst.

Herstel pagina’s die uit Google’s index zijn verdwenen

Kies één waardevolle pagina die traffic verloor. Niet twintig. Eén.

Inspecteer eerst de oude URL. Geeft deze een 301? Zit er een ketting in? Komt hij op de juiste nieuwe URL uit? Laadt de bestemming voor Googlebot? Inspecteer dan de nieuwe URL. Bevestig statuscode, canonical, robots-directives, gerenderde HTML, interne links, sitemap-opname en laatste crawldatum.

Gebruik de URL-inspectietool in Search Console voor de live URL, niet alleen de geïndexeerde versie. De geïndexeerde versie toont wat Google laatst opsloeg. De live-test toont wat Google nú kan ophalen.

Schaal daarna per template. Als één gemigreerde blogpost de verkeerde canonical heeft, hebben alle gemigreerde blogposts die waarschijnlijk. Als één productcategorie noindex is, zijn alle productcategorieën dat wellicht. Als één auteursarchief plots indexeerbaar is, creëert elk auteursarchief weer dunne pagina’s.

Search Console-validatie is traag (dagen tot weken, niet uren). Het betere vroege signaal is crawlgedrag. Check serverlogs als je die hebt. Worden doorgestuurde legacy-URL’s nog opgevraagd? Bereiken Googlebot-requests de eindbestemmingen? Dalen 404’s voor waardevolle oude URL’s?

Rankings herstellen meestal per groep. Als gerepareerde productcategorieën weer gecrawld worden en impressies terugkeren, pas dan dezelfde fix toe op de resterende categorieën. Blijf niet aan ongerelateerde dingen sleutelen terwijl de eerste reparatie nog verwerkt wordt.

AI-citations voegen nu een tweede migratieprobleem toe

Joost de Valk verwoordde het nieuwe probleem scherp:

“Er is geen Change of Address-formulier voor een model dat een jaar vóór je verhuizing is getraind.”

Google kan redirects crawlen. Search Console kan een site-move verwerken. LLM’s en AI-answer-engines kunnen nog steeds oude hostnamen of URL’s dragen in trainingsdata, retrieval-indexen, partner-indexen of gecachte citation-lagen. Een schone 301 helpt Google maar herschrijft niet elke oude citation elders opgeslagen.

De oplossing is niet magisch. Houd redirects in leven. Laat oude URL’s naar de beste nieuwe match resolven. Werk high-authority profielen, canonical-bronpagina’s, organization-schema, sameAs-verwijzingen, XML-sitemaps en interne links bij. Werk waar mogelijk citations bij op platforms die AI-systemen vaak inladen.

Dit weegt zwaarder voor WordPress dan men toegeeft (ik zat hier jaren naast). Veel migraties leunen op plug-ins of host-regels die na drie maanden worden opgeschoond. Als AI-citations nog naar oude URL’s wijzen, zijn die redirects de brug. Sloop je de brug, wordt de citation een dood spoor.

Voor aanpalende opschoning, lees de SEOJuice-gidsen over redirect-ketens en 301-redirects, XML-sitemap best practices en canonical-tag-fouten.

Een 14-daags herstelplan voor WordPress-migratie-SEO

Je kunt een rommelige migratie herstellen zonder alles tegelijk te fixen. De volgorde weegt zwaarder dan de toolstack.

Dag 0 t/m 1: stop het bloeden

• Bevestig eigendom van het oude domein, oude host, DNS, CDN en Search Console-properties.
• Herstel redirect-controle vóór je content bewerkt.
• Schakel homepage-catchall-redirects uit.
• Verwijder per ongeluk ingestelde noindex-tags en robots-blokkades.
• Dien schone sitemap-indexen in voor de nieuwe site.
• Test handmatig een steekproef van oude high-value URL’s.

Heb je geen controle meer over het oude domein, wordt herstel snel lastiger. Herwin controle vóór je title-tags gaat bespreken.

Dag 2 t/m 4: bouw de map opnieuw

• Maak de oud-naar-nieuw-URL-tabel.
• Prioriteer URL’s met backlinks, organische kliks, omzet, conversies en AI-citations.
• Scheid URL’s op type: posts, pagina’s, producten, categorieën, tags, media, archieven, feeds.
• Fix redirects in batches, te beginnen met de meest waardevolle groepen.
• Hertest elke batch na uitrol.

Vertrouw niet op “alle redirects succesvol geïmporteerd”. Crawl de lijst.

Dag 5 t/m 7: repareer templates

• Audit canonicals per paginatype.
• Check robots-directives en noindex-regels.
• Bekijk titels, headings, schema, breadcrumbs en interne links.
• Controleer paginering en archief-templates.
• Bevestig hreflang-doelen bij meertaligheid.
• Test WooCommerce-categorie-, product- en filtergedrag.

Hier verdient een WordPress technische SEO-review zijn geld. Je zoekt template-niveau falen, geen losse eigenaardigheden.

Dag 8 t/m 14: bewijs herstel

• Monitor Search Console-coverage en crawlstatistieken.
• Check logs voor Googlebot-activiteit op legacy-redirects.
• Volg rankings per URL-groep, niet alleen per keyword.
• Vergelijk analytics-landingspagina’s vóór en ná herstel.
• Houd notities bij van elke redirect-, template- en sitemap-wijziging.

Verbeteren traffic en rankings op gerepareerde groepen, schaal dan dezelfde fix. Verandert er niets, stop met willekeurige edits en hercheck de map.

Wat je níet moet doen na een mislukte WordPress-migratie

Installeer geen drie extra SEO-plug-ins. Je creëert overlappende canonicals, dubbele sitemaps en redirect-regels zonder eigenaar.

Redirect niet elke 404 naar de homepage. Google is duidelijk dat irrelevante massaredirects soft 404’s kunnen worden.

Wijzig de permalink-structuur niet opnieuw omdat de huidige “netter oogt”. Schone URL’s zijn nutteloos als ze blijven veranderen.

Herschrijf geen content voordat toegang, redirects, canonicals en indexeerbaarheid zijn hersteld. Contentkwaliteit compenseert geen gebroken route.

Verwijder oude redirects niet omdat “Google het vast wel doorheeft”. Google’s eigen richtlijn zegt: houd ze zo lang mogelijk, minstens een jaar.

Zie de homepage-ranking niet als bewijs dat de migratie prima is. Brand-herstel kan template-instortingen verhullen. Check de landingspagina’s die vroeger non-brand traffic brachten.

Als de oude URL’s niet uitleggen waar ze heen gingen, heeft Google geen reden voor je te gokken.

FAQ

Hoe lang duurt SEO-herstel na een WordPress-migratie?

Kleine fixes kunnen binnen dagen crawl- en impressie-veranderingen tonen. Ranking-herstel duurt meestal langer omdat Google oude URL’s moet recrawlen, redirects verwerken, canonicals updaten en vertrouwen opbouwen in de nieuwe URL-set. Reken voor grotere sites in weken, niet in uren.

Moet ik mijn sitemap opnieuw indienen na een WordPress-migratie?

Ja, maar pas nadat de sitemap schoon is. Een sitemap vol oude-domein-URL’s, noindexed URL’s of canonical-mismatches vertraagt diagnose. Open de sitemap-index en child-sitemaps handmatig vóór indienen.

Zijn 301-redirects voldoende om rankings te behouden?

Ze zijn noodzakelijk, maar niet het hele werk. De bestemming moet relevant, indexeerbaar, intern gelinkt, correct gecanoniseerd en aanwezig in schone sitemaps zijn. Een 301 naar een zwakke of irrelevante pagina kan nog steeds traffic verliezen.

Wat als ik mijn WordPress-permalink-structuur heb gewijzigd?

Behandel het als een URL-migratie. Bouw een map van elke oude permalink naar de nieuwe bestemming. Neem categorie-bases, trailing-slash-gedrag, productbases, paginering en oude ?p=123-fallbacks mee als die resolven.

Kan ik de oude host verwijderen na de migratie?

Alleen als redirects elders zijn geregeld en getest. Veel sites verliezen traffic omdat de oude host de enige plek was waar redirects bestonden. Crawl oude URL’s en bevestig dat ze nog correct resolven vóór iets uit dienst te nemen.

Conclusie: het herstel-playbook had de launch-checklist moeten zijn

Een WordPress-migratie-herstel is niet glamoureus. Het is URL-boekhouding, redirect-discipline, template-checks en geduld. Dezelfde checklist die de daling repareert, had vóór live-gang moeten bestaan.

Bij seojuice.io geldt dezelfde regel. Saaie URL-continuïteit wint van heroïsche schoonmaak. Gebruik dit artikel twee keer: één keer om de huidige migratie te repareren, en één keer vóór de volgende live gaat.

Hulp nodig om de breuk te vinden?

Is je WordPress-migratie gevolgd door een daling in organisch verkeer en is de oorzaak nog onduidelijk? Begin met de URL-map en een redirect-audit. SEOJuice kan paniek omzetten in een herstel-queue en daarna in een launch-checklist voor de volgende migratie.