Website Migration SEO: A Checklist for a Safer Site Move

Key takeaways

Record important URLs, a baseline, and an owner before the move.
Separate changes that keep URLs from changes that need new destinations.
Test the public release and investigate confirmed failures promptly.
Use DEX Health and Search Console metrics to support page review.

Website migration SEO is the work of protecting a site’s useful content, access, and search signals when its platform, domain, design, or URLs change. Start with an inventory and a baseline. Plan each destination, test the new site, and check the live release before judging its search results.

A successful move needs more than a launch date. Someone must own the URL map, another person may control the server, and the business needs to confirm that its important pages still work. Put those decisions in one record so a missing redirect or contact form has a clear owner.

This guide takes you through planning, testing, launch, and review. It includes a hypothetical blog move and explains where DEX Health and Search Console metrics can support your checks.

What Is Website Migration SEO?

A website migration changes how an existing site is built, served, or organized. The SEO work is to preserve what readers and search engines need while the technical setup changes. Moving a site is different from publishing a new article.

Common moves include switching a content management system, changing a domain, moving hosting, redesigning templates, or changing the paths of existing pages. Several can happen together, but each adds decisions to test.

Write a scope statement before choosing a date. For example: “Move our blog to a new CMS while keeping the domain, article URLs, and content.” That statement is much easier to verify than “launch the new website.”

Also record what will stay the same. A developer needs to know whether a changed title is intentional. An editor needs to know whether an old guide is being moved or rewritten. Without that record, the team may mistake an accidental loss for an approved change.

How Can a Website Migration Affect Your SEO?

A move can change whether a page is available, what it says, and which address represents it. A familiar-looking design can still hide missing text, broken resources, or an unintended search setting.

The business risk is practical. A customer may reach an outdated service page. A useful guide may stop linking to the contact page. A downloadable checklist may disappear even though the new home page works.

Google notes that significant moves can cause temporary ranking changes as pages are processed. Its site-move guidance recommends planning changes carefully and, where possible, separating major changes rather than doing everything at once.

Temporary movement is not a reason to ignore a confirmed fault. A broken destination needs attention now. A change in clicks needs investigation before anyone calls it a migration failure. Keep those two kinds of evidence separate.

The aim is a controlled move with known decisions and working pages. No checklist can promise that positions or traffic will stay unchanged.

Before the Move: Build a URL Inventory and SEO Baseline

Identify pages and assets worth preserving

Build a website migration URL inventory of the public addresses the business relies on. Include service pages, articles, landing pages, images, and downloads. Use the CMS, existing sitemaps, and available search or analytics records to help find them.

Do not use traffic as the only measure of value. A low-traffic warranty page may answer an important customer question. An old article may have useful links from other sites. Ask the business which pages people need to complete a task.

For each item, record its purpose, current address, proposed destination, and owner. Add a field for the test that will prove the decision works. A spreadsheet is enough if the team keeps it current.

Record a baseline and assign owners

Save a useful comparison period for key pages before the release. Note the data source, dates, filters, and any seasonal event. Keep a copy of the URL list beside that record so later reports refer to the same pages.

Assign people to content, technical delivery, and final approval. One person can fill several roles, but each task still needs an owner. Include a way to report blockers on launch day.

Our SEO performance guide explains the metrics in depth. Here, the baseline has a narrower job: giving your team a fair starting point for reviewing the move.

What Changes If Your URLs Stay the Same?

Use the CMS migration content checklist to compare what survived behind those addresses.

Keeping the same addresses removes the need to map those pages to different addresses. It does not remove the need to test them. A new CMS or template can change the page behind a familiar URL.

Compare a representative set of old and new pages. Pick a service page, an article with a table, an image-heavy post, and a page with a form. Add examples for any unusual layout or language your site uses.

Check whether the answer, title, headings, images, navigation, and next action survived. Read the main content itself. A screenshot can miss text that was removed from a tab or a section that no longer loads.

For a hosting move, follow Google’s separate guidance for moves without URL changes. Coordinate technical testing and availability with the person managing the hosting.

Keep any existing redirect rules in the review too. An older campaign address may still send visitors to a current page. The fact that today’s main URLs are unchanged does not tell you whether those older routes survived.

How to Map Old URLs to New Destinations

For a page without a relevant target, review whether to keep, combine, rebuild, or retire it before approving its route.

Use the detailed process for URL mapping for website migration to give every important old URL a clear decision. Use the page’s purpose to choose the destination. A tidy-looking folder structure is not enough if it sends a reader to an unrelated answer.

Pages that keep the same URL

Mark these as retained. Test that the address serves the intended page directly. Do not add a redirect simply to make every inventory row look alike.

Pages moving to a new URL

Map the old address to the equivalent new page. For a permanent move, Google’s redirect documentation describes permanent server-side redirects such as 301 and 308. Ask the implementer to test the actual response and final destination.

Use the separate guide to test migration redirects rather than checking only whether a browser eventually opens something. Record the route it follows and whether the final page answers the same need. Test links within the new site so they point to the chosen destination.

Merged or retired pages

A merged guide needs a destination that still delivers the useful material. If there is no relevant replacement, do not send every removed page to the home page. Record the removal decision and check the appropriate response with the implementer.

A migration can expose overlap that already existed. Review both articles before merging them. Keep the useful answer and record which address will remain the main reference, rather than preserving two full versions of the same task.

What Should You Test Before Launch?

Agree on a website migration rollback plan with clear triggers, owners, and a tested return path.

Check content and search settings

Use a test environment to compare the planned pages before the public switch. Keep test-site access under control, and give the launch team a clear list of settings that must change when the site goes live.

Inspect titles, descriptions, main headings, content, and the intended indexing settings. Check that a canonical URL identifies the intended public version. Google’s canonical guidance explains the signals and their limits.

For a multilingual site, include each language in the test sample. Confirm that the language links lead to the correct versions. A working English page does not prove that its Spanish or Portuguese partner is available.

Review structured data against the new page. Our structured data guide covers implementation and validation; the migration check is whether the move changed or broke it.

Open important images and downloads. Follow links from articles to services and contact pages. Submit a permitted test through a form, or ask its owner to verify the flow. Confirm what the visitor sees afterward.

Review a narrow-screen layout and the main navigation. If the new template feels slow or shifts while loading, use our website performance workflow to investigate the cause.

Define launch blockers and a rollback plan

Agree on what stops the release. Examples include missing core pages, failed forms, or a URL map that has not been tested. Record who can approve a delay and who can restore the previous setup if necessary.

A backup alone is not a complete reversal plan. The technical owner should know what must be restored, what new data could be affected, and how the team will verify the restored site.

Launch-Day SEO Checklist

Use a short release list tied to the inventory. Avoid introducing unrelated rewrites while the team is trying to confirm that the move works.

Confirm the approved scope, current backup, technical owner, and launch decision.
Release the intended site and apply the approved URL changes.
Test important old URLs, their responses, and their final destinations.
Check public access and remove development-only restrictions where appropriate.
Verify important pages, images, downloads, forms, and language routes.
Check canonicals, internal links, search settings, and the sitemap output.
Record the release time, test results, known issues, and the next review owner.

Assign a real result to each check: passed, failed, or waiting for evidence. “The developer is checking it” is a status update, not proof that the URL works.

Google’s sitemap guidance helps you review the submitted URL set. A sitemap supports discovery; it does not guarantee indexing. Use it alongside direct page checks.

Our CMS publishing guide covers checking a newly released post. For a migration, apply release checks to the affected set of existing pages, not just one new entry.

What Should You Monitor After Migration?

Start with the important pages and the faults reported during launch. Give each issue an owner and record the fix. Repeat a check when its input changes, rather than marking an earlier test as proof of a later release.

Use Search Console to review the old and new properties where relevant. Its search performance report provides page and query views for investigating changes. Keep the period and scope clear.

When URLs change, compare the content’s old and new destinations as a pair. Looking only at a declining old address can miss activity at the new one. Looking only at the whole site can hide a lost service page.

Also confirm that reporting still works. A changed tracking setup or filter can create a break in a chart. Label any gap before treating it as a change in customer behavior.

DEX organizes important Search Console metrics, including impressions and clicks. Use those results to choose pages for closer review. Keep the inventory and release log available so you can connect a change in the numbers with the address and work involved.

For questions about page discovery, use our crawling and indexing guide. The migration task is to identify what changed and verify the affected pages.

Why Did Traffic Drop After a Website Migration?

A drop after launch is a reason to investigate. It does not identify its own cause. Start with the affected pages and dates, then compare the finding with the release record.

Check measurement before assuming a loss

Confirm the property, page filters, comparison period, and tracking setup. Ask whether traffic moved to new URLs or whether a report stopped counting part of the site. Keep incomplete periods separate from finished ones.

Investigate access and URL signals

Open the important destinations. Check for unavailable pages, incorrect redirects, unintended indexing restrictions, and canonicals pointing somewhere unexpected. Trace a failed old address to its final result.

Prioritize confirmed access failures over cosmetic changes. If a quote page cannot load, improve its availability before experimenting with the heading. Use a focused test to confirm the correction.

Compare content and search demand

If the page works, compare the answer before and after the move. Was a key section removed? Did the service scope change? Did navigation stop pointing to it? Ask the editor to document the difference.

Consider demand and other site changes too. A seasonal decline or a changed offer can affect results during the same period. Do not promise that reversing one title will restore traffic without evidence.

Website Migration Example: Moving a Small Business Blog

Imagine a coffee catering company moving its blog to a new CMS. This is a hypothetical planning exercise, not a customer result. The business wants to keep useful guides and the path to a quote request.

Old path	Decision and destination	Owner	Acceptance check
/services/coffee-catering/	Keep the same service URL.	Business and developer.	Service details and quote form work.
/blog/event-coffee/	Move to /blog/coffee-for-events/.	Developer.	Old URL redirects to the equivalent guide.
/blog/event-coffee-tips/	Merge its useful advice into the same event guide.	Editor and developer.	Advice survives and the old route reaches it.
/downloads/event-checklist.pdf	Keep the existing download address.	Content owner.	The correct file opens from the article.
/blog/2018-opening-night/	Retire after confirming no useful replacement is needed.	Business and developer.	Approved removal response; no unrelated redirect.

Add a status and test date to each row. Suppose the new guide opens, but its link to the PDF fails. That row remains failed until the download works; the article’s appearance is not enough to approve it.

The merged guides also need an editorial check. The new page should keep the useful event advice in one answer. It should not paste both introductions together or leave two pages serving the same question.

After launch, the team can review the affected pages and relevant queries. This example does not assign a traffic gain, a recovery deadline, or a ranking to the move.

How DEX Fits Into Your Post-Migration Review

DEX Health lets you analyze page quality and SEO, including on the free plan. Use it on important public destinations after the move. Review the findings with the inventory, correct confirmed issues, and check the affected pages again.

DEX also connects to Search Console and organizes important search metrics. That gives the business a way to follow visibility and clicks while the technical team handles the move. A page quality score and a search result answer different questions.

The migration itself still needs clear technical ownership. DEX’s page review is not a substitute for configuring hosting, implementing redirects, testing backups, or deciding whether to reverse a release.

DEX’s ongoing content process includes reviewing pages that have not gained positions after about 30 to 60 days. That is an editorial follow-up window, not a migration response deadline. A broken destination or failed form needs investigation when you find it.

Keep the handoff simple: the public URL, intended task, observed issue, owner, and verification step. That turns a warning into work the team can finish.

Start your free SEO plan with DEX and bring page-quality checks into your content workflow. After a move, use the checks and search evidence to decide what needs attention next.

FAQ

When should you use Google's Change of Address tool?

Use it for a move from one domain or subdomain to another when its requirements apply. It is not needed for a hosting change with the same URLs, an HTTP-to-HTTPS move, or a path change within the same domain. Follow the current Search Console instructions.

How long should migration redirects stay in place?

Google's site-move guidance generally recommends keeping them for at least one year and as long as possible. Useful old links may continue to receive visits, so review real use before removing redirects.

Should you change the domain, CMS, and content at the same time?

Separate major changes where practical. A clear scope makes faults easier to trace. If several changes must happen together, document them and test their effects before launch.

How long can search changes take after a migration?

There is no fixed recovery deadline. The size of the move, access, server capacity, and processing of the affected URLs matter. Check confirmed technical failures promptly instead of waiting for a ranking timeline.

Sources

Dex SEO

Dex SEO is an AI SEO agent for small businesses. Every article here is planned from search data, drafted by Dex, fact-checked against the sources it cites, and reviewed by the team before it is published.

How this article was made: planned and drafted by Dex from search data, fact-checked by Dex (10 claims checked), then approved by the Dex SEO team.