En redirect chain er en kæde, hvor én URL viderestiller til en ny URL, som igen viderestiller videre. Et simpelt eksempel er A → B → C i stedet for A → C.
Kæder opstår ofte, når URL’er ændres flere gange, eller når gamle redirect-regler ikke bliver opdateret. Hvert ekstra hop kræver endnu en HTTP-anmodning og gør løsningen langsommere og mere sårbar.
Hvorfor er redirect chains et problem?
- Ekstra ventetid: Browseren eller crawleren skal gennemføre hvert hop, før slutindholdet kan hentes.
- Crawl-arbejde: Flere anmodninger bruges på den samme destination.
- Flere fejlpunkter: Et udløbet domæne, en forkert regel eller et loop kan afbryde kæden.
- Sværere fejlsøgning: Canonicals, interne links og sitemaps kan ende med at pege på forskellige led.
Google oplyser, at permanente serverside-redirects ikke medfører tab af PageRank. Derfor er “lidt linkværdi tabt ved hvert hop” ikke en god forklaring. Den praktiske grund til at forkorte kæden er hastighed, crawl-effektivitet og robusthed.
Sådan finder og retter du kæden
- Crawl sitet og eksportér URL’er med 3xx-status.
- Følg hver redirect til den endelige URL og markér forløb med mere end ét hop.
- Ændr den første regel, så A peger direkte på C.
- Ret interne links, canonicals og sitemap, så de peger direkte på C og ikke på en redirect.
- Test både gamle indgående adresser og slut-URL’ens statuskode.
Kæde eller loop?
En kæde når frem til en slutside. Et redirect loop sender derimod anmodningen rundt uden et gyldigt slutpunkt, for eksempel A → B → A. Et loop skal rettes straks, fordi brugeren ikke kan åbne indholdet.
Ved en større migrering bør redirect-kortet gennemgås før lancering, så historiske URL’er peger direkte mod deres endelige erstatning. Det gør det også lettere at bevare reglerne korrekt, når sitet flyttes igen.
Kilder kontrolleret 10. oktober 2026: Google Search Central om redirects og Google om redirect chains ved site moves.