Website migration SEO checklist: protect search visibility through a redesign or move

Protect search visibility in a migration by recording the existing site and keeping useful URLs where you can. Map every changed address, test the new site and watch real customer outcomes after launch. A checklist cuts avoidable risk. It can't guarantee unchanged rankings.

What counts as a migration

A migration is any change that can move, hide or break what search engines and customers rely on. Because the checks differ by type, record each change separately:

A hosting move with unchanged URLs doesn't need new redirects or a Change of Address request. It still needs infrastructure testing. A redesign that keeps every URL still needs content, rendering, link and function checks.

Risk depends on scope, implementation and what the business relies on. A domain move isn't automatically riskier than a platform move. Scope the real change before choosing a checklist:

Planning a wider redesign? Our redesign checklist covers the broader process. This guide covers the SEO launch checklist in full.

Why migrations fail

Watch for seven common causes:

1. missing or wrong redirects

2. useful pages removed without good reason

3. lost search intent or content

4. stripped or conflicting page metadata

5. broken internal paths

6. accidental crawler or indexing blocks

7. broken measurement

These aren't equal: a missing meta description isn't the same as a site wide indexing block.

Not every problem is an SEO loss. A migration can fail commercially while rankings hold, for example when enquiries stop reaching the inbox. Fewer recorded sessions can also come from a tag or consent change. A common mistake is treating every dip after launch as a ranking problem.

Inventory the site and build the benchmark pack

No single tool lists every URL that matters. Build the inventory from several sources and record which ones you couldn't get.

These sources overlap, and none is complete alone. A crawler only finds what it can discover and access. Use a rendered crawl where content or links load with JavaScript. In practice, pull:

• a CMS export of pages, posts and products

• every XML sitemap the site publishes

• Search Console's top pages and top linked pages

• at least a year of analytics landing pages

• the existing redirect rules from the server, plugins and content delivery network (CDN)

Look hard for the URLs a page crawl misses:

For each important page, record:

• URL, status, canonical and indexability

• title, main heading and topic coverage

• structured data and key internal links

• business purpose, enquiries or revenue, and seasonality

Prioritise by that evidence, not a universal top 100 rule. Zero recorded visits doesn't prove a page has no purpose. It may still serve customers, support or legal needs.

Then capture a benchmark you can compare later. Export Search Console clicks and impressions by page and query before the move. Keep the 16 month view for seasonal context. Our guide shows how to read the Search Console reports.

Analytics and Search Console never match exactly. Compare like with like, and reconcile analytics with real forms, calls or orders. Annotate the exact release time, time zone and tracking version.

Add operational benchmarks too: a working enquiry test, a checkout test and the response of priority pages. The pack should let you tell lost demand from missing measurement.

Map URLs and implement redirects

Every old URL needs a decision, not necessarily a redirect:

Keep URLs that still suit the page. Map merges to the page that actually absorbs the useful content. Retire pages honestly when there's no equivalent. The new destination must exist and work before you redirect to it.

Merges need care: check the destination genuinely covers the old page's useful content. Otherwise you've retired the page, just less honestly.

Here's an example map for a plumber's site:

Your real test list also needs scheme and host variants. Add case, encoding and trailing slash versions. Check query parameters that carry attribution or real functions.

A wildcard rule needs tests that should match and tests that shouldn't. Look for loops, self redirects and broad rules that shadow exceptions. A common mistake is testing one redirect and assuming the rule works everywhere.

Implement and test redirects

Use a direct permanent server redirect for a permanent move. Google treats 301 and 308 as permanent. Use temporary redirects only for temporary situations. JavaScript redirects are a last resort, because rendering can fail.

PageRank is one of Google's systems for reading links between pages. Google says permanent redirects don't cause a loss in PageRank. That isn't a promise every ranking stays put. Redirects don't replace equivalent content either.

Server, CMS, platform and edge rules can all work. Compare them on capability, limits and who maintains them. Your map stays the source of truth, wherever the rules run.

Test every redirect for:

• its first status code

• the full chain of hops

• the final address and response

• relevant content and indexability at the destination

A final 200 page can still hide an irrelevant destination or a soft error. Forms, bookings and API endpoints need their own decision. Test each one, because a broad page rule can break a submission.

Keep permanent redirects for as long as possible, generally at least a year. The Change of Address tool is a separate matter, because its effects last 180 days.

Keep paying for the old domain, its DNS and a valid HTTPS certificate. You don't need the old CMS just to serve redirects. Our guide explains SSL certificates if the host changes.

Keep one record per old URL, outside any plugin or developer account:

Retiring a page with no useful replacement can correctly return a 404 or 410. A custom error page must not return a success code. Google treats error content on a 200 response as a soft 404.

Preserve useful content and internal paths

Keep what's useful, not every old defect:

For priority pages, keep the customer intent, the useful coverage and verified proof. Carry titles, headings and descriptions across deliberately, then review their roles. Fix false claims and expired offers now. Our guide helps you keep a service page focused on what buyers ask.

Compare old and new templates for main content, navigation, breadcrumbs and body links. Point internal links straight at final pages. A clean path cuts needless requests and helps visitors. Small sites don't need to obsess over crawl budget. Our guide covers useful internal paths.

Canonicals, sitemaps and structured data

Canonicals should point to the intended final pages. It's a signal, not an order. It doesn't replace a redirect when visitors need to move. Hunt down staging and old host canonicals.

Generate the new sitemap from final canonical, indexable URLs. Google uses lastmod only when it's consistently and verifiably accurate. It aids discovery. It can't force indexing.

Carry over relevant, valid structured data, then recheck each type's eligibility. Google says markup enables a feature without guaranteeing it. FAQ rich results stopped appearing in Google Search from 7 May 2026, as Google's Search documentation updates record. Our schema guide covers the types.

Keep accurate authorship, reviews and case evidence too. Our guide shows how to show genuine experience and credibility.

Check the platform before committing

Test the destination platform against your map before you sign:

Here's what the platforms themselves say:

• WordPress: a plain database search and replace can break serialised data. Use a migration aware tool after a backup.

• Squarespace: the export is partial. Images may import only as links that break when the old site closes.

• Wix: sites must be hosted on Wix. Moving off means exporting what you can and rebuilding the rest.

• Shopify: there are several migration methods, from CSV files to partner builds. Its redirects only work when the old URL no longer loads a page. Prefixes such as /cart and /apps can't be redirected.

Shopify doesn't necessarily change every URL either. Compare the actual structures. Our Squarespace to WordPress guide covers that route in detail.

Some customer records may not move the way products do:

• passwords

• subscriptions

• payment tokens

• consent records

Have the commerce owner confirm the method and any customer communication. Custom and headless builds need their rendered HTML checked. The browser view isn't enough.

Choosing a new platform? Our guide helps you compare website platforms against the capabilities you need. Then ask the developer to prove each requirement:

If the platform can't do what the map needs, solve that before fixing a launch date.

Protect staging and prepare the switch

Protect staging with real access controls, such as a password. Don't copy live personal or payment data into a loosely protected test site. Turn off real notifications, payments and webhooks there.

robots.txt controls crawling. It isn't security: a blocked URL can still appear in results. A noindex rule only works if crawlers can fetch the page. Check HTML robots tags and X-Robots-Tag headers, including on PDFs.

If staging leaks into search, fix the access or indexing condition first. A temporary removal lasts about six months and needs a lasting fix behind it. Scope it carefully so you don't remove the live site.

Before release, sweep the production configuration:

Remove only the temporary production blocks. Private accounts and carts may need their restrictions kept. Check the CDN and firewall too, because a correct template can't override a blocking response upstream.

Crawl staging with the right authentication and compare it with your inventory. Missing pages and changed titles show up before launch, not after.

DNS, email and backups

Record who holds registrar, DNS and hosting access. Add the CDN, certificates and recovery details.

For a hosting change, Google suggests lowering DNS TTL at least a week ahead. TTL is how long other networks may keep your old DNS answer. Test the new host first, then watch logs on both hosts as traffic shifts. Shut the old host only when its traffic reaches zero. If it still serves redirects, keep it running.

Don't promise anyone a 24 or 48 hour switch. Choosing a host? Our guide covers hosting requirements and responsibilities.

A website move touches more than web pages:

Record the existing MX, SPF, DKIM and DMARC records before touching DNS. These email records route and authenticate mail. They don't belong to the web host. If a new service sends mail, add it to the existing SPF record, as Google's SPF guide shows. Test inbound mail and website mail separately.

A common mistake is pointing every DNS record at the new web host, mail included.

Take a restorable backup with a timestamp and a restore procedure. A WordPress backup needs both the files and the database. Test the restore somewhere safe. A backup existing isn't proof it can restore the service.

Complete the launch day checklist

Here's the full checklist, in four groups. Mark each item passed, failed, untested or not applicable, with a reason and an owner.

Before the switch:

Routing and crawl:

Search and customers:

Outside systems and records:

A critical failure blocks the relevant launch. Critical means a failure in any of these:

• customer delivery or payments

• security or broad access

• routing for priority pages

A completion percentage can't override it. A known minor exception needs an owner and an agreed fix.

Enquiry tests matter more than they look. Across 100 website audits from May 2023 to September 2026, we sent labelled test enquiries. About 1 in 5 sites with an enquiry form failed the test. The request didn't reach the person who answers it within one business hour.

No checklist score overrides those gates. You can keep your record in our free tool:

It's a manual record, not an automated scan or a launch certificate. Its saved progress isn't a site backup either. After launch, our meta title and description checker helps spot metadata slips. It doesn't certify SEO success.

Follow the launch running order

Run the switch in a set order, with the named people available:

Release approval depends on the critical checks, not the calendar. In the first hour, check priority URLs and accidental blocks. Then test enquiries, payments and mail. Don't wait for Search Console to spot an outage.

A quick spot check helps during the switch. It doesn't replace testing the full map. The right sample depends on templates, rule types and business value, not a fixed 20 URLs. Pick a quieter period when the responsible people are around. For some businesses, that isn't a weekend.

Agree a limited content freeze to cut variables. Record what's frozen, who approves exceptions and when it ends. Don't impose a fixed eight week freeze. Security fixes, legal corrections and stock changes can't wait for an SEO verdict.

Version every redirect change and keep the map in sync with what's deployed. Don't turn every new 404 into a redirect automatically. Check the purpose of temporary rules before deleting them. Host, CDN or platform changes can quietly remove rules. Recheck them periodically.

Monitor crawling, search and customers

Monitor three layers:

• service health and real customer journeys

• crawl and indexing evidence

• commercial search outcomes, such as qualified enquiries

A working homepage proves little. Neither does a rising indexed count. A site: search isn't a full list of indexed pages. Each source answers a different question:

Crawl Stats example URLs aren't comprehensive. Its totals can differ slightly from your logs. The URL Inspection live test checks access, not indexing. The Page indexing report doesn't expect every URL to be indexed.

Ask the host or developer what log period and scope you can get. With a CDN, origin logs may miss requests served at the edge. Keep only the fields you need and protect access. If logs aren't available, say so rather than reporting zero crawl errors.

Separate intended 301 and 308 redirects and deliberate 404 and 410 retirements from real failures. Investigate sustained server errors (5xx), rate limits (429) or blocking errors fast. Google says 5xx and 429 responses slow crawling. Verify a claimed Googlebot by reverse and forward DNS, not its user agent label.

Review windows are operational, not recovery promises. Check constantly during the switch, then frequently over the first days. Review important exceptions daily while risk is high, then weekly. Because Search Console data lags, use live checks for outages.

There's no standard dip to ignore for two weeks. Diagnose by severity and affected function. A checkout failure needs action even if traffic is flat. On a medium site, Google says new URLs can take a few weeks or more to show. Larger sites take longer.

A small fall in a quiet series may be inconclusive. When numbers do fall, work through four questions in order:

1. Is it measurement? Check tags, consent and the release annotation.

2. Is it one section? Compare mapped page groups, not the whole site.

3. Is it crawling or indexing? Check responses, blocks and canonicals for that group.

4. Is it demand? Compare the same period last year and other channels.

Our guide to diagnosing a traffic drop goes deeper on each check.

Track faults as a defined count, not a traffic curve:

Count unresolved unexpected failures in the same test inventory each day. Zero means the tested paths work. It doesn't prove search has settled.

For performance regressions, check field and lab evidence. Our guide on website speed and SEO covers the ranking question. Once the move settles, a broader DIY SEO audit catches anything the migration checks missed.

Decide whether to repair or roll back

Agree recovery authority before launch. Name the incident owner and who can change routing or DNS. Name who controls customer records and who verifies recovery. Define the longest tolerable outage and data loss in plain words.

The plan needs the last working release, the backup time and the records created since. It also needs a way to preserve and reconcile them.

Here's how a rollback can lose data. The launch snapshot is taken at 09:00. Five orders arrive before a checkout incident at 10:00. Restoring the 09:00 database would erase those orders while the payments still exist at the processor.

So preserve the new records first. Reconcile orders, payment IDs, stock and customer notifications. Check whether a code or routing reversal avoids a full restore. This is an example risk, not an Elev8d incident.

A DNS reversal isn't seen by every resolver at once. Browsers and search engines also cache permanent redirects, as Shopify notes for its own. If you filed a Change of Address and genuinely reverse the move, follow Google's cancellation steps. Never treat a one click restore as an SEO safe reversal.

After a repair or reversal, retest the customer journey, measurement and key URL paths. Record the incident, the decision, the restored version and the reconciled records.

Handle domain, ecommerce and local moves

Some moves carry extra requirements:

Domain moves

For a domain or eligible subdomain move, verify both Search Console properties. Put the redirects in place first. Then use the Change of Address tool, say from example.com to example.net. It's not for hosting changes, HTTP to HTTPS, path changes or www switches. It doesn't replace page mapping either.

Ecommerce

Preserve product and category intent. Map discontinued, merged and changed items deliberately. Don't send every removed product to an unrelated category just to clear 404s.

Check variants and filters. Then check pagination, feeds and reviews. Our guide covers ecommerce SEO in more depth.

Multilingual sites and several domains

Hreflang tags tell Google which page suits which language or region. Update the locale URLs. Keep the tags reciprocal, because Google ignores hreflang pairs that don't point to each other. Don't collapse distinct translations into one language just to simplify redirects.

Consolidating several domains? Keep a separate inventory and decision record for each source. Where you can separate the work, avoid changing every other system at the same time.

Local businesses

Update the website link on the existing Business Profile. Don't create a duplicate profile because the site moved. Google's representation guidelines still apply to the real business. Update priority listings, partner links and ads too.

Our profile guide covers profile changes. Our local guide covers local listing continuity.

Assign ownership, timing and budget

Every action needs an accountable owner. Here's a starting handover board:

One person can hold several roles. Each action still needs access and a backup contact.

For a scoped small business project, preparation might look like this:

That's an example, not a commitment. A small, simple move may take less. A large catalogue or missing access can take much longer. A fixed date doesn't override a failed critical check.

Cost the work by scope:

• the number and complexity of URL classes

• platform capability and data transfers

• integrations, testing and incident cover

• monitoring after launch

Keep SEO work, development, hosting overlap and third party services separate. Ask for an itemised quote with GST treatment, inclusions and exit handover. Our guide to website costs gives broader context. The website cost estimator gives a planning range, not a quote.

Here's an example cost of getting it wrong. Say a move costs you 20 qualified enquiries. One in four would have become a job, each worth $800 after direct costs. That's $4,000 at risk before any repair work. It doesn't prove a migration caused a loss, or that a fee prevents one.

Sometimes the right call is to wait. Defer when any of these is true:

• there's no reliable map for changed URLs

• critical tests fail

• recovery access is missing

• the platform can't support the requirements

• data transfer or ownership is unresolved

A narrower template or content change, with its own checks, can be a useful alternative.

Judge a migration result on its evidence

Migration case studies deserve scrutiny. A good quarter after a release doesn't prove the new structure caused it. Content, advertising, seasons and demand may have changed too.

Ask for the launch date, URL counts, the map version and dated exports. Look for the issue log, not just the highlights. A credible set includes a migration that went wrong.

Where evidence is missing, treat it as missing. A placeholder result or a hand drawn recovery curve proves nothing.

What we recommend at Elev8d

Frequently asked questions

Next steps

Written by Ajay K.Co-founder, Elev8d

Ajay is the co-founder of Elev8d and writes most of what you will read here. Psychology grad turned marketer, which is a fancy way of saying he cares about why people click, not just where things rank. Every guide is written in plain English for Australian businesses, tested on real campaigns before it earns a spot on this site.