En 301-redirect siger, at en side er flyttet for altid; en 302 siger, at flytningen er midlertidig, og at den gamle adresse kommer tilbage. Søgemaskiner handler på den forskel: efter en 301 indekserer de den nye adresse i stedet for den gamle, efter en 302 beholder de som regel den gamle. Brug en 301 (eller en 308) til alt permanent, fx en omdøbt side, et nyt domæne eller skiftet til HTTPS, og en 302 (eller en 307) kun når den oprindelige adresse virkelig kommer tilbage. Hold hver redirect til ét enkelt hop, og tjek den med et værktøj, der viser hvert trin.
Statuskoderne for redirects
En redirect er et svar i 3xx-intervallet med en Location-header, der angiver den nye adresse. Fem koder har betydning i praksis:
KodeBetydningBevarer metodenBrug den til301 Moved PermanentlyFlyttet for altidIkke garanteret: browsere gør en POST til en GETOmdøbte sider, nye domæner, HTTP til HTTPS302 FoundMidlertidigt et andet stedIkke garanteret: browsere gør en POST til en GETKortvarige flytninger, at sende besøgende til en login-side303 See OtherHent resultatet fra en anden adresseNej, altid en GETEfter at en formular er sendt, så en genindlæsning ikke sender den to gange307 Temporary RedirectMidlertidigt et andet stedJa, metode og bodyMidlertidige flytninger af API-endpoints og formularer308 Permanent RedirectFlyttet for altidJa, metode og bodyPermanente flytninger af API-endpoints og formularer
For almindelige sider, som browsere henter med GET, opfører 301 og 308 sig ens, og det samme gør 302 og 307. Forskellen viser sig, når en klient sender en POST: efter en 301 eller 302 gentager de fleste klienter den som en GET uden body, mens 307 og 308 får dem til at sende præcis den samme request igen. Derfor bør API’er, der flytter et endpoint, bruge 308 eller 307. Den fulde liste over koder finder du i oversigten over HTTP-statuskoder.
Hvad redirects gør ved SEO
Googles dokumentation om redirects behandler 301 og 308 som permanente og 302, 303 og 307 som midlertidige. En permanent redirect er et stærkt signal om, at målet skal vises i søgeresultaterne i stedet for den gamle adresse. En midlertidig redirect er et svagt signal, så den gamle adresse forbliver som regel indekseret.
Det giver tre typiske fejl:
En 302 til en permanent flytning. Mange frameworks og plugins redirecter som standard med 302. Tjek efter en flytning af sitet, at dine redirects faktisk svarer 301 eller 308.
At sende alt til forsiden. Når en gammel side ikke har noget modstykke, kan Google behandle en redirect til forsiden som en soft 404. Send hver gammel side til det nærmeste match, eller lad den svare 404 eller 410.
Gamle links, der peger på redirects. En redirect er et sikkerhedsnet, ikke en destination. Opdater interne links, canonical-tags og sitemap til den endelige adresse, så hverken besøgende eller crawlere skal betale for det ekstra hop.
Redirects på serversiden er det tydeligste signal. Meta refresh-tags og JavaScript-redirects virker for besøgende, men søgemaskiner ser dem først, når siden er indlæst, og andre klienter ser dem måske slet ikke.
Hvilken skal du bruge?
En side er omdøbt eller lagt sammen med en anden: 301.
Sitet er flyttet til et nyt domæne, til HTTPS eller mellem www og domænet uden www: 301 fra hver gammel variant direkte til den endelige adresse.
En side ligger midlertidigt et andet sted, under en kampagne eller mens den bygges om: 302.
En besøgende skal logge ind først: 302 til login-siden og derefter tilbage.
En formular er sendt: 303 til resultatsiden.
Et API-endpoint er flyttet: 308, hvis det er for altid, 307, hvis det er midlertidigt, så klienter bevarer deres metode og body.
Sitet er nede på grund af vedligeholdelse: ingen redirect. Svar 503 Service Unavailable på den oprindelige adresse, så søgemaskinerne kommer tilbage senere i stedet for at indeksere en vedligeholdelsesside.
Browsere husker permanente redirects
Browsere cacher 301- og 308-svar, ofte længe, og følger dem uden at spørge serveren igen. En forkert permanent redirect bliver derfor ved med at sende tilbagevendende besøgende det forkerte sted hen, også efter at du har rettet serveren. Når du opsætter en ny regel, så test den først som en 302, og skift den til en 301, når den er rigtig. Hvis en forkert 301 allerede er gået ud, hjælper en Cache-Control: no-store-header på fremtidige redirects nye besøgende, men de kopier, browserne allerede har, udløber efter deres egen tidsplan.
Redirect-kæder og loops
En kæde er en redirect til en adresse, der redirecter igen: http://example.com til https://example.com til https://www.example.com til https://www.example.com/en/. Hvert hop er endnu en tur frem og tilbage, før siden begynder at indlæse, og Google følger højst 10 hop. Kæder vokser over års flytninger af sitet, hvor hver flytning lægger sin regel oven på den forrige. Ret dem ved at sende hver gammel variant direkte til den endelige adresse i ét hop.
Et loop er en kæde, der aldrig slutter: to regler sender besøgende frem og tilbage, indtil browseren giver op med “for mange omdirigeringer”. De typiske årsager:
HTTP og HTTPS. Et CDN taler med din server over HTTP, mens serveren redirecter hver HTTP-request til HTTPS. Bag Cloudflare er det indstillingen Flexible SSL; Full (strict) løser det.
www og domænet uden www. Webserveren tilføjer www, og applikationen fjerner det, eller omvendt. I WordPress skal du tjekke, at WordPress-adressen og webstedsadressen stemmer overens med serverens regel.
Afsluttende skråstreger og sprogregler. Én regel tilføjer en skråstreg eller et sprogpræfiks, en anden fjerner det.
Sådan tjekker du en redirect
Fra en terminal viser curl hvert hop med statuskode og Location-header:
curl -sIL http://example.com/old-page | grep -iE “^(HTTP|location)”
HTTP/1.1 301 Moved Permanently
Location: https://example.com/old-page
HTTP/2 301
location: https://example.com/new-page
HTTP/2 200
To hop: den anden regel burde have været den første. I en browser åbner du udviklerværktøjerne, sætter flueben ved Preserve log på fanen Network og indlæser den gamle adresse; hver redirect får sin egen række. Husk, at browseren kan besvare en 301 fra sin cache, så et privat vindue giver et renere billede.
Eller brug vores gratis redirect-tjekker: indtast en URL, og se hvert hop med statuskode, hvor kæden ender, og om den looper, er for lang eller bruger en midlertidig redirect, hvor du nok mente en permanent. Den følger op til 5 hop, tjekket live fra Stockholm.
Sådan opsætter du en 301
De fleste hostingudbydere og CDN’er har en indstilling til redirects i deres dashboard. I serverkonfigurationen:
# nginx: one page
location = /old-page { return 301 /new-page; }
# nginx: a whole domain, keeping the path
server {
server_name old-example.com www.old-example.com;
return 301 https://example.com$request_uri;
}
# Apache (.htaccess): one page
Redirect 301 /old-page /new-page
Tjek bagefter den gamle adresse, dens HTTP- og www-varianter og en adresse med en query string, og sørg for, at hver af dem når den endelige side i ét hop.
Overvågning af redirects med Uptimecheck
En HTTP(S)-monitor i Uptimechecks oppetidsovervågning følger som standard op til 10 redirects og bedømmer siden for enden, som tæller som oppe, når den svarer med en status fra 200 til 399. Et loop eller en kæde, der er længere end det, rapporteres som nede med “Too many redirects”, og hændelsen fortæller, når kæden hopper frem og tilbage mellem HTTP og HTTPS eller mellem www og domænet uden www. Tjek kører helt ned til hvert minut fra Stockholm, London og New York, og et ekstra tjek bekræfter en fejl, før du får en alarm.
Vil du overvåge selve redirecten, fx efter en domæneflytning, så slå Follow redirects fra, så monitoren bedømmer redirectens egen statuskode, sæt Expected status codes til 301, og tilføj et header-tjek af, at Location er lig med den nye adresse. Hvis nogen senere ændrer redirecten til en 302 eller peger den et andet sted hen, hører du om det. Se sådan tilføjer du din første monitor og guiden til HTTP-statuskoder i overvågning.
Få besked, når en flytning går i stykker. Prøv Uptimecheck gratis i 14 dage, uden kreditkort.