Core/Dash Dimension: Antal redirects

Dimension: Navigation: Antal redirects (redir)

Dimensionen redir tæller HTTP-redirects, før den endelige side nås. Værdierne er 0, 1, 2 eller 3+. Hver redirect er en fuld netværks-roundtrip, der sker, før din server overhovedet begynder at generere HTML.

På en 100 ms RTT-forbindelse tilføjer én redirect 100 ms til TTFB. På en 200 ms mobilforbindelse fordobles det. To redirects på mobil: 400 ms ren ventetid, før browseren modtager en enkelt byte af din side. Denne latens er usynlig i lab-tests, der rammer den endelige URL direkte, men rigtige brugere, der følger links, bogmærker eller søgeresultater, absorberer den ved hvert besøg.

Værdierne

0 redirects

Måltilstanden. Browseren ramte den endelige URL ved den første anmodning. Al intern navigation bør give denne værdi. Hvis dit eget sites links, sitemaps og canonical-tags er korrekte, forbliver den interne trafik på 0.

1 redirect

Almindeligt for ekstern trafik: opgraderinger fra HTTP til HTTPS, www-normalisering eller URL'er til marketingkampagner. Acceptabelt for indgående links, du ikke kontrollerer. Ikke acceptabelt for dine egne interne links. Hvis CoreDash viser 1 redirect på interne navigationer, peger dine links på gamle eller inkonsekvente URL'er.

2+ redirects

Redirect-kæder. En forkortet URL redirecter til et sporingsdomæne, som redirecter til dit HTTP-endpoint, som redirecter til HTTPS. Tre hop, tre roundtrips. Gruppér efter URL for at finde ud af, hvilke indgangspunkter der skaber disse kæder, og eliminér derefter mellemleddene.

Hvor redirects kommer fra

• HTTP til HTTPS: Forældede interne links, der stadig peger på http://. Opdatér alle links, sitemaps og canonical-tags til at bruge https:// direkte.
• www-normalisering: Inkonsekvens mellem www og ikke-www. Gennemtving én på DNS-niveau, og opdatér alle referencer.
• Ændringer i CMS-slugs: Gamle stier, der redirecter til nye stier via 301. Fint for eksterne backlinks, men opdatér hvert internt link til at pege direkte på den nye slug.
• Vanity-URL'er til marketing: Vanity-stier som /spring-sale, der redirecter til /products/seasonal. Hver besøgende betaler latensomkostningen ved hvert klik.
• URL-forkortere i e-mail og på sociale medier: Links, der passerer gennem Bitly, sporingspixels eller e-mailtjenesteudbydere, før de når dit domæne. Hver tjeneste tilføjer en roundtrip, du ikke kan kontrollere, men du kan minimere dine egne redirects, så det samlede antal forbliver lavt.

Debugging-workflow

1. Filtrér for redir ≥ 1: Se, hvor stor en procentdel af din samlede trafik der rammer mindst én redirect. Alt over 15 % er værd at undersøge.
2. Gruppér efter URL: Find ud af, hvilke landingssider der er de værste syndere. Marketingsider og gamle blogindlæg med ændrede slugs har tendens til at dominere.
3. Opdel intern vs. ekstern: Filtrér efter navigation origin. Same-origin-trafik med redirects betyder, at dine egne links er forkerte. Cross-origin-redirects er sværere at rette, men mindre presserende.
4. Fiks kilden, ikke redirecten: Optimér ikke selve omdirigeringen (hurtigere serversvar). Eliminér den ved at opdatere det link, der forårsagede den.

Tekniske tommelfingerregler

• 0 redirects på al intern navigation. Ingen redirect fra dit eget site er acceptabel, når du kontrollerer kildelinket.
• Foretag en audit efter hver URL-migrering. Når du ændrer slugs eller flytter sider, så grep din kodebase og dit CMS for de gamle stier. Redirects er et sikkerhedsnet for eksterne links, ikke en erstatning for at opdatere dine egne referencer.
• Afsæt 150 ms per redirect på mobil. Hvis dit TTFB-mål er 800 ms, og brugerne rammer to redirects, har du allerede brugt 300 ms, før din server overhovedet laver noget arbejde.

Redirects er den nemmeste TTFB-gevinst at finde og rette. Ingen kodeændringer, ingen server-tuning, ingen asset-optimering. Opdatér bare den URL, der peger på det forkerte sted.