A website migration is one of the few SEO projects where a single afternoon of mistakes can undo years of work. Change your domain, move platforms, restructure your URLs or switch to HTTPS without a plan, and pages that used to bring in steady enquiries can vanish from Google while old links lead customers to error pages.
The good news is that most migration losses are preventable. Google publishes clear guidance on moving a site, and the work is mainly careful preparation, accurate redirects and close monitoring afterwards. This SEO migration checklist sets out 23 steps across four phases, with owners and timing, a table of migration types and their risks, and the mistakes we see most often when Singapore SMEs relaunch their websites.
What counts as an SEO migration
Any change that alters the URLs, content, structure or hosting of many pages at once is a migration from a search engine’s point of view. Common types and their typical risk are below; the risk levels are our rough planning guide, not a measured score.
| Migration type | Example | URLs change? | Typical SEO risk | Change of Address tool? |
|---|---|---|---|---|
| HTTP to HTTPS | Adding an SSL certificate site-wide | Protocol only | Low if redirects are correct | No |
| Domain change | Rebranding from oldname.com.sg to newname.sg | Yes, every URL | High | Yes |
| Platform change | Moving from Wix or a custom build to WordPress or Shopify | Often | Medium to high | No, unless the domain changes |
| URL restructure | Changing /services/aircon-servicing.html to /aircon-servicing/ | Yes | Medium to high | No |
| Redesign without URL changes | New theme and layout, same URLs | No | Low to medium (content and internal links still change) | No |
| Merging sites | Combining two brand sites into one | Yes, for one site | High | Yes, if a whole domain moves |
Google’s guide to site moves with URL changes is the primary reference for any move where URLs change. Read it before you start; the steps below put it into a practical order for a small team.
Phase 1: Plan and benchmark (4–8 weeks before launch)
1. Define the scope and reason for the migration
Write down exactly what is changing: domain, platform, URL structure, design, content or all of these. The more you change at once, the harder it is to diagnose problems. If you can, separate a domain change from a redesign by a few weeks.
2. Choose a launch window
Avoid your busiest season. A tuition centre should not migrate in January enrolment week, and a retailer should avoid the run-up to 11.11 or Chinese New Year. Pick a quieter weekday when your developer is available for several days afterwards.
3. Record a performance baseline
Export at least three months of Search Console data (clicks, impressions, top queries and top pages) and GA4 data for organic sessions and key events such as enquiry forms and WhatsApp taps. Without a baseline you cannot tell whether the migration caused a change. Our list of SEO KPIs to track shows which numbers to keep.
4. Crawl and inventory every existing URL
Use a site crawler to list every URL on the current site, then add URLs from your XML sitemap, Search Console’s top pages, GA4 landing pages and backlink exports. Pages that receive links or traffic but are not linked internally are easy to miss.
5. Identify your most valuable pages
Flag the pages that bring the most organic clicks, enquiries and inbound links. These get the closest attention in redirect mapping and testing. Our guide to inbound links explains why linked pages matter during a move.
6. Agree roles and a rollback plan
Decide who signs off each stage, who builds and tests redirects, and what happens if something serious breaks on launch day. Keep a full backup of the old site and confirm you can restore it.
Phase 2: Build and test on staging (2–4 weeks before launch)
7. Plan the new URL structure
Keep URLs the same wherever possible; every change creates a redirect and a small risk. Where you do change them, use short, readable, lowercase URLs. Our guides to SEO-friendly URL structure and site structure cover the principles.
8. Build a one-to-one redirect map
In a spreadsheet, map every old URL to its closest equivalent new URL. Google recommends server-side permanent redirects, such as 301s, for moved content; see its guide to redirects and Google Search. Avoid redirecting many unrelated old pages to the homepage, which Google may treat like a missing page.
9. Decide what to retire
Some old pages are outdated or thin. Either merge them into a stronger page and redirect, or let them return a 404 or 410 status if there is no relevant replacement. Make these decisions deliberately rather than by accident.
10. Block the staging site from search engines
Protect the staging site with a password or IP restriction so it cannot be indexed before launch. A robots.txt block or noindex tag also works, but remember to remove it at launch. Google’s robots.txt introduction explains what robots.txt does and does not do.
11. Carry over titles, descriptions and headings
Check that each important page keeps or improves its page title, meta description, H1 and main content. Platform changes often reset these to defaults.
12. Preserve content and internal links
Make sure key text, FAQs and images, with alt text, survive the move, and update internal links to point directly at new URLs rather than through redirects. Our guide to internal links explains why.
13. Set canonical tags and structured data
Each new page should carry a self-referencing canonical tag pointing to its new URL, as described in Google’s guide to consolidating duplicate URLs. Recheck any structured data, such as LocalBusiness or Product markup, so it reflects the new URLs and remains accurate.
14. Test performance and mobile usability
Test key templates on a mid-range phone over mobile data. A new design that is slower than the old one can hurt engagement even if every redirect works.
15. Test forms, tracking and integrations
Submit every enquiry form, tap every WhatsApp and call button, and confirm GA4 records each key event. Check booking systems, payment pages and any CRM connection. Update your privacy notice if what you collect changes, in line with the PDPA.
Phase 3: Launch day
16. Remove staging blocks and go live
Remove any password, robots.txt block or noindex tag carried over from staging. This is one of the most common and damaging migration errors, so check it twice.
17. Switch on and test redirects
Activate the redirect map and test a sample of old URLs, including your most valuable pages, with a crawler or redirect checker. Each should return a single 301 to the correct new page, without chains or loops.
18. Submit the new XML sitemap
Submit the new sitemap in Search Console so Google discovers the new URLs. Google’s site-move guide also suggests keeping a sitemap of the old URLs available for a while so Google can find the redirects. Our guide to sitemaps has the basics.
19. Use the Change of Address tool if the domain changed
If you moved to a new domain, verify both domains in Search Console and use the Change of Address tool from the old property. Google states it is for domain or subdomain moves, not for HTTP-to-HTTPS changes or URL changes within the same domain.
Phase 4: Monitor and fix (launch to 3 months after)
20. Watch Search Console daily for the first two weeks
Check the Page indexing report for new errors, the Performance report for sudden drops on key pages, and crawl stats for server errors. Some short-term fluctuation is normal while Google processes the move.
21. Fix 404s and broken links quickly
Crawl the new site, review 404 reports and add any missing redirects. Pay special attention to old URLs that still receive external links or traffic.
22. Update external references
Update your Google Business Profile website link, social media profiles, ad destination URLs, email signatures and directory listings. Ask partners who link to you to update important links.
23. Compare results with your baseline and keep redirects in place
At four, eight and twelve weeks, compare clicks, impressions, top queries and enquiries with your baseline, allowing for seasonality. Google’s site-move guidance recommends keeping redirects for as long as possible, generally at least a year. Do not let your old domain expire if it still receives links.
A simple migration timeline with owners
For a typical SME website of up to a few hundred pages, an illustrative timeline might look like this:
- Weeks −8 to −6 – Scope, baseline and URL inventory (owner: marketing lead). Steps 1 to 5.
- Week −6 – Sign-off and rollback plan (owner: business owner). Step 6.
- Weeks −5 to −2 – Build, redirect map and staging tests (owner: web developer, with marketing lead checking content). Steps 7 to 15.
- Launch day – Go live and verify (owner: web developer, with marketing lead on call). Steps 16 to 19.
- Weeks +1 to +2 – Daily monitoring and fixes (owner: web developer). Steps 20 and 21.
- Weeks +2 to +12 – External updates and reviews (owner: marketing lead and business owner). Steps 22 and 23.
How AI can help with a site migration
AI and automation can speed up the most tedious parts of a migration: matching old URLs to new ones by title and content similarity, checking large redirect maps for chains and loops, comparing old and new page titles in bulk, and summarising crawl reports after launch. They are also useful for monitoring, flagging new 404s or indexing drops as they appear.
The limits matter here more than in most SEO tasks. An automated redirect suggestion can be confidently wrong, sending a service page to an unrelated article. Treat every AI-generated mapping as a draft that a person who knows the business reviews, especially for your most valuable pages, and never let a tool push redirect or robots.txt changes live without approval.
Marketing2u’s AI SEO Agent monitors status codes, redirects, canonicals, sitemaps and index drops, and flags broken links; it does not change redirects, URLs or robots.txt itself, so those stay with your developer. The AI Website Agent watches for broken pages and links and can run agreed test submissions on your forms after launch. Neither can promise that rankings will be preserved.
SEO migration mistakes to avoid
- Leaving the staging noindex or robots.txt block in place. The whole site can drop out of search within days.
- Redirecting everything to the homepage. Visitors and search engines lose the specific page they wanted.
- Redirect chains. Old URL to interim URL to new URL slows crawling and users. Point each old URL straight at its final destination.
- Forgetting images, PDFs and other files. Brochures and price lists often have their own links and traffic.
- Losing tracking. If GA4 or conversion tags are missing on the new site, you cannot measure the impact.
- Changing everything at once. A new domain, platform, design and content in one launch makes problems hard to trace. Our guide to common web design mistakes covers related pitfalls.
- Removing redirects too early. Old links and bookmarks keep sending visitors for years.
Planning your migration
A successful website migration protects what already works: the pages that rank, the links that point to you and the enquiries they produce. Follow this SEO migration checklist in order, give your most valuable pages the most attention, and plan for close monitoring after launch rather than treating go-live as the finish line.
If you are still deciding whether to change your domain at all, read our guide on whether your domain name matters for SEO, and run an SEO audit on the current site first so you know what you are protecting.
Frequently asked questions
Will I lose rankings when I migrate my website?
Some short-term fluctuation is common while Google recrawls and processes the move, especially for domain changes. With accurate one-to-one redirects, preserved content and quick fixes for errors, many sites recover to their previous level over the following weeks or months. Nobody can promise no impact, so plan the launch for a quieter period.
How long should I keep 301 redirects after a migration?
Google’s site-move guidance recommends keeping redirects in place for as long as possible, generally at least a year. In practice, keep them indefinitely for pages that still receive links or traffic, and keep renewing the old domain if it has inbound links.
Do I need the Change of Address tool for an HTTPS migration?
No. Google says the Change of Address tool is for moving to a different domain or subdomain. For an HTTP-to-HTTPS move on the same domain, set up site-wide 301 redirects, update canonical tags and internal links, and submit the HTTPS sitemap in Search Console.
What is a redirect map?
A redirect map is a spreadsheet listing every old URL alongside the new URL it should permanently redirect to. It is the core document of any SEO migration, because it ensures visitors and search engines reach the closest equivalent page instead of an error.
Sources and further reading
- Google Search Central: Site moves with URL changes
- Google Search Central: Redirects and Google Search
- Search Console Help: Change of Address tool
- Google Search Central: Consolidate duplicate URLs with canonicals
- Google Search Central: Introduction to robots.txt
Related guides
- 301 vs 302 vs 307 vs 308 Redirects: Which One to Use
- How to Fix 404 Errors and Use 301 Redirects Correctly
- SEO-Friendly URL Structure: Best Practices for 2026
- How To Do An SEO Audit: 9 Things To Check For
- Best Site Structure for SEO: How to Organise Your Website for Rankings
Browse every article in our SEO guides.