Checking HTTP Status Codes: Testing Redirects After a Relaunch

8 min read Auf Deutsch lesen

In short

Whether a redirect works is shown only by the status code the server returns at every hop, not by the browser. After a relaunch, every old URL should lead in one step with 301 or 308 to its content equivalent, http and www included. According to Google's documentation, Googlebot follows at most 10 redirects. Typical mistakes are 302 instead of 301, chains over several hops, blanket redirects to the homepage and a forgotten noindex in the header.

After a relaunch or a move to a new domain, everything often looks right in the browser: you type in an old address and land on the new page. Whether the redirect is also clean for search engines is something you can’t see that way. For that you need to know what the server answers at every hop. Below is which status codes to expect, how to check them and which mistakes we find most often.

The status codes that matter

Every response from a web server starts with a three-digit code. For redirects and moves, these are the relevant ones:

Code Meaning When it’s right
200 OK, content follows At the end of every chain
301 Moved permanently Relaunch, domain change, changed URL
308 Moved permanently, method kept Like 301, e.g. for form endpoints
302 / 307 Temporarily elsewhere Maintenance, short-term campaigns
404 Not found Page doesn’t exist and never did
410 Permanently removed Deleted on purpose, no replacement
5xx Server error Never, it’s an error

Which redirect passes on which signals is explained in our glossary under 301 redirect.

Why the browser misleads you when checking

Browsers cache permanent redirects. Once you have requested an old URL, you are redirected directly next time without asking the server. If you have since changed or broken the redirect, your own browser won’t tell you.

On top of that, the browser only shows the end of the chain. Whether it got there via one, two or four hops, and whether there was a 302 in between, isn’t visible in the address bar. Checking therefore needs a tool that queries every hop from the server individually.

Checking with the HTTP status checker

Our checker queries up to 20 URLs at once and follows every redirect individually, up to 10 hops. For every hop you see the status code, response time and response headers. Unlike our other tools, the request runs via our server, because the browser isn’t allowed to query foreign addresses itself.

HTTP Status Checker

Check status codes and redirects

One URL per line, up to 20 at once. Every step of the redirect chain is shown separately.

    Requests go through our server in Germany because browsers aren’t allowed to query other sites directly. URLs are not stored. Public addresses on ports 80 and 443 only, at most 60 checks per ten minutes. Details in our privacy policy.

    Two settings help with troubleshooting:

    • User agent: with “Googlebot” or “Safari (iPhone)” you see whether the site answers certain visitors differently. Our request doesn’t come from Google’s IP addresses. A firewall that checks this may block it, which is then not a fault of your site.
    • Method: the default is GET. Some servers answer HEAD requests differently or not at all. If HEAD gives an odd result, cross-check with GET.

    What to check after a relaunch

    Take the most important old URLs, ideally the ones with the most clicks in Search Console, and check them in these variants:

    1. http and https, with and without www. All four variants of the homepage should lead to the one correct address in one step. Often it’s two: first http to https, then to www.
    2. Old subpages. Every old URL should lead in one step with a 301 to its content equivalent and end there with a 200.
    3. With and without a trailing slash. /services and /services/ should not both answer with 200, one variant redirects to the other.
    4. Deleted pages. Without a replacement: 404 or 410. With a replacement: 301 to the replacement.
    5. The headers at the target. If there is an X-Robots-Tag: noindex, the page won’t be indexed despite a correct redirect. That happens when a setting from the development environment goes live.

    The most common mistakes

    302 instead of 301. Many plugins and hosting panels create a temporary redirect by default. A permanent move needs a 301 (or 308).

    Chains. An old URL first leads to an intermediate address and then to the target, for example because earlier moves left redirects behind. According to Google’s documentation, Googlebot follows at most 10 redirects, and browsers and users wait at every hop. Every old address should point directly to the final target.

    Loops. A redirects to B, B back to A. The checker then stops and shows the hops where it goes round in circles.

    Everything to the homepage. A blanket redirect of all old URLs to / looks to Google much like a 404. The signals of the old subpages are lost.

    Redirects via JavaScript or meta refresh. They look the same in the browser but return a 200 instead of a 301. In the checker you recognise this when the chain ends after one hop with a 200, although the browser redirects.

    Different answers per visitor. If the site answers Googlebot differently from a normal browser, a security plugin is often behind it, but sometimes malicious code that sends only search engines to foreign sites. How to find such code is covered in Reading WordPress malware.

    Creating redirects, not just checking them

    If the redirects are still missing, our redirect generator builds the rules for Apache, Nginx or Astro from an old and a new URL list. How redirect mapping fits into a relaunch is described in the article Website Relaunch: Cost, Process, and the Priciest SEO Traps.

    The checker is also available on its own under HTTP status checker, together with our other free tools.


    You’re planning a relaunch or move and don’t want to lose rankings? Find out more on the websites page, or drop us a line.

    Frequently Asked Questions

    Why does the browser show a working redirect even though it's broken?

    Browsers cache permanent redirects (301 and 308). Once you have followed a redirect, you keep landing on the old target, even if the server now answers differently. To check, use a tool that queries every hop directly from the server, such as our HTTP status checker or curl.

    Is 302 instead of 301 a problem?

    For a permanent move, yes. 302 and 307 mean "temporary": search engines then tend to keep the old URL in the index. Permanent moves call for 301 or 308. A 302 is right when the redirect really only applies briefly, for example during maintenance.

    404 or 410 for deleted pages?

    Both tell search engines that the page is gone. 410 says more clearly that it was removed on purpose. More important than choosing between them is that pages with a content equivalent are redirected with a 301 and don't end in a 404.

    Why does my site answer Googlebot differently than the browser?

    Common causes are security plugins, firewalls or CDNs that treat bots differently, and malicious code that redirects only search engines to foreign sites. Our checker lets you switch the user agent and compare the answers. Our request does not come from Google's IP addresses, though, so a firewall that checks this may still block it.

    Daniel Nilges
    Daniel Nilges

    Founder & Full-Stack Developer

    20+ years of web development experience. Specialised in Laravel, WordPress and custom software for mid-sized businesses.