Redirect chain

En redirect chain er en kæde af viderestillinger. I stedet for at en gammel adresse sender direkte til den aktuelle side, går besøget gennem én eller flere mellemstationer. Forløbet kan eksempelvis være gammel URL → mellemstation → ny URL. Hver pil er en separat redirect, ofte en 301-redirect.

Kæden kan opstå efter flere redesigns, ændringer i produktnavne eller gentagne oprydninger i URL-strukturen. Hver enkelt ændring kan have været fornuftig på tidspunktet. Problemet opstår, når den nye viderestilling bliver lagt oven på den gamle, uden at de tidligere regler bliver samlet.

For brugeren kan kæden betyde en langsommere åbning og i værste fald en fejl. For Googlebot og andre crawlere betyder den ekstra forespørgsler og en mere kompliceret vej til den rigtige adresse. På en stor webshop kan tusindvis af kæder samtidig gøre teknisk vedligeholdelse markant sværere.

En redirect chain er ikke det samme som en redirect loop. I en kæde ender man til sidst på en gyldig side. I et loop bliver browseren sendt rundt mellem adresser, indtil den stopper med en fejl. Begge dele bør rettes, men årsagen og oplevelsen er forskellig.

Viderestillinger er nødvendige, når URL’er ændres. Målet er derfor ikke at fjerne alle redirects. Målet er at gøre dem direkte, dokumenterede og relevante, så gamle links fortsat hjælper brugeren uden at skabe en unødvendig omvej.

Find først kæderne med en crawler, serverlog eller et redirect-værktøj. En crawler kan vise startadresse, hvert hop og den endelige statuskode. Search Console kan samtidig pege på sider, Google har problemer med at hente, men den er ikke en fuld erstatning for en teknisk gennemgang.

Kontrollér derefter, om slutmålet er korrekt. En direkte redirect er kun en forbedring, hvis den ender på den mest relevante side. En gammel produktside bør ikke automatisk sendes til forsiden, hvis der findes en ny model, kategori eller guide, der bedre matcher brugerens forventning.

Ret selve redirect-reglen, så den første gamle URL peger direkte på den endelige adresse. Hvis A går til B og B går til C, bør A normalt pege direkte på C. Bevar kun B → C, hvis B også er en adresse, som fortsat kan modtage eksterne besøg.

Opdatér alle interne links til slutadressen. Interne links bør ikke med vilje gå gennem en redirect. Det gælder navigation, brødtekst, billeder, canonical-tags, hreflang, XML-sitemap og links i skabeloner. Ellers bliver kæden ved med at blive brugt, selv efter reglen er ryddet op.

Test både med og uden afsluttende skråstreg, http og https samt eventuelle www-varianter. Nogle kæder skyldes ikke sideændringer, men flere lag af domæne- og protokolregler. En adresse kan først blive sendt fra http til https, derefter fra www til uden www og til sidst til en ny sti.

Dokumentér større ændringer. Gem gammel URL, ny URL, årsag og dato. På en hjemmeside med mange kampagner eller produktskift gør dokumentationen det lettere at undgå, at næste ændring genindfører en gammel mellemstation.

En virksomhed ændrer først `/raadgivning/` til `/ydelser/raadgivning/`. To år senere bliver området omdøbt til `/strategisk-raadgivning/`. Den oprindelige regel sender stadig `/raadgivning/` til `/ydelser/raadgivning/`, og en ny regel sender derefter videre til `/strategisk-raadgivning/`.

Gamle brochurer, backlinks og søgeresultater kan stadig pege på den første adresse. Besøget virker, men det går gennem to hop. Interne links fra fem gamle blogindlæg peger ovenikøbet på mellemstationen. Kæden er derfor aktiv hver dag, selv om ingen længere ser den gamle side.

Løsningen er at ændre den første regel, så `/raadgivning/` går direkte til `/strategisk-raadgivning/`. Blogindlæggene opdateres til den endelige URL, og sitemap samt canonical kontrolleres. Mellem-adressen beholdes som direkte redirect, fordi den stadig findes i eksterne links.

Efter rettelsen testes alle tre adresser. Den endelige side skal svare med 200, mens de to gamle hver skal bruge ét hop. Der kontrolleres også, at ingen regel skaber en 404-fejl eller sender til en side med et helt andet emne.

Guiden om SEO-optimering af en hjemmeside kan bruges som en bredere ramme, men selve redirect-arbejdet bør altid udføres med en konkret URL-liste og en efterfølgende test.

Den største faldgrube er at oprette redirects løbende uden at kontrollere eksisterende regler. WordPress-plugins, webserver, CDN og hosting kan alle have deres egne viderestillinger. Når reglerne ligger flere steder, kan ingen se hele kæden på én gang.

En anden fejl er at rydde op ved bare at slette mellemregler. Hvis den gamle adresse stadig har trafik eller backlinks, kan resultatet blive en 404. Oprydning betyder normalt, at startadressen kobles direkte til slutmålet – ikke at historikken ignoreres.

Pas på brede wildcard-regler. En regel, der sender alt under en gammel mappe til én ny side, kan være nem at skrive, men den kan ødelægge relevante destinationer. Kortlæg først hvilke URL’er der findes, og lav mønstre, der kan testes med realistiske eksempler.

Det er også en fejl at sende alt til forsiden. Brugeren har klikket på et bestemt produkt, en artikel eller en service. En generel forside er sjældent den nærmeste erstatning. Irrelevante redirects kan opleves som en blindgyde, selv om statuskoden teknisk set er korrekt.

Endelig kan cache skjule resultatet. Browsercache, cache i WordPress og CDN-cache kan få en gammel regel til at se aktiv ud, efter den er ændret. Ryd relevante lag og test i et nyt browservindue eller med et værktøj, der viser de faktiske HTTP-svar.

Google anbefaler at undgå lange redirect-kæder og at sende videre direkte til den endelige destination. En enkelt relevant redirect er en normal del af webdrift. Problemet er de unødvendige hop og uklare slutmål.

Kæder bruger en del af crawlerens tid. På et lille site er et par enkelte kæder sjældent katastrofale, men på store sites kan mønsteret bidrage til dårligere udnyttelse af crawl budget. Derfor bør omfang og prioritet vurderes i forhold til sitets størrelse.

Redirects skal normalt være server-side HTTP-redirects. JavaScript- eller meta refresh-løsninger kan have særlige anvendelser, men de er mindre robuste som standardløsning. Brug den enkleste tekniske metode, der passer til platform og hosting.

Når et domæne flyttes, kan flere normaliseringer være nødvendige: http til https, gammelt domæne til nyt domæne og gammel sti til ny sti. Planlæg dem som én samlet destination, så brugeren ikke bliver sendt gennem hvert historisk trin.

Kontrollér også links i PDF’er, nyhedsbreve og eksterne profiler. De kan ikke altid opdateres, men de forklarer, hvorfor en gammel adresse stadig har trafik. Interne links og egne profiler bør derimod ændres til slutadressen, når det er muligt.

En god redirect-liste bliver vedligeholdt som en del af hjemmesidens tekniske dokumentation. Det gør næste redesign mindre risikabelt og reducerer behovet for at gætte på, hvorfor en bestemt regel blev oprettet.

Kør en fast kontrol efter større publiceringer, domæneændringer og redesigns. Filtrér rapporten efter tre eller flere statuskoder i samme forløb, og gennemgå de mest besøgte eller mest linkede adresser først.

Test derefter slutmålets relevans, ikke kun om det svarer. En status 200 kan stadig være forkert, hvis brugeren lander på en side, der ikke svarer til det oprindelige link.

Kontrollér til sidst, om den gamle URL stadig bliver brugt internt. En teknisk regel kan være rettet, mens navigation, sitemap eller indhold fortsat sender besøgende gennem den. Begge dele skal være på plads.

Når kontrollen dokumenteres med før- og efterliste, bliver redirect-arbejde en overskuelig del af vedligeholdelsen frem for en bunke regler, ingen tør røre.