301 redirect: Flyt URL'en til den rigtige destination

301 redirect er den rigtige løsning, når en URL er flyttet permanent til en ny, relevant adresse. Koden kan sende både brugere og søgemaskiner videre, men den kan ikke gøre en dårlig destination logisk. Begynd derfor med URL-valget og brug sitemap som kontrol af de ønskede destinations-URL'er bagefter.

En 301 redirect er en permanent adressebesked

En 301 redirect er et HTTP-svar fra serveren. Browseren anmoder om den gamle URL, modtager statuskoden 301 og en ny adresse i Location-headeren og fortsætter derefter til destinationen. For brugeren ligner det en automatisk videresendelse; for systemerne er det et signal om en permanent ændring.

Hold de vigtigste roller adskilt, før en redirect bliver behandlet som en universalløsning:

• Kilde-URL'en er den adresse, brugeren eller crawleren oprindeligt anmoder om
• Statuskoden beskriver, om flytningen er permanent eller midlertidig
• Location angiver den konkrete destination, som klienten skal følge
• Destinationssiden skal selv svare korrekt og løse et relevant behov
• Google vurderer redirectet sammen med canonical, links, sitemap og indhold

RFC 9110 definerer 301 som en permanent flytning til en ny URI. Google Search Central beskriver samtidig permanente redirects som et stærkt signal om, at destinations-URL'en bør være kanonisk. Det er ikke det samme som en garanti for en bestemt placering. Google skal stadig crawle, forstå og vurdere den nye side i sammenhæng med alle øvrige signaler.

301 og 308 er permanente – men ikke helt ens

Både 301 og 308 betyder permanent flytning for Google Search. Forskellen bliver vigtig ved andre requestmetoder end almindelig GET: RFC 9110 tillader historisk, at en klient ændrer en POST til GET efter et 301-svar, mens 308 skal bevare metoden. På normale indholdssider er 301 ofte passende. Ved formularer, API'er og andre write-requests bør udvikleren vælge bevidst og teste den faktiske klientadfærd.

Vælg mellem 301, midlertidig redirect og en reel fejlkode

Den afgørende beslutning er ikke, hvilket plugin der er lettest. Den er, om ændringen er permanent, og om en anden side fortsat opfylder den gamle URLs formål. Google skelner mellem permanente redirects, der peger mod en ny kanonisk adresse, og midlertidige redirects, hvor kilden fortsat kan være den foretrukne søgeresultat-URL.

Brug denne enkle opdeling, før der bliver skrevet regler:

• Brug 301 eller 308, når flytningen er permanent og destinationen er relevant
• Brug 302 eller 307, når flytningen reelt er midlertidig
• Brug 404 eller 410, når indholdet er væk uden en tilsvarende erstatning
• Behold URL'en med 200 OK, hvis indholdet stadig har et selvstændigt formål
• Brug canonical til nødvendige dubletter, som fortsat skal kunne åbnes

Et midlertidigt udsolgt produkt skal ikke nødvendigvis permanent omdirigeres til en kategori, hvis produktsiden snart vender tilbage. En udgået ydelse kan derimod flyttes permanent til en direkte efterfølger, når den nye side besvarer samme købssituation. Varigheden og brugerens forventning skal være tydelige nok til, at teknikken ikke gætter på forretningsbeslutningen.

Når en side ikke har en ærlig erstatning

Det føles ofte mere aktivt at sende alle slettede sider til forsiden. Google advarer specifikt mod at omdirigere mange gamle URL'er til én irrelevant destination, fordi det kan forvirre brugere og behandles som soft 404. Hvis den gamle side handlede om et ophørt produkt, og ingen kategori eller efterfølger løser samme behov, er en korrekt 404 eller 410 mere præcis. Bevar eventuelt en hjælpsom fejlside, men lad statuskoden være sand.

Byg et URL-kort før reglerne implementeres

Ved få ændringer kan én redirect besluttes direkte. Ved redesign, domæneskift eller ny informationsarkitektur skal gamle og nye URL'er kortlægges systematisk. Google anbefaler et URL-map før en migrering. Kortet gør destination, begrundelse og test synlig, så en wildcard-regel ikke skjuler hundrede forkerte valg.

Start med de URL'er, der har dokumenteret værdi eller en vigtig funktion:

• Eksportér nuværende sitemap, CMS-URL'er og kendte landingssider
• Tilføj trafik, organiske klik, eksterne links og sidens forretningsrolle
• Vælg én mest relevant ny destination eller en bevidst 404/410-beslutning
• Notér redirecttype, ejer, afhængighed og forventet slutstatus
• Markér mønstre, der kan automatiseres uden at ændre betydningen

Et URL-map er også en stopregel. Hvis teamet ikke kan forklare, hvorfor gammel side A og ny side B hjælper samme bruger videre, bør redirectet ikke godkendes endnu. Den uenighed kan afsløre, at nyt indhold mangler, at to sider bør samles, eller at en gammel URL faktisk skal forblive tilgængelig under migreringen.

Match brugerens job – ikke bare et fælles emneord

To sider kan handle om SEO og stadig være forkerte erstatninger for hinanden. En tidligere prisside bør ikke automatisk ende på en generel guide, hvis læseren stadig forventer pris, scope og købsvilkår. Sammenlign målgruppe, søgeintention, hovedsvar og næste handling. En stærk destination viderefører det væsentlige job uden at skjule et ændret tilbud. Det reducerer både tilbageklik, supportspørgsmål og risikoen for, at Google vælger et andet resultat.

Implementér redirectet direkte og opdatér alle interne signaler

Når URL-kortet er godkendt, bør redirectet normalt ligge så tæt på serverens requesthåndtering som platformen tillader. Google anbefaler permanente server-side redirects, fordi de er lettest at fortolke. Den konkrete metode afhænger af CMS, framework, Apache, NGINX, CDN og hosting – ikke af én universel kodeblok.

En robust implementering skal gøre mere end at få browseren til at skifte adresse:

• Kilden svarer 301 og peger direkte på den endelige HTTPS-destination
• Destinationen svarer 200 OK uden endnu et unødvendigt hop
• Interne links peger direkte på den nye URL frem for gennem redirectet
• Canonical og eventuelle hreflang-signaler bruger de nye adresser
• Det aktive sitemap indeholder destinationer, ikke gamle redirect-URL'er

Undgå at gøre JavaScript til førstevalg. Google kan udføre JavaScript-redirects efter rendering, men anbefaler dem kun, når server-side eller instant meta refresh ikke er mulig. Et serversvar virker tidligere i kæden og er lettere at kontrollere med almindelige HTTP-værktøjer. Brug platformens dokumenterede løsning, og lad kildekoden eller konfigurationen indgå i normal review og rollback.

Opdatér signalerne, selv om redirectet virker

Et redirect beskytter gamle bogmærker og eksterne links, men egne systemer bør ikke blive ved med at sende brugere gennem det. Google anbefaler at opdatere interne links efter en flytning, og det samme gælder canonical, sitemap, hreflang, annonce-URL'er og profil-links. Direkte links reducerer ekstra requests og gør den nye struktur tydelig. Artiklen om tekniske SEO-problemer i den rigtige rækkefølge viser, hvorfor modstridende signaler skal løses som en fælles mekanisme.

Test både den enkelte redirect og hele mønstret

Et redirect er ikke testet, fordi den endelige side åbner i en browser. Browseren følger automatisk flere hop og kan skjule både en forkert første status, en kæde og et loop. Kontrollen skal vise hele forløbet fra gammel URL til endelig respons og sammenligne resultatet med det godkendte URL-map.

Test mindst disse forhold før og efter udgivelsen:

• Den gamle URL svarer med den aftalte permanente eller midlertidige status
• Location er absolut, korrekt kodet og peger på den valgte destination
• Redirectet har højst det nødvendige ene hop og ender stabilt på 200 OK
• Query-parametre og trailing slash håndteres efter en bevidst regel
• En repræsentativ stikprøve fra hver regel og sidetype består samme kontrol

Ved store migreringer bør hele URL-listen testes maskinelt, men resultaterne skal stadig sammenholdes med intentionen. En teknisk succes kan være en kommerciel fejl, hvis 5.000 gamle produktsider returnerer 301 og alle ender på forsiden. Rapporter derfor både status, slut-URL og matchbeslutning. Så kan udvikling finde regelbrud, mens marketing eller produktejer kontrollerer destinationens relevans.

Negative tests finder de dyre fejl. Test også det, der ikke må ske. En ikke-eksisterende tilfældig URL må ikke blive fanget af en bred regel og sendt til en irrelevant side. En midlertidigt flyttet kampagne må ikke få permanent status. Et redirect må ikke loop'e mellem www, HTTPS og trailing slash. Negative cases viser, om reglen er for bred, og beskytter fremtidige URL'er, som ikke fandtes i migrationsarket ved lanceringen.

Overvåg flytningen og behold redirects længe nok

Efter udgivelsen skal de tekniske svar kontrolleres straks, mens Googles behandling tager længere tid. Google beskriver site moves som en proces pr. URL og oplyser, at mellemstore websites ofte bruger nogle uger på, at de fleste sider flyttes i indekset. Midlertidige udsving er derfor mulige, men de må ikke bruges til at forklare dokumenterede fejl væk.

Følg få signaler, der kan adskille normal behandling fra en forkert opsætning:

• Crawl- og serverlogs for gamle URL'er, fejl og uventede destinationer
• Search Console for indeksering, klik og visninger på gamle og nye sider
• Sitemap med kun de nye kanoniske URL'er og deres behandlingsstatus
• Brugernes 404'er, supporthenvendelser og kritiske flows efter lancering
• Den aftalte forretningshandling på de nye destinationssider

Google anbefaler at beholde redirects så længe som muligt og generelt mindst ét år ved en site move. Det giver Google tid til at recrawle adresser og flytte signaler, også fra eksterne links. Fra brugerens perspektiv kan vigtige redirects beholdes endnu længere. Egen navigation og højt trafikerede eksterne links bør dog opdateres, så redirectet fungerer som sikkerhedsnet og ikke som permanent intern infrastruktur.

Dokumentér hvem der må fjerne en regel, og hvad der skal kontrolleres først. En gammel URL kan stadig have eksterne links, direkte trafik eller trykte materialer, selv om den er forsvundet fra det aktive sitemap. Når mange URL'er, skabeloner og systemer skal ændres samlet, kan et afgrænset SEO- og websprint med implementering og test være passende. Scope bør være URL-map, regler, test og overvågning – ikke et løfte om, at alle placeringer forbliver uændrede.