Your Website Returns 404 After a Migration—How to Recover the Missing Page
A 404 after a redesign or platform migration is not just a cosmetic error page. It means a URL that visitors, search engines, advertisements or other websites still know no longer reaches the resource they expected. The fix is rarely “redirect every broken URL to the homepage.” The useful work is to identify what the old address represented, decide whether an equivalent page still exists, and repair the route without creating chains, loops or irrelevant destinations.
When I audit a migration, I treat each 404 as a routing decision backed by evidence. That keeps the repair small, measurable and safe.
First, confirm that it is a real 404
Open the exact failing URL, including its protocol, hostname, path, trailing slash and any meaningful case differences. Then inspect the HTTP response in your browser’s Network panel or with a header-checking tool. A hard 404 returns an HTTP 404 status. A page that looks missing but returns 200 is a soft 404 and needs a different diagnosis.
If Search Console specifically reports a soft 404, use Webcurry’s soft-404 troubleshooting guide. If it reports “Page with redirect,” review the redirect-status diagnostic before changing anything.
Build an old-to-new URL map before editing redirects
Start with a spreadsheet or export containing the old URL, its previous purpose, its current status and the proposed destination. Sources for old addresses include the previous sitemap, Search Console performance and indexing reports, analytics landing pages, backlink reports, paid-campaign links, XML exports and a crawl of the old site if it is still available.
Do not guess destinations from similar words in the slug. Open the replacement page and confirm that it satisfies the same visitor intent. A retired service page should not automatically point to a generic services page; a discontinued product should not be sent to an unrelated bestseller.
Use this decision rule for every missing URL
The same content still exists at a new address: use a server-side permanent redirect to the closest equivalent URL.
Several old pages were genuinely consolidated: redirect each one to the new combined resource only when it answers the same need.
The page was removed and has no useful replacement: keep a proper 404, or use 410 when you intentionally want to signal that it is gone.
The page should still exist at the same URL: repair the route, publication state, CMS record or rewrite rule instead of adding a redirect.
You cannot establish the old page’s purpose: investigate backlinks, archived content and analytics before choosing a destination.
Google recommends permanent server-side redirects such as 301 or 308 for URL moves and advises pointing old URLs directly to their final destinations. Redirect chains add latency and make migrations harder to debug.
Trace why the page became missing
A migration can create 404s even when every page appears to have been copied. Common causes include changed slugs, dropped folder paths, altered uppercase characters, removed file extensions, missing locale folders, unpublished CMS records, incomplete product imports, and rewrite rules that were not moved to the new server.
Compare the old and new patterns. Look for systematic changes such as /services/web-design/ becoming /web-design or .html disappearing.
Check the content record. Confirm that the page, product, post or collection item exists and is published in the production environment.
Inspect the route before the theme. If the server returns 404, redesigning the error page will not restore the missing resource.
Test variants deliberately. Check www versus non-www, HTTP versus HTTPS, trailing slashes, letter case and language or market subfolders.
Review the redirect destination. A typo can turn a valid old URL into a redirect that ends on another 404.
Platform-specific fixes
Wix
For a Wix page whose slug changed, check the URL Redirect Manager in the site’s SEO tools. Wix can create automatic redirects for several page types when their slugs change, but Wix Blog slug changes require a manual redirect. When moving a site to Wix, add redirects wherever the new page cannot preserve the old path. Test the published custom domain, not only an editor preview.
WordPress
Confirm that the post or page is published and its permalink matches the migration map. If many valid pages suddenly return 404, resave the permalink settings to regenerate rewrite rules, then check the web-server configuration and any caching or redirect plugin. Do not keep resaving permalinks as a permanent fix if the server cannot read the rewrite configuration.
Shopify
Create URL redirects for old product, collection and page paths after their originals become unavailable. Shopify reserves some paths and only applies redirects from URLs that are actually broken, so test the old storefront URL in a private window. For international stores, also test market and language subfolders rather than assuming one path behaves identically everywhere.
Avoid four migration shortcuts that create new problems
Redirecting every 404 to the homepage. This hides the broken route from people without supplying a relevant replacement and can be treated as a soft 404.
Allowing multi-hop chains. Update old rules so each address reaches the final destination in one hop wherever possible.
Leaving old URLs in internal links. A redirect is a safety net, not a substitute for updating menus, body links, canonicals, structured data and hreflang references.
Submitting broken URLs in the sitemap. The current sitemap should contain canonical, indexable destination URLs—not retired addresses or redirecting paths.
If the migration also changed design, navigation or page templates, work through the ranking-drop recovery guide. If old and new URLs are competing, inspect the canonical configuration rather than adding more redirects blindly.
Update every signal that still names the old URL
Once the redirect or restored route works, replace old internal links in navigation, breadcrumbs, page copy, buttons, image links and structured data. Update canonical tags, hreflang annotations, XML sitemaps, advertising destinations, email templates and social profile links. Contact important external sites when a direct update is realistic, even though the redirect should remain.
A stale response may be cached after the repair. If different devices still see different versions, use Webcurry’s cache-layer diagnostic to separate browser, CDN, application and service-worker caching.
A practical verification checklist
Request the old URL and confirm it returns the intended status.
If redirected, confirm the final page returns 200 and the chain contains no avoidable hop.
Confirm the destination’s canonical tag points to the correct final URL.
Crawl internal links and remove references to the old address.
Check that only the destination appears in the current XML sitemap.
Test mobile, desktop, logged-out and international variants where relevant.
Inspect both the old and final URLs in Search Console and monitor Not found errors after Google recrawls them.
Keep the redirect live long enough for users, bookmarks, crawlers and external links to transition.
What successful recovery looks like
The goal is not to make every 404 disappear. Legitimately deleted URLs should still return a proper error. Success means that valuable moved content has a direct, relevant permanent route; intentionally removed content reports an honest status; and the live site no longer advertises retired addresses.
Run the migration map like a small acceptance test: old URL, expected result, actual status, final URL and owner. That record makes future redesigns safer and turns a vague SEO problem into a finite repair job. For a wider post-migration check, use the technical SEO checklist.
Official references
Fix the route, not just the symptom
A migration 404 is a broken promise between an old address and a visitor’s expectation. Restore that promise with evidence: identify the old page, choose the correct outcome, repair the route, update every internal signal and verify the final response. If you need a second pair of eyes on a migration map or stubborn 404 pattern, ask Webcurry to review the website.
Comments