3xx-omleidingscodes

Hoe een redirect werkt

Een redirect is twee verzoeken, geen een. De client vraagt om URL A, de server antwoordt met een 3xx-status en een header Location die URL B noemt, en de client doet dan een vers verzoek naar B. Browsers volgen dit automatisch, dus een bezoeker ziet alleen de eindpagina en de eind-URL in de adresbalk. Het tussentijdse antwoord kost nog steeds een volledige rondreis, en dat is waarom lange redirectketens traag zijn.

Twee eigenschappen scheiden de 3xx-codes van elkaar. De eerste is permanentie: een permanente redirect vertelt clients en crawlers dat de oude URL is uitgefaseerd en dat de nieuwe hem zou moeten vervangen in bookmarks, links en indexen, terwijl een tijdelijke redirect zegt dat de oude URL nog steeds de echte is en terug zal komen. De tweede is methodebehoud. De oudere codes laten een client een POST in een GET veranderen wanneer hij de redirect volgt, en de nieuwere verbieden dat, zodat een POST een POST blijft. Dat is het verschil tussen een formulierinzending die intact bij de nieuwe URL aankomt en een die als lege GET aankomt.

Elke 3xx-code en wat hij betekent

• 300 Multiple Choices. De resource bestaat in verscheidene representaties en de server laat de client kiezen. Er is geen standaard machineleesbaar formaat voor de lijst, dus vrijwel niets implementeert het. In de praktijk zult u geen 300 tegenkomen. Zie de handleiding 300 Multiple Choices voor waarom hij vooral als zoekterm overleeft.
• 301 Moved Permanently. De resource heeft een nieuw permanent thuis. Zoekmachines dragen rankingsignalen over naar het doel, en clients mogen de redirect cachen, soms agressief. Dit is de code voor een domeinwijziging, een migratie van HTTP naar HTTPS of een permanente URL-herstructurering.
• 302 Found. Een tijdelijke redirect. De oorspronkelijke URL behoudt zijn identiteit, dus zoekmachines blijven normaal het origineel indexeren in plaats van het doel. Historisch veranderden veel clients de methode in GET bij het volgen van een 302, en dat is waarom de standaard waarschuwt om hier niet op methodebehoud te vertrouwen.
• 303 See Other. "Uw verzoek is verwerkt; ga nu en GET deze andere resource." De client wordt expliciet verteld GET te gebruiken voor het vervolg, ongeacht de oorspronkelijke methode. Dit is het juiste antwoord op een formulier-POST die op een resultaatpagina zou moeten landen.
• 304 Not Modified. Helemaal geen redirect. Beantwoordt een voorwaardelijk verzoek en betekent "uw gecachete kopie is nog steeds actueel, hergebruik hem". Er is geen body en geen Location. Zie 304 Not Modified.
• 305 Use Proxy en 306 zijn verouderd. 305 werd om veiligheidsredenen afgeschaft en 306 wordt niet gebruikt. Negeer beide.
• 307 Temporary Redirect. Dezelfde betekenis als 302, maar de methode en body moeten behouden blijven. Een POST die een 307 volgt, komt bij de nieuwe URL aan als een POST.
• 308 Permanent Redirect. Dezelfde betekenis als 301, maar de methode en body moeten behouden blijven.

Wat er misgaat met redirects

• Een tijdelijke code op een permanente verhuizing. De meest voorkomende en duurste fout. Zoekmachines houden de oude URL geïndexeerd en de nieuwe erft de status van de oude niet.
• Een permanente code op een tijdelijke verhuizing. Moeilijker terug te draaien, want een gecachete 301 kan terugkerende bezoekers lang nadat u de regel verwijdert nog steeds naar de verkeerde plek sturen.
• Redirectketens. http naar https, dan non-www naar www, dan oud pad naar nieuw pad is drie rondreizen voordat er content aankomt. Elke sprong voegt latency toe en elke sprong is een plek waar de keten kan breken.
• Redirectlussen. A stuurt naar B en B stuurt terug naar A, meestal omdat een regel op applicatieniveau en een regel op server- of CDN-niveau het oneens zijn over de canonical vorm. Browsers geven na een vast aantal sprongen op en tonen een fout.
• Alles naar de homepage wijzen. Wanneer uitgefaseerde pagina's allemaal naar de root redirecten in plaats van naar hun dichtstbijzijnde equivalent, wordt de redirect vaak behandeld als een zachte 404 en blijft de bezoeker zoeken.
• Verloren POST-bodies. Een API- of formulier-endpoint dat achter een 301 of 302 is geplaatst, kan zijn methode en payload verliezen bij sommige clients. Gebruik 307 of 308 voor alles dat geen gewone GET is.

Hoe u uw redirects controleert en repareert

1. Zie wat een URL teruggeeft, zonder te volgen:

   curl -sI https://example.com/old-page | grep -Ei "^(HTTP|location)"

   Dat drukt de statusregel en het doel in één keer af.
2. Volg nu de hele keten en tel de sprongen:

   curl -sIL -o /dev/null -w "%{num_redirects} hops, final %{http_code}, %{url_effective}\n" https://example.com/old-page

3. Klap ketens samen tot één sprong. Wijs de oorspronkelijke URL rechtstreeks naar de uiteindelijke bestemming in plaats van hem door tussenliggende regels te laten lopen.
4. Match de code met de intentie. Permanente verhuizing: 301, of 308 als het endpoint niet-GET-verzoeken accepteert. Tijdelijke verhuizing, onderhoudspagina of A/B-splitsing: 302, of 307 waar de methode moet overleven. Post-dan-redirect-flow: 303.
5. Repareer lussen door de canonical vorm eenmaal te beslissen (protocol, host en schuine streep achteraan) en die in precies één laag af te dwingen. Lussen betekenen vrijwel altijd dat twee lagen allebei proberen gezaghebbend te zijn.
6. Test opnieuw met een koude cache. Een browser die een 301 heeft gecachet, blijft die gehoorzamen, dus bevestig met curl of een privévenster voordat u concludeert dat de reparatie niet werkte.

Een kapotte redirect betrappen voordat het verkeer daalt

Redirects breken zonder enig zichtbaar symptoom. Een regel die begint te lussen, of een certificaat dat faalt op het redirectdoel, laat de oude URL nog steeds antwoorden, dus niets ziet er verkeerd uit totdat verkeer en rankings dalen. Een externe check die de keten volgt en de eindstatus toetst, betrapt een kapotte redirect op het moment dat hij verschijnt, en vanaf veel netwerken controleren scheidt een wereldwijde regelwijziging van een regionaal CDN-probleem. HostTracker draait checks vanaf 300+ meetpunten in 158 steden en waarschuwt per e-mail, sms, spraakoproep, Slack, Telegram en meer. Test een URL en zijn redirectketen met de HTTP-checktool, en lees 301 vs 302 voordat u een code kiest.