Website Migration SEO Checklist for a Safer Redesign

An SEO website migration checklist helps protect search traffic during a redesign or rebuild. It covers old URLs, useful content, redirects, staging access and launch checks. Before migration, crawl the current site and record indexable URLs, metadata, canonicals and backlinks. During migration, test redirects, XML sitemaps, robots.txt and internal links. After launch, check indexation, Search Console coverage, rankings, traffic and crawl errors. Rankings can fall when these signals change. Careful planning and fast fixes can limit the loss.

What Is an SEO Website Migration Checklist?

SEO website migration planning checklist

An SEO website migration checklist is a set of checks for protecting search traffic during website changes. It covers the platform, design, domain, URLs and content. It also checks crawling, indexation, analytics, testing and launch tasks.

A website migration may involve a CMS change, platform migration, domain move or URL change. Even a visual rebuild can change HTML, headings, links, speed and content. Each change may affect Technical SEO and organic rankings.

Start by recording the old site. A website crawl should show indexable URLs, status codes, metadata, canonical URLs, headings and internal links. Compare this record with the new site before launch.

The checklist also gives each task an owner. Developers can test redirects and page loading. Content teams can review retained pages. Analysts can check traffic and conversions.

Most migrations take several weeks to prepare. Close checks may then run for several weeks after launch. The time depends on site size, CMS limits, server access and changed URLs.

How Do You Preserve SEO During a Website Redesign?

Website redesign SEO protects useful content, keywords, URLs, links and canonical tags. It also protects value from backlinks. Compare both sites before launch. Keep pages that bring search traffic. Don't remove content that search needs.

Start with clear page data. Keep pages with impressions, clicks, rankings, backlinks, leads or sales. A page with little traffic may still support an important sales path.

Some pages may cover the same topic. You can join them when their purpose and audience match. Redirect each old URL to the stronger new page. Keep useful headings, terms and detail.

Remove a page only when it has no useful purpose. It must also have no good replacement or search value. Check backlinks, links and past results first. Don't send every removed page to the homepage.

Check canonical tags, structured data, navigation and internal links in the new design. JavaScript menus must show key links to crawlers. Our approach to how we work is based on evidence. We compare templates and URLs. We record each decision and assign an owner.

Web Design and Technical SEO should be planned together. They shouldn't be treated as separate jobs. For organisations considering Technical SEO in South Brisbane, these rules also apply to national and international websites. Protect the URLs, content and sales paths that already work.

Before Migration: Build Your SEO Baseline

A pre-migration SEO baseline records the current site's key data. This includes URLs, rankings, organic traffic, conversions, indexation, backlinks, metadata, structured data and crawl issues. Use a crawl and analytics data to find what needs protection.

Save the data in a shared file. Give each URL an owner and a clear decision. Include service pages, content hubs and every sales path. Don't only review pages with the most visits.

Crawl the existing website and export indexable URLs, status codes, titles, meta descriptions, canonicals, headings and word counts.

Record organic landing pages, conversions, engagement data and key query data from analytics and Search Console.

Find high-value pages through rankings, impressions, clicks, backlinks, revenue or business value.

Check the current robots.txt file, XML sitemap, pagination, hreflang, structured data and canonical setup.

Map old URLs to their planned new URLs, including pages to join, replace or retire.

Record the current internal links and find orphan pages, broken links and key navigation paths.

Create a rollback plan, test process and named approval process for SEO-critical changes.

Google Search Console and Google Analytics offer useful first-party data. Keep your own crawl exports too. Save backlink and rank data before launch. This makes later checks more useful.

What Redirects Are Needed When Changing Website URLs?

Website URL changes usually need direct 301 redirects. Each valuable old URL should point to its closest new match. Don't create chains, loops or unrelated targets. Test redirects before launch. Update internal links, the XML sitemap and canonical URLs.

Use a URL redirect map as your main record. Show the old address, new address, reason, redirect type and test result. A direct response is best. Extra steps can slow crawling.

Migration situation	Recommended action	SEO risk to avoid
Old page has a closely matching replacement	Use a direct 301 redirect to the equivalent new URL	Do not create multiple redirect hops
Several pages are consolidated into one relevant page	Redirect each old URL to the consolidated destination	Do not redirect unrelated pages to the homepage
Page has no suitable replacement	Return an appropriate 404 or 410 after reviewing links and traffic	Do not force every retired URL to an irrelevant page
HTTP, HTTPS, www or trailing-slash format changes	Standardise the preferred format with direct redirects and canonicals	Do not create redirect loops or mixed signals
Domain or subdomain changes	Map old URLs individually and use the relevant search-engine change tools	Do not rely on a domain-level redirect alone

A canonical URL cannot replace a redirect. Update internal links to the preferred address. Add only live canonical URLs to the XML sitemap. Test common URLs and old addresses with query strings, capitals and old folders.

How Do You Stop a Staging Website Being Indexed?

A staging website is best protected with HTTP authentication or network controls. These controls stop crawlers and users from entering the site. A noindex directive adds protection. Robots.txt alone isn't enough.

Access control is stronger than a page rule. It protects unfinished content, test forms and private files. Keep staging separate from production. Make sure developers know which site they're changing.

Restrict staging access with HTTP authentication, VPN access, IP allowlisting or another server-level control.

Apply a noindex directive to staging pages as a secondary safeguard where the environment can be crawled.

Keep staging out of XML sitemaps and remove public links pointing to it.

Use a separate host and confirm that production canonicals do not accidentally point to staging.

Test the live site after launch to ensure authentication, noindex rules and temporary blocks have been removed correctly.

Before release, check response headers, meta robots and robots.txt on key templates. Repeat these checks on the live host. A forgotten block can hide the new site. A forgotten noindex can stop indexation.

During Migration: Test the New Website Before Launch

Pre-launch testing checks if the new site can be crawled and used. It also checks if it matches or improves the old site. Test status codes, redirects, content, metadata, canonicals, links, structured data, mobile behaviour, speed and indexation controls.

Use a test site that matches the planned server, CMS and launch process. Include different templates, content lengths, media types and sales actions. Pay close attention to JavaScript. It may add content or links after the first page load.

Crawl the pre-production build and compare key templates, URLs, content, headings, metadata and canonicals with the baseline.

Test the redirect map for direct responses, suitable targets, chains, loops and false 404 pages.

Check robots.txt, meta robots, X-Robots-Tag, XML sitemaps and canonical tags for blocking rules.

Check internal links, navigation, breadcrumbs, pagination, images, hreflang and downloadable files.

Test JavaScript rendering, structured data, mobile layouts, Core Web Vitals and key sales paths.

Confirm analytics, Tag Manager, consent controls, Search Console verification and event tracking.

Get final SEO sign-off and set launch checks, backups and rollback ownership.

Record each failure, owner and due date. A CMS change can affect many templates. Server access may limit log tests or redirect rules. Fix serious crawl and tracking issues before launch.

After Launch: What Should You Check on the New Website?

After launch, check redirects, indexation, crawl errors, robots.txt, XML sitemaps, canonicals, analytics, rankings, traffic, speed and conversions. Compare these results with the old baseline. Check valuable URLs first. Fix unusual changes quickly.

Start with a production crawl and key URLs. Check new pages and old addresses with backlinks. Google Search Console shows index coverage and crawl data. Server logs can show if key files are being requested.

Crawl the production website and confirm that priority old URLs redirect to the right new URLs.

Check robots.txt, XML sitemaps, canonicals, noindex rules, status codes and internal links.

Submit or resubmit the production XML sitemap and inspect key URLs in Search Console.

Review index coverage, crawl data, server logs and new 404, 5xx, blocked or redirected URL groups.

Confirm analytics, conversions, events, consent signals and campaign tracking.

Monitor rankings, impressions, clicks, organic sessions and revenue against the old baseline.

Fix serious errors first, record the changes and keep checking during the settling period.

Red flags should prompt a quick review:

Widespread noindex rules or a blocked production robots.txt file.

Large groups of old URLs returning 404 or 5xx responses without a clear reason.

Canonical tags pointing to staging, the wrong domain or unrelated pages.

Analytics or conversion tracking stopping during the launch.

Keep a change log during the settling period. If results fall, compare affected URLs with their old content, links, redirects and templates. Our team can use Technical SEO checks with design and analytics reviews. A rollback can help when a serious fault can't be fixed safely.

Can a Website Redesign Cause Rankings to Drop?

A website redesign can cause rankings to drop. This may happen when URLs or useful content change. Broken links, blocked crawlers, poor relevance, slow pages and weak redirects can also cause problems. Short-term changes may settle. A lasting fall needs a close review.

A ranking drop doesn't always mean the redesign failed. Search engines may need time to recrawl pages and process redirects. Still, check crawl errors, indexation and tracking before blaming normal change.

Compare affected pages at URL level. Look for missing headings, shorter content, changed canonicals and lost links. Check structured data, page speed and JavaScript rendering too. Backlinks must also reach useful pages.

Keep the same domain when practical. A domain change can still work with careful mapping and search-engine change tools. The goal is to protect useful signals while improving the user experience. Web Design should support visibility, access, speed and conversions.

If you need help, we can review the data and rank the fixes. We can also work with developers. The aim is controlled website change management. No one can promise that rankings will never change.

Questions About SEO Agency

How Long Does SEO Take to Recover After a Website Migration?

Recovery varies by site size, crawl rate, URL changes and launch quality. Some changes settle within weeks. Larger migrations can take longer. Monitor indexation, redirects, rankings and traffic. Fix technical issues as soon as they appear.

Should I Redesign My Website Before or After an SEO Audit?

Complete an SEO audit or baseline before the redesign. It finds valuable pages, weak areas, backlinks, rankings and sales paths. A second review of the new site is needed before launch.

How Do I Migrate a Website Without Losing Traffic?

Crawl the old site and keep valuable content. Map each key URL and add relevant 301 redirects. Keep internal links and canonical tags. Protect staging and test the live site. After launch, check Search Console, analytics, rankings and crawl errors.

Should I Keep the Same Domain Name During a Website Redesign?

Keeping the same domain can reduce the number of changes at once. It isn't always possible or best. If the domain changes, map URLs one by one. Use direct redirects, updated canonicals and internal links. Use the relevant search-engine change tools.

How Do I Check if a Website Migration Was Successful?

Run a production crawl and test the redirect map. Inspect key URLs in Google Search Console. Review index coverage and crawl errors. Confirm analytics and conversions. Compare rankings, impressions, clicks and organic traffic with the old baseline.