12 min read
How to Check URL Redirects (and Read a Redirect Chain)
Check URL redirects step by step with TrueURL, curl and DevTools, read every hop of a redirect chain, and fix loops, long chains and mixed 301/302 redirects.
Read articleFree redirect tool
Mobile vs Desktop Redirect Checker
Check one URL twice, as desktop Chrome and as Safari on iPhone, and compare both redirect chains side by side. Spot device-based redirects that send mobile visitors somewhere unexpected.
Cloudflare's edge always validates certificates, so this cannot skip the check. Certificate problems are reported in the result.
Sent with the first request, up to 16 KB. JSON bodies are sent as application/json, others as a form, unless you set a Content-Type header.
1 to 50. Browsers stop after 20.
Sites can redirect phones, crawlers and link preview bots differently.
Custom Request Headers 0/20
Sent with every request in the chain.
No custom headers.
Enter a value to send this header. Header values are never saved.
Follow <meta http-equiv="refresh"> tags and Refresh headers found in HTML pages.
Follow simple, unconditional redirects such as location.href = "…" in page scripts.
Settings are remembered in this browser. Cookies, header values and the POST body are never saved.
Why mobile and desktop redirects differ
Some sites decide where to send a visitor based on their device, detected from the User-Agent header. Typical examples are separate mobile sites (m.example.com), app download pages, store or region selectors and ad landing pages. When that logic is wrong, mobile visitors end up on the home page, an error page or a page unrelated to the link they followed.
Google mainly crawls and indexes the mobile version of pages, so a broken mobile redirect hurts search visibility as well as the user experience.
How the comparison works
TrueURL checks the URL twice with the same settings, changing only the User-Agent: a recent desktop Chrome on Windows and Safari on iPhone. The two redirect chains are shown side by side with their final URLs and status codes, so any difference stands out at a glance.
Only the User-Agent changes. Sites that choose a version by screen size in JavaScript may behave the same in both columns, even though they look different on a real phone. To test other agents, such as Chrome on Android or Googlebot, pick a preset in Advanced Settings on the Redirect Chain Checker.
What a good result looks like
- Responsive site: both columns end on the same final URL. This is the setup Google recommends and the easiest one to maintain.
- Separate mobile URLs: desktop stays on
www.example.com/pageand mobile goes to the equivalentm.example.com/page, not to the mobile home page. The desktop page should point to its mobile URL with<link rel="alternate" media="only screen and (max-width: 640px)" href="https://m.example.com/page">, and the mobile page should have a canonical tag pointing back. - Dynamic serving: the same URL for both, with different HTML. The response should include
Vary: User-Agentso caches don't mix up the versions.
Common mobile redirect mistakes
- Faulty redirects: every mobile visitor is sent to the mobile home page instead of the matching page.
- Missing mobile pages: a desktop page without a mobile version redirects to an error. Serve the desktop page instead.
- One-way redirects: mobile users are redirected, but desktop users who open an
m.link aren't sent back to the desktop page. - App interstitials: a redirect to an app store or a full-screen app banner hides the content the visitor came for.
- Extra hops on mobile only: a detour through a device-detection or tracking service, which hurts most on slow mobile connections.
Guides
Frequently asked questions
Which User-Agents does the comparison use?
Desktop Chrome on Windows and Safari on iPhone, both with recent version numbers. Practically all device-detection code recognises the first as a desktop computer and the second as a phone.
Does Google see the mobile or the desktop result?
Mostly the mobile one. Google crawls and indexes the web primarily with Googlebot Smartphone, whose User-Agent looks like Chrome on an Android phone. If the mobile column ends on the wrong page, Google may index that too. To see what a site sends to Googlebot's User-Agent, use the Googlebot smartphone preset in Advanced Settings on the Redirect Chain Checker. Sites that verify Googlebot by its IP address may still answer TrueURL differently.
Are separate mobile URLs (m-dot sites) bad for SEO?
They're supported, but harder to get right: every page needs a matching mobile URL, correct annotations and redirects in both directions. Google recommends responsive design, which avoids device redirects altogether. If you run an m-dot site, check your key pages here after every release.
Why are both columns identical when my site looks different on a phone?
Your site probably adapts in the browser, with responsive CSS or JavaScript, rather than with server-side redirects. That's the recommended approach, and it means there is no device-based redirect to compare.
Can I compare other devices, such as Android phones or tablets?
This tool compares desktop Chrome with Safari on iPhone. For other devices, open Advanced Settings on the Redirect Chain Checker, choose a preset such as Chrome on Android or paste any User-Agent string, and run the check.
Do device redirects slow down mobile pages?
Yes. Every redirect costs a full round trip before the page starts loading, and mobile networks have higher latency than broadband. A redirect from www to m. alone can add a noticeable delay; you can measure it with the Redirect Latency Checker.