SEO Migration Checklist: 20 Steps to Protect Your Rankings When Moving Your Website

If you’ve ever watched a perfectly good website lose 60% of its organic traffic overnight because someone skipped a redirect map, you know why having a proper SEO migration checklist matters. I’ve seen it happen to Singapore businesses more times than I’d like to admit. A redesign goes live on a Friday afternoon, nobody checks the 301s, and by Monday morning the phone calls start: “Jim, where did all our traffic go?”

This guide is the exact process we follow at Best SEO when handling site migrations for our clients. It covers every phase, from the first planning meeting through to the 90-day post-migration monitoring window. Whether you’re moving from HTTP to HTTPS, switching domains, restructuring your URL architecture, or migrating to a new CMS entirely, this is your reference document.

I’ve broken it into three parts: pre-migration preparation, the migration itself, and post-migration monitoring. Each step includes the specific actions you need to take, the tools involved, and the mistakes I see teams make repeatedly.

Let’s get into it.

Part 1: Pre-Migration (Steps 1–6)

The pre-migration phase is where 80% of the real work happens. If you rush this part, no amount of post-launch firefighting will save your rankings. I tell every client the same thing: a migration is like renovating your HDB flat. You don’t start knocking down walls before you have the floor plan approved.

Step 1: Define Your Migration Goals with Measurable Targets

Before you touch a single file, get crystal clear on why you’re migrating and what success looks like. “We want a nicer website” is not a migration goal. That’s a wish.

Here are examples of actual migration goals I’ve worked with:

• Retain at least 90% of current organic traffic within 8 weeks of launch
• Preserve all page-one keyword rankings for the top 50 commercial terms
• Reduce page load time from 4.2 seconds to under 2 seconds on mobile
• Consolidate three separate subdomains into a single domain with proper URL hierarchy
• Move from HTTP to HTTPS without losing link equity from 1,200+ referring domains

Write these down. Put them in a shared document. Make sure your developer, your designer, your content team, and your boss all agree on them. I’ve seen migrations derail because the marketing team wanted to preserve every URL while the design team was quietly deleting 40% of the pages to “simplify the navigation.”

Your goals dictate your redirect strategy, your URL mapping approach, and your success metrics. Without them, you’re flying blind.

One more thing. Document your current baseline numbers before anything else. Pull these from Google Search Console and GA4:

• Total organic sessions (last 90 days)
• Top 100 landing pages by organic traffic
• Total indexed pages
• Total impressions and average position for your target keywords
• Core Web Vitals scores for your top 20 pages
• Crawl stats from GSC (pages crawled per day, response times)

These numbers become your “before” snapshot. Without them, you cannot measure whether the migration succeeded or failed. I keep these in a spreadsheet that gets reviewed weekly for 12 weeks after launch.

Step 2: Plan Your Migration Timing Strategically

Timing a migration poorly can amplify the damage. Here’s how I think about scheduling.

Avoid your peak traffic periods. If you run an e-commerce site in Singapore and December is your biggest month because of 12.12 sales and Christmas shopping, do not migrate in November. Push it to January or February. If you’re a B2B services company and your busiest quarter is Q1, migrate in Q3.

Pull up your GA4 data and look at traffic patterns by month, by day of week, and by hour. Find your quietest window.

For most Singapore B2B websites I’ve worked with, Tuesday or Wednesday mid-morning (around 10am SGT) is the sweet spot. Your team is fresh, fully staffed, and you have the rest of the working day to catch issues. Avoid Friday launches. If something breaks, you’re scrambling over the weekend when your developer might be at East Coast Park.

Build a realistic timeline that accounts for these phases:

• Discovery and audit: 1–2 weeks
• URL mapping and redirect planning: 1–2 weeks (longer for large sites)
• Staging site build and content migration: 2–6 weeks depending on site size
• QA testing on staging: 1–2 weeks
• Go-live and immediate monitoring: 1 week
• Post-migration monitoring: 8–12 weeks

For a 200-page corporate website, expect the full process to take 8–12 weeks from start to finish. For a 5,000-page e-commerce site, budget 16–20 weeks minimum. Rushing this timeline is one of the most common causes of migration failures I see.

Step 3: Assign Clear Roles and Responsibilities

A migration touches every part of your web presence. You need specific people accountable for specific tasks, not a vague “the web team will handle it” arrangement.

Here’s how I structure migration teams:

Project Manager: Owns the timeline, runs the weekly check-ins, and is the single point of contact for decisions. This person doesn’t need to be technical, but they need to understand the stakes and keep everyone on schedule.

Technical SEO Specialist: Responsible for the crawl audit, URL mapping, redirect implementation review, robots.txt configuration, XML sitemap updates, canonical tag verification, and post-launch monitoring. This is the most critical role in the migration. If you don’t have this expertise in-house, hire someone.

Lead Developer: Handles the staging environment setup, server configuration, DNS changes, SSL certificate installation, redirect implementation at the server level, and CMS migration. They need to understand HTTP status codes, .htaccess rules (or equivalent for your server), and how CDNs interact with redirects.

Content Lead: Manages content inventory, ensures all pages are accounted for, handles content updates or consolidation, and verifies that meta titles, descriptions, and structured data are correctly transferred.

QA Tester: Systematically checks every page type on the staging site. Tests forms, navigation, internal links, images, videos, and interactive elements across desktop and mobile.

Create a RACI matrix (Responsible, Accountable, Consulted, Informed) for every major task. I know it sounds like overkill, but I’ve watched a $50,000 migration go sideways because the developer assumed the SEO team was handling redirects, and the SEO team assumed the developer was handling them. Nobody did.

Before any work begins, make sure your developer creates a complete backup of the current site. Database, files, media, configurations, everything. Store it somewhere separate from your hosting environment. If the migration fails catastrophically, you need the ability to roll back within hours, not days.

Step 4: Conduct a Thorough Technical SEO Audit

You wouldn’t renovate a building without first checking the structural integrity. Same principle applies here. A pre-migration SEO audit tells you what’s working, what’s broken, and what you should fix before, during, or after the move.

Here’s what to audit and the tools I use:

Full site crawl (Screaming Frog or Sitebulb):

• Total number of URLs (HTML pages, images, PDFs, JavaScript files)
• HTTP status codes for every URL (200, 301, 302, 404, 410, 500)
• Page titles and meta descriptions (duplicates, missing, too long, too short)
• H1 tags (missing, duplicate, multiple per page)
• Canonical tags (self-referencing, cross-domain, missing)
• Hreflang tags if you have multilingual content
• Internal link structure and orphan pages
• Page depth (clicks from homepage)
• Response times per URL

Google Search Console data:

• Index coverage report (valid, excluded, error pages)
• Core Web Vitals (LCP, FID/INP, CLS) for mobile and desktop
• Manual actions or security issues
• Crawl stats (pages crawled per day, average response time, crawl budget usage)
• Sitemaps status

Backlink profile (Ahrefs or Semrush):

• Total referring domains
• Top linked pages (these are your highest-priority redirect targets)
• Anchor text distribution
• Any toxic or spammy links that should be disavowed before migration

Google Analytics 4:

• Top landing pages by organic sessions
• Conversion data by landing page
• Bounce rate and engagement metrics for key pages

Here’s a critical point many teams miss. Fix existing issues before you migrate, not after. If your current site has 150 broken internal links, 30 pages with duplicate titles, and 12 redirect chains, clean those up on the current site first. Migrating a messy site just creates a messier new site with additional migration-related problems layered on top.

I worked with a Singapore fintech company last year that had 847 pages returning soft 404 errors on their existing site. They wanted to migrate to a new CMS without fixing these first. We spent two weeks cleaning up the existing site before starting the migration. The result? Their post-migration traffic recovery took 3 weeks instead of the typical 6–8 weeks, because search engines weren’t wasting crawl budget on dead pages.

Step 5: Build a Complete URL Inventory

This is the foundation of your redirect map, and it needs to be comprehensive. Miss a URL here, and that page becomes a 404 after migration. If that page had backlinks or organic traffic, you’ve just thrown away SEO value.

Collect URLs from all of these sources:

1. Screaming Frog crawl export. This gives you every URL the crawler can find by following links on your site. Export the full list.

2. Google Search Console > Pages report. This shows every URL Google knows about, including ones that might not be linked internally. Export the full list of valid (indexed) pages and the “Excluded” pages too. Some excluded pages might still have backlinks pointing to them.

3. Google Analytics 4 > Pages and screens report. Filter by organic traffic. This shows you which URLs actually receive visitors. These are your highest-priority pages.

4. XML sitemap. Download your current sitemap and extract all URLs. Compare against the crawl data. If there are URLs in your sitemap that aren’t in your crawl, investigate why.

5. Backlink tool export (Ahrefs or Semrush). Export all pages that have at least one referring domain. Some of these pages might be old, deleted, or already 404ing. They still need to be in your redirect map because external sites are linking to them.

6. Server access logs (if available). These can reveal URLs that bots and users are requesting that don’t appear in any other data source. Particularly useful for finding old URLs from previous migrations that are still receiving traffic.

Combine all these sources into a single spreadsheet. Remove exact duplicates. You should end up with columns for:

• Current URL
• HTTP status code
• Organic sessions (last 90 days)
• Number of referring domains
• Whether it’s in the XML sitemap
• Whether it’s indexed in GSC

Sort by organic traffic descending. Your top pages get the most attention during mapping. For a typical 500-page Singapore corporate site, this inventory process takes 4–8 hours. For a 10,000-page e-commerce site, budget 2–3 days.

Don’t forget image URLs. If your images rank in Google Image Search or are embedded on external sites, they need redirects too. Use Screaming Frog’s image extraction feature to pull all image URLs.

Step 6: Create Your URL Redirect Map

This is the single most important document in your entire migration. Get this wrong, and you will lose rankings. Full stop.

Your redirect map is a spreadsheet with at minimum these columns:

• Old URL (full path including domain)
• New URL (full path including domain)
• Redirect type (301 in almost all cases)
• Notes (why this redirect exists, any special considerations)

Rules for creating your redirect map:

Rule 1: Every old URL must have a destination. That destination is either a new URL (301 redirect), a 410 Gone status (content permanently removed with no equivalent), or it remains the same (URL structure unchanged).

Rule 2: Redirect to the most relevant equivalent page. If /services/seo-audit/ on the old site becomes /seo-services/technical-audit/ on the new site, that’s a straightforward 1:1 redirect. Never redirect unrelated pages to the homepage. Google treats mass homepage redirects as soft 404s, and you lose the link equity anyway.

Rule 3: Avoid redirect chains. If Page A already redirects to Page B on your current site, and Page B is moving to Page C on the new site, make sure Page A redirects directly to Page C. Chains slow down crawling and leak link equity at each hop. Screaming Frog can identify existing redirect chains in your current site.

Rule 4: Handle parameter URLs. If your site uses URL parameters for filtering, sorting, or tracking (e.g., /products/?sort=price&category=shoes), decide whether these need individual redirects or whether a pattern-based redirect rule will handle them.

Rule 5: Plan for deleted content. If you’re removing pages that have no equivalent on the new site, use a 410 status code rather than a 404. A 410 tells Google the removal is intentional and permanent. Google will de-index these pages faster than with a standard 404.

Here’s a practical example. Say you’re a Singapore law firm migrating from an old WordPress site to a new one with a restructured URL hierarchy:

Old URL	New URL	Type
/corporate-law-services/	/services/corporate-law/	301
/blog/2019/changes-to-companies-act/	/insights/companies-act-amendments-singapore/	301
/team/john-tan-retired/	(none)	410
/contact-us/	/contact/	301

For large sites, you’ll also need regex-based redirect rules to handle patterns. For example, if every blog post is moving from /blog/YYYY/post-slug/ to /insights/post-slug/, a single regex rule can handle hundreds of redirects. But always test regex rules thoroughly. A badly written regex can redirect your entire site to a single page.

Set up a staging environment to test everything. Your developer should create a copy of the new site on a staging subdomain (e.g., staging.yoursite.com). Password-protect it. Add a noindex meta tag to every page and block it in robots.txt. You do not want Google indexing your staging site.

Test your redirects on staging before going live. Use Screaming Frog to crawl the old URL list against the staging site and verify that every redirect lands on the correct destination with a 301 status code.

Part 2: During Migration (Steps 7–14)

This is launch day and the hours immediately surrounding it. Everything you planned in Part 1 gets executed here. Move methodically. Don’t skip steps because things “look fine.”

Step 7: Implement All 301 Redirects

With your redirect map finalised and tested on staging, it’s time to implement the redirects on your production server.

Where to implement redirects depends on your server:

• Apache servers: .htaccess file using RewriteRule directives
• Nginx servers: Server configuration file using rewrite or return directives
• Cloudflare or CDN: Page Rules or Bulk Redirects
• CMS plugins: Redirection plugin for WordPress, or equivalent for your platform

I strongly recommend implementing redirects at the server level rather than through CMS plugins whenever possible. Server-level redirects are faster (they execute before the CMS even loads) and more reliable. Plugin-based redirects add a database query for every redirect, which can slow your site if you have thousands of them.

For an Apache server, a basic redirect looks like this:

Redirect 301 /old-page/ https://www.yoursite.com/new-page/

For pattern-based redirects:

RewriteRule ^blog/([0-9]{4})/(.*)$ /insights/$2 [R=301,L]

Critical checks after implementing redirects:

• Test at least 50 redirects manually using a browser or curl command
• Verify that redirects return a 301 status code, not a 302 (temporary redirect). A 302 does not pass full link equity.
• Check for redirect loops (Page A redirects to Page B, which redirects back to Page A). These will crash the page.
• Check for redirect chains (A → B → C). Flatten them to A → C.
• Verify that both www and non-www versions redirect correctly
• Verify that HTTP versions redirect to HTTPS versions
• Test trailing slash and non-trailing slash variations

Use httpstatus.io or Screaming Frog’s list mode to bulk-check redirect status codes. Feed in your entire old URL list and verify every single one resolves correctly.

Step 8: Update DNS Settings

If your migration involves a domain change or a hosting provider change, you’ll need to update your DNS records. This is the step where your site actually “moves” to its new home.

Before changing DNS:

• Lower your DNS TTL (Time to Live) to 300 seconds (5 minutes) at least 48 hours before migration. This ensures that when you make the switch, the change propagates quickly. If your TTL is set to 86400 (24 hours), some users will see the old site for up to a day after you switch.
• Document your current DNS records (A records, CNAME records, MX records, TXT records). Screenshot them. You need these for rollback if something goes wrong.
• Ensure your new server is fully configured and tested before pointing DNS to it.

During DNS change:

• Update A records to point to your new server’s IP address
• Update CNAME records if applicable
• Verify MX records are correct (you don’t want to lose email during a site migration)
• Verify any TXT records for domain verification (Google Search Console, email authentication like SPF/DKIM) are recreated on the new DNS

After DNS change:

• Use whatsmydns.net to monitor DNS propagation globally
• Test from multiple devices and networks (office WiFi, mobile data, VPN) to confirm the new site is loading
• Keep the old server running for at least 2 weeks after DNS change. Some DNS resolvers cache aggressively, and you want the old server to serve redirects to anyone still hitting it.

For Singapore-specific considerations: if your site uses a .sg domain managed through SGNIC, DNS changes can sometimes take slightly longer to propagate through local ISPs like Singtel, StarHub, and M1. Test from each network.

Step 9: Verify SSL Certificate Installation

If your migration involves moving to HTTPS (and in 2026, every site should be on HTTPS), verify your SSL certificate is properly installed and configured on the new server.

Check these items:

• Certificate covers all required domains and subdomains (www and non-www, plus any subdomains like blog.yoursite.com)
• Certificate chain is complete (intermediate certificates are installed)
• No mixed content warnings (HTTP resources loaded on HTTPS pages). Use the browser console or a tool like Why No Padlock to identify mixed content.
• HSTS headers are configured correctly if you’re using them
• HTTP to HTTPS redirects are working for all URL patterns

A common mistake: the developer installs the SSL certificate but forgets to set up the HTTP to HTTPS redirect. So the site works on HTTPS if you type it in directly, but anyone visiting via an old HTTP link gets a non-secure page or an error. Test both protocols for every URL pattern.

Step 10: Migrate All Content Completely

Content migration sounds simple. It rarely is. Here’s what needs to transfer correctly:

Page content: Body text, headings, images, videos, embedded media, tables, downloadable files (PDFs, docs). Don’t just check that the text transferred. Check that formatting is intact, images display correctly, and all media files are accessible.

SEO metadata: Page titles, meta descriptions, Open Graph tags, Twitter Card tags. I’ve seen migrations where the developer imported all the page content perfectly but left every meta description blank because the new CMS used a different field name. Check every page type.

Structured data: Schema markup (Organisation, LocalBusiness, FAQ, Product, BreadcrumbList, etc.). If your old site had structured data generating rich results in Google, verify it’s present and valid on the new site. Use Google’s Rich Results Test on your staging site.

Internal links: Every internal link on every page needs to point to the correct new URL. Not the old URL that then redirects. The actual new URL. Internal links that go through redirects waste crawl budget and create unnecessary server load. Use Screaming Frog to crawl the staging site and identify any internal links that return 301 status codes. Fix them to point directly to the final destination.

Images: Verify that all images have transferred, that they load correctly, that alt text is preserved, and that image file names haven’t changed (or if they have, that redirects are in place). For Singapore businesses, this is particularly important if you have product images that rank in Google Image Search.

Forms and interactive elements: Contact forms, search functionality, calculators, booking widgets, chat integrations. Test every single one. I once saw a migration where the contact form looked perfect but the form action URL still pointed to the old domain. Every lead submission for two weeks went into a void.

Step 11: Update Robots.txt

Your robots.txt file on the new site needs to be correct from the moment you go live. Get this wrong and you could accidentally block Google from crawling your entire site.

Checklist for robots.txt:

• Remove any “Disallow: /” rules that were used on the staging site to block crawlers. This is the single most common migration mistake I encounter. The staging site had a blanket disallow rule, the site goes live, and nobody removes it. Google dutifully stops crawling the entire site. Rankings disappear within days.
• Ensure the sitemap directive points to your new XML sitemap URL
• Verify that any intentional disallow rules (e.g., blocking /admin/, /cart/, /checkout/) are correct for the new URL structure
• If you’ve changed URL patterns, update the disallow rules accordingly

After updating robots.txt, use the robots.txt tester in Google Search Console (or the Robots Testing Tool at google.com) to verify that your important pages are crawlable and your private pages are blocked.

Step 12: Submit Updated XML Sitemap

Your XML sitemap needs to reflect the new site structure. Here’s what to do:

• Generate a new XML sitemap containing all the new URLs you want indexed
• Ensure the sitemap only contains 200-status URLs (no redirects, no 404s, no noindexed pages)
• If your site is large, use a sitemap index file with multiple child sitemaps organised by section (e.g., sitemap-pages.xml, sitemap-posts.xml, sitemap-products.xml)
• Submit the new sitemap in Google Search Console
• Also submit the old sitemap (with the old URLs) temporarily. This helps Google discover the redirects faster. Google will crawl the old URLs, encounter the 301 redirects, and update its index to the new URLs. Keep the old sitemap submitted for 2–4 weeks, then remove it.

For Bing, submit the new sitemap through Bing Webmaster Tools as well. If your Singapore business targets Chinese-speaking audiences, consider submitting to Baidu Webmaster Tools too.

Step 13: Verify Google Search Console and Analytics Setup

This step is about making sure your tracking and monitoring tools are properly configured for the new site.

Google Search Console:

• If you’ve changed domains, add and verify the new domain property in GSC
• Use the Change of Address tool in GSC (Settings > Change of address) to notify Google of the domain change. This is only available for domain changes, not for URL restructuring on the same domain.
• Keep the old domain property active in GSC for at least 6 months. You need it to monitor how Google processes the redirects.
• Submit your new sitemap in the new property
• Verify that the correct sitemap URL is referenced

Google Analytics 4:

• Verify that your GA4 tracking code is present on every page of the new site
• If you changed domains, update the data stream settings in GA4 to reflect the new domain
• Check that events, conversions, and e-commerce tracking are firing correctly. Use GA4’s DebugView or the Google Tag Assistant browser extension.
• Set up annotations or notes in your reporting to mark the migration date. This makes it much easier to analyse traffic changes later.

Other tracking tools:

• Facebook Pixel, LinkedIn Insight Tag, Google Ads conversion tracking, any other marketing pixels. Verify all of them are present and firing on the new site.
• Heatmap tools (Hotjar, Microsoft Clarity). Update configuration if needed.
• Rank tracking tools (Ahrefs, Semrush, SE Ranking). Update the tracked domain if it changed.

Step 14: Conduct a Final Pre-Launch Audit

This is your last quality gate before going live. Run through this checklist systematically. Don’t skip items because you’re under time pressure.

Technical checks:

• Full crawl of the new site with Screaming Frog. Check for 404 errors, broken internal links, missing meta tags, duplicate content, missing canonical tags, and orphan pages.
• Page speed test on the top 10 pages using Google PageSpeed Insights. Compare against your pre-migration baseline. If the new site is significantly slower, fix it before launching.
• Mobile usability test. Google’s Mobile-Friendly Test, plus manual testing on actual devices (not just browser dev tools).
• Structured data validation using Google’s Rich Results Test on key page templates.
• Robots.txt review (one final check that the staging disallow rules are removed).
• XML sitemap validation. Ensure it’s accessible and contains only valid URLs.

Content checks:

• Spot-check at least 20 pages across different templates (homepage, service pages, blog posts, product pages, contact page) for content accuracy.
• Verify all images load correctly and have alt text.
• Check that downloadable files (PDFs, whitepapers) are accessible.
• Test all forms by submitting test entries and confirming they arrive at the correct email or CRM.

Redirect checks:

• Bulk-test your entire redirect map one final time. Every old URL should return a 301 to the correct new URL.
• Test edge cases: URLs with parameters, URLs with trailing slashes, URLs with uppercase characters, URLs with special characters.

Only when every item on this checklist passes should you proceed to launch.

Part 3: Post-Migration (Steps 15–20)

The site is live. Your work is far from over. The post-migration phase is a 90-day monitoring and response period. This is where you catch issues early and prevent small problems from becoming ranking disasters.

Step 15: Monitor Crawl Activity in Google Search Console

Within the first 24–48 hours after launch, check Google Search Console’s crawl stats report (Settings > Crawl stats). You want to see:

• An increase in crawl rate. Google should be crawling your site more aggressively as it discovers the changes. If crawl rate drops, something is blocking the crawler (check robots.txt immediately).
• Mostly 200 and 301 status codes. A spike in 404 or 500 errors indicates problems with your redirects or server configuration.
• Reasonable response times. If average response time jumps from 200ms to 2000ms, your new server is struggling under load or there’s a configuration issue.

Also check the Pages report (Indexing > Pages) daily for the first two weeks. Watch for:

• A temporary dip in indexed pages (normal, as Google processes redirects)
• New “Not found (404)” errors (indicates missing redirects)
• New “Redirect” entries (Google discovering your