# How do I check if my 301 redirects are working correctly?

> Check a redirect by requesting the old URL and confirming it returns a single 301 status straight to the correct final URL, with no chain, no loop, and the right destination. Do this for a sample by hand with a redirect checker or your browser's network tab, and for the whole site with a crawl that reports the status and hop count of every URL. WPBuildAI verifies the redirect map after a migration, so every old URL resolves in one hop.

Source: https://wpbuildai.com/check-if-301-redirects-are-working-correctly/
By lawrence-arya · 2026-06-06

---
To check that your 301 redirects are working correctly, you are confirming one thing per URL: the old address returns a single 301 straight to the correct final page, with no chain and no loop. That is the whole test, and it scales from a quick spot-check to a full-site report. By hand, use a redirect checker or your browser's network tab on important URLs. For the whole site, run a crawl that reports the status, destination, and hop count of every URL. WPBuildAI verifies the redirect map after a migration, so every old URL resolves in one hop to the right page.

There is one check that is easy to skip: after Google's June 2026 site move update, a complete pass has to cover [all domain variants, including the www and non-www forms](https://searchengineland.com/for-site-moves-specify-all-domain-variants-with-googles-change-of-address-tool-480552) you may not actively use, because a variant that quietly resolves on its own is a redirect you never tested.

## What a correct redirect looks like

Knowing the target makes the check simple, because you are confirming the presence of one good outcome and the absence of several bad ones. A correct redirect is a single response with a 301 status whose location header is the true replacement URL, reached in one hop. Google's [redirects guidance](https://developers.google.com/search/docs/crawling-indexing/301-redirects) explains why that single permanent hop is what passes ranking signals cleanly. So your check looks for: status 301 (not 302, not 200, not 404), one hop (not a chain), and a destination that is the real replacement page (not the homepage or an unrelated page). If all three hold, the redirect is correct. If any fails, you have found a problem to fix. Framing the check as "one permanent hop to the right page" gives you a precise pass/fail test for every URL rather than a vague sense of whether redirects "work."

## How to check one URL by hand

For a handful of important URLs, a manual check is quick and instructive. Use a redirect checker tool, paste the old URL, and it shows the full chain of responses with status codes and destinations, so you can see whether it is a single 301 to the right place or a chain. Or use your browser's developer tools: open the network tab, enable "preserve log," load the old URL, and read the sequence of requests, each redirect appears as its own entry with its status and location, and the final entry should be a 200 on the correct destination. Checking by hand this way is worth doing for your highest-value URLs because it shows you exactly what is happening, which builds intuition for what the at-scale report is flagging. But it is only practical for a few URLs; a whole migration needs the scaled approach.

## Verify at scale, not by sampling

A migration produces far too many redirects to check by hand, so the real verification is a crawl. Use a crawler that takes your list of old URLs and reports, for each, the final status code, the destination URL, and the number of hops it took to get there. That turns thousands of individual checks into one report you can sort and filter: everything that is not a clean single-hop 301 to the right page stands out. The 2024 [Web Almanac](https://almanac.httparchive.org/en/2024/) shows how common multi-hop chains are across the web, which is exactly what a scaled check surfaces that spot-checking misses. Because a small share of pages carries most traffic, Ahrefs found in its [search traffic study](https://ahrefs.com/blog/search-traffic-study/) that verifying the high-value URLs first protects most of the rankings, so sort the report by traffic and confirm those rows individually even within the scaled check.

## A worked example: verifying 500 redirects

Picture a migration with 500 redirects to verify. Checking them by hand would take a day and you would still miss some; instead you feed the 500 old URLs into a crawler. The report comes back with each URL's final status, destination, and hop count. Filtering it, you find 470 are clean single-hop 301s to the right pages, fine. The other 30 break down into: 12 chains (two or more hops), 8 that return 302 instead of 301, 6 that 404 because the redirect was never added, and 4 pointing at the homepage instead of the real replacement. That is a precise fix list, generated in minutes. You collapse the chains, change the 302s to 301s, add the 6 missing redirects, and re-point the 4 homepage dumps to relevant pages, then re-run the crawl to confirm all 500 are now clean. The scaled check turned an impossible manual task into a finite, verifiable one.

## What the check should catch

A good verification catches five specific problems, each with a clear fix. Chains, where a URL passes through multiple hops, which you collapse to one, the issue in [the too many redirects error](/301-redirects-causing-too-many-redirects-error-migration-fix/). Loops, where redirects point back at each other until the browser gives up, the same error's worst form. 404s, where a redirect is missing entirely, the basis for [fixing broken links](/fix-broken-links-wordpress-after-migration/). 302s that should be 301s, which signal a temporary move and withhold the equity transfer. And redirects pointing at the wrong or a generic page, like the homepage, instead of the true replacement. Each is fixable once found, and the value of verifying is finding them before they cost rankings, not discovering them weeks later in Search Console. This closes the loop on [setting up the redirects](/set-up-301-redirects-moving-wordpress-to-ai-website-builder/) from the [URL mapping template](/website-url-mapping-template-excel-automated/).

## When to verify: before and after launch

Timing matters, and the strongest approach verifies twice. Before launch, verify the redirects on staging so you catch chains, 302s, missing rules, and wrong targets while they are cheap to fix and no visitor has hit a broken URL. Google's [site move guidance](https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes) frames verification as part of a safe move for exactly this reason. After launch, verify again on the live site, because the production environment can behave differently from staging, caching, the live server config, and the CDN can all affect how redirects resolve, and then watch Search Console over the following weeks for any old URLs slipping into not-found states that the crawl did not predict. The pre-launch check prevents problems; the post-launch check confirms the live environment matches and catches anything environment-specific. Doing both is what turns "we set up redirects" into "the redirects provably work in production."

## Reading the status codes correctly

Part of verifying is interpreting what you see, since the status codes carry the meaning. A 301 is what you want for a permanent move; a 302 is temporary and the wrong choice for a migration, even though the page may appear to redirect, because it withholds the ranking-signal consolidation. A 200 on an old URL that should have moved means no redirect fired, the URL is still serving content where you expected it to redirect, which can cause duplicate-content issues. A 404 means the redirect is missing entirely. And a long chain, several 301s before a final 200, is a shape problem even though each individual hop is "a redirect." Reading these correctly prevents false confidence: a URL that "redirects" is not necessarily redirecting correctly, since a 302 or a chain technically redirects while still being wrong. The check is not "does it redirect" but "does it return one 301 to the right page," which the status codes tell you precisely.

## Common mistakes verifying redirects

The recurring errors leave broken redirects in place. Spot-checking only a few URLs misses the chains, 302s, and missing rules scattered across the rest. Checking "does it redirect" without reading the status code passes 302s and chains as if they were correct. Verifying only on staging misses environment-specific breaks that appear in production. Not re-running the check after fixing issues leaves you unsure the fixes worked. And treating Search Console as the verification, rather than a crawl, means you discover problems weeks late, after they have already cost rankings. Each is avoided by the same approach: verify the whole set with a crawl that reports status, destination, and hops, read the codes precisely, check before and after launch, prioritise high-value URLs, and re-run after fixing, which is what makes the redirects provably correct rather than assumed.

## Key points to remember

Check your 301 redirects by confirming, per URL, a single 301 status straight to the correct final page, no chain, no loop, no 302, no 404, no homepage dump. Spot-check your highest-value URLs by hand with a redirect checker or the browser network tab to see exactly what happens, then verify the whole site with a crawl that reports each URL's status, destination, and hop count, filtering for anything that is not a clean single hop. Read the status codes precisely, since a 302 or a chain technically redirects while still being wrong, and verify both before launch on staging and after launch in production, watching Search Console for stragglers. WPBuildAI verifies the full redirect map after a migration, so every old URL resolves cleanly in one hop; send your site URL for a fixed quote.

Not affiliated with Google, WordPress, or Lovable.