Most of the faults that damage a migration aren’t dramatic.
They’re small things nobody checked, on a site that looks perfectly finished.
I’ve written about why sites lose traffic after a migration in general terms. This is narrower. It’s what I actually found on two projects, one after launch and one before, in roughly the order I found it.
The sitemap that didn’t exist
On Kwiat’s move to a headless Shopify build, the first thing I checked after launch was the sitemap.
At /sitemap.xml, it returned a 404.
On a standard Shopify theme, a sitemap comes built in. On a Hydrogen build it doesn’t, and Kwiat’s content lived in two places: products and collections in Shopify, editorial and education content in Sanity. Anything that needs to know about every page has to be built to pull from both.
So Google had nothing to discover the new URLs from.
I flagged it straight away, then wrote a specification for the development team. A sitemap index pointing to three sitemaps, one each for products, collections and editorial content, listing only live, indexable URLs. They built it. I checked it once it was live.
The developers hadn’t missed anything. A custom build only has what someone specifies, and nobody had asked for a sitemap.
Content that only appeared in the browser
Some of the education pages served almost no visible text or headings in the initial HTML.
The content sat inside a script payload and only turned into words once JavaScript ran.
Google renders JavaScript, and the pages were ranking, so this wasn’t a disaster. But it’s a risk with crawlers that don’t render, including some AI crawlers, and you’d never spot it by looking at the page in Chrome.
I check the rendered HTML as well as the page now, on every migration.
Old URLs that still worked
Kwiat’s old category tree had been flattened into a single collection level.
After the move, the old category URLs still returned pages instead of redirecting. They relied on canonical tags to point at the new ones.
On a lot of searches, an old URL and a new URL were both showing up.
A redirect is an instruction. A canonical is a hint. When URLs change, I’d use the redirect.
Canonicals pointing somewhere odd
A small number of category pages had canonical tags pointing at broader, less relevant collections.
That tells Google the narrower page is basically a copy of the broader one, so it may not bother showing it for the specific searches it should win.
It’s easy to end up with when canonicals are generated by a rule rather than set by hand.
Titles that were just the page name
Collection pages were running very short titles and descriptions. Often just the collection name.
Nothing was broken. Pages loaded, links worked, the design was fine.
But the listings in search would look thin next to competitors writing for the click, and automatic metadata is the default on most new templates. It’s the first thing I look at after a redesign.
The page nobody remembered
The other project was The Evewell, a London fertility clinic rebuilding its WordPress site. This one was different because the audit came before the build.
One page sat outside the /support/ section and drew 5,145 clicks a year. That made it the ninth-highest traffic page on the site.
Pages outside the main structure are the ones most likely to be renamed, moved or forgotten, because they don’t fit the new layout neatly. Tidied in without a redirect, those clicks would have gone to an error page.
An old IVF landing page also redirected to a URL that returned a 404. The redirect existed. Nobody had checked where it ended.
Both went into the briefs for the developer before the build, along with a 207-URL redirect map, so every old URL had a confirmed destination before anything was built.
What I’d check on any migration
This is roughly the order:
- List every URL that has traffic or links, including the ones outside the main structure.
- Confirm a redirect for each, and test where it ends, not just that it exists.
- Check the sitemap exists and lists the new URLs.
- Compare the raw HTML with the rendered page on the key templates.
- Check canonicals on a sample of every page type.
- Look at titles and descriptions on every template.
- Request a made-up URL and see what comes back.
- Watch Search Console for the weeks afterwards.
Google’s guidance on site moves covers similar ground, including a troubleshooting section for common mistakes.
What I can’t say
I can’t tell you what each of these faults cost.
Kwiat’s traffic was affected by plenty of other things around the move, including work by the client’s own team and developers, and the figures for the whole site don’t isolate any one fault. Evewell’s new site hasn’t launched, so I can’t say yet what the redirect map protected.
What I can say is that every one of these was found by checking, and none of them was visible to a visitor.
The questions I’d ask
Does the sitemap exist?
Do the old URLs redirect, and to the right place?
Is the content in the HTML, or only in the browser?
Are the canonicals pointing where you think?
Did the titles survive?
Did anyone remember the page outside the main structure?
The full accounts are in the Kwiat migration case study and the Evewell case study. If you’re planning a move, the site migration checklist sets out the whole sequence, and my site migration service covers the work. You can also request a free assessment.
FAQ
What are the most common site migration mistakes?
Missing or wrong redirects, pages removed that were earning traffic, content that isn’t in the HTML, wrong canonicals, reset titles and a missing sitemap. Most of them are invisible to visitors, which is why they get missed.
Do I need a sitemap after a migration?
Yes. It helps Google find the new URLs. On custom builds it often has to be specified and built, because it doesn’t come with the platform, so I’d check it exists and lists only live, indexable pages.
Should I use redirects or canonical tags when URLs change?
I’d use redirects. A redirect says the page has moved. A canonical is a hint, and relying on it left old and new URLs showing up together on Kwiat.
When should SEO be involved in a migration?
Before the build, while templates and URLs are still easy to change. On Evewell the briefs reached the developer before anything was built. After launch the same checks work, but you’re fixing a live site.
How do I check what a made-up URL returns?
Type a nonsense address on your own domain. It should come back as a 404. If it loads a normal page with a 200 status, that’s a soft 404 problem worth fixing.
Sources
- Site move with URL changes, Google Search Central, accessed 21 October 2026. Supports: the general site move guidance and its troubleshooting section.
- Paul Myers, Kwiat headless Shopify migration, 2026 (published case study). Supports: the sitemap, rendering, old URL, canonical and title findings.
- Paul Myers, Evewell pre-migration audit, 2026 (published case study). Supports: the page outside the main structure, the broken redirect and the 207-URL redirect map.
