Vet du redan att du vill ha en 301 och bara behöver veta exakt hur du sätter upp den? Här är korrekta, kopierbara recept för Apache (.htaccess), nginx och WordPress, plus hur du verifierar att omdirigeringen verkligen svarar med en 301. Är du osäker på vilken statuskod du ska välja, läs först 301 mot 302.
Apache: .htaccess
På Apache ligger reglerna i en .htaccess-fil i webbroten. För en enkel omdirigering av en enskild sökväg räcker Redirect 301:
Redirect 301 /gammal-sida/ https://www.exempel.se/ny-sida/För att omdirigera en hel domän, eller för mönster, använder du mod_rewrite. Flaggan R=301 sätter statuskoden och L avslutar regelkedjan:
RewriteEngine On
RewriteCond %{HTTP_HOST} ^gammaldoman\.se$ [NC]
RewriteRule ^(.*)$ https://www.nydoman.se/$1 [R=301,L]Den här regeln skickar varje adress på gammaldoman.se till samma sökväg på www.nydoman.se med en permanent omdirigering. Vill du i stället ha en tillfällig, byt R=301 mot R=302.
nginx
På nginx skriver du reglerna i serverblocket. Det enklaste och snabbaste sättet för en hel domän är return 301:
server {
listen 80;
server_name gammaldoman.se www.gammaldoman.se;
return 301 https://www.nydoman.se$request_uri;
}Variabeln $request_uri bevarar sökväg och frågesträng, så att /en/sida?x=1 följer med till den nya domänen. För en enskild sökväg använder du location:
location = /gammal-sida/ {
return 301 https://www.exempel.se/ny-sida/;
}Föredra return framför rewrite när du bara ska skicka vidare. return är tydligare och billigare. Behöver du mönstermatcha finns rewrite ... permanent;, där permanent betyder 301 och redirect betyder 302.
WordPress
I WordPress vill du sällan röra serverfilerna direkt. Det vanligaste är ett plugin som hanterar omdirigeringar, till exempel Redirection, där du lägger upp källa och mål i ett gränssnitt och pluginet svarar med en 301. Det är smidigt för enstaka sidor och för att fånga 404:or, men varje anrop går då genom PHP.
Vill du ha omdirigeringen på servernivå, snabbare och utan PHP, lägger du i stället reglerna i Apaches .htaccess eller nginx-konfigurationen enligt recepten ovan. För enstaka, programmatiska fall kan du också skicka en omdirigering i temats kod tidigt, innan något skrivs ut:
add_action( 'template_redirect', function () {
if ( is_page( 'gammal-sida' ) ) {
wp_redirect( home_url( '/ny-sida/' ), 301 );
exit;
}
} );Andra argumentet till wp_redirect är statuskoden. Glöm inte exit; direkt efter, annars fortsätter sidan att laddas.
Verifiera med curl
Lita aldrig på att en omdirigering är rätt utan att kontrollera statuskoden. Med curl -I hämtar du bara svarsrubrikerna:
curl -I https://www.exempel.se/gammal-sida/Du vill se HTTP/... 301 och ett location:-fält som pekar på rätt måladress. Vill du följa hela kedjan av hopp och se varje steg, lägg till -L och fler rubriker:
curl -sIL https://www.exempel.se/gammal-sida/ | grep -i '^HTTP\|^location'Då ser du varje statuskod och måladress i kedjan, vilket gör det lätt att upptäcka om något oväntat 302 eller ett extra hopp smugit sig in.
Akta dig för kedjor och slingor
Två fel återkommer. En kedja uppstår när A pekar på B som pekar på C, varje extra hopp kostar tid och kan späda ut signalen. Peka alltid direkt på slutmålet. En slinga uppstår när A pekar på B som pekar tillbaka på A, då fastnar webbläsaren i en oändlig omdirigering och visar ett felmeddelande. curl -sIL ovan avslöjar båda direkt, så kör alltid en kontroll efter att du satt upp en regel. Vill du läsa mer om koderna, gå tillbaka till guidehubben.
Testa alltid med 302 innan du sätter 301
Ett råd som sparar mycket huvudvärk under utveckling: använd en tillfällig 302 medan du provar dig fram, och byt till 301 först när regeln är bekräftat rätt. Skälet är att webbläsare cachar en permanent 301 hårt. Har din egen webbläsare väl sparat en felaktig 301 fortsätter den att skicka dig vidare även efter att du rättat regeln på servern, ända tills cachen löper ut eller du tömmer den manuellt. En 302 cachas inte på samma sätt, så servern tillfrågas på nytt vid varje besök, och du ser dina ändringar direkt. Konkret: skriv R=302 i Apache eller rewrite ... redirect; i nginx under testfasen, och ändra till permanent först när curl -I visar att rätt måladress kommer tillbaka.
Apache: omdirigera utifrån frågesträngen
En vanlig komplikation är adresser med en frågesträng, alltså det som står efter ett ?. RewriteRule matchar bara sökvägen, inte frågesträngen, så för att fånga en parameter behöver du ett separat villkor med RewriteCond %{QUERY_STRING}:
RewriteEngine On
RewriteCond %{QUERY_STRING} ^id=42$
RewriteRule ^artikel\.php$ https://www.exempel.se/ny-sida/? [R=301,L]Den här regeln skickar artikel.php?id=42 till den nya sidan. Lägg märke till frågetecknet sist i målet: ett tomt ? tar bort den ursprungliga frågesträngen så att den inte hänger med vidare. Utan det skulle Apache normalt lägga på den gamla frågesträngen på måladressen igen.
Vill du tvärtom behålla och föra vidare frågesträngen till målet använder du flaggan QSA (Query String Append):
RewriteRule ^gammal-sokvag$ /ny-sokvag [R=301,L,QSA]Apache: enklare mönster med RedirectMatch
Behöver du inte hela kraften i mod_rewrite men ändå vill matcha ett mönster, är RedirectMatch ett smidigare alternativ. Det tar ett reguljärt uttryck direkt och behöver inget RewriteEngine On:
RedirectMatch 301 ^/blogg/(.*)$ https://www.exempel.se/artiklar/$1Här flyttas allt under /blogg/ permanent till motsvarande sökväg under /artiklar/. Statuskoden anges först, precis som i den enklare Redirect 301, men med stöd för mönster och grupper.
Apache: anpassade felsidor med ErrorDocument
Strikt sett är en felsida inte en omdirigering, men frågan dyker ofta upp i samma .htaccess-sammanhang. Med ErrorDocument pekar du ut en egen sida som ska visas vid ett visst fel, till exempel en snyggare 404 i stället för serverns standardsida:
ErrorDocument 404 /sidan-finns-inte/Observera skillnaden mot en redirect: besökaren stannar på den felaktiga adressen och servern svarar fortfarande med statuskoden 404, men visar ditt eget innehåll. Vill du i stället att en borttagen adress permanent ska leda vidare till en riktig sida, är det en 301-redirect du ska använda, inte ErrorDocument.
Varför nginx ofta är snabbare än .htaccess
En teknisk skillnad värd att känna till är hur de två servrarna läser sina regler. Apache med .htaccess är konstruerat så att servern letar efter och läser in .htaccess-filer i varje katalog längs sökvägen vid varje begäran, om den funktionen är påslagen. Det är flexibelt, du kan lägga regler nära innehållet utan att röra huvudkonfigurationen, men det innebär återkommande filåtkomst per anrop.
nginx har ingen motsvarighet till .htaccess. Reglerna ligger i serverkonfigurationen som läses in en gång när nginx startar och sedan hålls i minnet. Det betyder att nginx slipper det löpande arbetet med att leta upp och läsa regelfiler för varje begäran. För omdirigeringar är det dessutom därför return 301 rekommenderas: det är en enkel, direkt instruktion som avslutar bearbetningen omedelbart, till skillnad från en rewrite som kräver mönstermatchning. På Apache kan motsvarande effekt nås genom att lägga reglerna i serverns huvudkonfiguration i stället för i .htaccess och stänga av .htaccess-uppslagningen med AllowOverride None, men då tappar du den per-katalog-flexibilitet som många delade webbhotell bygger på.