Redirects der ikke rådner — ét hop, eller I har ikke flyttet URL'en

En redirect er et løfte til to parter: brugeren, der har et bogmærke eller et link i en mail, og crawlen, der har et signal, I gerne vil beholde. Løftet holder, når det gamle hop lander på den rigtige side i ét 301. Det rådner, når I lægger et hop ovenpå et hop, lader en 302 stå, eller svarer 200 på noget, der ikke længere er en side. I tror I har flyttet URL'en. I har flyttet smerten til et sted, I ikke kigger.

Kæder er ikke et kosmetisk problem. Hvert ekstra hop er crawl-budget, I donerer, og et sted en klient eller en bot kan stoppe. En A→B→C, hvor C siden blev 404, er tre chancer for at tabe den, I troede I havde reddet. En loop er værre: I har bedt browseren om at blive. Teams opdager det, når PageSpeed eller et crawl-tool viser 'redirect chain' på en URL, de lovede var kanonisk. De retter den ene. De rører ikke inventaret.

302 vs 301 er det valg, I tager når I er usikre, og glemmer at vende tilbage. En 302 siger midlertidigt. Søgemaskinen må behandle den som det. Hvis jobbet var 'den gamle slug er død, den nye er hjem', er 301 ordet. Hvis jobbet var 'vi A/B-tester en landingside i to uger', er 302 rigtigt — og I skylder en dato, hvor den enten bliver 301 eller forsvinder. En 302 uden ejer er hvordan I har et midlertidigt hop i tre år.

Vi skriver det, fordi 'vi har redirects' er blevet et tjek, I sætter ved go-live og aldrig åbner igen. Et ærligt setup er kedeligt: ét hop pr. gammel URL, 301 når flytningen er rigtig, 404 når siden er død, og en kø I faktisk gennemgår. Uden den vane har I en fil fra bureauet. I har ikke et inventar.

En redirect er et navngivet løfte: den her URL er ikke længere her; den lever der. Statuskoden er en del af løftet. 301 og 308 siger varigt. 302 og 307 siger midlertidigt. Forskellen på 301/302 og 308/307 er om metoden må skifte — relevant for formularer og API-kald, sjældent for en gammel blogpost. For et marketing-site er sætningen næsten altid: 301, ét hop, til den kanoniske. Resten er undtagelser, I skal kunne forklare.

Det er ikke en canonical-tag. Canonical siger 'af de sider, der findes, er det her den foretrukne'. Redirect siger 'den her URL findes ikke længere som en side'. Bland de to, og I har en URL der 200'er med en canonical til et andet host, mens I også 301'er et tredje sted. Crawlen vælger. I har ikke valgt. Canonical er til dubletter, I stadig serverer. Redirect er til URL'er, I ikke længere vil have inde.

Det er heller ikke et sitemap-entry. Sitemap'et fortæller hvad I gerne vil have crawlet nu. Redirect-inventaret fortæller hvad I skylder de URL'er, I ikke længere vil have crawlet som sig selv. At slette en slug fra sitemap'et og lade den 404 uden at I har besluttet det, er ikke hygiene. At 301'e alt det ukendte til forsiden er det heller ikke: det er en blød 404 med 200-status på destinationen, og crawlen lærer at jeres forside er svaret på alt det døde.

Og det er ikke 'en regel i WordPress-pluginet, I slår til'. Et plugin der auto-301'er ved slug-ændring er et værktøj. Det er ikke ejerskab. Pluginet husker den sidste ændring. Det husker ikke kampagnen fra sidste efterår, PDF'en I flyttede, eller at I nu kører Next.js og den gamle .htaccess ikke længere bliver læst. Inventaret er den fil, I deployer. Alt andet er et håb, I har sat hos en vendor.

Den første fejl er at lægge hop på hop. I ændrer slug igen. Pluginet eller next.config tilføjer B→C. A→B bliver stående. Om et år er A→B→C→D, og D er en 404 fordi nogen ryddede 'ubrugte sider'. Relancér-indlægget er at have kortet på cutover-dagen. Her er pligten at slå kæden sammen, hver gang I flytter. Et inventar, I kun åbner ved relaunch, er hvordan redirects rådner.

Den anden fejl er 302'en, I aldrig gjorde permanent. 'Vi er ikke sikre på den nye URL.' Det er ærligt i to uger. Det er en løgn i to år. Søgemaskinen har fået at vide at flytningen er midlertidig. I har fået at vide at I skulle vende tilbage. Ingen gjorde det. Skriv datoen, eller skriv 301. En 302 uden ejer er et midlertidigt hop, I har gjort til arkitektur.

Den tredje fejl er regex, der sluger det, I ikke mente. En catch-all der smider query-strengen væk, så UTM og paginering lander forkert. En trailing-slash-regel der kæder med www-reglen der kæder med http→https, så ét bogmærke er fire hop. Skriv de få, I skylder, eksplicit. En klog stjerne er hvordan I 301'er `/blog/foo` til `/` fordi I mente `/blog/:slug`. Test med de URL'er, I faktisk har ude i mails.

Den fjerde fejl er soft-404 og forside-tragt. En SPA der 200'er alle stier og renderer 'siden findes ikke' i klienten. Et WordPress-tema der viser et søgeresultat med 200. En regel der sender ukendte URL'er til home 'så vi ikke taber linket'. I har fortalt crawlen at det er en side. Den er det ikke. Fejlsider-indlægget er chrome. Her er pligten at lade en død URL være død — 404 eller 410 — eller at flytte den i ét 301 til noget, der faktisk erstatter den.

Relancering er det job, der oftest er rigtigt som et 1:1-kort, og oftest rådner som et spreadsheet. Relancér-indlægget er paritet og cutover. Her er pligten efter: hver ny slug-ændring slår kæden sammen. I flytter ikke 'sitet'. I flytter de URL'er, I stadig skylder. Hvis den nye stack ikke læser den gamle .htaccess, er cutover ikke færdig. I har skiftet host. I har ikke flyttet hoppene.

Kampagne-URL'er er det job, I glemmer, fordi de ikke ligner 'sitet'. /tilbud-forår, /lp/webinar-maj, en UTM-landingside I lovede i et nyhedsbrev. Når kampagnen er død, er URL'en det også — medmindre I 301'er til det, der faktisk erstatter den, eller 404'er med vilje. At lade den 200'e som en tom skabelon er en soft-404. At sende den til forsiden er at fortælle crawlen at forsiden er tilbuddet. Skriv erstatningen, eller skriv 404.

www, https og trailing slash er det job, der oftest bliver fire hop. http://www.example.dk/foo/ → https://www… → https://example.dk/foo/ → https://example.dk/foo. Det er én kanonisk URL, I har gjort til en kæde. Sæt den kanoniske. Lad de tre andre 301'e direkte dertil. Performance-indlægget er LCP. Her er at nægte at lade et bogmærke betale fire RTT'er for et slash, I ikke ville eje som indhold.

Gamle PDF'er, bilag og 'download prisliste' er det job, der oftest 404'er i en mail, nogen sender igen. Hvis filen flyttede, er det et 301 til den nye fil eller til den side, der erstatter den. Hvis filen er død med vilje, er det 404 — ikke et hop til forsiden, så I kan sige at linket 'virker'. Et dokument, I har delt ude i verden, er en URL I skylder et svar. Det er ikke 'bare en fil i /public'.