How it works
Browsers follow redirects silently, so you only see where you land. We follow them one at a time instead: request the URL, read the status code and Location header, and repeat, up to 10 hops. Each hop shows its status, where it points and how long the server took to answer. Every hop is validated before we follow it, so a redirect can’t send the checker to a private address.
What we flag
- Chains.
http://example.com→https://example.com→https://www.example.comis two hops where one rule would do. Common after a site moves hosts twice. - Temporary redirects on permanent moves. A 302 tells search engines the old URL may come back, so they may keep it indexed. HTTPS upgrades, www rules and renamed pages should be 301 or 308.
- Loops. A rule that sends the URL back to one it already visited. Browsers show an error page.
- Downgrades. Any hop from
httpsback tohttp. - A bad ending. A chain that ends in a 404 or 5xx loses the page completely.
- Slow hops. Over a second to answer a redirect usually means an app server is doing work a CDN rule could do instantly.
Fixing a chain
- Find the final URL (the last hop above).
- Change the first rule to point straight at it. On most hosts that means one rule that matches both
http://and the non-canonical host. - Update internal links, canonicals and your sitemap to use the final URL, so nothing hits the redirect.
- Run the checker again on the old URL and on the http:// and www variants.
Then check the sitemap lists only final URLs with the sitemap checker, and that the final page’s canonical points to itself with the meta tag checker.
Limits
We follow HTTP redirects only. Meta refresh tags and JavaScript redirects happen in the browser and aren’t followed. Some sites answer bots differently from browsers, so a firewall may show us a block page or a challenge instead.