Treat a redesign as a migration of content, URLs and functions. Inventory what still serves a purpose, assign destinations to old addresses and define acceptance before launch. Checks can reduce avoidable errors; they do not guarantee unchanged visibility after publication.

The method: redesign as an SEO migration project

1. Freeze the SEO baseline before any design decision

Before wireframes or template changes, record what currently drives visibility and leads: top landing pages, indexed URLs, pages with backlinks, top queries, local landing pages, pages appearing in rich results, and pages with strong conversion performance. This baseline becomes the protection list.

  • Export current URLs, titles, meta descriptions, canonicals and indexability rules.
  • Identify pages with traffic, links, conversions and local intent.
  • List all structured data types currently deployed.
  • Document Core Web Vitals, crawl errors and sitemap status.

This is the point where website redesign services and SEO and SXO support should work from one shared scope, not parallel tracks.

2. Decide what must stay stable

The safest redesign is the one that preserves as much URL and content continuity as possible. If a page performs well and still matches business intent, keep its URL, search intent, core copy blocks, heading logic and internal link equity.

Common mistakes come from changing too many variables at once: new design, new CMS, new URL structure, rewritten copy, changed navigation, deleted category pages and different analytics setup. Each additional change makes diagnosis harder if traffic drops.

3. Build a page-by-page URL mapping

Google recommends preparing a URL mapping from the current site to the new format before launch. That mapping should cover all important old URLs and send each one to the closest equivalent new page with a permanent redirect. Redirecting everything to the homepage is usually a relevance loss, not a migration strategy. developers.google.com

  • Map one old URL to one best new URL wherever possible.
  • Preserve key category, service, editorial and local landing pages.
  • Merge pages only when the new destination fully covers the old intent.
  • Remove redirect chains and loops before launch.

4. Protect on-page relevance during copy and UX updates

A redesign often weakens SEO because high-intent copy is shortened in favor of design. Secure projects keep the language that proves relevance: clear headings, service details, geographic qualifiers, supporting FAQs, trust elements, and internal links to deeper pages.

This is where SXO matters. Better UX is useful only if it still helps users and crawlers understand the page purpose quickly. Strong redesigns improve scanning, trust and conversion without flattening content into generic marketing language.

5. Rebuild internal linking deliberately

Internal links are frequently damaged during redesign through simplified menus, removed footer links or card-based layouts with vague anchor text. That can weaken page discovery and topical hierarchy even if redirects are perfect.

  • Keep links from top-authority pages to strategic commercial pages.
  • Maintain breadcrumb logic where relevant.
  • Use descriptive anchors, especially for service and local pages.
  • Update internal links to the final new URLs instead of relying on redirects.

Google explicitly recommends updating as many links as possible once a move starts, both for user experience and to reduce server load. developers.google.com

6. Preserve canonicals, indexation rules and XML sitemaps

After launch, the new site should not send mixed signals. Google recommends checking that canonical annotations on the new site reference the new URLs, and its canonicalization guidance treats redirects as a strong signal while warning against using noindex as a canonicalization shortcut. developers.google.com

  • Self-canonicalize indexable pages unless a different canonical is intentional.
  • Do not leave staging noindex tags on production.
  • Publish clean XML sitemaps with final canonical URLs only.
  • Keep robots.txt aligned with real crawl goals.

7. Reimplement structured data with more precision, not less

Redesigns often remove valid schema during template rebuilds. That is avoidable. Google recommends using the most specific structured data type that fits the business, and for local businesses it recommends the most specific LocalBusiness subtype with useful administrative details. developers.google.com

For redesign projects, the practical priority is to preserve and improve entity clarity:

  • Organization or the most specific business subtype on the appropriate brand page.
  • LocalBusiness markup for location pages when the company serves physical areas or offices.
  • Service, FAQ, breadcrumb and article-related markup where relevant and compliant.
  • Consistent name, address, phone, logo and URL references across the site.

When this layer is handled well, structured data supports SEO, local discoverability, and clearer interpretation by answer engines and LLM-oriented systems. For many projects, a dedicated structured data implementation review is justified.

Performance and rendering risks that quietly damage SEO

Many redesign losses are technical rather than editorial. Modern templates can increase JavaScript, shift content loading, break mobile rendering or slow template response times. Search engines can process JavaScript, but unnecessary rendering complexity still raises risk and slows diagnosis when pages are not indexed or interpreted as expected.

  • Test rendered HTML, not only source HTML.
  • Keep main content and internal links available without fragile client-side dependencies.
  • Control image weight, font loading and layout shifts.
  • Validate mobile templates, faceted navigation and pagination behavior.

The redesign should improve perceived speed and crawl efficiency together. Faster pages help users convert, but they also reduce the chance that a visual upgrade turns into a crawl budget or rendering quality problem.

The main risks that cause avoidable SEO loss

  • Unplanned URL changes: pages move without redirects or with poor destination matching.
  • Content dilution: important copy is removed in favor of cleaner layouts.
  • Navigation simplification: fewer links to deep, high-value pages.
  • Broken canonical logic: old canonicals, staging tags or conflicting signals remain live.
  • Schema regression: rich-result and entity markup disappears during template rebuild.
  • Performance regressions: the new site is heavier, slower or more dependent on JavaScript.
  • Local page consolidation: city or office pages are merged without preserving local intent.
  • No post-launch watch period: teams launch, then stop checking crawl, indexation and redirect behavior.

The checks an agency should run before launch

  1. Crawl the staging site and compare indexable templates against the current production site.
  2. Validate the redirect map on a sample of top pages, then at scale.
  3. Check titles, metas, headings, canonicals, hreflang when relevant, robots rules and sitemap generation.
  4. Validate structured data on critical templates and local pages.
  5. Test mobile rendering, Core Web Vitals proxies and image optimization.
  6. Confirm analytics, tag management and Search Console properties are ready.
  7. Review internal linking from menus, breadcrumbs, footers and contextual blocks.
  8. Confirm forms, conversion paths and thank-you pages work after redirect rules are active.

What to monitor immediately after launch

Google notes that medium-sized migrations can take a few weeks for most pages to move in its index, and larger sites can take longer. That means the right question is not “did positions move on day two?” but “are search engines receiving coherent signals and are the right pages replacing the old ones?” developers.google.com

  • Redirect response codes and destination relevance.
  • Index coverage of strategic pages.
  • Search Console performance by page, query and search feature.
  • Generative AI visibility reports in Search Console where available. developers.google.com
  • 404 errors, soft 404s and blocked resources.
  • Log patterns, crawl frequency and abnormal drops in bot access.
  • Lead volume, calls, form submissions and local page engagement.

Bing should not be ignored in redesigns either. Bing Webmaster Tools documentation highlights tools for checking redirects, crawl issues and URL health, and Bing’s webmaster guidance also emphasizes proper handling of URL moves with redirects. bing.com

Further documentation

Verification workshop: evidence before a decision

A proposed exercise on a chosen scope, using fictional data where needed. Record what you observe; this scenario describes no test already performed on your website.

Action to try

Before a redesign, select five distinct old pages: service, article, document, category and translated page. Prepare a target meeting the same need for each.

Record to retain

Keep mappings and a before-and-after check of content, useful action, HTTP response, canonical and language links where present.

What this evidence does not establish

Five successful checks do not cover the whole site. HTTP 200 does not establish correct content, forms or link migration.

Further documentation : Google Search Central — Site moves

Explore the method