The migration goes live, everyone celebrates for about a day, and then the numbers start sliding. Search Console fills up with 404 errors after the site migration, old bookmarks hit a blank page, and a product that used to rank on page one is suddenly nowhere. I have been through this on store migrations at Universal Wholesale, and the cleanup always looks the same. It is boring work. It is also the work that decides whether you keep your traffic.
This is the routine I follow once a new site is live and the old URLs start hitting a wall.
Why 404 errors show up after a site migration
A migration changes addresses. Platforms use different URL patterns, so a WooCommerce product at one path becomes a Shopify product under /products/, and category pages turn into collections under /collections/. If nobody tells search engines and browsers where each old page went, every old link becomes a dead end.
The usual causes I run into:
- The redirect map was built from a partial export, so some products never made it in.
- Category and tag pages were left out because people only thought about products.
- Old URLs with query strings, pagination or uppercase letters were never listed.
- Products were merged or retired during the move and nobody decided where their old pages should point.
- Images and PDFs that other sites linked to directly now live at new file paths.
None of this means the migration failed. It means the redirect list was a first draft, which it always is.
Build the list of broken URLs first
Before fixing anything I want one sheet with every old URL that is now failing. I pull from three places and merge them in Excel:
- Search Console. The Pages report, filtered to Not found 404. These are the URLs Google already knew about, so they matter most.
- The old sitemap. If you saved a copy before launch, every URL in it should either load or redirect. I run the list through a crawler and flag anything that returns 404.
- Analytics. In GA4 I look at landing pages from the months before the move. Pages that used to bring people in are the ones I fix first.
Then I remove duplicates and sort by how much each URL used to matter. A product page with years of traffic outranks a tag archive nobody visited. That order becomes the work queue.
How do I fix 404 errors after a migration?
For each broken URL, pick the closest live page and add a 301 redirect. The word that matters is closest. A discontinued product should point to its replacement or to the collection it belonged to, not to the homepage. Google tends to treat a pile of homepage redirects like soft 404s, and visitors hate landing somewhere that has nothing to do with what they clicked.
My rules when mapping:
- Same product on the new site: redirect one to one.
- Product gone, close replacement exists: redirect to the replacement.
- Product gone, no replacement: redirect to the most specific collection or category.
- Page with no real equivalent and no traffic or links: let it return 404, or 410 if you want to be explicit. Not every dead page needs saving.
On Shopify I upload redirects in bulk through the URL Redirects import in the admin. On WordPress I use a redirect plugin or server rules, depending on the host. Either way I keep the master sheet as the source of truth, because six months later someone will ask why a URL goes where it goes.
Watch for chains and loops
Migrations stack on top of earlier migrations. If the old site already had redirects, you can end up with A going to B, B going to C, and C going to the new page. Each hop slows things down and some crawlers give up. I check a sample of redirected URLs with a header checker and collapse every chain so the old URL lands on the final page in one hop.
Loops are rarer but nastier. Usually two rules point at each other after someone edits a handle. The browser shows a too many redirects error and the page is just gone. Test after every bulk upload, not once at the end.
Fix the internal links too
Redirects catch outside traffic. Your own site should not depend on them. After a migration I search the new content for old URLs: menus, footer links, blog posts, product descriptions with links to related items, promo banners. Anything pointing at an old path gets updated to the new one directly. It is faster for visitors and cleaner for crawlers, and it shrinks the 404 report to the problems that actually come from outside.
Then tell Google and wait
Submit the new sitemap in Search Console. When you have fixed a batch of URLs from the Not found list, use Validate fix so Google rechecks them. This takes time, sometimes weeks, and the report will look worse before it looks better because Google keeps finding old URLs it remembers.
I check the 404 list weekly for the first couple of months. New entries keep surfacing as Google recrawls older links, and each one goes through the same mapping rules. After that it becomes a monthly glance.
What I would do differently on the next one
Most of this cleanup is avoidable. The redirect map should be built from a full crawl of the old site plus the analytics landing page list, not from a product export alone. It should be loaded and tested on a staging copy before launch. And somebody should own it for at least two months after go live, with time set aside for it.
If you are already past launch and staring at a wall of 404s, start with the ten URLs that used to bring in the most visitors. Redirect those to their closest match today, check that each lands in one hop, and work down the list from there.