Look for three residues: redirect chains longer than one hop, pages reachable by URL but linked from nowhere, and duplicate schema blocks from the old theme still firing. Each is survivable alone. Together they explain a lot of sites that never recovered their pre-migration performance.
The migration nobody wrote down
Most firms have moved a website at least once — a redesign, a platform change, a switch from one developer to another. Almost none have documentation of what happened to the old URLs.
That's the condition this post is written for. You weren't there, or you were and it was four years ago, and the person who did it has moved on. What you have is a site that works and a nagging sense it never quite got back to where it was.
Residue one: redirect chains
When a page moves, a 301 redirect points the old URL at the new one. Fine. The problem comes when it happens twice.
Original URL → 2019 redesign URL → 2022 restructure URL → current URL. Three hops. Each hop is a place where signal can attenuate and where a crawler may give up before reaching the destination.
How to check: Take a handful of your oldest URLs — from an old business card, a printed brochure, an email signature, an archived page — and paste each into a browser with developer tools open, watching the network tab. Or use any redirect-checker tool that shows the full chain rather than just the endpoint. You're looking for anything that isn't a single hop to a live page.
Pay attention to what redirects to the homepage. Bulk-redirecting everything to the homepage is a common migration shortcut and it wastes whatever those pages had earned.
Residue two: orphaned pages
An orphaned page exists and can be loaded, but nothing on your site links to it. It survived the migration because the URL still resolves; it just fell out of the navigation.
These are invisible from the front end by definition — you cannot click to a page nothing links to.
How to check: Compare your sitemap against your navigation. Anything in the sitemap you can't reach in three clicks from the homepage is a candidate. In Search Console, the Pages report under Indexing will show URLs Google knows about, including ones you may have forgotten.
Some orphans are harmless. Some are old service pages still competing with their replacements, which brings you back to pages fighting each other.
Residue three: duplicate schema from the old theme
Theme changes leave structured data behind. The old theme's Organization node is still being emitted somewhere, alongside the new one, and both validate cleanly. An engine gets two partially-conflicting assertions about who you are.
How to check: View source and search for application/ld+json. Count the blocks. More than one Organization or WebSite node is your finding. The mechanics of this are covered in how do I tell if my schema is being read, not just present.
Three more worth a look
Mixed http and https. If a migration included an SSL move, check that internal links, image sources, and canonical tags all use https. Stragglers produce duplicate-URL problems that are entirely self-inflicted.
An old sitemap still submitted. Search Console may still be pointed at a sitemap listing URLs that no longer exist. Check the Sitemaps report and remove anything stale.
Internal links to old URLs. Even when redirects work, links inside your own content pointing at pre-migration URLs add an unnecessary hop to every one. Worth fixing at the source rather than relying on the redirect.
What you can and can't conclude
Pending — This is the honest label for the whole post. You can find each residue individually, and each finding is real. What you can't do from outside is establish whether they're currently costing you anything, because that requires comparing pre- and post-migration performance — and if the migration predates your Search Console data, that comparison isn't available at any price.
Directional — That redirect chains and duplicate entity signals are worth cleaning up. Well-supported in principle. The size of the gain on your specific site is not something anyone can quote you honestly.
Unconfirmed — That the migration caused a decline you've noticed. Post-migration drops get attributed to the migration by default, and sometimes correctly — but seasonality, a coinciding algorithm update, and an unrelated internal change all present the same way. If your Search Console data doesn't reach back far enough to see the before, that attribution stays an inference.
The realistic goal
You are unlikely to fully reconstruct what happened. The goal isn't archaeology — it's making sure the site as it stands today has one clean path to every page, one set of entity signals, and no URLs quietly competing with their own replacements.
That's achievable without knowing what went wrong in 2019.
Migration residue is one of six symptoms in the full map at how do I tell if my website is losing me clients.