A Pre-Migration Checklist for Your Website

A website migration checklist is a structured, phase-by-phase list of tasks that protects your content, rankings, and traffic when you move a site to a new platform, domain, or hosting environment.

Run it before you touch anything on the new site. Most migration damage happens not during the move itself, but in the hours before it: missing backups, unmapped redirects, and skipped staging tests that let silent errors slip into production.

The checklist covers three phases: pre-migration (audit, backup, redirect mapping), migration day (DNS changes, crawl checks, Google Search Console submissions), and post-migration monitoring for 30 days. Each phase has a clear owner so you know what you handle yourself and what requires a developer.

If you are migrating from WordPress without breaking your site, the same three-phase logic applies. The platform changes; the order of operations does not.

Work through every section below before your go-live date. Skipping even one step has a cost, and that cost usually shows up in your search rankings two weeks after the move.

Phase 1: The Pre-Migration Audit

The pre-migration audit is the most important step in the entire checklist. It tells you exactly what you have before you move it, so you are not discovering missing pages, broken links, or lost rankings after the fact. Without it, you are migrating blind.

Start by crawling your current site with a tool like Screaming Frog, Sitebulb, or any comparable crawler. The goal is a complete inventory: every URL, every internal link, every canonical tag, every page title and meta description. This is your source of truth for the entire migration.

Pay specific attention to your top-performing pages. These are the pages driving the traffic and rankings you cannot afford to lose. Map their current URLs, organic traffic, and backlink count before anything else moves.

Your audit should produce four outputs:

• A full URL inventory of every indexable page on the current site
• A top-pages report showing which URLs send the most organic traffic and hold the most backlinks
• A list of broken links and existing 404s so you are not carrying errors into the new site
• A metadata export (titles, descriptions, H1s, canonicals) to replicate on the new platform

Understanding the SEO signals that actually move rankings is useful context here. Your audit is not just a safety net; it is the brief you hand off to whoever builds the new site.

One more thing: record your current ranking positions and traffic baselines in a spreadsheet. You will need these numbers to evaluate post-migration health. You cannot diagnose a traffic drop if you never measured where you started.

Back Up Everything Before You Move Anything

A backup creates a complete, restorable copy of your site so that if anything breaks during migration, you can roll back to the exact state you started from. Make this backup the day before migration day, after all content is final.

The critical distinction: a backup is not the same as a content export. A content export gives you the text and images in a portable format. A backup gives you the entire environment, including your database, configuration files, and server state, so you can restore the site to exactly how it worked before. You need both.

Founders routinely skip full backups because the export feels like enough. It is not. If your new platform has a configuration error or a plugin conflict, an export does not help you restore the old site quickly. A backup does.

Organize your backup into three categories:

1. Database backup: Your posts, pages, user accounts, settings, and all dynamic content. Export this separately and verify the file is not empty before moving on.
2. File system backup: Your theme files, plugin directories, uploaded media, and any custom code. Download a complete copy to local storage, not just to another cloud folder on the same host.
3. DNS and hosting configuration: Document your current nameservers, A records, MX records, and any custom DNS entries. Losing these during a hosting change can take your email offline alongside your site.

Store at least one backup copy off-platform entirely. For more detail on the full backup process, see backing up and migrating WordPress without losing your rankings.

Map Your Redirects Before You Touch the New Site

Redirect mapping means creating a documented plan that tells every old URL where to go on the new site, so visitors and search engines land on the right page instead of a 404. This plan must exist as a spreadsheet before a single URL changes.

A 301 redirect is permanent. It tells search engines to pass the SEO value from the old URL to the new one. Use 301s for every page you are moving or renaming. A 302 redirect is temporary and does not transfer ranking authority. Use it only when you genuinely intend to restore the original URL later, which is rare in a migration context.

The most common redirect mistake is creating redirect chains. A chain happens when URL A redirects to URL B, which then redirects to URL C. Search engines follow the chain but lose some signal strength with each hop.

Here is the pattern to watch for and fix: if your old URL /blog/post-1 redirects to /articles/post-1, which then redirects to /articles/post-1-updated, flatten that to a single redirect: /blog/post-1 goes directly to /articles/post-1-updated. One hop, not two.

Audit for chains in your existing site before migration. Many sites already have legacy redirects from previous moves. Carry those chains into a new migration and you compound the problem.

A few rules to follow when building your redirect map:

• Every URL in your audit inventory needs a destination, even if that destination is the homepage
• Prioritize pages with backlinks first; those carry the most ranking equity
• Check for case-sensitivity issues, especially if you are moving between platforms with different URL handling
• Test every redirect in your staging environment before go-live

A weekly SEO routine that catches redirect issues early will help you find any redirect drift in the weeks after launch.

Build and Test on a Staging Environment First

A staging environment is a private copy of your new site where you can test everything, including redirects, forms, and crawlability, before real visitors or search engines see it. Never build your migration directly in production.

Most hosting providers offer one-click staging. If yours does not, a subdomain or password-protected environment serves the same purpose. The goal is a realistic copy of the new site that you can break without consequence.

Run all six of the following tests before you declare staging ready:

1. Crawl the staging site and compare the URL count to your audit inventory. Every page should be accounted for.
2. Test every redirect from your redirect map manually and with a bulk redirect checker.
3. Check all internal links for broken anchors, especially if your URL structure changed.
4. Submit a test form, checkout, or signup to confirm dynamic functions work on the new environment.
5. Run a Lighthouse or Core Web Vitals check to confirm the new platform is not slower than the old one.
6. Review page titles, meta descriptions, and canonical tags on at least your top 20 pages.

The robots.txt file needs its own attention. In staging, you should have Disallow: / to block search engine indexing. On migration day, that line must be removed or replaced before you go live. Forgetting this is one of the most common and damaging migration errors: your entire site becomes invisible to Google, and you may not notice for days.

If you are building a professional site without touching code, most no-code platforms handle staging through their own preview environments. The checklist items are the same regardless of the tool.

Migration Day: What to Do in Order

Migration day is not the time for decisions. Every choice about redirects, content structure, and configuration should already be made. Your job on go-live day is to execute a pre-planned sequence quickly and verify each step before moving to the next.

Work through this sequence in order:

1. Lower your DNS TTL to 300 seconds (5 minutes) at least 24 hours before migration day. TTL controls how long DNS records are cached across the internet. A lower TTL means your DNS change propagates faster, so fewer visitors get stuck on the old server during the switch.
2. Run a final backup of the current site immediately before making any changes.
3. Point your domain to the new host by updating your nameservers or A record.
4. Remove the Disallow: / from your staging robots.txt and confirm the live site is crawlable.
5. Verify your SSL certificate is active on the new domain. An HTTPS error on go-live destroys trust and rankings simultaneously.
6. Test your top 10 pages manually in a browser: load, redirects, forms, and images.
7. Submit your XML sitemap to Google Search Console to prompt re-crawling of the new URLs.

Schedule your migration during your lowest-traffic window. This is a precaution, not a guarantee of reduced impact. It gives you more runway to catch and fix problems before the bulk of your audience hits the new site.

For founders handling this without technical help, launching your site without a developer covers the hosting and DNS steps in plain language.

Migration Checklist at a Glance

The table below covers every major task from this article across three phases. Use it as a reference to assign ownership and confirm completion before you move to the next phase.

Post-Migration: What to Monitor in the First 30 Days

The first 30 days after a migration are a monitoring period, not a coast period. Some temporary ranking fluctuation is normal as Google re-crawls and re-evaluates your new URLs. A sudden, large drop in indexed pages is not normal, and it needs immediate investigation.

Set up a simple monitoring routine that covers these five tasks:

1. Check Google Search Console for crawl errors every few days in the first two weeks. Look for 404s on URLs that should be redirecting and fix them immediately.
2. Track your indexed page count in Search Console under Coverage. Compare it against your URL inventory from the audit. A large gap means pages are not being found or are being blocked.
3. Monitor organic traffic in your analytics tool week over week. A gradual, slow decline over four to six weeks is usually Google re-weighting the new site; this typically stabilizes. A sudden 50% drop in the first week points to a technical error: a blocked robots.txt, missing redirects, or a canonical pointing to the wrong URL.
4. Check your top 20 pages for ranking position changes weekly. These are the pages you can least afford to lose.
5. Audit for new broken internal links that might have been introduced during the build.

The sudden vs. gradual drop distinction matters. Gradual is normal recalibration. Sudden means something is wrong technically. Treat them differently.

Writing content that recovers and holds rankings after a migration is one of the fastest ways to signal quality to Google on the new site. Pair it with a weekly SEO routine to stay on top of post-migration health so nothing slips through unnoticed.

Five Migration Mistakes That Cost Rankings

Most migration ranking losses are avoidable. They come from a predictable set of errors, all of which appear on this list. Know them before you start.

1. No redirect map before go-live. Old URLs return 404s, backlinks point to dead pages, and search engines deindex your content. This is the most common and most expensive mistake.

2. Forgetting to remove the staging robots.txt block. Your live site stays hidden from search engines until you notice. By then, your indexed page count has already collapsed.

3. Migrating and redesigning simultaneously. Changing your URL structure, platform, and visual design at the same time makes it impossible to diagnose which change caused a traffic drop. Do one at a time.

4. No pre-migration traffic baseline. You have no way to measure the impact of the migration if you did not record your starting point. You are guessing about recovery when you could be measuring it.

5. Redirect chains left unflattened. Each additional hop in a chain dilutes the SEO equity passed along. Chains from previous migrations compound quietly over time and are hard to untangle after the fact.

For a deeper walkthrough of how these errors play out in practice, see a detailed guide to migrating from WordPress without breaking your site.

Frequently Asked Questions

The questions below cover the search intent most commonly associated with website migrations. Each answer is written to stand alone for schema markup purposes.

Q: How long does a website migration take? A: The timeline depends on site size and complexity. A small site (under 100 pages) can be migrated in one to two days of focused work, but the full process including pre-migration audit, redirect mapping, staging testing, and 30 days of monitoring spans four to six weeks. Rushing any phase increases the risk of ranking loss.

Q: Will a website migration hurt my SEO? A: A well-executed migration with proper redirects, metadata preservation, and early Search Console submission can complete with minimal ranking impact. Some fluctuation in the first few weeks is normal. Migrations that skip the checklist, particularly the redirect map and staging tests, routinely result in significant, longer-lasting ranking drops.

Q: Do I need a developer to migrate my website? A: Not necessarily. Many no-code platforms handle hosting, DNS, and SSL setup without requiring technical expertise. The tasks in this checklist that benefit most from developer involvement are complex redirect rules, server configuration, and troubleshooting crawl errors. Before you decide, see choosing a no-code platform before you migrate.

Q: What is the most important thing to do before a website migration? A: Complete the pre-migration audit and create a full backup. These two steps give you the data to plan your redirect map and the safety net to recover if something goes wrong. Without them, everything else in the checklist rests on guesswork.

Q: How do I tell Google about my new site after migration? A: Submit your XML sitemap through Google Search Console as soon as your new site is live and crawlable. If your domain has changed, add the new domain as a property in Search Console and use the Change of Address tool under Settings. This accelerates re-crawling of your new URLs.

Run the Checklist. Then Run Your Business.

A website migration checklist reduces an inherently risky process to a predictable sequence of verifiable steps. Work through the three phases in order: audit and prepare before you touch the new site, execute migration day as a scripted sequence, then monitor actively for 30 days after go-live.

The honest time cost for a small site is real. Expect several days of focused work spread across four to six weeks. Skipping steps does not save time; it creates recovery work that costs far more.

If rebuilding your web presence is the goal, not just surviving the migration, automating your content publishing end to end and getting a blog that runs itself are the next logical conversations. If you want a system that handles the content flywheel so you can focus on selling, get early access to Agent Solo.