Core/Dash Dimension: Redirect Count

Dimension: Navigation: Redirect Count (redir)

The redir dimension counts HTTP redirects before reaching the final page. Values are 0, 1, 2, or 3+. Each redirect is a full network round trip that happens before your server even starts generating HTML.

On a 100ms RTT connection, one redirect adds 100ms to TTFB. On a 200ms mobile connection, that doubles. Two redirects on mobile: 400ms of pure waiting before the browser receives a single byte of your page. This latency is invisible in lab tests that hit the final URL directly, but real users following links, bookmarks, or search results absorb it on every visit.

The values

0 redirects

The target state. The browser hit the final URL on the first request. All internal navigation should produce this value. If your own site links, sitemaps, and canonical tags are correct, internal traffic stays at 0.

1 redirect

Common for external traffic: HTTP to HTTPS upgrades, www normalization, or marketing campaign URLs. Acceptable for inbound links you do not control. Not acceptable for your own internal links. If CoreDash shows 1 redirect on internal navigations, your links are pointing to old or inconsistent URLs.

2+ redirects

Redirect chains. A shortened URL redirects to a tracking domain, which redirects to your HTTP endpoint, which redirects to HTTPS. Three hops, three round trips. Group by URL to find which entry points create these chains, then eliminate intermediaries.

Where redirects come from

• HTTP to HTTPS: Outdated internal links still pointing to http://. Update all links, sitemaps, and canonical tags to use https:// directly.
• www normalization: Inconsistency between www and non-www. Enforce one at DNS level and update all references.
• CMS slug changes: Old paths redirecting to new paths via 301. Fine for external backlinks, but update every internal link to point directly to the new slug.
• Marketing vanity URLs: Vanity paths like /spring-sale redirecting to /products/seasonal. Every visitor pays the latency cost on every click.
• URL shorteners in email and social: Links passing through Bitly, tracking pixels, or email service providers before reaching your domain. Each service adds a round trip you cannot control, but you can minimize your own redirects so the total stays low.

Debugging workflow

1. Filter for redir ≥ 1: See what percentage of your total traffic hits at least one redirect. Anything above 15% is worth investigating.
2. Group by URL: Find which landing pages are the worst offenders. Marketing pages and old blog posts with changed slugs tend to dominate.
3. Split internal vs external: Filter by navigation origin. Same origin traffic with redirects means your own links are wrong. Cross origin redirects are harder to fix but less urgent.
4. Fix the source, not the redirect: Do not optimize the redirect itself (faster server response). Eliminate it by updating the link that caused it.

Engineering rules of thumb

• 0 redirects on all internal navigation. No redirect from your own site is acceptable when you control the source link.
• Audit after every URL migration. When you change slugs or move pages, grep your codebase and CMS for the old paths. Redirects are a safety net for external links, not a substitute for updating your own references.
• Budget 150ms per redirect on mobile. If your TTFB target is 800ms and users hit two redirects, you have already spent 300ms before your server does any work.

Redirects are the easiest TTFB win to find and fix. No code changes, no server tuning, no asset optimization. Just update the URL that points to the wrong place.