301 vs 302: welke omleiding past bij jouw URL-wijziging?

Gebruik een 301 als een pagina blijvend naar een ander adres verhuist. Kies een 302 als de omleiding tijdelijk is en het oorspronkelijke adres terugkomt. Controleer eerst of de bestemming dezelfde bezoekersvraag beantwoordt. Daarna test je de echte serverreactie: alleen zien dat je ergens anders uitkomt, bewijst niet dat de omleiding goed staat.

301 en 302 verschillen in de bedoeling van de verhuizing

Een redirect stuurt een verzoek voor een URL door naar een andere URL. Bij een serverredirect krijgt de browser een HTTP-statuscode en een bestemming in de Location-header. De status vertelt welk soort omleiding wordt bedoeld.

Een 301 betekent een permanente verplaatsing. Je zegt daarmee dat het nieuwe adres de blijvende bestemming is. Een 302 betekent een tijdelijke omleiding: het oude adres blijft bedoeld voor gebruik zodra de tijdelijke situatie voorbij is.

Voor Google is een permanente redirect een sterk signaal om de bestemming als canonieke URL te behandelen. Dat is het voorkeursadres dat Google voor de inhoud selecteert. Een tijdelijke redirect geeft een zwakker signaal voor die overstap. Het is geen afzonderlijke schakelaar waarmee je bepaalt welke URL altijd in de zoekresultaten verschijnt.

De verwante codes 308 en 307 betekenen respectievelijk permanent en tijdelijk. Ze behouden expliciet de HTTP-methode en verzoekinhoud bij het doorsturen. Bij 301 en 302 kunnen clients een POST-verzoek omzetten naar GET. Dat onderscheid kan relevant zijn bij formulieren of applicaties. Het betekent niet dat 307 en 308 alleen voor een bepaald internetprotocol of alleen voor HTTPS bestaan.

Google beschrijft deze verschillen in de documentatie over redirects en Google Search. Voor een gewone informatiepagina begint jouw keuze bij de vraag of het oude adres terugkomt.

Beantwoord drie vragen voordat je een code kiest

Begin bij wat er met de pagina verandert. Een andere URL kan een administratieve wijziging zijn, maar ook betekenen dat een dienst verdwijnt. Die situaties vragen niet vanzelf om dezelfde oplossing.

1. Welke vraag beantwoordde de oude pagina? Noteer het product, de dienst of de informatie waarvoor iemand de pagina bezocht.
2. Beantwoordt de nieuwe bestemming die vraag nog? Vergelijk inhoud, aanbod en de actie die een bezoeker daar kan uitvoeren.
3. Komt de oude URL terug? Leg vast of de verplaatsing blijvend is, of welke gebeurtenis de tijdelijke omleiding beëindigt.

Bekijk vervolgens wat er nu gebeurt. Soms bestaat al een redirect vanuit een eerdere verhuizing, waardoor een nieuwe regel een extra tussenstap toevoegt. Controleer ook of de bestemming bereikbaar is en niet zelf weer terugstuurt.

Weet je niet welke oude pagina’s nog belangrijk zijn? Een SEO-audit kan helpen om bestaande omleidingen, bezoekersroutes en indexeringsproblemen in samenhang te beoordelen. De uitkomst hoort een onderbouwde lijst met URL-keuzes te zijn, niet alleen een lijst met gevonden statuscodes.

Beslismatrix voor vijf veelvoorkomende wijzigingen

Gebruik deze matrix als startpunt. De bestemming moet steeds inhoudelijk kloppen. Een correcte code maakt een ongeschikte landingspagina niet geschikt.

Dienstpagina en domeinwissel: vergelijk de inhoud per URL

Stel dat een fietsenmaker de pagina voor een onderhoudsbeurt van een algemeen adres naar een specifieker adres verplaatst. De aangeboden onderhoudsbeurt blijft gelijk en afspraken worden voortaan op de nieuwe pagina aangevraagd. Een 301 past bij die blijvende verhuizing.

Bij een domeinwissel geldt dezelfde afweging voor iedere pagina. Stuur de oude onderhoudspagina naar de nieuwe onderhoudspagina, en de oude contactpagina naar de nieuwe contactpagina. Alles naar de nieuwe homepage sturen levert wel een bestemming op, maar laat veel bezoekers opnieuw zoeken.

Een domeinwissel wordt lastiger te beoordelen wanneer tegelijk diensten, teksten en navigatie veranderen. Leg daarom in je SEO-strategie vast welke veranderingen noodzakelijk zijn en welke je apart kunt uitvoeren. Zo kun je achteraf beter verklaren waar een probleem ontstaat.

Onderhoud en campagnes: tijdelijk betekent niet altijd 302

Een tijdelijke vervangende route kan een 302 rechtvaardigen als bezoekers daar nog steeds hun taak kunnen uitvoeren. Denk aan een informatiepagina die tijdens een verbouwing van het websitesysteem tijdelijk elders staat.

Is de website simpelweg niet beschikbaar en toon je alleen een onderhoudsmelding? Dan kan een 503-status op het opgevraagde adres passender zijn. Daarmee meld je tijdelijke onbeschikbaarheid. Een onderhoudspagina is immers niet automatisch een inhoudelijke vervanger voor alle pagina’s van je website.

Bij een terugkerende campagne is eerst de vraag of een omleiding nodig is. Een vaste pagina voor een jaarlijkse magazijnverkoop kan buiten de actieperiode uitleg geven over het evenement en vermelden dat nieuwe data volgen. Dat voorkomt dat bezoekers telkens op een andere bestemming belanden.

Moet die pagina tijdelijk uitwijken, leg dan vast wanneer zij terugkomt. Alleen het woord ‘campagne’ is onvoldoende reden om 302 te kiezen. Een eenmalige actie die definitief wordt vervangen, kan om een andere oplossing vragen.

Geen relevante opvolger: forceer geen bestemming

Een verwijderd product heeft niet altijd een gelijkwaardige vervanger. Een heel andere uitvoering, toepassing of prijsklasse kan onvoldoende aansluiten bij wat de bezoeker zoekt. Een categoriepagina kan soms helpen, maar is niet automatisch een passende opvolger.

Overweeg eerst of de oude pagina nog nuttige informatie kan bieden, zoals specificaties, ondersteuning of passende alternatieven. Als die functie ontbreekt en de pagina echt weg is, kan een 404 of 410 de juiste reactie zijn. Een bruikbare foutpagina mag bezoekers verder helpen, terwijl de server de juiste foutstatus blijft teruggeven.

Voor grotere assortimenten hoort deze afweging bij ecommerce SEO: maak onderscheid tussen tijdelijk uitverkocht, definitief vervallen en daadwerkelijk vervangen. Anders krijgt ieder product dezelfde regel terwijl de bezoekersvraag verschilt.

Een redirect is een signaal, geen garantie op dezelfde ranking

Een 301 vertelt dat een adres blijvend verandert. Daarmee staat niet vast dat de nieuwe pagina dezelfde ranking krijgt. Google moet de wijziging verwerken en de bestemming beoordelen. Inhoudelijke aansluiting, bereikbaarheid, interne verwijzingen en canonical-signalen moeten met de verhuizing overeenkomen.

Ook een 302 garandeert niet dat de oorspronkelijke URL zijn positie houdt. De code beschrijft de bedoelde tijdelijkheid; hij reserveert geen plaats in de zoekresultaten. Als de situatie lang blijft bestaan, kan de verwerking door Google afwijken van wat jij met de code wilde aangeven.

Een langer bestaande 302 is evenmin automatisch een penalty. Het is vooral aanleiding om te controleren of de wijziging nog werkelijk tijdelijk is. Misschien is het terugkeerbesluit vergeten, of blijkt de nieuwe bestemming inmiddels definitief.

Werk daarom niet met een vast percentage beloofde linkwaarde of rankingbehoud. Beoordeel afzonderlijk of de techniek klopt en hoe de zichtbaarheid zich ontwikkelt. In je SEO-rapportage kun je de wijzigingsdatum, betrokken URL’s en ontwikkeling van vertoningen en klikken naast elkaar zetten. Een verschil direct na de wijziging bewijst op zichzelf nog geen oorzaak.

Controleer de status, eind-URL en volledige keten

Een browser laat vooral het eindresultaat zien. Je opent een oud adres en ziet een andere pagina. Daarmee weet je nog niet of er een 301, een 302, een script of een eerder opgeslagen omleiding tussen zat.

Open in de ontwikkelaarstools van je browser het tabblad Network of Netwerk. Laat verzoeken bij navigatie bewaard blijven en schakel de browsercache tijdens de test uit. Open daarna de oude URL opnieuw en selecteer het eerste documentverzoek. Bekijk de status en, bij een serverredirect, de Location-header.

Volg vervolgens alle documentverzoeken tot de eind-URL. Een serverredirect geeft een 3xx-reactie voordat de doelpagina wordt opgehaald. Bij een omleiding met JavaScript kan de oorspronkelijke pagina eerst een 200-status teruggeven en daarna een nieuwe navigatie starten. Het zichtbare eindpunt kan gelijk zijn, terwijl de uitvoering verschilt.

• Status: komt de ontvangen code overeen met de bedoelde permanente of tijdelijke wijziging?
• Bestemming: verwijst de Location-header naar de afgesproken URL?
• Keten: gaat de oude URL direct naar het doel, of zitten er extra omleidingen tussen?
• Eindreactie: levert de bestemming de verwachte pagina en status op?
• Inhoud: krijgt de bezoeker daadwerkelijk een antwoord op de oorspronkelijke vraag?
• Tijdelijkheid: is bij een 302 vastgelegd wanneer iemand controleert of de oorspronkelijke route terug kan?

Een eindreactie met status 200 is onvoldoende als de pagina een foutmelding toont of over een andere dienst gaat. Controleer voor een pagina die vindbaar moet zijn ook of indexeringsinstellingen en canonical-verwijzingen bij het gekozen doel passen.

Ontstaan verschillen tussen browsers of locaties, onderzoek dan waar de redirect wordt uitgevoerd: in WordPress, de hostingconfiguratie of een tussenliggende CDN. Dat valt onder technische SEO. Tijdelijkheid zelf kun je niet uit één serverreactie bewijzen; daarvoor heb je ook het wijzigingsbesluit nodig.

Een afgebakend Apache-voorbeeld met controlepunten

Als jouw website Apache gebruikt en de configuratie dit toestaat, kan een beheerder een serverregel inzetten. Onderstaand fictief voorbeeld gebruikt RedirectMatch om één exact pad blijvend te laten verwijzen naar een passende nieuwe uitleg. Het is een instructievoorbeeld, geen instelling die al op jouw website staat.

RedirectMatch 301 ^/oude-handleiding$ https://www.voorbeeld.org/gids/starten

De tekens ^ en $ begrenzen het patroon: deze regel richt zich op het volledige pad /oude-handleiding. Een variant met een afsluitende slash of extra paddeel valt niet vanzelf onder dezelfde match. Bepaal vooraf welke varianten je werkelijk wilt ondersteunen. Een brede regel voor een hele map kan andere pagina’s raken dan één exact pad.

Laat de beheerder controleren of de benodigde module en configuratierechten beschikbaar zijn en of het CDN of andere regels eerder ingrijpen. De Apache-documentatie voor RedirectMatch beschrijft de syntax en toegestane context. Een Nginx-server of een beperkt CMS-beheerscherm gebruikt andere mogelijkheden; kopieer deze Apache-regel daar niet.

• Vraag de oude URL op en controleer de ontvangen 301-status en Location-header.
• Controleer dat het doel de bedoelde handleiding toont en geen extra omleidingsketen veroorzaakt.
• Test de slashvariant en een vergelijkbaar maar ander pad. Leg vast welke regel iedere reactie veroorzaakt.
• Controleer na publicatie opnieuw zonder een oude browsercache; een bewaarde reactie kan de nieuwe meting verbergen.

Als de handleiding alleen tijdelijk uitwijkt, kan een tijdelijke code passen bij het vastgelegde terugkeerbesluit. Wijzig de code echter niet alleen omdat het aanpassen eenvoudiger lijkt. De bezoekersvraag en de bedoeling van de verhuizing blijven leidend.

410 en 451 zijn geen omleidingscodes

Een 410 meldt dat een bron verdwenen is. Een 451 meldt onbeschikbaarheid om juridische redenen, zoals omschreven in RFC 7725. Ze sturen iemand niet met een redirectstatus naar een opvolgende pagina. De juiste status hangt af van de werkelijke situatie; deze technische uitleg bepaalt niet of een juridische blokkade op jouw website noodzakelijk is.

Werkblad: maak iedere omleiding controleerbaar

Gebruik één regel per oude URL in een spreadsheet. Daarmee kan een ondernemer de keuze beoordelen en kan een uitvoerder precies zien wat er moet worden ingesteld.

Fictief voorbeeld: een verhuurbedrijf beoordeelt twaalf oude pagina’s. Zeven krijgen blijvend een nieuw adres voor hetzelfde aanbod en worden met 301 doorgestuurd. Twee wijken tijdelijk uit naar een werkende vervangende pagina en krijgen 302. Drie gaan over vervallen aanbod zonder nuttige opvolger en krijgen na inhoudelijke beoordeling een 410.

De inventarisatie omvat dus twaalf oorspronkelijke reacties en negen redirectbestemmingen: zeven plus twee. De uitvoerder controleert alle twaalf oude URL’s en beoordeelt bij de negen redirects ook de bestemming. Voor de twee tijdelijke routes plant de eigenaar een aparte hercontrole zodra het oorspronkelijke aanbod terug is. Dit voorbeeld rekent alleen de controleomvang door; het voorspelt geen bezoekersaantallen of SEO-resultaten.

Voer het besluit uit en plan de hercontrole

Pas de omleiding aan op de plek die de huidige reactie veroorzaakt. In WordPress kan dat een redirectplugin zijn, maar ook een serverregel of hostinginstelling. In Shopify gebruik je voor ondersteunde URL-wijzigingen het redirectbeheer. Controleer welke mogelijkheden het gebruikte systeem daadwerkelijk biedt; niet ieder beheerscherm laat je vrij tussen 301 en 302 kiezen.

Voorkom tegenstrijdige regels op meerdere plekken. Wanneer een CDN al doorstuurt, bereikt het verzoek de instelling in je websitesysteem mogelijk niet eens. Test na de wijziging daarom de publiek bereikbare URL, niet alleen een voorbeeldweergave in het beheer.

Werk na een permanente verhuizing de interne links bij zodat ze rechtstreeks naar het nieuwe adres verwijzen. Controleer waar nodig ook navigatie, sitemap en canonical-verwijzingen. Houd de redirect beschikbaar voor oude externe links en opgeslagen adressen.

Bij een 302 blijven de eigenaar en het terugkeermoment onderdeel van de oplevering. Een controlepunt kan bijvoorbeeld zijn: ‘na herstel van het boekingsformulier test de beheerder de oorspronkelijke route en verwijdert daarna de tijdelijke omleiding’. Dat is duidelijker dan ‘later nog bekijken’.

Hercontroleer betrokken URL’s na een themawisseling, pluginvervanging, hostingmigratie of aanpassing van caching. Een eerder geslaagde test bewijst niet dat een gewijzigde website dezelfde reacties blijft geven.

Scheid het inhoudelijke doel van het verzoekgedrag

Gebruik voor een wijzigingsbesluit drie aparte uitspraken: welk antwoord blijft nodig, komt het oorspronkelijke adres terug en welk verzoek moet de bestemming verwerken? Laat die uitspraken afzonderlijk goedkeuren. Zo kan een inhoudseigenaar een verhuizing beoordelen zonder daarmee ongemerkt toestemming te geven voor een andere verwerking van een aanvraag.

De leverancier Merova in de volgende gevallen is fictief. Ook de materialen, routes, aantallen, verzoeken en testuitkomsten zijn verzonnen. Werkelijk verkeer, prestaties en meetresultaten zijn onbekend. De leverancier heeft een aanvraagcatalogus met uitleg over denkbeeldige platen en bevestigingsmaterialen.

Werk vijf verschillende routebesluiten uit

• Catalogusuitleg verhuist blijvend. De uitleg over Lindeplaat staat voortaan onder de gidsen. De producthouder bevestigt dat toepassing en uitvoering gelijk blijven. Voor het gewone GET-verzoek wordt een permanente omleiding beoordeeld; het oude artikel komt niet terug.
• Onderhoudsuitleg wijkt tijdelijk uit. De oorspronkelijke gids keert terug zodra de gecontroleerde onderhoudstekst beschikbaar is. De vervanger moet ondertussen dezelfde noodzakelijke vragen beantwoorden. De inhoudseigenaar benoemt wie de terugkeer accepteert.
• Een technisch downloadadres verdwijnt. Het adres stond nog in de administratie, maar het document heeft geen functie of opvolger meer. Behoud in een register is geen reden voor een redirect. De eigenaar onderbouwt verwijdering; technisch beheer bepaalt de passende foutreactie.
• Een aanvraag krijgt een ontvangstpagina. Na geslaagde verwerking moet een afzonderlijk resultaat worden opgehaald. Technisch beheer beoordeelt hiervoor een functionele route met 303. Die ontvangstpagina is geen permanente vervanging van het adres waarop de aanvraag werd verwerkt.
• Een wijzigingsactie krijgt tijdelijk een andere interne verwerker. Het synthetische POST-verzoek moet zijn methode behouden. Technisch beheer beoordeelt daarom 307 en controleert daarnaast of de bedoelde verwerker de actie inhoudelijk mag en kan behandelen.

Een permanent verhuisd HTML-artikel en een wijzigingsactie krijgen dus niet vanzelf dezelfde instelling. Bij de actie moet je bovendien weten wat er al is gebeurd voordat de omleiding verschijnt. Methodebehoud bewijst niet dat opnieuw aanbieden zonder gevolgen kan.

Vervang een los label door een toetsbaar besluit

Staat in het werkblad alleen “tijdelijk”, dan ontbreken het terugkeercriterium, de terugkerende inhoud en de verantwoordelijke. Vraag bijvoorbeeld om: “De gids keert terug nadat de producthouder de instructie voor Lindeplaat heeft geaccepteerd.” Technisch beheer legt vervolgens methode en doeladres vast.

Blijft onduidelijk of de oude inhoud terugkomt, markeer dat als open besluit. Een uitvoerder kan die onzekerheid niet oplossen door alvast een code te kiezen. Laat ook vastleggen welke huidige reactie voorlopig aanvaardbaar is en welk inhoudelijk ontbrekend antwoord uitvoering blokkeert.

Bij de ontvangstpagina moet de beheerder twee gebeurtenissen uit elkaar houden: de aanvraag is verwerkt en het resultaat wordt bekeken. Laat het testbewijs tonen op welk moment verwerking is afgerond. Een ontvangsttekst die alleen verschijnt omdat een adres bereikbaar is, bewijst geen geslaagde verwerking. Omgekeerd mag het opnieuw bekijken van dat resultaat niet zonder beoordeling als nieuwe aanvraag worden behandeld. Houd deze acceptatie apart van de catalogusverhuizing.

Leg vast wat het verzoek onderweg verandert

Maak voor functionele routes een verzoekdossier in een afgeschermde synthetische testomgeving. Gebruik geen echte aanvraag, bestelling of contactverzending. Laat de omgeving uitsluitend verzonnen waarden verwerken, zonder persoonsgegevens, wachtwoorden of publieke toegangssleutels. Een publieke informatiepagina kun je apart met een gewoon GET-verzoek beoordelen.

Begin het dossier met de oorspronkelijke methode en de volledige URL, inclusief relevante padvariant en aanwezige query. Noteer voor het synthetische verzoek welke velden worden verzonden. Bijvoorbeeld materiaal=Lindeplaat, uitvoering=smal en proefreferentie=TEST-MEROVA. Deze waarden beschrijven uitsluitend het fictieve geval.

Bewaar daarna de eerste HTTP-status, de ontvangen Location, de methode van het volgende verzoek en het ontvangen resultaat. Voeg een inhoudelijke acceptatie toe: welke handeling of welk antwoord moest aantoonbaar overblijven? Zonder die laatste beoordeling kan een technisch leesbaar dossier nog steeds een verkeerde uitkomst goedkeuren.

Beoordeel drie gevallen met verschillende fouten

1. Aanvraagvelden verdwijnen. Een synthetische POST naar https://www.example.com/proef/aanvraag ontvangt 302. De testclient volgt met GET naar https://www.example.com/proef/verwerker. Daar ontbreken de verzonden materiaalvelden. Het oordeel luidt: verzoekgedrag wijkt af; onderzoek methodewisseling en ontvangst bij de verwerker.
2. De verkeerde uitvoering verschijnt. GET naar https://www.example.com/handleiding/smal ontvangt 301 naar https://www.example.com/gidsen/breed. Het volgende verzoek blijft GET en de pagina antwoordt met 200. Het oordeel luidt: inhoudelijk afgewezen, omdat de handleiding voor de smalle uitvoering ontbreekt.
3. Het afzonderlijke resultaat klopt. Een gesimuleerde aanvraag wordt in de testomgeving eenmaal als afgehandeld geregistreerd. Daarna verwijst 303 naar een ontvangstpagina voor die proefreferentie. Het oordeel blijft afhankelijk van bewijs dat die pagina het juiste resultaat beschrijft en geen nieuwe aanvraag uitvoert.

Gebruik bij deze drie gevallen een kort beoordelingsblad: geval [naam], doorslaggevend bewijs [waarneming], ontbrekend bewijs [vraag], besluit [accepteren of herstellen]. Voeg de verzoekdetails als onderbouwing toe. Zo ziet de beoordelaar meteen waarom een geval faalt, zonder opnieuw alle technische gegevens te moeten interpreteren.

Het eerste geval zegt niets over een verkeerde verwerking door Google. De waargenomen afwijking zit tussen de verzonden POST en de ontvangen GET. Onderzoek dat traject voordat je conclusies over zoeken trekt. Bij 301 en 302 kan een client de methode op deze manier veranderen.

Bij automatisch volgen behouden 307 en 308 de methode. Daarmee is de inhoudelijke verwerking nog niet bewezen. De eigenaar moet aantonen dat de bedoelde verwerker de juiste actie behandelt. Laat technisch beheer beoordelen hoe een herhaling wordt voorkomen of herkend voordat iemand een mislukte proef opnieuw aanbiedt.

Sluit een geval pas wanneer zowel het verzoekbewijs als de inhoudelijke beoordeling beschikbaar zijn. “De pagina opent” is bij een aanvraag onvoldoende; “de methode blijft POST” evenzeer.

Geef een tijdelijke route een begin en een einde

Een tijdelijke route heeft meer nodig dan een controledatum. Beschrijf het huidige doel, de reden voor uitwijking, de inhoud die terugkomt, degene die de omleiding beëindigt en het publieke verzoek dat daarna moet werken. Die gegevens maken duidelijk wat afronding werkelijk betekent.

Bij Merova blijft de oude onderhoudsgids administratief bestaan terwijl de instructie wordt herzien. Bezoekers krijgen tijdelijk actuele uitleg op een ander adres. Het behoud van het administratieve record zegt niets over het antwoord dat een publiek verzoek op dat moment ontvangt.

Controleer de vervanger vóór de tijdelijke overstap

De tijdelijke uitleg moet in dit fictieve geval antwoord geven op drie vragen: welke uitvoering wordt bedoeld, welke voorbereiding hoort daarbij en waar staat de bijbehorende tekening? De inhoudseigenaar vergelijkt die antwoorden met de oorspronkelijke gids. Ontbreekt de tekening, dan blokkeert dat de overstap, ook wanneer de geplande 302 technisch correct lijkt.

Houd taal en productvariant zichtbaar in de beoordeling. Een Nederlandse instructie voor Lindeplaat smal is geen vervanger voor een andere taal of uitvoering alleen omdat beide pagina’s onderhoud bespreken. Noteer welke verschillen bewust zijn toegestaan en welke informatie gelijk moet blijven.

Leg voor de onderhoudsroute bijvoorbeeld vast: “Na acceptatie van de herziene instructie geeft het oorspronkelijke gidsadres bij GET weer de eigen inhoud met 200.” Wijs een inhoudseigenaar aan voor de acceptatie en een beheerder voor het beëindigen van de omleiding. De projecthouder controleert het publieke bewijs.

Beslis afzonderlijk over terugkeer en tijdelijke bestemming

Na het onderhoud zijn er twee adressen om te beoordelen. Het bronadres moet weer de afgesproken eigen gids leveren. Voor de tijdelijke bestemming neem je een apart besluit: blijft daar nuttige zelfstandige uitleg staan, of verdwijnt die pagina? De terugkeer van de bron bepaalt dat niet automatisch.

Bekijk ook verwijzingen die tijdens het onderhoud zijn aangepast. Een link vanuit de productuitleg moet weer bij de juiste onderhoudsgids uitkomen. Een redactionele verwijzing naar zelfstandige achtergrondinformatie mag mogelijk blijven. Beoordeel de bedoeling van de link voordat je alle verwijzingen terugzet.

Blijkt tijdens de herziening dat de oude gids nooit meer op het oude adres terugkomt, dan verandert het inhoudelijke besluit. Leg vast welk adres voortaan de blijvende uitleg draagt. Pas daarna beoordeelt technisch beheer de uitvoering. Het verstrijken van een week is op zichzelf geen reden om een tijdelijke code permanent te maken.

Voor een campagne geldt dezelfde afsluiting: benoem welk antwoord bezoekers na de actie op het oorspronkelijke adres krijgen. Zonder dat antwoord blijft de terugkeer onbeslist, ook wanneer de campagne intern al als afgerond staat.

Onderzoek twee verschillende reacties op hetzelfde verzoek

Stel dat een gewone publieke browser bij Merova een oude 301 naar catalogus A ontvangt. Een beheerder ziet bij een controle direct op de configuratielaag een nieuwe 302 naar catalogus B. Beide waarnemingen zijn fictief. Ze beschrijven verschillende controlepunten en bewijzen nog niet waar het verschil ontstaat.

Maak de vergelijking eerst precies. Gaat het werkelijk om dezelfde volledige URL en dezelfde GET-methode? Verschillen in protocol, host, afsluitende slash of query kunnen een ander verzoek opleveren. Zet de gegevens naast elkaar voordat je een opgeslagen reactie als oorzaak aanwijst.

Noteer daarbij of tussen de twee waarnemingen instellingen zijn gewijzigd. Anders vergelijk je mogelijk verschillende toestanden en blijft de verklaring voor het verschil onzeker.

Bewaar de ontvangen reactie per controlepunt

Registreer bij beide observaties het tijdstip, de volledige URL, de ontvangen status en Location. Noteer aanwezige Cache-Control- en Age-headers letterlijk. Ontbreekt een header, schrijf dan “niet aanwezig in deze waarneming”. Vul geen veronderstelde waarde of bewaartijd in.

Een ontbrekende Age-header bewijst niet dat de reactie vers van de oorsprong komt. Cachegebruik blijft daarmee onbekend. Een ontvangen 302 kan eveneens uit een cache komen. De code alleen vertelt onvoldoende over de voorwaarden waaronder een reactie wordt opgeslagen of hergebruikt.

301 en 308 kunnen onder toepasselijke voorwaarden heuristisch worden gecachet. Dat betekent niet dat iedere browser iedere permanente omleiding altijd bewaart. Methode, cacheheaders en overige voorwaarden bepalen de werkelijke opslag en het hergebruik. Voor onderzoek naar die voorwaarden kan technisch beheer de cacheregels in RFC 9111 raadplegen.

Koppel iedere verwachting aan de verantwoordelijke laag

Laat de beheerder aangeven welke reactie de browser ontvangt, welke reactie een eventuele proxy hoort te leveren en welke reactie het CMS heeft ingesteld. Een correcte CMS-instelling kan onbereikt blijven wanneer een eerdere laag al antwoord geeft. Zoek daarom naar het eerste aantoonbare verschil tussen verwachting en ontvangst.

Een controle met andere browserinstellingen kan helpen om een hypothese te onderzoeken. Hetzelfde geldt voor een afwijkende query. Zo’n verzoek vervangt echter niet het publieke bewijs voor het oorspronkelijke adres. Houd onderzoeksverzoeken herkenbaar apart van de gewone GET waarmee je de vrijgave beoordeelt.

Laat wijzigingsgerichte cacheafhandeling en verantwoordelijkheid voor de relevante responseheaders vastleggen. Beschrijf welke bron of regel onderzocht wordt en wie bevestigt dat de bedoelde reactie daar geldt. Een algemene opdracht om alles te wissen maakt niet duidelijk welke oorzaak is aangepakt.

Herstel vervolgens bron voor bron. Herhaal exact dezelfde publieke GET en controleer daarnaast een aangrenzend adres dat behouden moest blijven. Krijgt de oorspronkelijke route nu de afgesproken 302 naar B, maar wordt de behouden pagina meegestuurd, dan is de wijziging nog niet gereed. Bewaar beide reacties bij hetzelfde herstelbesluit.

Teken de ontvangen route per afzonderlijke stap uit

Gebruik bij een combinatie van protocol en pad geen enkele verzamelregel met “redirect werkt”. Schrijf de werkelijk ontvangen reis uit. Een fictief voorbeeld is http://www.example.com/oude-uitleg/ → https://www.example.com/oude-uitleg/ → https://www.example.com/gidsen/uitleg/. Dit zijn twee omleidingen en één eindantwoord. Twee stappen betekenen niet vanzelf twee fouten.

Registreer bij iedere overgang de ontvangen status en Location. Noteer daarna de status en inhoud van het eindantwoord. Als de eerste overgang permanent is en de tweede tijdelijk, schrijf je beide bedoelingen apart op. De keten heeft dan niet één gezamenlijke redirectcode.

Wijs het beheer van iedere overgang toe

Laat technisch beheer vaststellen wie de protocolkeuze uitvoert en wie de padverhuizing beheert. Dat kunnen verschillende lagen en verantwoordelijken zijn. Een hostwijziging, zoals een overstap tussen een adres met en zonder www, hoort eveneens als afzonderlijke keuze in het dossier wanneer die werkelijk voorkomt.

Controleer een slashvariant als eigen verzoek. Een bron zonder afsluitende slash is niet automatisch gelijk aan de geschreven bron met slash. Leg vast welke varianten ondersteund worden en welk antwoord ieder daarvan hoort te krijgen. Zo voorkomt een ogenschijnlijk kleine correctie dat een ander pad ongemerkt wordt meegenomen.

Bij Merova beheert de hostingverantwoordelijke in dit fictieve geval de protocolovergang. De applicatiebeheerder beheert de gidsverhuizing. De inhoudseigenaar bevestigt dat de laatste URL dezelfde uitleg toont. Deze verdeling helpt bepalen wie bewijs moet leveren wanneer de eerste overgang klopt en de tweede verkeerd uitkomt.

Beoordeel een gerichte verkorting met omliggende routes

Kan het eerste oude adres direct naar de passende huidige eindbestemming verwijzen, laat de beheerder dan beoordelen waar die verkorting thuishoort. Bespreek ook wat er gebeurt met het bestaande HTTPS-adres. Dat adres kan nog zelfstandig worden aangevraagd en heeft dus een eigen verwachte reactie.

Controleer na een wijziging naast de bedoelde bron een behouden buurpagina en een niet bedoelde padvariant. Een brede verkorting kan meer verzoeken raken dan de oorspronkelijke combinatie. Het bewijs moet daarom laten zien dat de route korter is geworden én dat de afbakening klopt.

Een lus vraagt een ander herstelbesluit. Bij A → B → A ontbreekt een eindpagina. Zoek welke twee regels elkaar opnieuw activeren en laat de verantwoordelijke de tegenstrijdigheid oplossen. Het verhogen van een toegestane hoeveelheid gevolgde omleidingen herstelt de ontbrekende bestemming niet.

Bewaar de oude en nieuwe ontvangstreis naast elkaar. Zo kan een reviewer zien welke overgang is vervallen, welke beheerlaag veranderde en of dezelfde bezoekersvraag nog wordt beantwoord. Een kortere route met een verkeerde eindpagina wordt niet geaccepteerd.

Test tien bronadressen met drie gerichte uitzonderingen

Maak een kleine vrijgaveset van bestaande publieke GET-routes voordat je een wijziging beoordeelt. De fictieve set van Merova bevat vier blijvend verhuisde uitlegpagina’s, drie tijdelijk uitgeweken onderhoudspagina’s, twee behouden pagina’s en één bewust verwijderd document zonder equivalent. Dat zijn tien bronregels, waarvan zeven redirects.

Geef de regels herkenbare namen: permanent P1 tot en met P4, tijdelijk T1 tot en met T3, behouden B1 en B2, verwijderd V1. Koppel iedere naam aan de volledige URL in het werkblad. De namen helpen bij overleg; ze vervangen nooit het precieze verzoekbewijs.

Herstel een codefout, een te brede regel en een inhoudsfout

1. T2 ontvangt een blijvende code. Het terugkeerbesluit is nog geldig, maar de publieke GET krijgt 301. Laat de veroorzakende regel gericht herstellen naar de afgesproken tijdelijke reactie. Herhaal T2 en controleer T1, dat al correct tijdelijk uitweek.
2. B1 wordt onbedoeld omgeleid. Een breed patroon vangt de behouden pagina op. Beperk de werking tot de bedoelde bronroutes. Herhaal B1 en controleer P1 als nabije route die juist wel moet blijven doorsturen. Beide verwachtingen moeten tegelijk kloppen.
3. P3 toont de verkeerde productvariant. De permanente code klopt, maar de bestemming behandelt Lindeplaat breed terwijl de bron over smal ging. Laat de inhoudseigenaar de passende bestemming aanwijzen. Herhaal P3 en controleer de route voor breed, zodat het herstel die uitvoering niet verwisselt.

Een technische codetest kan P3 goedkeuren omdat de eerste status overeenkomt met het werkblad. De inhoudstest wijst hetzelfde geval af. Bewaar beide beoordelingen en noteer welke voorwaarde ontbreekt. Een groen technisch vinkje mag de nog openstaande productvraag niet overschrijven.

Gebruik de buurroute steeds als tegenproef op de gekozen wijziging. Bij een begrenzing moet een behouden adres buiten de regel blijven, terwijl de bedoelde verhuisroute erbinnen blijft. Kies dus geen willekeurige werkende pagina als geruststelling; kies een verzoek dat een te brede of te smalle oplossing zichtbaar maakt.

Voor passende gewone inhoud verwacht je aan het einde doorgaans 200 met het juiste antwoord. V1 heeft een andere acceptatie: de bewust verwijderde bron geeft de afgesproken 404 of 410. Die foutstatus hoort bij het verwijderbesluit en telt niet als mislukte redirect.

Voer in deze vrijgaveset uitsluitend de afgesproken GET-controles uit. Verstuur geen aanvraag om een informatieverhuizing te testen. Noteer per afwijking het herstel, het herhaalde oorspronkelijke verzoek en de tegenproef. Rapporteer de afzonderlijke uitkomsten; maak er geen percentage van dat beweert hoeveel van de SEO goed staat.

Laat bij een hertest ook de eerdere fout herkenbaar staan. Schrijf bijvoorbeeld bij P3 dat eerst de brede uitvoering verscheen en daarna de smalle uitvoering is geaccepteerd. Daarmee blijft zichtbaar welk probleem de aanpassing oploste. Een lijst met uitsluitend de laatste codes verliest precies de informatie die een volgende beoordelaar nodig heeft bij een terugkerende variantfout.

Draag besluiten over met publiek controleerbaar bewijs

Verdeel de overdracht over concrete verantwoordelijkheden. De producthouder bepaalt welk antwoord en welke taal nodig zijn. Technisch beheer bepaalt response, methodegedrag en beheerlaag. De inhoudseigenaar accepteert de ontvangen uitleg. De projecthouder tekent de vrijgave op basis van het gezamenlijke bewijs.

Laat niemand tekenen voor een onbekend onderdeel. Een producthouder kan bevestigen dat de Nederlandse smalle uitvoering klopt, maar hoeft daarmee geen uitspraak over proxygedrag te doen. Omgekeerd kan een beheerder een correcte eerste response aantonen zonder de materiaaluitleg inhoudelijk te beoordelen.

Vergelijk de verwachte en ontvangen Location letterlijk

Schrijf in de overdracht zowel de verwachte als de waargenomen Location uit. Controleer host, pad, slash en noodzakelijke querywaarden. Houd privéwaarden buiten het gedeelde beoordelingsblad. Als daardoor een technisch relevant onderdeel ontbreekt, verwijs dan naar afgeschermd bewijs en vermeld dat de vergelijking daar plaatsvindt.

Een selectie van 301 in het CMS bewijst geen publieke eerste 301. Een proxy kan al een andere reactie leveren voordat het verzoek het CMS bereikt. Koppel daarom de instelling aan een waarneming op het volledige publieke bronadres. Benoem wie een verschil tussen die twee onderzoekt.

Bewaar een versie of export om terug te kunnen kijken, maar behandel die niet als actueel bewijs. Een export beschrijft opgeslagen instellingen op een bepaald moment. Het verzoekbewijs beschrijft wat een bezoeker bij de controle daadwerkelijk ontving. Voor vrijgave zijn die twee soorten informatie niet uitwisselbaar.

Maak een beperkt herstelbesluit bij onverwachte permanentie

Stel dat een tijdelijke onderhoudsroute onverwacht een permanente reactie geeft. De inhoudelijke vraag of de vervanger alle tekeningen bevat, staat bovendien nog open. Laat de beheerder een klein herstel naar de eerder bewezen toestand beoordelen. Leg vast welke bron geraakt wordt en welk eerder bewijs die toestand ondersteunt.

Maak hiervan geen onbesproken wijziging van alle onderhoudsroutes. De aangetroffen fout bewijst niet dat hun besluiten gelijk zijn. Herhaal het betrokken verzoek na herstel en houd de ontbrekende tekening als afzonderlijk acceptatiepunt open. Technisch terugzetten sluit een inhoudelijke vraag niet vanzelf.

Laat het oorspronkelijke werkblad beschikbaar, inclusief eerdere bestemming, besluit en beoordelaar. Daarmee kan iemand de wijziging reconstrueren of een inverse wijziging voorbereiden. Overschrijf historische waarnemingen niet met het gewenste resultaat; voeg een nieuwe waarneming met tijdstip en beoordeling toe.

Spreek vóór vrijgave af wat er gebeurt als de publieke waarneming afwijkt van de ingestelde reactie. De projecthouder kan de betreffende regel openhouden terwijl een onafhankelijk correct onderdeel wel wordt beoordeeld. Vermeld de afbakening expliciet, zodat een gedeeltelijke acceptatie niet wordt gelezen als goedkeuring van de hele wijziging. Bij een onbekende beheerlaag blijft de technische eigenaar verantwoordelijk voor het uitzoeken daarvan; de inhoudseigenaar hoeft geen serveroorzaak te raden om een verkeerde pagina te kunnen afwijzen.

Beoordeel oude bronnen opnieuw wanneer hun doel verhuist

Verhuist een vervangend adres later opnieuw, zoek dan welke oude bronverzoeken daarvan afhankelijk zijn. Beoordeel ieder oorspronkelijk bezoekdoel. Alleen wanneer de nieuwe bestemming dezelfde taak ondersteunt, kan een directe verwijzing naar dat nieuwe doel passend zijn.

Een oude brochure over Lindeplaat kan bijvoorbeeld nog montagevragen beantwoorden terwijl de actuele catalogus vooral nieuwe uitvoeringen beschrijft. Lage gemeten bezoeken maken die brochurefunctie niet automatisch overbodig. Ook opgeslagen adressen kunnen later nog worden gebruikt; zonder passende meting blijft de omvang daarvan onbekend.

Onderscheid oude productinformatie van verdwenen inhoud

Een product dat niet meer wordt aangeboden, kan nog nuttige uitleg hebben. Laat de eigenaar bepalen of specificaties of ondersteuning beschikbaar moeten blijven. Dat is een ander besluit dan het verwijderen van inhoud die geen functie en geen equivalent meer heeft. Laat een assortimentswijziging deze keuzes niet stilzwijgend samenvoegen.

Controleer na een geaccepteerde doelwijziging ook de eigen links, canonical-verwijzingen en sitemap op overeenstemming met het gekozen adres. Kijk daarbij naar de betrokken pagina’s en hun functie. Een technisch bijgewerkte verwijzing is onvoldoende wanneer zij nu naar een andere uitvoering leidt.

Neem bij een nieuwe doelverhuizing ook bronnen mee die al langer naar het vorige doel verwijzen. Begin met de vastgelegde afhankelijkheden en noteer welke herkomst nog onbekend is. Test vervolgens het oorspronkelijke adres rechtstreeks; alleen het tussenadres openen laat niet zien wat die oudere bezoeker ontvangt. Leg per oude bron vast of de taak gelijk blijft, aanvullende uitleg nodig heeft of inmiddels een afzonderlijk verwijderbesluit vraagt. Zo ontstaat een beoordeelde opvolging zonder dat een verzameling oude regels blind naar de nieuwste catalogus wordt gezet. Bewaar onbesliste bronnen herkenbaar voor inhoudelijke beoordeling.

Houd zoekobservaties los van verzoekacceptatie

Noteer bij zoekobservaties de oude bron, de nieuwe URL, de onderzochte periode en de definitie van de gemeten grootheid. Schrijf ontbrekende metingen expliciet op. Geen beschikbare waarneming is iets anders dan een gemeten nul. Vermijd dat samengevoegde URL-gegevens een verschuiving tussen bron en doel verbergen.

Een browser die na een redirect de juiste pagina ontvangt, bewijst alleen die ontvangstreis. Daaruit kun je niet vaststellen hoe Google de pagina crawlt, rendert of indexeert. Een permanente reactie geeft evenmin een garantie op opname of positie. Houd technische acceptatie en zoekwaarnemingen daarom als afzonderlijke beoordelingen beschikbaar.

Controleer bestaande tijdelijke regels op hun werkelijke terugkeerbesluit: is de aanleiding voorbij, komt de afgesproken inhoud terug en wie beëindigt de uitwijking? Controleer oude permanente regels op de actuele betekenis van hun doel. Een ooit passende bestemming kan inmiddels andere vragen beantwoorden, ook wanneer de ontvangen status onveranderd is.

FAQ over 301, 302 en caching

Hoe kies ik tussen een 301 en een 302?

Kies 301 als de oude URL blijvend wordt vervangen door een relevante nieuwe bestemming. Kies 302 als de oorspronkelijke URL terugkomt na een tijdelijke situatie. Ontbreekt een passende bestemming, beoordeel dan eerst of je de pagina behoudt of een 404 of 410 laat teruggeven.

Hoe pas ik een redirectcode aan?

Zoek eerst uit waar de redirect ontstaat: in je websitesysteem, een plugin, de server of het CDN. Pas daar de bestaande regel aan als het systeem de gewenste code ondersteunt. Controleer daarna de publieke serverreactie, de eind-URL en eventuele tussenstappen.

Waarom zie ik na een wijziging nog de oude redirect?

Een browser, CDN of andere cache kan een eerdere omleiding bewaren. Test met uitgeschakelde browsercache en controleer welke tussenliggende cache actief is. Wis zo nodig de betreffende cache en meet opnieuw. De zichtbare landingspagina alleen bewijst niet welke code de server nu teruggeeft.

Wat doe ik als een verwijderde pagina geen opvolger heeft?

Stuur bezoekers niet automatisch naar de homepage. Beoordeel eerst of de oude pagina nog nuttige informatie kan bieden. Is de inhoud definitief verdwenen en ontbreekt een relevante vervanger, dan kan een 404 of 410 passend zijn, met een foutpagina die bezoekers verder helpt.

Leg je oude URL, nieuwe URL en wijzigingsdoel voor

Wil je laten beoordelen of jouw omleiding klopt? Stuur via het Niblah-contactformulier de oude URL, de beoogde nieuwe URL en de reden voor de wijziging. Vermeld of het oude adres terugkomt en welke status je nu meet, als je die al hebt gecontroleerd. Daarmee kan Niblah de keuze, bestemming en benodigde controle voor jouw WordPress-website of Shopify-webshop gericht beoordelen.