Så undviker du 301-omdirigeringen som fastnar i besökarens webbläsare

Supporten ser rätt sida, besökaren ser fel sida

En kund hör av sig med en skärmdump. Sidan hen ser är gammal, ibland till och med en 404-sida som pekar mot ett webbhotell ni lämnade för länge sedan. Du öppnar samma adress i din egen webbläsare och ser exakt rätt sida. Du ringer webbhotellets support, och de ser också rätt sida. Ingen av er lyckas återskapa felet.

Felet sitter inte på servern. Det sitter i webbläsaren hos just den besökaren, dit varken du eller supporten kan logga in. Orsaken är nästan alltid densamma. En permanent omdirigering (301 Moved Permanently) skickades ut under en tidigare flytt, och webbläsaren sparade beslutet i sin cache. Sedan dess läser den aldrig den ursprungliga adressen igen, den går rakt till den gamla destinationen utan att fråga servern om något har ändrats.

Varför en 301 cachas som standard

Det här är inget fel i webbläsaren och inget resultat av slarvig konfiguration. Det är HTTP-specifikationen som fungerar precis som den ska. RFC 9110, som definierar HTTP-semantiken, säger rakt ut att en 301 är cachebar utan att servern behöver be om det särskilt.

"A 301 response is heuristically cacheable; i.e., unless otherwise indicated by the method definition or explicit cache controls (see Section 4.2.2 of [CACHING])."
RFC 9110, avsnitt 15.4.2

Ordvalet är avgörande. Texten säger heuristiskt cachebar, inte att svaret ska sparas för evigt. Specifikationen ger webbläsaren tillåtelse att gissa ett rimligt lagringsvärde när servern inte anger något eget, och i praktiken behandlar de flesta webbläsare en 301 som ett mycket starkt, långlivat beslut. Exakt hur länge beror på webbläsarens egen cachepolicy, inte på en tidsgräns i RFC:n. Det enda du kan säga med säkerhet är att den ligger kvar tills cachen rensas, antingen av besökaren själv eller av webbläsaren när utrymmet behöver frigöras.

Varför servern inte kan ta tillbaka en cachad 301

En vanlig omdirigering är ett svar servern skickar varje gång en förfrågan kommer in, och den kan ändras när som helst. En cachad 301 fungerar tvärtom. Webbläsaren har redan bestämt sig och skickar aldrig frågan vidare till servern för att kontrollera om beslutet fortfarande gäller. Det spelar ingen roll att ni ändrar konfigurationen, tar bort omdirigeringen eller pekar om domänen i morgon. Webbläsaren frågar inte, den agerar bara på det den redan vet.

Det förklarar varför supporten upplever sig maktlös. De kan granska serverloggarna, testa med curl, be er skicka en skärmdump från nätverksfliken, och allt pekar på att serversidan svarar korrekt. Problemet finns bara på en plats de aldrig når, nämligen den enskilda besökarens lokala cache.

308 löser inte cacheproblemet, det flyttar det

Många som stöter på det här drar slutsatsen att lösningen är att byta statuskod, till exempel till 308 Permanent Redirect, eftersom den bevarar HTTP-metoden på ett sätt en 301 inte gör. Det är ett rimligt antagande, och det är fel i just den här frågan. RFC 9110 räknar i avsnitt 15.1 upp de statuskoder som är heuristiskt cachebara, och listan innehåller 200, 203, 204, 206, 300, 301, 308, 404, 405, 410, 414 och 501. 301 och 308 står i exakt samma lista. Byter du till 308 för att göra rätt ur ett metodperspektiv försvinner inte cacheproblemet, du flyttar det bara till en statuskod med identiskt beteende.

De två koder som faktiskt saknas i den listan är 302 Found och 307 Temporary Redirect. Det är ingen slump. De är byggda för situationer där destinationen inte är permanent, och webbläsaren förväntas fråga servern på nytt varje gång.

Vill du se hur en riktig adress svarar just nu kan du köra den genom vår redirect-kollare, som visar hela omdirigeringskedjan och vilken statuskod varje steg svarar med.

Skyddsprotokollet under en flytt

Slutsatsen är enkel att formulera, även om den går emot en instinkt många har. Så länge en flytt inte är helt avslutad och bekräftat stabil ska ni aldrig sätta en 301. Håll er till en temporär omdirigering (302 Found) tills ni är säkra.

1. Kör 302 under hela flytten. Så länge målet kan tänkas ändras, domänen kan bytas tillbaka eller värdnamnet är tillfälligt, ska omdirigeringen vara temporär.
2. Sätt en explicit cachekontroll på omdirigeringssvaret. En header som Cache-Control: no-store, eller åtminstone ett kort max-age, tar bort gissningsfaktorn och tvingar webbläsaren att fråga servern igen nästa gång.
3. Vänta med 301 tills destinationen är bevisat stabil. Först när adressen inte längre kommer ändras, och ni har testat att allt fungerar under åtminstone någon vecka, byter ni till en permanent omdirigering.

Om cachningen redan har hänt

Ibland kommer den här artikeln för sent, felet ligger redan ute hos ett okänt antal besökare. Åtgärderna delar sig i två nivåer.

Den enskilda besökaren kan själv rensa sin cache för adressen. I Chrome går det via Utvecklarverktyg (DevTools) och nätverksfliken, genom att tvinga fram en ny förfrågan förbi cachen. I Firefox finns funktionen "Glöm den här webbplatsen", som rensar all lokal data för domänen. Problemet är att du inte kan göra det åt dina besökare, bara skriva en instruktion och hoppas att den hittar rätt person.

Den räddning ni faktiskt kontrollerar sitter på servernivå, men den har en tydlig gräns. Har webbläsaren redan cachat att adress A ska gå till adress B, går situationen ofta att rädda genom att låta B själv omdirigera vidare till C, den nya rätta platsen. Det fungerar eftersom webbläsaren fortfarande skickar en ny förfrågan till B, den har bara memorerat steget från A till B. Men det förutsätter att ni fortfarande äger och styr B. Har ni satt en 301 från den gamla domänen till ett tillfälligt värdnamn hos ett webbhotell ni sedan lämnat, och det värdnamnet återanvänts eller stängts, finns ingen plats kvar att lägga en räddande omdirigering på. Då återstår bara att vänta ut cachens livslängd hos varje besökare, adress för adress.

En kort notering om POST och metodbyte

En 301 tillåter webbläsaren att byta metod vid det efterföljande anropet, till exempel från POST till GET, medan en 308 bevarar metoden exakt. Det är ofta just den skillnaden som lockar folk att hoppa till 308. Den spelar roll för formulär och API-anrop, men den löser inte cacheproblemet. Behöver ni bevara metoden utan att riskera permanent cachning under en instabil period är 307 Temporary Redirect rätt val, inte 308.

Tre vanliga flyttmisstag hos svenska webbplatser

Mönstret dyker upp om och om igen hos svenska sajter. Ingen av situationerna handlar om ett dåligt webbhotell, snarare om i vilken ordning sakerna görs.

Webbhotellsbyte via ett tillfälligt värdnamn

Vid byte av webbhotell är det vanligt att lägga en 301 från den gamla domänen till ett tillfälligt värdnamn hos den nya leverantören, i väntan på att DNS-posterna ska slå igenom överallt. Problemet uppstår om ni glömmer byta tillbaka till en ren domän-till-domän-omdirigering efteråt, eller om värdnamnet senare försvinner. Besökare som råkade träffa den gamla domänen under mellanperioden har nu en permanent cachad omväg till en adress som inte längre finns.

HTTPS-migrering i fel ordning

Konsolidering av www och icke-www, och övergången till https, görs ofta samtidigt, och det är lätt att sätta 301 direkt eftersom målet "borde" vara permanent. Problemet är att många gör det innan certifikat och omdirigeringsregler är fullt testade. Upptäcks ett fel i regeln efter att den redan cachats hos ett antal besökare, sitter de kvar på den felaktiga varianten tills cachen förfaller av sig själv.

Domänbyte

Byter ni hela domänen, till exempel efter ett namnbyte på företaget, är trycket att sätta 301 direkt starkt, eftersom flytten känns definitiv. Men definitiv för er är inte samma sak som testad och stabil. Vänta med den permanenta statusen tills ni bekräftat att allt, inklusive undersidor och formulär, fungerar på den nya domänen. Flyttas hela installationen samtidigt, till exempel en WordPress-sajt, är ordningen ännu viktigare. Se gärna vår genomgång av att flytta WordPress utan att det går sönder innan ni rör en enda omdirigeringsregel.

En fråga om ordning, inte om rätt eller fel statuskod

Ingenting här handlar om att 301 är fel att använda. Den är rätt verktyg när flytten faktiskt är permanent och bekräftat stabil. Poängen är ordningen. Kör 302 medan ni fortfarande kan tänkas ändra er, och spara 301 till sist, som en bekräftelse snarare än en gissning.

Misstänker ni att en gammal omdirigering redan spökar hos några besökare är redirect-kollaren ett bra första steg för att se vad servern faktiskt svarar just nu, medan vår guide om att felsöka en domän själv tar vid där servertestet slutar. Ett näraliggande ämne är delad cache och personligt innehåll, som handlar om mellanliggande cachar som visar fel innehåll för fel person, snarare än webbläsarens egen lagring av en omdirigering.