Imagine a Malaysian shoe shop moving its online store from one platform to another. Customers may see a better design, but its product pages, category addresses, checkout and search listings could all be affected. A website migration plan records what changes, what must still work and how the team will check it.
What Counts as a Website Migration?
A migration is a significant change to a site's platform, domain, URLs, hosting or structure. A visual redesign can be part of one, but changing colors alone does not require redirecting pages. A move that changes public URLs needs a different plan from a hosting change that keeps every URL. Identify the actual changes first. If visitors still use the same URLs after a hosting move, Google's hosting-change guidance is more relevant than its URL-change process.
The main SEO risk is losing the paths that connect people and search engines to useful pages. A new homepage cannot replace a well-used product page simply because the new design looks better. Our website architecture guide explains what those paths should do.
Decide What Must Survive
Write down the launch goal and the pages and functions it depends on. For the shoe shop, that may include brand and category pages, size guidance, returns, stock status, checkout and Malay or Chinese versions where offered. Note who owns each item and who can approve launch or pause it.
Save a copy of the old site and a rollback plan. Avoid combining a platform change, domain change and large content rewrite unless there is a clear reason and enough time to test each. A useful baseline includes Google Search Console clicks and indexing, analytics conversions, the current sitemap, a crawl of internal links, and the site's important landing pages. Record the measurement dates, verify access to the old and new Search Console properties if the domain changes, and test a real checkout path; traffic alone cannot tell you whether orders still work.
Inventory and Map Old URLs to New Ones
Collect old URLs from the sitemap, site crawl, Search Console, analytics and any pages with important inbound links or sales. A sitemap is not a complete inventory: it may omit older pages that still receive visits or links. Include category, product, help, translated and campaign pages that people still reach. Mark whether each page stays at the same URL, moves to an equivalent URL, is consolidated into a genuinely relevant page, or is intentionally retired.
For changed URLs, make an old-to-new map before launch. A shoe-size guide should go to its new guide, not to the homepage. Google recommends server-side permanent redirects such as 301 or 308 when URLs move, and warns against redirecting unrelated pages to one destination. Avoid redirect chains. Our redirect-map guide covers the detailed mapping and response tests.
Test the New Site Before Launch
Keep the staging site from being accidentally indexed, preferably behind access control, then make sure those controls will not carry into production. Crawl the preview with the proposed URL map beside it. Check page titles, headings, canonical URLs, navigation, internal links, images, and any structured data or hreflang the site already uses. Confirm that important content is present in readable page text.
Test customer paths on a phone and desktop: finding a shoe size, choosing a variant, paying, receiving an order confirmation and contacting support. These are business checks, not just SEO checks. Preview a sample of high-value old URLs through the planned redirects. A green homepage is not proof that every product page works.
Launch With a Short, Owned Checklist
At release, work from a short list with an owner and a pass/fail result for each check:
- Activate the approved redirects and test old URLs against their final destinations.
- Check that new pages return usable responses and production has no accidental staging
noindexor robots block. - Confirm canonical tags and internal links point to the preferred new URLs, then publish the new XML sitemap.
- If the domain or subdomain changed, use Google's Search Console Change of Address tool after redirects work. This tool is not for path-only, HTTP-to-HTTPS or www-to-non-www moves on the same domain.
Keep a named person responsible for fixing broken paths and a way to restore the old service if checkout or key pages fail. For a hosting-only move with unchanged URLs, confirm DNS, old and new server responses, and Search Console verification instead of inventing redirects.
Monitor the Old and New Site
Compare the new site with the dated baseline: important page responses, indexing, Search Console clicks, analytics orders or enquiries, and server errors. Check both old and new URLs. A temporary search fluctuation can be normal while Google recrawls a move, but widespread 404s, wrong redirects or lost checkout actions deserve immediate investigation.
Fix the cause before declaring success. Google recommends keeping URL-move redirects for as long as possible, generally at least a year, and updating your own links to the final URLs. Do not declare success when the homepage first loads. Keep checking useful pages and customer journeys until the known issues are resolved.
Frequently Asked Questions
What Is SEO Migration?
It is the planning and checking needed to preserve discoverable, useful pages when a website changes platform, domain, URL structure or hosting. The exact checks depend on which parts change.
How Do You Migrate a Website Without Losing SEO?
No team can guarantee unchanged search traffic. Inventory important URLs, map each moved page to a relevant destination, test the new site and redirects, remove accidental production blocks, then monitor Search Console and customer actions after launch.
Does a Redesign Always Need Redirects?
No. If only the visual design changes and page URLs remain the same, redirects may be unnecessary. Check content, navigation and technical signals anyway; add redirects only for URLs that actually move or are consolidated.