Website Migration SEO Checklist: Protect Rankings During a Redesign

Protect SEO during a website migration by inventorying current URLs, preserving valuable content, mapping every changed page to a relevant destination and testing permanent server-side redirects before launch. Update canonicals, internal links and sitemaps, then monitor crawling, indexing and conversions after release.

Do not combine a domain move, platform change, navigation rewrite and large content deletion unless the business need outweighs the diagnostic risk.

Before development

Confirm the migration type

Document whether URLs, domain, protocol, hosting, platform, content or design will change. Google has separate guidance for site moves with URL changes and hosting changes without visible URL changes.

Capture the current site

Crawl all indexable URLs and combine them with sitemap, analytics, Search Console, backlink and server-log sources where available. Record status, canonical, title, heading, indexability, internal links, traffic, queries and conversion role.

Keep the crawl as launch evidence. A spreadsheet of “important pages” alone will miss long-tail articles, files and externally linked URLs.

Decide each URL’s future

Mark each page keep, improve, consolidate, redirect or retire. Preserve URLs when the intent and content remain equivalent. Where a URL changes, map it to the closest relevant destination.

Do not redirect every removed page to the homepage. A true replacement deserves a redirect; a page with no replacement may appropriately return 404 or 410 after internal links are removed.

During design and content work

Preserve search intent

Compare the current page’s queries and content with the replacement. A visually cleaner page that removes specifications, FAQs or evidence may no longer satisfy the same need.

Google’s people-first content guidance asks whether content is substantial, trustworthy and useful. Improve quality while retaining the information that earned relevance.

Keep metadata and headings intentional

Create unique, descriptive titles and descriptions. Maintain one clear page topic and semantic heading structure. Do not auto-generate titles from navigation labels without editorial review.

Plan images and files

Map important image and document URLs where they have external links or search visibility. Optimise new images, preserve meaningful alt text and avoid embedding critical text only in graphics.

During development

Implement permanent redirects

Use server-side 301 or 308 redirects for permanent moves where the hosting architecture supports them. Google describes permanent redirects as strong canonical signals in its redirect guidance.

Avoid chains and loops. Redirect directly from every known old URL to the final canonical destination. Preserve query parameters only when they carry meaningful state.

Update canonical signals

Every indexable page should have the intended self-referencing canonical. Internal links and XML sitemaps should use the same canonical host, protocol and trailing-slash convention.

Google explains that redirects and rel="canonical" are strong signals while sitemap inclusion is weaker, and recommends linking internally to canonical URLs in its canonicalisation documentation.

Control staging

Protect staging through authentication or network access where feasible. Do not rely only on robots.txt to keep confidential drafts private. Before launch, remove staging-only noindex directives and ensure production is crawlable.

Preserve structured data

Recreate only markup supported by visible content. Validate organisation, breadcrumb, article or service-related schema as appropriate. For editorial pages, follow Google’s Article structured-data guidance.

Meet performance and accessibility requirements

Optimise media, fonts and JavaScript; reserve image dimensions; test responsive templates. Measure LCP, INP and CLS using web.dev’s current guidance.

Test keyboard use, focus, labels, errors and contrast against WCAG 2.2. Migration should not trade search equity for a less usable interface.

Pre-launch validation

Crawl the new environment using the planned production URLs. Check:

• every old URL mapping;
• redirect status and final destination;
• no chains, loops or accidental soft 404s;
• canonicals and indexability;
• robots and sitemap;
• title/description uniqueness;
• headings and content presence;
• internal broken links;
• structured data;
• image loading and alt text;
• analytics and conversion events;
• forms and integrations; and
• custom 404 behaviour.

Compare counts by page type with the old crawl. Investigate missing categories or sudden reductions rather than accepting the total.

Launch sequence

Back up the current production state and confirm rollback conditions. Deploy redirects and new pages together. Update sitemap and robots references, verify DNS/TLS if changed and test from outside the development network.

Submit the sitemap through the available search tools and request inspection for a small set of representative pages. Do not repeatedly resubmit every URL as a substitute for crawlable architecture.

Post-launch monitoring

Monitor old and new URL responses, crawl errors, indexing, canonical selection, query/page performance, conversions and server health. Check high-value pages daily during the initial period, then reduce frequency as behaviour stabilises.

Expect search engines to recrawl. Google notes that crawling may increase after a site move. Keep redirects for as long as practical—at least through user, link and search transition—not only until the new page appears once.

Investigate patterns: one template missing canonicals, a category blocked by robots or redirect rules dropping uppercase paths. Avoid reacting to normal daily movement with broad changes.

Common migration failures

• Starting URL mapping after launch.
• Redirecting all removed pages to home.
• Allowing redirect chains.
• Shipping production with noindex.
• Changing content intent and URL simultaneously without review.
• Leaving internal links pointing at redirects.
• Publishing duplicate protocol/host variants.
• Omitting articles or files from the inventory.
• Losing analytics or form tracking.
• Switching off the old infrastructure before validating traffic.

Migration sign-off

Require business, content, SEO and technical owners to sign off the evidence relevant to them. A developer can confirm redirects; a service owner must confirm that the destination still answers the customer need.

Use the B2B Website Redesign Checklist for the wider programme. If traffic has already declined, follow Why Your Website Might Be Losing Google Rankings to diagnose rather than assume migration is the only cause.

AUZtec Innovations combines SEO and Google marketing with web engineering and cloud deployment. A migration review verifies the technical signals and the buyer-facing content before the release becomes difficult to reverse.