EN 
ESWebsite Migration SEO Checklist for a Safe Relaunch
A safe website migration starts with a complete URL inventory and ends only after the old and new URLs have been monitored in search, analytics and server logs. Map every valuable page to a relevant destination, use permanent server-side redirects, update canonicals and internal links, submit the new sitemap and test the live site as both a user and a crawler. Do not combine a domain move, CMS replacement, redesign and content rewrite unless the business accepts the additional diagnostic risk.
1. Define the type of migration before changing anything
“Website migration” can mean several different projects. Moving to a new hosting provider while preserving every public URL is mainly an infrastructure change. Moving to a new domain, changing URL paths, merging websites or replacing a catalogue structure changes the addresses that search engines know. A redesign may do either, depending on whether the information architecture changes.
This distinction determines the plan. A hosting-only move needs DNS preparation, capacity checks and monitoring on both servers. A URL-changing migration needs all of that plus a page-level redirect map, new canonical signals and updated internal links.
Where practical, separate major changes. Google advises changing one thing at a time because a combined domain move, CMS replacement and content rewrite makes any loss much harder to diagnose. If commercial deadlines require one launch, establish a stronger baseline and a clear owner for every part of the migration.
2. Build an evidence-based URL inventory
Do not create a redirect list from the navigation menu alone. Important URLs may be absent from the menu but still receive organic visits, links, enquiries or product revenue. Combine several sources:
- the current XML sitemap and a crawl of the public site;
- landing pages from web analytics;
- indexed and linked pages reported in Search Console;
- server logs, backlink exports and paid campaign destinations;
- images, PDFs and other files with search traffic or external links.
Give each old URL one decision: keep it unchanged, redirect it to a relevant new equivalent, consolidate it into a stronger page, or retire it with a genuine 404 or 410 response. Avoid sending unrelated pages to the home page. That is unhelpful to visitors and can be treated as a soft 404.
The result should be a testable old-to-new mapping, not a loose list of rewrite rules. Include the expected status code, new canonical, page title, language alternate and content owner. For multilingual websites, map each language version independently and update every hreflang reference to the new address.
3. Prepare the new site before launch
A staging site should be protected from accidental indexing, but those protections must not reach production. Add a launch check for temporary noindex directives, password gates and restrictive robots.txt rules. Test representative templates, forms, images, downloads, structured data and mobile layouts before DNS or redirects change.
On the new site, each indexable page should use its final public URL consistently:
- a self-referencing canonical points to the preferred HTTPS URL;
- internal links go directly to final destinations, without redirect hops;
- navigation, breadcrumbs, pagination and language selectors use the new URLs;
- structured data and Open Graph fields contain the correct domain;
- the XML sitemap lists only canonical, indexable URLs that return 200.
Preserve the meaning of pages that already perform. A redesign can improve hierarchy, readability and conversion paths without removing the content that explains the offer. If content must change, record which pages are being rewritten so that any search movement can be distinguished from a technical migration issue.
If this planning needs to be part of a broader rebuild, our website development process connects information architecture, UX, implementation and launch QA. For international structures, our international SEO work covers language targeting, crawlability and measurement.
4. Launch permanent redirects and measurement together
For permanently moved pages, use server-side permanent redirects such as HTTP 301 or 308. Redirect each old URL to its closest useful new equivalent. A redirect chain such as old A → temporary B → final C adds latency and makes troubleshooting harder, so point old URLs directly to the final destination.
Test redirect rules before release with a representative set that includes deep pages, parameters, uppercase variants, trailing slashes, media files and previous redirects. Then run the complete URL map immediately after launch. The test should flag:
- old URLs that still return 200;
- redirect loops, chains and irrelevant destinations;
- new URLs that return errors or are blocked from indexing;
- canonicals or hreflang tags that still reference staging or the old domain;
- internal links that rely on redirects.
Keep verification for both properties in Search Console when a domain changes, preserve analytics tags and annotations, and submit the sitemap containing the new canonical URLs. Google notes that a sitemap supports discovery but does not guarantee crawling or indexing, so it is a signal and a monitoring tool rather than a substitute for correct links and redirects.
5. Validate the migration after launch
A successful deployment is not the end of a migration. Search engines process moves URL by URL, and temporary visibility fluctuations can occur while pages are recrawled and reindexed. Monitor trends by page group rather than looking only at total traffic.
During the first checks, compare:
- HTTP status and canonical responses for old and new URL samples;
- submitted versus indexed pages in Search Console;
- organic landing pages and conversions in analytics;
- Googlebot activity and errors in server logs;
- template performance, mobile usability and form completion;
- top linked pages and paid campaign destinations.
Investigate changes by template, directory, country and language. If one section falls while the rest is stable, the cause is probably local to that mapping or template. A site-wide fall suggests a broader issue such as crawling restrictions, widespread canonical errors, unavailable assets or server instability.
Redirects should remain available for as long as users and crawlers may request the old URLs. Google recommends keeping them generally for at least one year, while from a user perspective retaining them indefinitely is sensible when old links continue to exist. Update important external links where possible and keep the old domain under your control.
Common website migration questions
Should every old URL redirect to the home page?
No. Redirect an old page to the closest relevant replacement. If no useful equivalent exists, return a genuine 404 or 410. A blanket home-page redirect creates a poor experience and may be interpreted as a soft 404.
Can a redesign keep the same URLs?
Yes. If the existing URLs are logical and valuable, preserving them reduces migration complexity. You can still improve layouts, templates, content and navigation while keeping stable addresses.
How long does a website migration take to settle in search?
There is no fixed period. Google processes moves per URL, so timing depends on site size, crawl demand and server performance. Plan for monitoring over weeks rather than expecting every URL to switch immediately.
What should be checked first if organic traffic falls?
Start with availability and indexing: status codes, robots directives, canonicals, redirect destinations and sitemap URLs. Then compare the affected pages by template and directory before changing content or redirect rules.
A practical launch decision
A migration is ready when every important old URL has an approved outcome, the new site has passed technical and visual QA, analytics is recording the required actions, and the team can monitor both environments after launch. If those conditions are not met, postponing the switch is usually less expensive than repairing an unmeasured release.
VOWE can review the migration plan, validate a staging build or support the release through our website maintenance and technical support service. To discuss the scope and the systems involved, send us the current site and the proposed launch outline.
