Een slug aanpassen in WordPress duurt technisch maar een paar seconden. Je opent een pagina, wijzigt het URL-deel en klikt op bijwerken. SEO-technisch is de wijziging groter: voor zoekmachines is de nieuwe URL een andere locatie. Wanneer de oude URL al is geïndexeerd, interne links ontvangt of backlinks heeft, moet je duidelijk maken dat de content permanent is verhuisd.
Daarom bestaat er geen knop waarmee je een slugwijziging ‘zonder enig risico’ uitvoert. Wel kun je het risico sterk beperken door de verhuizing correct te behandelen. De basis is een permanente 301 redirect van de oude naar de nieuwe URL, gevolgd door het bijwerken van interne links, canonicals en sitemaps.
Belangrijker nog: verander een slug alleen wanneer daar een echte reden voor is. Een kleine cosmetische verbetering levert zelden genoeg op om een goed presterende URL zomaar te vervangen.
Wanneer is een slugwijziging wel zinvol?
Een wijziging kan verstandig zijn wanneer de URL een duidelijke fout bevat, het onderwerp fundamenteel is veranderd of een oude sitestructuur onnodig ingewikkeld is. Ook bij consolidatie van dubbele content kan een nieuwe of bestaande hoofd-URL nodig zijn.
Minder sterke redenen zijn het toevoegen van één extra zoekwoord, het verwijderen van een stopwoord of het moderniseren van een URL die al jaren goed werkt. SEO is geen schoonheidswedstrijd. Als de huidige URL begrijpelijk is en prestaties heeft opgebouwd, is behouden vaak de veiligste optie.
Maak vóór de wijziging een korte nulmeting: noteer huidige URL, belangrijkste zoekopdrachten, klikken, vertoningen, positie-indicatie, interne links en eventuele belangrijke backlinks. Dan kun je na de migratie beter beoordelen wat er gebeurt.
Stap 1: kies de definitieve nieuwe slug
Bepaal eerst hoe de nieuwe URL er op lange termijn uit moet zien. Vermijd een tussenoplossing die je over drie maanden opnieuw wilt wijzigen. Houd de slug beschrijvend, in de taal van je doelgroep en zonder overbodige datums of toevoegingen als die niet essentieel zijn.
Controleer of de gewenste slug niet al door een andere pagina, bijlage of taxonomie wordt gebruikt. WordPress kan anders een suffix zoals -2 toevoegen. Dat is een signaal dat er een URL-conflict bestaat dat je eerst moet oplossen.
Denk daarnaast na over categoriepad of parent pages. Als de volledige URL door hiërarchie wordt bepaald, kan een wijziging hoger in de structuur meerdere onderliggende URLs beïnvloeden. Behandel zo’n project als een echte migratie en niet als één simpele slugwijziging.
Stap 2: plaats een 301 redirect van oud naar nieuw
Na publicatie van de nieuwe URL moet de oude locatie permanent doorverwijzen. Een 301-status vertelt browsers en zoekmachines dat de content naar een nieuwe vaste URL is verhuisd. Veel SEO- of redirectplugins kunnen dit beheren; op serverniveau kan het eveneens.
Test de redirect buiten je ingelogde WordPress-sessie. Open de oude URL in een privévenster en controleer dat je rechtstreeks op de nieuwe pagina uitkomt. Vermijd een keten zoals oud > tussen-URL > nieuw. Eén directe redirect is overzichtelijker.
Laat de redirect staan zolang oude links nog kunnen bestaan. Verwijder hem niet na een paar weken omdat Google de nieuwe URL inmiddels kent; externe websites, oude e-mails of opgeslagen bookmarks kunnen de oude URL nog lange tijd gebruiken.
Stap 3: werk alle interne links bij
Een 301 is een vangnet, geen vervanging voor onderhoud. Zoek binnen je site naar links die nog naar de oude URL wijzen en pas ze aan naar de nieuwe bestemming. Daarmee voorkom je onnodige redirects tijdens normaal browsen.
Controleer niet alleen artikelteksten. Denk aan menu’s, buttons, Elementor-templates, breadcrumbs, gerelateerde-contentblokken, footerlinks en eventueel structured data. Grote sites kunnen hiervoor een crawl gebruiken om oude URL-verwijzingen te vinden.
Als de oude slug vaak als relatieve link of in custom code staat, zoek ook in templates en widgets. Een migratie is pas echt afgerond wanneer de interne site consequent naar de nieuwe locatie wijst.
Stap 4: controleer canonical, sitemap en indexering
De nieuwe pagina hoort een self-referencing canonical naar de nieuwe URL te hebben, tenzij er bewust een andere canonicalstrategie bestaat. Controleer dat geen oude plugininstelling nog naar de vorige slug verwijst.
Je XML-sitemap hoort de nieuwe URL te bevatten en de oude niet meer. WordPress SEO-plugins werken dit doorgaans automatisch bij, maar controleer het resultaat. Dien niet voor iedere kleine wijziging handmatig tientallen sitemaps in; zorg vooral dat de sitemap technisch bereikbaar en actueel is.
In Search Console kun je de nieuwe URL inspecteren en zien of Google hem kan crawlen. Verwacht dat zoekresultaten tijd nodig hebben om de nieuwe locatie overal te verwerken. Een tijdelijke schommeling betekent niet meteen dat de migratie fout is.
Stap 5: behoud inhoud en intentie tijdens de verhuizing
Als je tegelijk de slug, titel, volledige tekst, interne structuur en zoekintentie verandert, wordt het moeilijk om prestaties te vergelijken. Probeer bij een pure URL-migratie de hoofdinhoud in eerste instantie stabiel te houden. Verbeteringen kunnen later gefaseerd worden doorgevoerd.
Moet de inhoud juist fundamenteel veranderen, wees dan realistisch: rankings kunnen wijzigen omdat het document zelf een andere zoekintentie bedient. Een 301 kan de verhuizing correct aangeven, maar garandeert niet dat de pagina dezelfde zoekresultaatposities houdt wanneer onderwerp en kwaliteit veranderen.
SEO-risico beperken betekent dus ook veranderingen kunnen isoleren en monitoren.
Veelgemaakte fouten na een slugwijziging
De schadelijkste fout is de oude URL simpelweg een 404 laten geven. Een andere fout is de oude URL naar de homepage redirecten terwijl er een exacte nieuwe versie bestaat. Dat is voor de gebruiker onlogisch en kan door zoekmachines als een slechte vervanging worden gezien.
Ook redirectketens komen vaak voor wanneer slugs meerdere keren zijn veranderd. Controleer daarom de historische route. Als /oude-slug/ naar /tussen-slug/ en die weer naar /nieuwe-slug/ gaat, pas de eerste redirect aan zodat hij direct naar de huidige URL wijst.
Vergeet bovendien caching niet. Na wijzigingen kunnen caches nog oude links of redirects tonen. Leeg relevante WordPress-, server- en CDN-cache wanneer tests tegenstrijdige resultaten geven.
Hoe lang duurt herstel na een URL-wijziging?
Daar is geen vaste termijn voor. Google moet de oude URL opnieuw tegenkomen, de redirect verwerken, de nieuwe URL crawlen en signalen consolideren. Op vaak gecrawlde pagina’s kan dat relatief snel gaan; op zelden bezochte pagina’s langer.
Monitor daarom trends in plaats van ieder uur te controleren. Kijk over een redelijke periode naar indexering, klikken en vertoningen. Controleer serverlogs of Search Console wanneer de oude URL lang blijft verschijnen.
Bij tientallen of duizenden gewijzigde URLs is planning nog belangrijker. Maak een redirectmap, test steekproeven en voer een crawl uit nadat de migratie live staat.
Maak bij meerdere wijzigingen eerst een redirectlijst
Wie tien of honderd slugs tegelijk wijzigt, kan beter niet vertrouwen op geheugen of automatische redirects. Zet oude URL, nieuwe URL en status in een eenvoudige lijst en test na de wijziging een representatieve selectie. Controleer vooral pagina’s met organisch verkeer, backlinks of veel interne links. Een redirect naar de homepage is zelden een goede vervanging wanneer er een direct passende nieuwe pagina bestaat. Door vooraf te mappen voorkom je ook redirectketens, waarbij een oude URL eerst naar een tussenversie en pas daarna naar de definitieve pagina wordt gestuurd.
Veelgestelde vragen
Verlies ik altijd ranking als ik een slug verander?
Niet noodzakelijk, maar er kan tijdelijk beweging ontstaan. Een correcte 301 redirect en bijgewerkte interne signalen beperken het risico.
Is een redirectplugin voldoende?
Een plugin kan de 301 regelen, maar je moet ook interne links, canonical, sitemap en uiteindelijke status controleren.
Moet de oude URL naar de homepage?
Nee als er een directe vervangende pagina bestaat. Redirect oude content naar de meest relevante nieuwe bestemming.
Kan ik meerdere slugs achter elkaar wijzigen?
Technisch wel, maar vermijd het. Kies liever één definitieve URL en voorkom redirectketens.
Wanneer moet ik een slug juist niet aanpassen?
Wanneer de bestaande URL duidelijk is, al goed presteert en de wijziging alleen cosmetisch of gebaseerd op een klein zoekwoordverschil is.
Verander een slug alleen met een goede reden
De veiligste slugwijziging is een wijziging die echt nodig is en daarna definitief blijft. Leg vóór de aanpassing vast waar de oude URL naartoe moet, werk interne links bij en controleer na publicatie of zowel de redirect als de nieuwe pagina correct reageren. Zo behandel je een slugwijziging als een kleine migratie in plaats van als een cosmetische tekstwijziging in WordPress.
