Tijdelijke of permanente redirect: kies per wijziging

Voor je een statuscode kiest, beantwoord je één vraag per wijziging: heeft de oude URL nog een toekomst op dezelfde plek? Als het antwoord ja is, gaat het om een tijdelijke situatie. Als het antwoord nee is, gaat het om een vaste vervanging. Als je het niet weet, noteer je dat expliciet en plan je een beslismoment, bijvoorbeeld na het onderhoudsvenster of na het gesprek met de leverancier.

Zo'n vraag voorkomt de meest voorkomende fout: een tijdelijke oplossing die jaren blijft staan. Wie een tijdelijke redirect plaatst zonder einddatum, loopt het risico dat hij ongemerkt blijft staan en dat het gekozen type niet meer bij de werkelijke situatie past. Leg daarom bij elke wijziging drie dingen vast: de oude URL, de bestemming en de datum waarop je de keuze herbekijkt.

Let ook op de omvang. Gaat het om één pagina, een map of de hele site? Bij een verhuis naar een ander domein of subdomein zoek je in de documentatie van Google en in je eigen Search Console-account na welke migratiehulp beschikbaar is en welke rechten je daarvoor nodig hebt; de startgids voor Search Console geeft enkel een algemeen overzicht van de rapporten.

Gebruik de tabel als vertrekpunt. Het is een werkhypothese per situatie, geen vaste wet: jouw context kan een andere keuze rechtvaardigen.

De laatste rij verdient aandacht: een redirect naar de homepage 'omdat het moet' is meestal geen goede vervanging voor een pagina met een eigen onderwerp. Kies enkel een bestemming die de bezoeker echt verder helpt.

Een redirect is voor Google een van de signalen waarmee een voorkeursversie van een pagina wordt gekozen. De documentatie over het consolideren van duplicaten beschrijft redirects als een sterk signaal dat de bestemming de canonical moet zijn, naast rel="canonical" als sterk signaal en een sitemap als zwak signaal; zie de uitleg over canonical URL's. Die methoden versterken elkaar, maar het blijven signalen: Google neemt zelf de uiteindelijke keuze.

Praktisch betekent dit dat je geen tegenstrijdige boodschappen mag sturen. Een redirect van pagina A naar pagina B terwijl B een canonical naar C bevat, of een sitemap die nog A vermeldt, maakt het beeld rommelig. Zorg dat de volgorde klopt: redirect, canonical op de bestemming die naar zichzelf verwijst en een sitemap met enkel de nieuwe URL.

Noteer ook wat niet werkt als verwijdermiddel. Robots.txt blokkeert crawlen en regelt niet welke versie als canonical geldt, en de bron raadt aan het niet te gebruiken om een canonical te kiezen. De Removals-tool verbergt hooguit tijdelijk content in de resultaten en is dus geen vervanging voor een goed ingestelde redirect.

Hoe de redirect wordt uitgevoerd, bepaalt wat een crawler te zien krijgt. Een redirect op serverniveau (in de HTTP-respons) is voor bezoekers en crawlers het eenvoudigst te lezen. Een redirect die pas na het laden via JavaScript gebeurt, werkt anders: Google verwerkt JavaScript in drie fasen, namelijk crawlen, renderen en indexeren, zoals beschreven in de basisgids over JavaScript en zoekmachines. Dat renderen kan met vertraging gebeuren en niet elke bot voert JavaScript uit. Kies voor een belangrijke verhuis dus liever een serverredirect.

Let daarnaast op deze situaties:

• Redirectketens: oude URL naar tussenstop naar bestemming. Verkort ze tot één stap.
• Lussen: A verwijst naar B en B naar A. Je ziet dit als foutmelding in de browser.
• Pagina's die Googlebot niet mag ophalen: een redirect op een URL die in robots.txt is geblokkeerd, wordt door Google niet gelezen.
• Verschillen tussen mobiel en desktop of tussen taalversies: test elke variant apart.

Een gewone browser negeert robots.txt, dus een browsertest bewijst niet dat Googlebot de redirect kan volgen. Gebruik daarvoor URL-inspectie in Search Console.

Voer deze stappen uit in volgorde en noteer het resultaat per URL:

1. Open de oude URL in een privévenster. Controleer dat je op de bedoelde bestemming terechtkomt, zonder tussenstops.
2. Gebruik een tool of de ontwikkelaarsconsole van je browser om de statuscode en de locatie-header te bekijken. Controleer of het type redirect past bij de beslissing uit het beslisblad.
3. Controleer in de broncode van de bestemming dat de canonical naar zichzelf verwijst en niet naar de oude URL.
4. Pas interne links, menu's en je sitemap aan zodat ze rechtstreeks naar de nieuwe URL wijzen.
5. Open in Search Console URL-inspectie voor de nieuwe URL. De door Google gekozen canonical lees je in de geïndexeerde gegevens van de URL, niet in de live test. De live test toont enkel hoe de pagina nu wordt opgehaald.
6. Bekijk het indexeringsrapport en het prestatierapport. Search Console raadt een controle ongeveer maandelijks aan, of na wijzigingen aan de site.
7. Plan voor tijdelijke redirects een kalenderherinnering op de einddatum, zodat de tijdelijke keuze niet permanent wordt.

Reken er niet op dat de resultaten na een bepaalde termijn zijn bijgewerkt: de snelheid van herindexering is onzeker en verschilt per site.

Stel dat een fictieve kmo twee wijzigingen tegelijk heeft: een pagina 'diensten/opruiming' wordt definitief samengevoegd met 'diensten/onderhoud', en de pagina 'afspraak-maken' staat twee weken offline wegens een systeemvervanging. De overdracht van de webbeheerder aan een collega bevat dan dit blad.

Wijziging 1, invoer: oude URL /diensten/opruiming, bestemming /diensten/onderhoud, terugkeer nee. Verwachte controles: permanente redirect in de header, één stap, canonical op de bestemming naar zichzelf, sitemap aangepast, interne links omgezet, URL-inspectie op de bestemming.

Wijziging 2, invoer: oude URL /afspraak-maken, tijdelijke omleiding of uitlegpagina, terugkeer ja, herbekijkdatum op de geplande heropening. Verwachte controles: tijdelijke redirect in de header, de sitemap blijft de oorspronkelijke URL bevatten zolang die terugkeert, en bevat de tijdelijke bestemming niet als vervanger, herinnering in de agenda, nacontrole op de datum zelf.

De collega die het overneemt, krijgt dus per wijziging vier dingen: de keuze, de reden, de controlelijst en het moment waarop opnieuw wordt beslist. Wat er daarna in zoekresultaten gebeurt, schrijf je niet op als verwachting, maar als iets om te meten.

Wil je weten welke publieke signalen je website nu al zichtbaar toont, bekijk ze dan via Marketing Scan. Een publieke scan meet zichtbare signalen en vervangt je eigen technische controles in Search Console niet.