Launch day went well. The new navigation felt cleaner. Stakeholders signed off. Nobody noticed anything wrong in the first week.
Then organic traffic dipped. Google Search Console started flagging redirect errors. Old service URLs returned 404. Pages that used to rank now send visitors to the homepage with a vague message. Analytics still shows sessions, but form submissions dropped and nobody can explain why.
This is a post-migration problem, not a "Google has not found your site yet" problem. The redesign is live. Search engines already knew your old URLs. What broke is the bridge between old paths and new ones, plus the signals that tell Google which version of each page to trust.
We work on technical SEO after a website migration with teams recovering from exactly this pattern. This guide focuses on what fails after go-live: redirects, canonicals, and the secondary issues that hide behind them.
Why Migrations Break Search Visibility After Launch
A website migration changes the URLs, templates, and internal paths that search engines already associated with your queries. When the new site goes live without a complete transition plan, Google keeps requesting old URLs. Users still click old links in emails, ads, and bookmarks. Partners still reference paths from last year's PDF.
Common post-launch triggers:
- Redirect map gaps: high-traffic old URLs never got a row in the spreadsheet
- Merged pages without intent match: two old service pages collapsed into one thin new page
- Platform cutover timing: redirects went live after DNS switched, leaving a window of 404s
- Catch-all rules: every unknown path 301s to the homepage instead of a relevant destination
- Canonical and redirect conflict: the server says one URL, the HTML canonical says another
These are fix-now issues on a live site. Waiting does not repair a 404 on a URL that still earns impressions in Search Console.
Redirect Failures (The Usual Suspects)
Redirect planning should happen before launch. After launch, your job is to find what the plan missed and close the gaps fast.
Missing or incomplete redirect map rows
Teams often map navigation URLs and forget long-tail paths: old blog posts, campaign landing pages, PDF download paths, tag archives, and parameterized URLs that still appear in Search Console.
What to do:
1. Export all URLs with impressions or clicks from Search Console (last 90 days).
2. Export top landing pages from analytics for the same period.
3. Test every row: old URL should return 301 to the best-matching new URL, not 404 or 200 with empty content.
A redirect map is not complete until every URL that mattered before launch has a verified destination.
404s and soft-404s on former money pages
A hard 404 is obvious. A soft-404 is worse for diagnosis: the server returns 200, but the page is empty, generic, or says "Page not found" inside a normal template. Google may drop these from results without a clear error flag in your browser.
After a redesign, check former service, pricing, and contact paths manually. If a URL used to convert and now shows a stub, treat it as urgent regardless of status code.
Redirect chains and loops
A chain passes through two or more hops before the final URL (`/old → /temp → /new`). Chains slow crawling and dilute signal. A loop never resolves (`/a → /b → /a`).
Use a redirect checker or curl (`curl -I -L`) on your top 20 old URLs. One hop to the final destination is the target.
302 instead of 301 on permanent moves
301 means the move is permanent; search engines should consolidate signals to the new URL. 302 means temporary. CMS defaults and plugin misconfiguration often leave 302s on paths that will never revert.
If the old site is gone for good, permanent moves need 301. Audit high-value paths first.
Catch-all homepage redirects
When developers cannot finish the map, some configs send every unknown path to `/`. That avoids 404 reports but destroys intent. A visitor (and Google) looking for `/services/mobile-apps` lands on a homepage that does not answer the query.
Homepage catch-alls are only valid when the old URL had no meaningful equivalent and the business intent truly is "start over." For service and product paths, route to the closest matching page or a dedicated "we moved this content" section, not the homepage by default.
www, non-www, HTTP, and HTTPS inconsistencies
Migrations often switch host preference (`www` vs bare domain) or finish an HTTPS rollout. If both versions resolve without a single canonical preference, you split signals and create duplicate redirect paths.
Pick one preferred host. Every other variant should 301 to it in one hop. Verify on staging before calling the migration done, then re-check on production after cutover.
Example: post-launch redirect verification
| Old path | Expected new path | Status you want | Common failure |
|----------|-------------------|-----------------|----------------|
| `/services/web-design` | `/services/web-development` | 301, one hop | 404 or 302 |
| `/blog/2019/mobile-tips` | `/news/mobile-performance-guide` | 301, one hop | Chain via `/blog/` |
| `/about-us` | `/company` | 301, one hop | Soft-404 on new URL |
| `/old-campaign-lp` | `/contact` | 301 (retired page) | Catch-all to `/` |
| `/services/mobile-apps` | `/services/mobile-development` | 301, one hop | Missing row (404) |
Test with tools, but spot-check in a browser too. Some CMS rules behave differently for logged-in users or geo variants.
Canonical Failures (Quiet Signal Breakers)
Redirects tell browsers and bots where a URL moved. **Canonical tags** tell search engines which URL is the preferred version when multiple paths show similar or duplicate content. After a redesign, canonical mistakes are common and easy to miss because pages still "look fine."
Canonicals pointing to old URLs or staging
New templates sometimes ship with hardcoded canonicals from the old site, staging hostname, or a CDN preview URL. Search Console may show "Duplicate, Google chose different canonical than user" on pages you thought were clean.
View source on key templates (homepage, top services, contact). The canonical should be the production HTTPS URL you want indexed, on the preferred host.
Conflicting canonical vs redirect signals
If `/old-path` 301s to `/new-path` but `/new-path` canonicals to `/old-path`, you send mixed instructions. Google may index unpredictably or delay consolidation.
Rule of thumb: the canonical on the final URL should reference itself (or the single preferred version of that content). Redirect sources should not be canonical targets after the move is permanent.
Duplicate paths: trailing slashes, filters, and CMS clones
Redesigns often introduce new duplicate patterns:
- `/services/` and `/services` both resolve
- Filtered or sorted views (`?sort=`, `/page/2/`) without consistent canonicals
- Print-friendly or AMP paths duplicating main content
- HTTP and HTTPS both accessible without redirect
Pick one URL pattern per page. Use 301 or canonical (prefer redirect for host and protocol) so Google does not split relevance across variants.
Self-referencing canonical on the wrong variant
Some CMS plugins set a canonical that does not match the URL in the address bar. The page loads at `/services/web-development/` but canonical says `/service/web-dev` (old slug). Fix template logic or plugin settings at the theme level, not page by page forever.
What Else Breaks (Often Right Behind Redirects)
Stale internal links in body copy
Developers fix server redirects. Editors forget links inside blog posts, case studies, and footers that still point to retired paths. Users click, hit a redirect chain or 404, and engagement drops. Run a crawl focused on internal links and fix high-traffic content first.
Outdated XML sitemap
Sitemaps listing staging URLs, old paths, or thank-you pages you do not want indexed confuse discovery after migration. Regenerate the sitemap from the new structure, remove dead URLs, and resubmit in Search Console.
Staging or preview URLs indexed
If staging was not noindexed or was briefly exposed during cutover, duplicate content can appear in results. Check site: queries and Search Console for hostnames that are not production. Block staging at the server level and remove indexed staging URLs via Search Console removal tools after fixing access.
Analytics and forms (measurement blind spot)
Broken GA4 or GTM tags after a theme change do not directly cause ranking loss, but they hide the problem. Traffic looks stable while leads fall. Verify form submissions and conversion events in the first week after launch. If organic clicks drop in Search Console but analytics looks flat, you may be double-counting or missing pageview events on new templates.
This guide does not replace a full analytics audit. It flags the pattern we see paired with redirect failures: SEO looks broken, but the team cannot prove it because tracking broke at the same time.
Search Console Triage After a Migration
Use live data to prioritize fixes. An export from launch week is not enough; check current reports.
Pages report
Look for spikes in **Not indexed** reasons after cutover: "Page with redirect," "Duplicate without user-selected canonical," "Crawled - currently not indexed," and "Not found (404)." Sort by impressions where available. A 404 on a URL with impressions beats a low-traffic blog 404.
Redirect and crawl errors
Search Console may surface redirect errors, server errors (5xx), or soft 404 warnings on URLs you migrated. Cross-reference with your redirect map. Every error row should become a ticket with owner and verified fix date.
Compare indexed page counts
A modest fluctuation is normal. A sharp drop in indexed pages on an established site often means redirect gaps, noindex left on templates, or canonical confusion. Pair index counts with your baseline URL list from before the redesign.
URL Inspection spot checks
After you fix a redirect or canonical on a high-value URL, use URL Inspection on the new destination. Confirm indexing allowed, canonical Google selected, and last crawl date. Request indexing once after a real fix, not daily.
Weekly rhythm (first four weeks post-migration)
1. Review Pages report and redirect-related issues.
2. Test top 10 old URLs from your baseline list.
3. Confirm analytics on contact and key conversion paths.
4. Log fixes in the redirect map (status code, date verified).
Fifteen focused minutes weekly beats discovering the gap in a quarterly review.
Recovery Sequence for a Live Site
When traffic or rankings drop after a redesign, work in this order:
1. Close redirect map gaps: every high-impression old URL returns 301 to the best match (one hop).
2. Fix host and protocol: single preferred www/non-www and HTTPS preference.
3. Correct canonicals on key templates: homepage, top services, contact, top blog or news entries.
4. Remove conflicting signals: noindex on production templates, staging blocked, catch-all rules narrowed.
5. Update internal links in nav, footer, and high-traffic content.
6. Refresh and resubmit XML sitemap in Search Console.
7. Verify analytics and forms on conversion paths.
8. Monitor two to four weeks while Google recrawls; avoid repeated indexing requests without underlying fixes.
Re-test your top three commercial URLs after steps 1 to 3. If Search Console still shows canonical or redirect conflicts on those URLs, do not move on to content expansion yet.
When Redirect Fixes Are Not Enough
Some migrations need deeper scope:
- Thousands of URL changes across multiple domains or subdomains
- Replatforming to JavaScript-heavy or headless architecture with rendering risk
- Large content consolidation where merged pages no longer match old query intent
- Legacy duplicate or thin content that the redesign copied forward without restructuring
In those cases, post-launch redirect repair is the floor. You may also need content merges rewritten for intent, structured data revalidation, and ongoing measurement. That work sits alongside migration SEO, not instead of it.
Key Takeaways
- Post-migration SEO problems are about broken bridges (redirects, canonicals, internal links), not patience on a brand-new domain.
- 404s, chains, catch-all homepage redirects, and 302s on permanent moves are the highest-impact redirect failures.
- Canonicals pointing to old or staging URLs and duplicate path variants quietly split signals after launch.
- Use Search Console to prioritize URLs with impressions, not just crawl errors in the abstract.
- Fix redirects and canonicals first, then sitemap and internal links, then monitor for two to four weeks.
What showed up first in your last migration: redirect errors, canonical warnings, or a traffic drop analytics could not explain?
If you are replanning a redesign or cleaning up after a rough cutover, planning website redesign and renewal with transition SEO early keeps redirect maps, canonicals, and launch QA in the same timeline as design and development.