Beginner’s Website Migration Checklist

Byeditorialteam Reading Time: 9 minutes

You’re moving a site; let’s keep every visitor and every ranking.

A clean migration is just careful prep plus a disciplined launch window. This checklist walks you step by step from decision to post-launch validation so you avoid traffic drops, broken pages, email outages, and SSL surprises. Follow it in order, check off each item, and you’ll ship with confidence.

Scope, Goals, and Success Criteria

Before you touch a server, define what you’re moving and why.

  • Scope: Domain only, hosting only, CMS only, design rebuild, or all of the above.
  • Primary goals: Faster pages, lower costs, new platform, better security, brand update, or consolidation of multiple sites.
  • Non-goals: Call them out to prevent scope creep.
  • Success criteria: No organic traffic loss after 14 and 30 days, same or better Core Web Vitals, zero 4xx on top 1,000 URLs, error-free Search Console coverage, no email disruption.
  • Freeze window: Lock content deployments and plugin/theme updates during migration week.

Document this in a one-page brief everyone can see.

Build the Source-of-Truth Inventory

You can’t protect what you don’t list. Create a spreadsheet with:

  • All URLs: Crawl your site (nav, XML sitemaps, and known landing pages). Include parameters that earn traffic.
  • Top traffic pages: From analytics. Flag those as priority.
  • Backlink magnets: From your link analysis tool.
  • Media and downloads: PDFs, images, video, audio, ZIPs.
  • Structured data: Article, Product, FAQ, Breadcrumb, Organization, LocalBusiness, etc.
  • Canonical tags and meta robots: Note current values.
  • Hreflang map: If you run multiple languages.
  • Internal search pages to exclude: So you don’t accidentally index them after launch.

This inventory powers redirect mapping, QA, and post-launch checks.

Benchmark the Current Site

You need a baseline to prove the migration worked.

  • Traffic and conversions: 30/60/90-day averages.
  • Page speed: Lighthouse or WebPageTest on key templates.
  • Core Web Vitals: Field data if available.
  • Index status: Google Search Console coverage, sitemaps, mobile usability, and enhancement reports.
  • Error logs: 4xx/5xx counts from the current host or your monitoring tool.
  • DNS records: Export the zone (A, AAAA, CNAME, MX, TXT, SPF, DKIM, DMARC, SRV, CAA).
  • SSL details: Certificate issuer, SANs, expiry, HSTS header, and redirect chain behavior.
  • Email routing: Provider, MX priority, SPF includes, DKIM selectors, DMARC policy.

Snap screenshots and export reports. You’ll compare these after launch.

Choose the Migration Path

Pick the one that matches your project.

  • Same domain, new host: Lowest SEO risk. Keep URLs identical and change nameservers or A records at launch.
  • Same host, new CMS or theme: Moderate risk. Keep URL structure and content hierarchy stable.
  • Domain change (site move): Higher risk. Requires rigorous one-to-one redirects and sustained monitoring.
  • Consolidation (many to one): Highest risk. Prepare detailed canonical and redirect strategy plus content de-duplication.

Write down the chosen path. Everything else flows from it.

Staging Environment and Access

  • Spin up staging on the new host with HTTPS enabled.
  • Block indexing on staging (robots.txt disallow + noindex header/meta).
  • Create SFTP/SSH, database, and control panel users.
  • Enable 2FA on all accounts.
  • Whitelist your office or VPN IPs if needed.

Content and Data Migration

  • Export content: Posts, pages, taxonomies, media, menus, users.
  • Export data: Product catalogs, orders, customers, forms, comments, custom tables.
  • Transform safely: Match slugs, categories, and permalink structure to the old site.
  • Media paths: Keep directory structure, or rewrite references during import.
  • Test search and filters: Especially for ecommerce facets.

URL Strategy and Redirect Mapping

The fewer URL changes, the better. When changes are required:

  • One-to-one mapping: For every old URL, define the exact new URL (no hops).
  • Avoid chains: Force direct 301 from old to final destination.
  • Preserve parameters that have SEO or paid value.
  • Handle trailing slashes and casing consistently.
  • Map media and PDFs with care; many earn backlinks.
  • Fold thin duplicates to the strongest canonical.

Maintain the map in a CSV with columns: old_url, new_url, redirect_type, priority, notes.

Technical SEO and Markup Parity

Port everything that helps search engines understand your site.

  • Titles and meta descriptions: Keep or improve; don’t drop length discipline.
  • Canonical tags: Mirror self-canonicals and cross-canonicals.
  • Open Graph and Twitter tags: Preserve share appearance.
  • Structured data: Recreate schema.org markup template by template. Validate on staging.
  • Pagination rels or alternatives: Solve for large collections.
  • Robots controls: Meta robots and X-Robots-Tag headers.
  • Hreflang: Keep language-region pairs and return-links consistent.
  • XML sitemaps: Build per type (pages, posts, products). Stage the sitemap index.

Performance Engineering

  • Image optimization: Modern formats where supported, dimension attributes, lazy-loading strategy.
  • Critical CSS and preload hints: For above-the-fold rendering.
  • Caching layers: Page cache, object cache, CDN cache.
  • Database hygiene: Indexes, query audits, job queues.
  • Asset bundling: Minify and combine where it helps; avoid excessive bundles on modern HTTP/2+ connections.
  • Third-party scripts: Audit, defer non-critical, remove stale tags.

Test with throttled connections and on low-power devices.

Security and Compliance

  • TLS configuration: Strong ciphers, HTTP/2 or HTTP/3 support, HSTS if you already use it.
  • WAF/CDN: Configure rulesets and origin protection.
  • Least-privilege access: Separate deploy and admin roles.
  • Secrets management: Don’t commit keys in repos.
  • Privacy obligations: Cookie consent, data processing notices, and regional requirements.
  • Backups: Daily automatic plus an on-demand snapshot before launch.

Email and DNS Planning

Email outages ruin launches. Lock this down.

  • Confirm MX, SPF, DKIM, DMARC values and copy them verbatim to the new DNS if you’re moving DNS.
  • Reduce TTL to 300 seconds on A/AAAA/CNAME and MX 48 hours before cutover.
  • If you use vanity nameservers, update glue records when IPs change.
  • If you’re not changing DNS, you can switch only the A/AAAA records at launch.

SSL Certificates and HSTS

  • Issue certificates for apex and subdomains on staging.
  • Validate Let’s Encrypt challenges or upload purchased certs.
  • Replicate HSTS settings; don’t add preload unless you already planned for it.
  • Confirm the redirect chain is: http → https and non-www → www (or the reverse), in a single hop.

Pre-Launch Quality Assurance (Staging)

Work through this list before you consider going live.

  • Crawl staging and generate a report of 4xx/5xx, redirect chains, and canonical conflicts.
  • Template checks: Home, listing, detail, search results, cart, checkout, contact, 404.
  • Forms and email: Submissions, transactional emails, and SMTP transport.
  • Search function: Pagination, sorting, filters.
  • Media: Image compression and retina variants.
  • Accessibility basics: Headings, alt text, focus order, color contrast on key templates.
  • Analytics tags: Fire once, no duplicates; consent rules as designed.
  • Error monitoring: Client and server error capture enabled.

Fix anything red before launch day.

Launch Runbook (Go-Live Day)

Pick a low-traffic window. Assign a single owner for each step and a Slack/Teams room for comms.

  1. Freeze content on the old site.
  2. Take final backups of both old and new environments.
  3. Enable production indexing on the new site; remove noindex at the last possible moment.
  4. Point traffic:
    • If you’re staying on the same DNS, update A/AAAA records to the new origin.
    • If you’re switching DNS providers, change nameservers.
  5. Purge caches on CDN and origin.
  6. Deploy redirects from your mapping file.
  7. Validate TLS and the HTTP → HTTPS and host redirects.
  8. Spot-check top 50 URLs by traffic and top 50 by backlinks.
  9. Submit sitemaps in Search Console.
  10. Turn on monitoring dashboards in read-only mode for stakeholders.

Record start and end times for each step.

Post-Launch Validation (Hour 1–24)

  • Crawl the live site: Confirm 0 critical 5xx, minimal 4xx, no redirect loops.
  • Redirect sampling: Test at least 200 mapped URLs across types.
  • Logs: Watch 404s in real time, fix patterns with targeted redirects.
  • Search Console: Verify property ownership (domain or URL prefix), resubmit sitemaps, check Coverage and Enhancements.
  • Analytics: Compare live traffic sources against baseline hour-by-hour.
  • Transactions: If applicable, complete a live checkout and refunds test.
  • Email flow: Confirm contact forms, password resets, order emails, and admin alerts.

Stabilization (Days 2–14)

  • Rebuild 404 report daily; add or adjust redirects for any recurring misses.
  • Core Web Vitals: Check field data trends; correct regressions with asset tuning.
  • Backlink audits: Ensure high-value referrers hit 200 OK or a single 301 to the intended page.
  • Disavow file: Re-upload if you changed properties in Search Console.
  • Schema validation: Sample key templates with Rich Results Test.
  • Ranking and traffic: Compare against your baseline. Minor wobble is normal; sustained drops mean mapping or content issues to fix.

Rollback Plan

Always prepare a safe retreat.

  • Keep the old site available on a locked-down URL for at least two weeks.
  • Store a full DNS zone export to restore nameservers or A records in one step.
  • Maintain database and file backups from the last pre-launch snapshot.
  • Document a five-step rollback: reverse DNS, disable new origin, restore old cache, revert analytics config, pause sitemap submissions.

If you must roll back, announce the decision early, make the change once, and debrief after recovery.

Common Pitfalls to Avoid

  • Indexing staging because you forgot to noindex or allowlist.
  • Changing URL structure without one-to-one redirects.
  • Dropping canonical tags on collections or variants.
  • Forgetting email records when moving DNS.
  • Double-proxing through CDN and WAF with conflicting cache rules.
  • Premature HSTS preload that locks you into a bad certificate config.

Slow down when any of these appear. Fix once, verify twice.

Agency and Team Tips

  • Use a shared runbook with owners, timestamps, and checkboxes.
  • Keep a decision log of deviations from plan and why.
  • Offer clients a plain-English status page: what changed, what to expect, where to report issues.
  • Put post-launch office hours on the calendar for the first week.

Minimalist Checklist (Tape This Near Your Monitor)

Prep
[ ] Scope, goals, success criteria
[ ] URL inventory and priority pages
[ ] Baselines: traffic, vitals, coverage, logs
[ ] Staging with HTTPS and indexing blocked
[ ] Content and data migrated
[ ] Redirect map complete
[ ] Performance tuned
[ ] DNS plan, TTL lowered, email records verified
[ ] SSL issued, HSTS decision recorded
[ ] Backups taken

Launch
[ ] Freeze content
[ ] Remove noindex on new site
[ ] Switch A/AAAA or nameservers
[ ] Purge caches
[ ] Apply redirects
[ ] Validate TLS and redirects
[ ] Spot-check top pages
[ ] Submit sitemaps
[ ] Turn on monitors

After
[ ] Crawl live site
[ ] Fix 404 patterns
[ ] Verify Search Console
[ ] Validate transactions and emails
[ ] Daily checks for two weeks
[ ] Debrief and document

Final Takeaway

Migrations fail when too many changes land at once without a map. They succeed when you separate concerns, keep URLs stable, ship airtight redirects, and prove success against a clean baseline. Use this checklist, resist shortcuts, and your launch will feel uneventful—which is exactly what you want.

Frequently Asked Questions

Do I need to change nameservers to migrate hosting?

No. If you keep your DNS provider, you can switch the A and AAAA records to the new server and leave nameservers alone. That’s often the simplest and safest path.

Will I lose search rankings during a domain change?

A well-executed domain move with exact 301 redirects, stable content, and thorough monitoring can retain rankings. Temporary volatility is common; sustained drops point to redirect gaps or content mismatches.

Should I enable HSTS when I migrate?

Only if your HTTPS setup is stable and you’ve run it safely for a while. HSTS improves security but can lock you into mistakes if you misconfigure certificates or redirects.

How long should I keep the old site online?

Keep a locked copy for at least two weeks so you can validate content, compare behavior, and roll back if needed. Some teams keep archival copies longer for legal or audit reasons.

What if staging accidentally gets indexed?

Block crawling immediately with authentication or noindex, remove any staging URLs from sitemaps, and request removal in Search Console. Then audit your deployment process to prevent a repeat.

How do I test redirects at scale?

Use your URL inventory CSV and run it through a crawler that reports status codes and chains. Fix anything that isn’t a direct 301 to the final destination.

Do I need to regenerate a new SSL certificate after moving?

Yes, certificates are tied to servers and domains. If the origin or proxy changes, issue valid certificates for your hostnames on the new path before go-live.

References

  • Google Search Central: Site moves with URL changes
  • Google Search Central: Manage your sitemaps
  • Let’s Encrypt: Certificates and renewal basics
  • Mozilla: HTTP Strict Transport Security (HSTS)
  • Cloudflare Learning Center: DNS records and TTLs
  • W3C: Web Content Accessibility Guidelines basics

Links

Similar Posts