How to test redirects after a migration: every row, one hop, a 200

“It redirects” is not the test. A url can redirect and still be wrong in four different ways, and each outcome below points at a different fix.

Some hosts answer their own redirects with a 308 rather than a 301; Google’s documentation treats the two as equivalent, so count both as a pass. The background on each code is in 301 vs 302 vs 410.

• every source in the map, not a sample. The rows that break are rarely the ones you would pick by hand.
• the urls planned as gone, to confirm they answer 410 (or 404) and not a 200 from an old page nobody unpublished.
• variants of the top pages: http://, the other host (www or bare domain), with and without a trailing slash. A map that is flat for the canonical spelling can still take three hops for http://example.com/page.
• urls under each wildcard rule that the crawl never found — a few from the server logs or Search Console. That is what the wildcard was for.

If the map came from Silentfrog, the generic csv is already that list: its first two columns are source_url and target_url, absolute urls, and unmatched rows are included with an empty target — which in the test should come back as the 410s or 404s you decided on (the two downloads). If the new site was crawled on a staging domain, replace that host with the live domain in the target column first. Source urls are written normalised, in lowercase and without a trailing slash, so add the original spellings of important urls separately.

Google’s site move guide suggests exactly this: “Test the redirects. You can use the URL Inspection Tool for testing individual URLs, or command line tools or scripts to test large numbers of URLs.” This loop reads a csv whose first two columns are the old url and the planned target, makes two requests per row — one without following redirects for the first status, one following them — and writes a tab-separated result:

tail -n +2 silentfrog-redirects.csv | cut -d, -f1,2 | while IFS=, read -r url planned; do
  first=$(curl -s -o /dev/null --max-time 15 -w '%{http_code}' "$url")
  result=$(curl -s -o /dev/null --max-time 15 -L --max-redirs 10 \
    -w '%{num_redirects}\t%{http_code}\t%{url_effective}' "$url")
  printf '%s\t%s\t%s\t%s\n' "$url" "$planned" "$first" "$result"
done > redirect-check.tsv

The columns are old url, planned target, first status, number of redirects followed, final status and final url. num_redirects, http_code and url_effective are curl’s own write-out variables; --max-redirs 10 matches the number of hops Google’s crawlers follow by default. Then print only the rows that fail:

awk -F'\t' '$3 !~ /^30[18]$/ || $4 != 1 || $5 != 200 || ($2 != "" && $6 != $2)' redirect-check.tsv

A row is printed when the first status is not 301 or 308, when the number of hops is not exactly one, when the final status is not 200, or when it lands somewhere other than the planned target. Empty-target rows always print, so the urls you retired are in the same list to confirm, and so do rows whose old and new path are the same: they answer 200 straight away and pass if the page is the right one.

three caveats — the comparison with the planned target is a text comparison, so the map must use the same spelling as the live site (https, host, trailing slash). cut -d, splits on every comma, which breaks for the rare url that contains one. And the loop uses full GET requests, not HEAD, because some servers answer HEAD differently — at a few thousand urls, consider a short sleep between rows to stay polite to your own server.

If you prefer a ui, a desktop seo crawler does the same job. In Screaming Frog, its redirect audit tutorial describes the setup: switch to list mode, upload the old urls, enable “Always Follow Redirects” in the advanced configuration so chains are followed to the end, crawl, and export the All Redirects report. It has one row per uploaded url with the number of redirects, whether the chain loops, the final status code and the final address — the same columns as the curl loop, plus every hop in between. The free version stops at 500 urls.

Either way, the check needs the old urls as input. A crawler pointed at the new site’s homepage only sees the new site’s links and never requests the old addresses.

The live test is done in an afternoon; Google’s side takes weeks. The site move guide puts it at “a few weeks for most pages to move” for a small to medium-sized site, longer for larger ones, and warns that visibility “may fluctuate temporarily during the move.”

The report and reason names are the ones Search Console uses in its page indexing report and its crawl stats report (under settings). Use the URL Inspection tool for single urls you want to look at closely. If the domain changed, the Change of Address tool belongs in the same week — Google says it is only needed for a move from one domain or subdomain to another.

The test is only as complete as the list it runs on. Silentfrog builds that list before launch: it crawls the old site and reads its sitemaps, accepts your own url list on top, matches every old url to a page of the new site that answered 200 during the crawl, and lets you review the uncertain rows before export. It does not test the live site afterwards — that is what this page is for.

The steps around it are in the website migration checklist; what to do with rows that take two hops is in redirect chains and loops.

• A pass is 301 (or 308), exactly one hop, a final 200, and the planned target — all four.
• Test every source in the map, the retired urls, host and protocol variants, and urls under each wildcard.
• A curl loop with num_redirects, http_code and url_effective checks thousands of rows; a list-mode crawl does the same with a ui.
• Watch Page with redirect grow while Not found (404), Redirect error and Soft 404 stay flat.
• Google needs weeks to process a move; keep checking for two to three months and keep the rules for at least a year.

No map yet? Build it in Silentfrog — the first 50 pages of the old site are free, and the csv it exports is the input for every check on this page.