A website redesign becomes an SEO migration whenever URLs, content, navigation, templates, rendering, hosting, domains, or tracking change. The visual design may be the most visible part of the project, but search risk lives in the details: a useful page disappears, a redirect chain is introduced, a canonical points to staging, or a form works without recording the enquiry.

Use this checklist to treat migration as a controlled release. It is designed for a business website moving to a new architecture or platform, whether the domain stays the same or changes.

No checklist can guarantee that visibility remains unchanged. Search engines must crawl and reassess the new site. The purpose is to preserve valuable signals, remove avoidable errors, and create evidence for quick diagnosis after launch.

Assign migration ownership before design begins

One person should own the migration plan across SEO, content, design, development, analytics, and domain operations. That owner does not need to perform every task, but must know who is responsible and what evidence marks each task complete.

  • [ ] Name the migration owner and launch decision-maker.
  • [ ] List everyone who can change the domain, DNS, hosting, repository, content, analytics, forms, CRM, and search-console property.
  • [ ] Record the current providers, account owners, renewal dates, and recovery methods.
  • [ ] Define what is changing: domain, protocol, host, platform, paths, content, templates, navigation, or all of them.
  • [ ] Set a launch window that allows monitoring and rollback support.
  • [ ] Create a shared issue log for migration risks and decisions.
  • [ ] Define a freeze period for untracked edits to the old site.

Avoid combining a domain change, platform change, full content rewrite, and brand change unless the business reason justifies the additional diagnostic complexity. When several major variables change together, identifying the cause of a problem becomes harder.

Capture the current baseline

The old website is the source of truth for what exists, not necessarily for what should be retained. Build an inventory before removing or rewriting anything.

Crawl and URL inventory

  • [ ] Crawl every internally discoverable URL on the current site.
  • [ ] Export indexable URLs from the XML sitemap.
  • [ ] Export landing pages from analytics for a representative historical period.
  • [ ] Export indexed and submitted pages from the available search-console tools.
  • [ ] Export pages receiving impressions, clicks, and links.
  • [ ] Collect URLs from paid campaigns, email templates, QR codes, listings, documents, and partner sites.
  • [ ] Include images, PDFs, and other files that earn traffic or links.
  • [ ] Normalize duplicates while preserving the original variants for redirect testing.

Do not rely on the current sitemap alone. It may omit old pages that still receive visits or external links.

Performance and search baseline

  • [ ] Record organic landing-page traffic and conversions.
  • [ ] Record important query groups and their landing pages.
  • [ ] Record indexed-page counts and current crawl warnings.
  • [ ] Record Core Web Vitals and representative lab tests.
  • [ ] Record qualified calls, forms, bookings, or sales attributed to organic landing pages.
  • [ ] Annotate seasonality, campaigns, outages, and other events that affect comparisons.

The baseline is not a forecast. It lets the team distinguish a migration issue from ordinary variation and shows which pages deserve the most careful treatment.

Content and proof inventory

  • [ ] Identify pages that are accurate, useful, and still aligned with the offer.
  • [ ] Flag outdated, duplicated, unsupported, or legally sensitive content.
  • [ ] Record each claim, testimonial, logo, certification, statistic, and result that requires evidence or permission.
  • [ ] Identify content that should be consolidated rather than copied.
  • [ ] Note pages that satisfy different search intent despite similar wording.
  • [ ] Preserve original images and their rights information.

Decide the destination of every old URL

Create a redirect map before the new routes are finalized. Each old URL receives one explicit outcome.

Keep

Keep a URL when its purpose remains useful and the path is already suitable. The design and content can change without changing the address.

  • [ ] Confirm the retained URL will return 200.
  • [ ] Preserve its core purpose and important information.
  • [ ] Update internal links to the final canonical form.
  • [ ] Carry forward relevant metadata, then improve it as needed.

Redirect

Use a permanent redirect when an old page has a genuine replacement.

  • [ ] Map the old URL to the closest equivalent new URL.
  • [ ] Prefer a direct one-hop redirect.
  • [ ] Avoid sending unrelated pages to the homepage.
  • [ ] Resolve chains inherited from earlier redesigns.
  • [ ] Include protocol, host, case, slash, parameter, and file variants where relevant.
  • [ ] Update internal links so they do not depend on redirects.

Many-to-one redirects can be appropriate when several overlapping pages are consolidated into one stronger resource. The destination must actually cover the important purpose of the retired pages.

Remove

When there is no suitable replacement, return an honest 404 or 410 response.

  • [ ] Confirm the URL has no valuable traffic, links, or required user purpose.
  • [ ] Remove it from navigation, internal links, and the sitemap.
  • [ ] Provide a useful custom 404 page for visitors.
  • [ ] Keep a record of the decision for post-launch support.

Reconsider

If the team cannot explain the destination, do not guess at launch. Mark the URL for review by the migration owner, content owner, and relevant subject-matter expert.

Design the new search architecture

The redesign should give every page a clear audience and search job.

  • [ ] Map important search intent to one primary page each.
  • [ ] Separate services that solve meaningfully different problems.
  • [ ] Consolidate pages that would compete for the same purpose.
  • [ ] Keep high-value pages within a clear crawlable path from primary navigation or hubs.
  • [ ] Create breadcrumbs and contextual internal links.
  • [ ] Connect resources and case studies to relevant commercial pages.
  • [ ] Use descriptive, durable URL slugs.
  • [ ] Avoid a cloned service-by-location page matrix.
  • [ ] Define the navigation, footer, related-content, and in-copy link rules.

Test the architecture with people who were not part of the design process. Ask them where they would find a specific service, proof, price explanation, or contact option.

Protect the staging environment

Staging must be available to the project team without becoming a competing public website.

  • [ ] Require authentication or an equivalent access control when possible.
  • [ ] Add a noindex directive as a second safeguard.
  • [ ] Keep staging out of public sitemaps and navigation.
  • [ ] Use test analytics properties or suppress production reporting.
  • [ ] Prevent test forms from entering live sales automation without a clear label.
  • [ ] Never link publicly to staging assets.
  • [ ] Create a launch task to remove staging controls from the production deployment only.

Do not rely on robots.txt alone to keep confidential or unfinished content out of search. Crawl blocking is not access control.

Build technical SEO into the templates

Indexing and canonical rules

  • [ ] Give each indexable page a self-referencing canonical URL.
  • [ ] Ensure canonicals use the final production protocol and host.
  • [ ] Keep drafts, search results, filters, tracking variants, and confirmation pages out of the index.
  • [ ] Generate an XML sitemap from canonical, indexable routes only.
  • [ ] Add the sitemap location to robots.txt.
  • [ ] Confirm pagination or filtered experiences have an intentional crawl policy.

Metadata and headings

  • [ ] Write a unique, accurate title for every indexable page.
  • [ ] Write a useful meta description without unsupported promises.
  • [ ] Provide one clear page-level heading.
  • [ ] Use lower-level headings in a logical hierarchy.
  • [ ] Keep visible headings aligned with the search purpose and metadata.

Structured data

  • [ ] Add organization and website data using verified facts.
  • [ ] Add breadcrumb data that matches visible breadcrumbs.
  • [ ] Add service and article data only where the page supports it.
  • [ ] Exclude ratings, locations, prices, or claims that are not visible and verified.
  • [ ] Validate representative pages and inspect rendered output.
  • [ ] Ensure important content and links exist in the initial or server-rendered HTML.
  • [ ] Use crawlable anchor links with descriptive labels.
  • [ ] Avoid interactions that are the only way to reveal essential content.
  • [ ] Confirm navigation works with a keyboard and without pointer-specific gestures.
  • [ ] Check that JavaScript errors do not remove the page’s core content.

Preserve and improve content carefully

A redesign is a good time to improve weak content, but complete rewrites increase variables during migration.

  • [ ] Keep the topic and useful information of valuable landing pages recognizable.
  • [ ] Preserve unique examples, FAQs, diagrams, and proof with permission.
  • [ ] Add missing information that helps the same visitor complete the same task.
  • [ ] Remove unsupported claims rather than carrying them into a new design.
  • [ ] Verify names, dates, locations, credentials, prices, and legal statements.
  • [ ] Review every imported page for broken formatting and links.
  • [ ] Record author, reviewer, publish date, and update responsibility for resources.

If a page’s purpose must change completely, consider whether a new URL is more honest and whether the old URL needs a distinct destination.

Optimize media and performance before launch

  • [ ] Create responsive image sizes and modern formats.
  • [ ] Include width and height attributes.
  • [ ] Compress images without making important detail unreadable.
  • [ ] Prioritize the likely largest-content image rather than lazy-loading it.
  • [ ] Lazy-load appropriate below-the-fold media.
  • [ ] Self-host only required font files and weights.
  • [ ] Remove unused scripts and third-party tags.
  • [ ] Reserve space for embeds, banners, forms, and consent tools.
  • [ ] Test representative pages on a mobile connection profile.
  • [ ] Test with an empty cache and with production-like assets.

Measure the homepage, main service page, resource, case study, and booking experience. A fast homepage does not compensate for a slow template used by most organic landing pages.

Rebuild measurement and lead handling

  • [ ] Preserve access to the analytics and search-console properties.
  • [ ] Record current configuration before changing tags.
  • [ ] Configure consent-aware analytics for the production host.
  • [ ] Track primary CTA clicks, phone links, form starts, form submissions, calendar views, and completed bookings where the tools support them.
  • [ ] Exclude internal and test activity according to the measurement plan.
  • [ ] Pass required source data to the CRM without storing more personal information than necessary.
  • [ ] Test notifications, routing, deduplication, and failure states.
  • [ ] Confirm thank-you and confirmation pages are not indexable.

Use test records that are easy to identify and remove through the system’s supported process.

Complete the pre-launch crawl

Freeze content long enough to test a stable release candidate.

  • [ ] Crawl every staging route.
  • [ ] Confirm all intended pages are present.
  • [ ] Confirm each indexable page returns 200.
  • [ ] Confirm redirect rules use the intended status and destination.
  • [ ] Check for redirect chains and loops.
  • [ ] Check broken internal and external links.
  • [ ] Check duplicate titles, descriptions, headings, and canonicals.
  • [ ] Check pages missing from navigation, hubs, breadcrumbs, or contextual links.
  • [ ] Validate the XML sitemap and compare it with the crawl.
  • [ ] Validate structured data on representative templates.
  • [ ] Search the rendered site for staging domains, placeholder text, unsupported claims, and test contact details.
  • [ ] Verify privacy, terms, contact, and consent content has the required approval.

Test the user experience

  • [ ] Test primary tasks on current mobile and desktop browsers.
  • [ ] Navigate every interactive element by keyboard.
  • [ ] Check focus order, visible focus, labels, errors, and status messages.
  • [ ] Check colour contrast and reduced-motion behaviour.
  • [ ] Test calls to action at common breakpoints.
  • [ ] Submit every form with valid, invalid, empty, and duplicate data where appropriate.
  • [ ] Test calendar availability, booking, rescheduling, cancellation, and fallback contact paths supported by the integration.
  • [ ] Confirm phone and email links use verified contact details.
  • [ ] Confirm the custom 404 page helps visitors recover.

Prepare the launch runbook

The runbook should state the exact sequence, owner, evidence, and rollback condition for each launch task.

  • [ ] Back up the current site and configuration through supported tools.
  • [ ] Export the final redirect map.
  • [ ] Lower DNS time-to-live in advance only if the domain operator determines it is appropriate.
  • [ ] Confirm domain, DNS, certificate, and hosting access.
  • [ ] Confirm the production environment variables without exposing secrets.
  • [ ] Confirm the final legal, contact, analytics, and integration settings.
  • [ ] Schedule the team responsible for launch and immediate monitoring.
  • [ ] Define rollback criteria for a broken deployment, domain failure, or critical lead-flow issue.
  • [ ] Record the old site’s final crawl for comparison.

Launch-day checks

  • [ ] Publish the approved production build.
  • [ ] Confirm the preferred domain resolves securely.
  • [ ] Confirm HTTP and alternate-host variants redirect in one hop.
  • [ ] Confirm high-priority old URLs reach their mapped destinations.
  • [ ] Confirm index controls changed correctly from staging to production.
  • [ ] Confirm canonical URLs use the production domain.
  • [ ] Confirm robots.txt and the XML sitemap are accessible.
  • [ ] Test navigation, forms, calls, calendar, CRM records, and notifications in production.
  • [ ] Confirm analytics receives the intended consent-aware events.
  • [ ] Crawl production and compare it with the approved staging crawl.
  • [ ] Submit or refresh the production sitemap in the relevant webmaster tools.
  • [ ] Annotate the launch in analytics and the project log.

Monitor after launch

Monitoring should be frequent immediately after launch and settle into a regular review once the site is stable.

First checks

  • [ ] Review server, deployment, and integration errors.
  • [ ] Review crawl failures, redirect mistakes, and unexpected 404 responses.
  • [ ] Confirm important pages are crawlable and canonicalized correctly.
  • [ ] Watch forms, bookings, calls, and CRM delivery.
  • [ ] Confirm staging URLs are not appearing in search tools.

Ongoing checks

  • [ ] Compare organic landing pages and query groups with the baseline.
  • [ ] Review indexed-page and excluded-page changes.
  • [ ] Review Core Web Vitals as field data becomes available.
  • [ ] Check backlinks that still point to redirected URLs and update the most important ones when practical.
  • [ ] Resolve new redirect chains rather than allowing them to accumulate.
  • [ ] Update the redirect map and decision log as issues are found.
  • [ ] Evaluate qualified organic enquiries, not only visits or rankings.

Avoid reacting to one day of variation by making broad untracked changes. Diagnose by page group, query group, device, location, and change type, then test the most likely cause.

Migration mistakes to avoid

  • Launching without a complete old-URL inventory.
  • Redirecting every removed page to the homepage.
  • Changing URLs only to make them look newer.
  • Leaving staging canonicals or noindex rules in production.
  • Publishing a sitemap full of redirects or non-canonical URLs.
  • Replacing useful content with shorter promotional copy.
  • Creating duplicate pages for services, industries, or cities.
  • Assuming analytics works because the script is present.
  • Letting test leads trigger live automations unnoticed.
  • Removing the old hosting environment before the migration is verified and rollback needs are resolved.

Plan your redesign before URLs change

If your redesign affects architecture, content, platform, or domain behaviour, book a strategy call to review the migration inventory, redirect plan, technical requirements, and launch gates before the new site goes live.