A new site goes live, it looks better than the old one, and a few weeks later organic traffic starts sliding. Nobody touched the content. The old URLs just stopped working.
It's the most common way a redesign loses what the old site earned, and it's almost never a design problem. It's a URL that was never mapped, a redirect that chains through three hops, a 302 someone meant as a 301, or a noindex tag that came over from staging on launch day.
We care about this more than most, partly because three of the six criticisms in our own Clutch reviews are about details that went unchecked. So we stopped trusting a spreadsheet of redirects and started testing them with a script.
| What happens | What it costs you | |---|---| | 200 at the same path | Nothing. Best case. | | One 301/308 to the new path | A little crawl time, rankings usually follow | | A chain: 301 to 301 to 200 | Slower crawling, and each hop is one more thing to break later | | 302/307 to the new path | You're telling search engines the move is temporary | | 404 or 410 | The page and its links are gone | | 200, but noindex | Live for people, invisible to search | | 200, but the canonical points somewhere else | You asked Google to rank a different page |
The first two are fine. Everything below them is something you want to find on staging, not in Search Console a month later.
It reads the old site's sitemap (including sitemap indexes), requests every path on the new site, follows redirects by hand so it can see each hop, and checks the page it lands on.
The /blog/a chain is the sneaky one. It's usually two rules that each look right on their own: one adds a trailing slash, the other moves /blog/ to /insights/. Fix it by pointing the old URL straight at the final one.
Staging is usually noindex on purpose. If your staging site blocks indexing, every page will report noindex. That's expected there. Run the script again against production the hour you launch: the same check then catches the tag if it survived the move, which happens more often than anyone admits.
Canonicals are compared by path, not domain. Staging pages often already point their canonical at the production domain. The script compares only the path, so staging.example.com/plans with a canonical of example.com/plans passes.
Your sitemap isn't every URL that matters. Pages with backlinks don't always appear in the sitemap. Before launch, export the top linked pages from your SEO tool, or the most visited ones from analytics, and run them through the same follow() function.
Before launch, save the old sitemap and publish it somewhere stable, for example /old-sitemap.xml on the new site, then point the workflow at that. Otherwise the "old" sitemap quietly becomes the new one after launch and the check passes forever.
This catches the URL side of a redesign. It won't tell you that the new page dropped the paragraph that answered the search query, that your analytics tag didn't come across, or that a form stopped recording where the lead came from. Those are the other ways redesigns lose enquiries. We put all twelve steps in order, from the URL map to the weeks after launch, in our website redesign checklist.
Over to you: run it against your own staging site before your next launch. What's the longest redirect chain you've found in the wild? Post it in the comments, along with whatever caused it.
From the team at Redlio Labs, where we design, build and grow websites and software for mid-size and large companies.