SOP: Recover SEO After a Website Migration

Post-migration SEO recovery requires three signals to agree: each valuable legacy URL must redirect to its final replacement, every canonical must use the production origin, and every sitemap must list absolute canonical URLs. A sitemap can help discovery, but it cannot rescue a historical page that now returns 404 or override a canonical pointing to localhost.

This SOP covers the diagnosis, implementation, and validation of a move from a legacy CMS such as WordPress to a server-rendered application such as Nuxt. It does not promise an instant rankings rebound. Its purpose is to restore consistent, crawlable signals without breaking the new URL structure.

Quick recovery sequence

1. Preserve evidence from Google Search Console, analytics, sitemaps, and backlinks.
2. Build a prioritized inventory of old URLs and final destinations.
3. Add direct permanent redirects without chains or blanket homepage fallbacks.
4. Generate canonical, hreflang, Open Graph, and structured-data URLs from one public origin.
5. Publish clean sitemaps and submit the new sitemap in Search Console.
6. Test HTTP responses, rendered HTML, and XML before and after release.
7. Monitor coverage, clicks, and errors while Google processes the migration.

The failure pattern: three compounding issues

In the anonymized case behind this procedure, organic traffic fell by roughly 85% within a few weeks. Indexed pages dropped from 76 to 34, and a URL that had generated more than 1,100 clicks over the previous year began returning 404.

There was no single cause:

Problem	Signal sent to Google	Observable outcome
Legacy URLs had no permanent redirects	Known content appeared to have disappeared	404 reports and no continuity between URLs
Canonicals pointed to localhost	The declared preferred version was not public	Conflicting or unusable canonical signals
Sitemaps contained localhost while the old sitemap remained in Search Console	Declared URLs did not match production	Harder discovery and diagnosis

Missing redirects were the most urgent problem. The other two made it harder for Google to understand the replacement site. Treat recovery as one connected system: URL history, canonical identity, and discovery should all lead to the same destination.

1. Preserve evidence before changing the site

Do not begin with a list of slugs recalled from memory. Export and combine:

• Search Console pages and queries, including clicks and impressions where possible;
• organic landing pages from analytics;
• URLs from legacy sitemaps;
• paths found by crawling the old site or reviewing logs;
• valuable backlinks;
• downloadable files and images with external links;
• every live route on the replacement site.

Store this evidence outside the redirect code and remove personal data or secrets before sharing it. If the brand homepage also disappeared from branded results, pair this process with the guide to recovering a homepage in Google results.

Prioritize impact, not raw URL count

Review URLs with clicks, impressions, conversions, or backlinks first. Then handle service pages, categories, posts, static assets, and legacy indexes. A page with 1,100 clicks deserves a manual destination decision; a no-traffic taxonomy can often follow a documented pattern.

The output of this stage should include at least:

Legacy URL	Final destination	Type	Priority	Evidence	Expected result
/old-article	/articles/current-guide	Post	High	Clicks and backlinks	301 → 200
/services/legacy/a	/services/a	Service	High	Impressions	301 → 200
/retired-resource	No replacement	Removed	Low	No demand	410

2. Make permanent redirects a single source of truth

Google recommends mapping old URLs to their new locations and using server-side permanent redirects, usually 301 or 308. Every redirect should resolve to the final destination; avoid chains such as A → B → C. See Google’s official guidance for site moves with URL changes.

Maintain one versioned redirect map and a small resolver. Normalize the request path before matching it:

• ignore query strings and fragments unless they genuinely identify different content;
• handle trailing slashes consistently;
• support language prefixes when applicable;
• separate exact matches from well-defined pattern rules;
• reject loops and destinations that redirect again.

A framework-neutral shape might look like this:

const permanentRedirects: Record<string, string> = {
  "/old-article": "/articles/current-guide",
  "/services/legacy/a": "/services/a",
};

export function resolveLegacyPath(input: string) {
  const path = normalizePath(input);
  return permanentRedirects[path] ?? null;
}

Run the resolver in middleware, at the edge, or on the server before the application renders the route. Test exact matches, trailing slashes, language prefixes, query strings, and current routes that must not redirect.

Do not turn the homepage into a universal fallback

Old and new URLs should be semantically related. Redirecting every removed page to the homepage frustrates visitors and can be interpreted as a soft 404. If no close replacement exists, return 404 or 410. The operating rule is: redirect when the content continues; return 404/410 when it ended without an equivalent.

Keep redirects for at least one year, as Google recommends. Leaving them in place longer often continues to help visitors and external links.

3. Use one public origin for every canonical signal

A localhost canonical is a release-blocking configuration defect. Create one shared URL utility that:

1. reads the public site URL from environment configuration;
2. validates its protocol and hostname;
3. rejects localhost, private addresses, and empty values in production;
4. normalizes the origin without a trailing slash;
5. builds absolute URLs consistently.

Use that utility for:

• rel="canonical";
• hreflang links and x-default;
• og:url;
• URLs inside JSON-LD;
• sitemaps and robots.txt.

Every indexable page should declare its preferred public URL. Google treats redirects and rel="canonical" as strong canonical signals, while sitemap inclusion is weaker. Review the official guide to consolidating duplicate URLs.

For multilingual sites, give every language version its own URL and reciprocal hreflang references. Do not hide all variants behind one URL based only on browser language.

4. Rebuild sitemaps that serve a purpose

The new sitemap should contain only publishable canonical URLs, expressed as absolute URLs on the production host. Use one sitemap or an index with child sitemaps for pages, posts, and other content types.

Verify that:

• every listed URL returns 200 and is indexable;
• localhost, preview hosts, and redirected paths are absent;
• lastmod represents meaningful changes instead of changing on every build;
• hreflang alternates resolve to real pages;
• robots.txt declares the primary sitemap location.

Google requires fully qualified sitemap URLs and describes sitemap submission as a hint, not a guarantee of crawling or indexing. Follow its documentation for building and submitting a sitemap.

What to do with the old sitemap

During a migration, Google recommends submitting a sitemap of the new URLs. Temporarily retaining a separate sitemap of old URLs can also help monitor how redirects are processed. Redirect warnings for those old entries are expected. Remove the legacy sitemap from Search Console after the migration has been processed.

This is more accurate than assuming every historical sitemap endpoint must serve XML forever. The important requirement is a deliberate, measurable plan that matches the actual state of the URLs.

5. Release and verify in layers

A visual spot check is not enough. Add automated checks that fail when they find:

• localhost or a preview domain in HTML, JSON-LD, robots, or XML;
• relative, duplicated, or unexpected canonical URLs;
• redirect destinations that do not return 200;
• chains, loops, or unnecessary internal redirects;
• non-canonical URLs inside a sitemap;
• incomplete hreflang pairs.

Record this path for every priority URL:

Legacy URL → 301/308 → final URL → 200
Final URL → absolute self-referencing canonical
Sitemap → final URL, never legacy URL or localhost

Run the checks against a production-like build and repeat them on the public domain after deployment. Local tests alone cannot fully validate production environment variables or CDN behavior.

6. Finish the Search Console work

After release:

1. submit the new sitemap;
2. inspect the highest-impact URLs and request indexing where appropriate;
3. validate 404 fixes only after confirming that redirects are live;
4. monitor indexing, clicks, and impressions by URL group;
5. annotate the migration date and each remediation release.

Do not treat every daily fluctuation as a new incident. Google notes that ranking changes are normal during a migration and that a small or medium site may take several weeks to move most pages.

SOP exit criteria

The technical remediation is complete when:

• every high-priority legacy URL has a documented outcome;
• redirects lead directly to 200 destinations without loops;
• canonical, hreflang, Open Graph, and JSON-LD use the correct public origin;
• sitemaps contain only absolute, canonical, indexable URLs;
• localhost is absent from all production artifacts;
• the new sitemap is in Search Console and monitoring is scheduled;
• redirect mappings and tests remain versioned for future reviews.

Frequently asked questions

What should you fix first after a failed SEO migration?

Start with legacy URLs that earned traffic, links, or conversions and redirect each one directly to its closest replacement. Then align canonicals, hreflang, and sitemaps with those final URLs.

Should every removed page redirect to the homepage?

No. Use the closest equivalent. When no useful replacement exists, return 404 or 410 instead of creating a soft-404 signal.

How long should redirects remain in place?

Google recommends at least one year. Keeping them longer usually continues to help visitors and old links.

Can a new sitemap recover lost traffic by itself?

No. It aids discovery, but recovery also requires correct redirects, coherent canonicals, accessible content, and time for Google to recrawl the site.