Redirect Checker

This redirect checker follows every URL you enter one hop at a time and shows each status code, from the first request to the final page. Paste up to 500 URLs, or upload a list, a crawl export, or an XML sitemap, and it finds redirect chains, loops, 404s, server errors, temporary redirects, HTTPS downgrades, and redirects to the home page. It also tests a redirect map, so you can see which old URLs reach the right page and which don’t.

How to use the redirect checker

• Add your URLs. Paste them one per line, or any text with URLs in it, or upload a .txt, .csv, .xlsx, or sitemap .xml file. Bare domains such as example.com are checked as https://.
• Choose who to check as. The default is our own user agent. You can also check as Chrome on Windows or Android, Googlebot Smartphone, or Bingbot, because some sites redirect phones and bots differently.
• Start the check. The redirect checker shows each result as soon as it’s ready. It requests up to four URLs at a time, and no more than two from one site, so your server isn’t overloaded.
• Review the problems. Select a number in the summary to filter the list, open a URL to see every hop, or use the Issues tab for each problem with its fix.
• Download the results. Export every result or every issue as CSV, or download a redirect map that points each old URL straight to its final page.

What the HTTP status codes mean

Every response starts with a three-digit status code. The HTTP status checker shows the code for each hop, so you can see exactly where a chain goes wrong:

These rules come from Google’s guides to how HTTP status codes affect its crawlers and redirects and Google Search. If a URL never answers at all, the redirect checker tells you why: the domain doesn’t resolve, the SSL certificate is invalid, the connection was refused, or it timed out.

Redirect chains and loops

A redirect chain is a URL that redirects more than once before it reaches a page, such as http://example.com/ to https://example.com/ to https://www.example.com/. Google’s crawlers follow up to 10 hops, but its site move guide advises redirecting straight to the final page, and if that isn’t possible, keeping chains to no more than 3 hops.

Chains build up over time: a site moves to HTTPS, then to www, then a page is renamed, and each change adds another rule. The redirect checker works as a redirect chain checker too, listing each chain with its codes, such as 301 → 301 → 200, so you can point the first URL straight at the last one. A loop is worse: the redirects lead back to a URL already in the chain, so the page never loads. The redirect checker stops a loop as soon as it repeats, and any chain after 10 hops.

A redirect without a Location

A 3xx response must include a Location header that says where to go, as the HTTP standard describes. A broken plugin or server rule can return 301 with no Location, which leaves browsers and crawlers stuck, so the 301 redirect checker reports it as an error.

Other problems the redirect checker finds

• Temporary redirects for permanent moves. A 302 or 307 tells Google to keep the old URL in search results. If the page has moved for good, use 301 or 308.
• Redirects to the home page. Google says sending many old URLs to the home page can confuse visitors and might be treated as a soft 404. Send each URL to the closest matching page instead, or let it return 404 or 410.
• HTTPS to HTTP. A redirect from a secure URL to an insecure one exposes visitors and can trigger browser warnings. HTTP pages that don’t redirect to HTTPS are flagged too.
• Meta refresh and JavaScript redirects. Google treats an instant meta refresh as permanent and a delayed one as temporary, and only sees JavaScript redirects after rendering the page. A server-side 301 is faster and more reliable.
• Signals on the final page. The checker reads the final page’s canonical, robots meta tag, and X-Robots-Tag header, and warns about noindex or a canonical that points elsewhere.
• Site versions that end in different places. Select Add http and www versions to add the http, https, www, and non-www home pages of each site and see whether they all end at one URL.

Test a redirect map before and after a migration

Before a migration or redesign, you usually have a spreadsheet of old URLs and their new pages. In the redirect checker’s Test a redirect map tab, paste the two columns, upload the .csv or .xlsx file, or paste Apache Redirect 301 lines. If the old URLs are paths such as /old-page/, add the site address once.

Each old URL gets one result: Pass when it ends at the expected page, Close match when only a trailing slash, letter case, http or https, or www differs, or when the expected URL redirects again, Wrong target, Not redirected, or Broken. Wrong targets often come from a folder or wildcard rule that matches first. Test the map on staging before launch, and again on launch day.

Fix chains with the redirect map download

After a URL check, the redirect checker’s Redirect map without chains button downloads a CSV of every URL that redirects, with its final page and the code 301. Import it into the htaccess Redirect Generator to turn it into rules for Apache, Nginx, IIS, Cloudflare, Netlify, Vercel, or a WordPress redirect plugin, so each old URL reaches its final page in one hop. Then update internal links, canonicals, and your sitemap to use the final URLs, and check the sitemap with the XML Sitemap Validator. Google suggests keeping redirects for as long as possible, generally at least a year.

Checking as Googlebot

Some sites redirect bots, phones, or visitors from some countries differently, which hides problems from your own browser. Choose Googlebot Smartphone in the redirect checker to see what a site sends to a client that identifies as Google’s smartphone crawler. The requests come from our server, not from Google, so sites that verify Googlebot by its IP address may block them or treat them as an ordinary visitor. To see what Google really requested, use your server logs with the Bot Log Analyzer.

Limits, privacy, and how it works

Browsers can’t read another site’s redirects directly, so the redirect checker requests each URL from our server, one hop at a time. Each hop has an 8-second timeout, each URL stops after 10 redirects or 25 seconds, and only the first 64 KB of the final page is read for its title, canonical, and robots tags. You can check up to 500 URLs at a time and 1,000 URLs an hour. Private and local addresses can’t be checked. Results go to your browser and aren’t stored, so the bulk URL status checker is as safe for a client’s site as for your own.