Website Redesign SEO: Keep URLs, Keep Rankings

Website redesign SEO is the work of changing a site’s design, templates and content without losing the search visibility the old site earned. When the domain and URLs stay the same, the risk isn’t redirects. It is everything the new templates quietly change: copy that was cut, headings that became styled divs, links that disappeared from the navigation, content hidden behind JavaScript, and a slower hero section.

This guide is for teams redesigning on the same domain and, ideally, the same URLs. It covers when a redesign turns into a migration, what content parity really means, the template changes that most often break SEO, how to test safely, and the checks before and after launch. If your URLs or domain are changing, start with our website migration SEO checklist, which covers baselines, redirect maps and monitoring for 90 days after launch; this page focuses on the redesign itself.

On this page

• Is a redesign the same as a migration?
• Keep your URLs, and know when you can’t
• Content parity: what “the same content” means
• Template changes that quietly break SEO
• Can you test a redesign without hurting SEO?
• Pre-launch QA: diff staging against production
• Launch day and the weeks after
• Redesigning without losing search visibility

Is a redesign the same as a migration?

Not always: a redesign that keeps the domain and every URL is a template and content change, while anything that moves URLs is a migration. The difference decides how much process you need. In our migration checklist, a same-URL redesign is the lowest-risk category; URL restructures, replatforms and domain changes are high risk because every old address needs a redirect.

Three common redesign decisions push a project across that line without anyone noticing:

• A new CMS or framework that generates different URL patterns, trailing slashes or file extensions.
• A cleaned-up information architecture that renames or nests sections.
• Merging or retiring pages during the content rewrite.

If any of those apply, the URL changes need a redirect map, covered in our guide to redirects and SEO. If only the hosting changes, Google has a separate guide to changing your hosting without changing URLs: test the new infrastructure first, check that firewall or denial-of-service protection doesn’t block Googlebot, lower DNS TTLs (Google’s example is a few hours) at least 1 week ahead, and expect a temporary dip in crawl rate followed by a steady increase “over the next few days”.

Keep your URLs, and know when you can’t

The single best redesign SEO decision is to keep every URL that has traffic, links or rankings exactly as it is. Same path, same trailing slash convention, same case. A redesign that keeps URLs avoids redirect chains, lost link equity and the reprocessing Google has to do after any URL change.

When a URL must change, treat that page as a small migration: one 301 from the old URL to its closest equivalent, internal links updated to the new URL, and the change recorded so it can be checked on launch day. Resist renaming URLs for tidiness alone. A slug that reads slightly awkwardly costs nothing; a renamed URL with a broken redirect costs the page.

Content parity: what “the same content” means

Content parity means each page on the new site carries the same main content, headings, links, metadata and structured data as the old version, unless you deliberately changed them. One of the most common causes of redesign losses we see is copy cut to fit a cleaner layout. Google’s mobile-first indexing guidance is a useful model because it spells out what parity means between two versions of a page:

• the same content, with primary content equivalent
• “the same clear and meaningful headings”
• the same structured data
• the same robots meta tags
• the same metadata, such as titles and descriptions
• no primary content that only loads on user interaction

The diagram shows what to compare on each template before launch.

Parity doesn’t mean nothing may change. Rewriting a page to be clearer and more complete is often the point of a redesign. It means every change is a decision, made page by page, rather than a side effect of a new layout. The accent rows are the ones designers don’t see and developers don’t think to check.

Template changes that quietly break SEO

Most redesign SEO losses come from template decisions that look harmless in a design review. These are the ones we check first:

The rules behind the table come straight from Google. Its link guidance says Google can reliably follow links only when they are <a> elements with an href. Its mobile-first guidance says Google won’t load content that requires user interaction such as swiping, clicking or typing, so tabs are fine only if their content is in the HTML on load. And web.dev’s guide to optimizing LCP warns: “Never lazy-load your LCP image.” The bar is specific: web.dev’s Web Vitals guide says LCP should occur within 2.5 seconds and INP should be 200 ms or less, measured at the 75th percentile of page loads. Lazy loading itself is widespread, used on images on 24.6% of mobile pages according to the 2024 Web Almanac, so check that a new template has not applied it to the hero image. A redesign that swaps a static hero for a lazy-loaded slider can undo a year of site speed optimization in one release.

JavaScript-heavy redesigns carry an extra risk beyond Google, because many AI crawlers don’t execute JavaScript at all. We cover that in JavaScript rendering and AI crawlers.

Can you test a redesign without hurting SEO?

Yes, if you follow Google’s testing rules. Many teams test a new design on a share of traffic before switching fully. Google’s guidance on website testing sets out how to do it without harming search:

• Don’t cloak. Googlebot should see what a typical user in the test sees, not a special version.
• Use rel="canonical" on any variant URLs, pointing to the original, rather than noindex.
• Use 302 redirects, not 301, when the test redirects users to a variant URL, because the redirect is temporary.
• Run the test only as long as necessary, then remove variants and test code.

For the staging site itself, password protection is the safest option because nothing needs to be removed at launch. Google’s hosting guide suggests a noindex rule if you use a public temporary hostname, which works, provided removing it is on the launch checklist. A staging noindex or Disallow: / that reaches production is the most common redesign disaster we see.

Pre-launch QA: diff staging against production

Before launch, crawl both sites with the same settings and compare them template by template. A diff surfaces changes nobody meant to make. The flow below is the one we use.

Pick the thresholds before you look at results. A word count drop of more than a fifth on a ranking page, any lost <h1>, any change in canonical or robots directives, and any page that loses more than a few internal links should be explained by someone. The rest of the technical baseline, from crawl access to rendering, is in our technical SEO checklist for AI search.

Launch day and the weeks after

On launch day, check the things that can remove pages from search, then the things that change how they rank. The timeline shows what to look at, and when.

Speed results take longest to confirm. Google’s PageSpeed Insights documentation says its field data covers “the previous 28-day collection period”, so a faster template won’t show fully in field data until 28 days after launch. Lab tests on launch day tell you whether it should.

In the first week, the Page indexing report is the early warning system. A jump in “URL marked ‘noindex’”, “Duplicate, Google chose different canonical than user” or “Soft 404” right after launch almost always traces back to a template. Inspect one affected URL, find the template it uses, and fix the template rather than the page. Use the live URL Inspection test to confirm the fix before asking Google to validate it, and remember the help page’s warning that the live test doesn’t check duplicate or canonical conditions.

If traffic falls and keeps falling after the first couple of weeks, work through causes in order: robots and noindex, then canonicals, then content parity on the pages that lost the most, then internal links, then speed. The fuller triage sequence, including rendering and AI citations, is in our website migration SEO checklist. The Search Console reports mentioned throughout are explained in our Google Search Console guide.

Redesigning without losing search visibility

A redesign that keeps URLs is one of the safest big changes a site can make, as long as the team treats content, headings, links and markup as things to carry over deliberately rather than things the new design happens to include. The pattern behind most redesign traffic drops is the same: the design review looked at how pages look, and nobody compared what they say to machines.

Build the parity check into the project plan, crawl and diff before launch, and watch Search Console for a month afterward. Good design principles and good SEO don’t conflict; our guide to web design for SEO covers where they meet. If you’re planning a redesign and want it built with parity, speed and crawlability designed in from the first template, that is how our web development service runs every rebuild.