Ändrade en 301-omdirigering, men webbläsaren skickar envist besökare till den gamla URL:en? En välbekant huvudvärk för alla som har konfigurerat webbplatsmigreringar eller strukturerat om länkar.

Problemet ligger varken hos servern eller WordPress. Webbläsaren minns permanent en permanent omdirigering och frågar inte servern igen; det är så HTTP-specifikationen fungerar. Tills cachen löper ut eller användaren rensar den manuellt, förblir den gamla regeln i kraft.

Här är en tydlig strategi: hur du testar omdirigeringar utan konsekvenser, varför 302 räddar dina nerver under felsökning, och vad du gör om cachen redan har fastnat för riktiga besökare.

💡 Snabb översikt:

• Börja alltid med 302 (tillfällig), testa, och byt först därefter till 301 (permanent)
• Rensa webbläsarens cache varje gång du ändrar omdirigeringsregler
• För Chrome: DevTools → Nätverk → Inaktivera cache, eller fliken Applikation → Rensa webbplatsdata
• Om en 301 redan är cachad av användare kan du bara vänta eller ändra mål-URL:en

Hur webbläsaren cachar en 301-omdirigering

När servern svarar med statusen 301 Moved Permanently tolkar webbläsaren det bokstavligt: "denna URL har flyttats för alltid." Den lagrar paret "gammal URL → ny URL" i sin egen omdirigeringscache, separat från sid- och bildcachen.

Nästa gång användaren (eller du, utvecklaren) öppnar samma adress skickar webbläsaren ingen förfrågan till servern alls. Den ersätter omedelbart med den sparade mål-URL:en från cachen. Servern ser ingen förfrågan, och du ser inte det aktuella beteendet.

HTTP-specifikationen definierar ingen strikt lagringstid för en sådan cache. I praktiken behåller Chrome, Firefox och Safari 301 i cachen tills den uttryckligen rensas. Serverns Cache-Control-header kan ignoreras av webbläsaren specifikt för 301, eftersom "permanent" betyder permanent.

Detta beteende är en funktion, inte en bugg. Det sparar en tur och retur för legitima permanenta flyttar (till exempel ett domänbyte). Under utveckling blir det dock en fälla.

Varför detta orsakar problem under konfiguration

Tänk dig ett scenario. Du sätter upp en omdirigering från den gamla URL:en /old-page till /new-page. Du konfigurerar en 301, testar den i webbläsaren, och den fungerar. En timme senare inser du att du gjorde ett misstag: den korrekta URL:en är /new-page/v2.

Du ändrar regeln på servern och trycker på "uppdatera" i webbläsaren. Du hamnar på /new-page. Igen. Eftersom webbläsaren redan kom ihåg det första paret och inte ger servern en chans att visa den nya regeln.

Du tror att omdirigeringen inte fungerar. I verkligheten fungerar den, bara inte den du just konfigurerade.

På en testsajt tillbringade vi en gång en halvtimme med att bläddra igenom .htaccess-regler innan vi insåg att webbläsaren visade cachen. Rensade cachen, och allt fungerade omedelbart som avsett.

Situationen är värre med besökare. Om du aktiverade en felaktig 301 på en produktionssajt fick alla som besökte under dessa minuter fel regel i sin webbläsarcache. Du åtgärdade felet på servern på 10 minuter, men deras webbläsare kommer att fortsätta skicka dem till den gamla URL:en i dagar eller veckor, tills cachen rensas.

Notera: du kan inte rensa omdirigeringscachen på användarens sida. Inget servertrick kan nå någon annans webbläsare.

Strategin 302 → 301: testa utan konsekvenser

En regel som sparar timmar av felsökning och skyddar mot misstag på en livesajt:

Börja alltid med en 302-omdirigering (tillfällig). Byt till 301 först efter att du är säker på att regeln är korrekt.

Webbläsaren cachar inte 302 aggressivt; den frågar servern på nytt vid varje förfrågan. Ändra regeln på servern, så plockar webbläsaren omedelbart upp det nya beteendet. Ingen cache-rensning behövs.

Steg-för-steg-metod för varje URL-ändring:

• Sätt upp en 302-omdirigering i .htaccess, Nginx-konfiguration eller via ett WordPress-plugin (till exempel Redirection).
• Öppna den gamla URL:en i inkognitoläge eller med alternativet "Inaktivera cache" aktiverat i DevTools.
• Bekräfta att du hamnar på rätt målsida.
• Kontrollera 2-3 ytterligare URL:er från samma grupp.
• Först när allt är testat, ersätt 302 med 301 i reglerna.
• Gör en slutkontroll i normalt webbläsarläge.

I praktiken tar detta tillvägagångssätt exakt två extra minuter per omdirigeringsgrupp och eliminerar helt risken för ett "cachat fel" för besökare.

Om du använder pluginet Redirection för WordPress skapar det 301 som standard. Växla manuellt till 302 i rullgardinsmenyn när du skapar en regel, och glöm inte att växla tillbaka till 301 efter testning.

Hur du rensar omdirigeringscachen lokalt

När webbläsaren redan har kommit ihåg en felaktig 301 och du inte kan se det aktuella beteendet, här är vad som hjälper:

Chrome. Öppna DevTools (F12), gå till fliken Nätverk och markera Inaktivera cache. Eller gör en fullständig återställning: Applikation → Rensa lagring → Rensa webbplatsdata. Den mest tillförlitliga metoden för en specifik webbplats är chrome://settings/clearBrowserData → Cachade bilder och filer.

Firefox. Webbutvecklarverktyg → Nätverk → Inaktivera cache. För en fullständig rensning: Historik → Rensa ut tidigare historik → Cache.

Safari. Utvecklare → Inaktivera cachar (menyn Utvecklare aktiveras i Inställningar → Avancerat).

Inkognitoläge är ett snabbt sätt att kontrollera färskt beteende utan att rensa huvudcachen. Webbläsaren använder en ren session utan sparade omdirigeringar.

Viktig nyans: att stänga webbläsaren rensar INTE 301-omdirigeringscachen. Till skillnad från sessionslagring överlever omdirigeringscachen omstarter av webbläsaren. Endast uttrycklig rensning eller inkognitoläge fungerar.

Vad du ska göra om cachen har fastnat för användare

Detta är det mest obehagliga scenariot: en felaktig 301 var aktiv på produktionssajten under en tid, och en del av din publik bär nu på den i sina webbläsarcachar. Du fixade serverregeln, men dessa användare fortsätter att hamna på fel ställe.

Här är vad du kan göra:

• Ändra mål-URL:en till en ny. Om den gamla location pekade på /page-v1 och du behöver /page-v2, ersätt helt enkelt adressen i samma regel. Webbläsare med den gamla mål-URL:en cachad kommer att fortsätta gå dit (problemet). Nya besökare kommer dock att gå till rätt plats. Detta löser inte problemet för de redan "infekterade", men det stoppar spridningen.

• Använd en annan omdirigeringsmetod. Om 301 är cachad frågar webbläsaren inte servern, men serverlogik fungerar fortfarande för nya besökare. Lägg till en JavaScript-omdirigering på målsidan som ett extra lager ovanpå HTTP-omdirigeringen för de som fortfarande landar på den gamla sidan.

• Erkänn ärligt: det finns inget direkt botemedel. Du kan inte nå användarens webbläsare. Om cachen redan är laddad är det enda sättet att återställa den om användaren rensar cachen eller besöker via en inkognitolänk. Lyckligtvis lever inte omdirigeringscachen för evigt: ominstallation av webbläsare, enhetsbyten och OS-uppdateringar återställer den så småningom.

Enligt vår erfarenhet blir en felaktig 301 kritisk endast i två fall: en massmigrering (hundratals URL:er) med ett fel i reglerna, eller en omdirigering av startsidan. I båda fallen överväger skadan från ett cachat fel all tid som sparas genom att hoppa över testning.

301, 302, 307, 308: När du ska använda vad

För att undvika förvirring, ha denna snabba översiktstabell för omdirigeringskoder till hands:

För en WordPress-webbplats är det tillräckligt att känna till skillnaden mellan 301 och 302 i de allra flesta fall. Koderna 307 och 308 är nischverktyg för situationer där det är kritiskt att bevara HTTP-metoden (till exempel måste ett formulär förbli en POST-förfrågan och inte omvandlas till GET under en omdirigering).

Kort sagt: 302 är ditt arbetsverktyg under utveckling. 301 är den slutgiltiga "klart"-stämpeln.

En fälla till: WordPress och caching-plugins

På WordPress staplas 301-cachningsproblemet ovanpå server- och plugin-cachning. En typisk situation:

Du redigerar en omdirigering i pluginet Redirection, klickar på "spara", och den fungerar inte. Du rensar webbläsarcachen, och fortfarande visas den gamla sidan. Vad händer? Ett caching-plugin (WP Rocket, LiteSpeed Cache, W3 Total Cache) serverade en cachad version av sidan; servern körde aldrig ens omdirigeringsregeln.

Steg för felsökning av omdirigeringar på WordPress:

• Rensa caching-plugins cache (varje plugin har sin egen "Rensa all cache"-knapp).
• Inaktivera cachning under testning (i WP Rocket är detta utvecklingsläge).
• Rensa webbläsarcachen (enligt beskrivningen ovan).
• Testa först därefter omdirigeringen.

På en testsajt håller vi caching-pluginet inaktiverat tills alla omdirigeringar är helt klara och aktiverar det först efter det slutgiltiga bytet från 302 till 301.

Denna korta engelska video demonstrerar visuellt skillnaden mellan 301 och 302 i praktiken och förklarar varför valet av omdirigeringskod påverkar SEO:

⁉️🤔 Vanliga frågor

Varför cachar webbläsaren 301 istället för att fråga servern varje gång?

HTTP-specifikationen definierar 301 som "resursen har flyttats permanent." Att fråga servern varje gång URL:en öppnas skulle motsäga innebörden av "permanent" och skapa onödig belastning. Cachning av omdirigeringen sparar en HTTP-förfrågan per besökare. I en skala av tiotusentals besök snabbar detta märkbart upp navigeringen. Webbläsaren cachar själva omdirigeringsfaktumet (paret "från → till"), inte sidinnehållet. Detta är en separat typ av cache som kallas omdirigeringscache. Chrome lagrar den i användarprofilen; Firefox lagrar den i filen places.sqlite tillsammans med navigeringshistorik. Det är därför rensning av bild- och skriptcache inte alltid återställer omdirigeringar; du behöver en fullständig rensning eller rensa webbplatsdata.

Kan du förhindra webbläsaren från att cacha 301 på serversidan?

Formellt sett, nej. Webbläsare kan ignorera headern Cache-Control: no-store för permanenta omdirigeringar. Specifikationen kräver inte att webbläsare respekterar Cache-Control för 301/308, eftersom en permanent omdirigering innebär att regeln inte kommer att ändras. Vissa versioner av Chrome och Firefox respekterar Cache-Control för 301, men du kan inte förlita dig på detta i produktion; beteendet är inte garanterat och varierar mellan versioner. Det enda tillförlitliga sättet att "ångra" webbläsarcachning av en 301 är att initialt använda 302 under testning. Om en 301 redan är cachad av användaren är servern maktlös.

Hur skiljer sig 302 från 307 i praktiken?

Båda är tillfälliga omdirigeringar, och ingen av dem cachas av webbläsaren. Skillnaden ligger i hanteringen av HTTP-metod. Med 302 kan webbläsaren ändra en POST-förfrågan till GET under omdirigeringen (detta hände historiskt, och många webbläsare gör det fortfarande). Med 307 är metoden garanterat bevarad: POST förblir POST, PUT förblir PUT. För WordPress och praktiskt taget vilken webbplats som helst är skillnaden försumbar eftersom omdirigeringar nästan alltid involverar GET-förfrågningar (sidöppning). 307 behövs endast om formulär, API:er eller filuppladdningar går genom en URL som du tillfälligt omdirigerar.

Hur kan jag kontrollera vilken omdirigering som är cachad i min webbläsare?

Öppna DevTools (F12) → fliken Nätverk, och markera "Inaktivera cache" (detta är OBLIGATORISKT, annars kommer webbläsaren inte att göra en förfrågan till servern och du kommer inte att se det aktuella svaret). Öppna sedan den gamla URL:en. I kolumnen Status ser du den faktiska svarskoden från servern (301, 302, etc.) och Location-headern med mål-URL:en. Utan "Inaktivera cache" kommer DevTools att visa en 200-status eller (disk cache), vilket betyder att webbläsaren serverade från cache och servern inte tillfrågades.

Behöver du behålla en 301-omdirigering för alltid?

Google rekommenderar att permanenta omdirigeringar behålls i minst ett år efter en flytt. I praktiken, om den gamla URL:en inte längre marknadsförs, inte har några externa länkar och inte är indexerad, kan omdirigeringen tas bort efter 6-12 månader. Men om andra webbplatser länkade till den gamla URL:en eller den finns i sökmotorers index, bör du behålla omdirigeringen permanent. Att ta bort en 301 med en regel cachad av användare kommer inte att lösa problemet; deras webbläsare kommer att fortsätta använda det cachade paret tills de rensar cachen.

Ska du vara rädd för 301-omdirigeringar?

Nej, om du följer regeln "302 först". En permanent omdirigering är ett pålitligt verktyg för att flytta innehåll, byta domäner och städa upp dubbletter. Problem uppstår bara när 301 sätts upp utan testning.

Kom ihåg nyckelpunkten: 301 är ett löfte till webbläsaren att "jag kommer inte att ändra mig." Ge inte det löftet förrän du är säker. Tio minuters testning av en 302-omdirigering i inkognito sparar dagar av uppstädning av cachade fel för din livepublik.