Website Redesign SEO: How to Redesign Without Losing Rankings

"The URLs aren't changing, so SEO isn't involved."

That sentence opens more redesign kick-offs than any other, and it is wrong in a specific way: of the five things a redesign changes that Google reads, the URL is the only one a redirect map can protect.

Website redesign SEO is the work of deciding, before and during a rebuild, which parts of a site's search footprint the new templates, navigation, URLs or platform are allowed to change, and checking the rest against the old site.

Four of those five things stay exposed after the redirect map is done: titles, the internal links the new templates do or don't carry, what the new stack renders, and how heavy the templates are. A sixth sits outside Search Console altogether: what the project does to the numbers you will later use to judge it.

Does a website redesign affect SEO?

A website redesign affects SEO whenever it changes something Google uses to rank a page: the URL, the title and H1, the internal links, the HTML Googlebot ends up processing, or the speed of the template. A redesign that keeps every URL can still change the other four.

Each of those channels shows up somewhere in Search Console, and each one looks like something else until you know where to look.

• URLs (paths, slugs, folders, trailing slashes) - What Google has to re-learn: The identity of every moved page; links and history attach to the URL, not the content - Where it surfaces in Search Console: Pages report: Not found (404), Page with redirect; Performance: impressions leave the old URL before they arrive at the new one
• Title element and H1 - What Google has to re-learn: What the page is about; what the title link in results should say - Where it surfaces in Search Console: Performance filtered to one page: same clicks, a different query set; title link in results no longer matches the tag
• Internal links (navigation, footer, related blocks) - What Google has to re-learn: Which pages the site itself treats as important; crawl order; anchor context - Where it surfaces in Search Console: Nothing direct. Links report → Internal links shows the new top pages; the loss is in the comparison with the old crawl, which Search Console doesn't keep
• How the HTML is built (server-rendered vs assembled in the browser) - What Google has to re-learn: The content, canonical and robots directives Googlebot processes, which may differ from what the browser shows - Where it surfaces in Search Console: URL Inspection → View crawled page; Pages report: Excluded by 'noindex' tag, Alternate page with proper canonical tag
• Template weight and layout - What Google has to re-learn: Core Web Vitals per URL group; mobile layout - Where it surfaces in Search Console: Core Web Vitals report, 28 days late, grouped by template whether you planned it that way or not

The table has one row it cannot show: what the redesign does to your own measurement. Conversion events get renamed, form IDs change, the field that stored the landing page gets a new key. None of that is visible in Search Console, and it decides whether anyone can say the project worked.

The four kinds of redesign and what each one risks

A brief that says "redesign" usually holds three decisions wearing one word: new templates, a new URL scheme to go with them, and, often enough, a new platform underneath. Each is a different redesign with a different failure mode, and the plan tends to have one line for all three that reads "301 redirects."

• Template-only: same URLs, same CMS - What changes: HTML, navigation, titles and H1s, CSS and JavaScript weight - Main way it loses rankings: Titles rewritten in a copy refresh; ranking pages lose their footer and menu links; a heavier template fails Core Web Vitals - The check that catches it: Internal-link diff and title/H1 parity, old crawl against staging
• URL changes on the same domain - What changes: Paths, folder structure, slugs - Main way it loses rankings: URLs cut while they still rank; redirects missing, chained, or pointed at the homepage - The check that catches it: A verdict for every URL with clicks, links or conversions; redirect map tested against the Search Console export
• Platform or stack change (often with URL changes) - What changes: Server, rendering model, URL rules, canonical and robots defaults - Main way it loses rankings: Everything above, plus directives set by JavaScript that Googlebot never runs; trailing-slash, case and parameter handling that changes without anyone deciding it - The check that catches it: View crawled page on one URL per template; staging behind 401 and X-Robots-Tag
• Domain change or rebrand - What changes: The host, and with it the entity - Main way it loses rankings: Signals split between old and new domain for months; variants of the old domain left unmoved - The check that catches it: Change of Address for every verified variant of the old domain, www and non-www included (Google site-move documentation, updated 17 June 2026)

Template-only is not the safe option. It is the cheap one. The losses it causes don't appear in a redirect report because there are no redirects to report, and a team that has been told "the URLs aren't changing" has usually been told, in the same breath, that nothing needs checking.

The two checks it does need are the ones the other three kinds need as well. That is why they sit in the first row.

On WordPress this is the commonest kind, because a theme rebuild is what most redesigns there amount to. The one I'll use as the case in this post was exactly that: a property-listings site in Bali, theme rebuilt from scratch, every listing and guide URL left where it was.

WordPress keeps the permalink structure and post slugs in the database, so a new theme doesn't move them. What a theme swap can take with it is whatever the old theme registered itself. A custom post type or taxonomy declared in the outgoing theme's functions.php leaves with the theme, and its URLs start returning 404 the day the new one is activated; the same types registered by a plugin come through untouched.

Two more things are stored per theme and don't always survive the switch: menu locations, which WordPress tries to map by name, and widgets, which land in Inactive Widgets when the new theme's sidebars have different IDs. Both are internal links, and a footer full of them can disappear without a single URL changing.

Google's site-move document is written for the second and fourth rows, and the June 2026 revision closed a gap that used to catch domain moves late. The Change of Address request now has to be submitted for every subdomain variant of the old domain, "even if you're not actively using these variants". A domain that only ever resolved on www still has a bare-domain property in the index, and a move that forgets it leaves half the signal behind. The same document rules the tool out for HTTP-to-HTTPS moves, which follow their own path.

Across all four rows, the size of the dip tracks one thing more than any other: how many of the ranking URLs moved. That is decided when the new URL scheme is signed off, long before anyone writes a redirect.

Before design starts: the baseline and the verdicts

The baseline is time-limited in a way the rest of the project isn't. Search Console keeps sixteen months of performance data and then deletes it; the Performance table in the interface stops at a thousand rows, which on a site with a few hundred URLs is the whole long tail, so the export goes through the Search Analytics API or the Looker Studio connector.

GA4 keeps event-level data for two months unless someone switches the property to fourteen, and the switch is not retroactive: set it the week the project is approved or there will be no pre-launch conversion data in Explorations by the time the site is live.

Add a full crawl of the current site, so the internal-link graph exists somewhere other than the live server, and backlinks per URL, since the per-domain count hides which pages hold them.

With the export in hand, each old URL that has clicks, a referring domain or a CRM conversion attached gets one of four verdicts before anyone touches it: keep, improve, merge, or redirect. A fifth, delete, exists and is rarely earned; in practice the deleted pages are the ones a sitemap clean-up removed without the export open.

The verdict criteria are short: a page that ranks or earns links stays as it is; a page with the right intent and weak execution keeps its URL and title and gets better content; two thin pages on one intent merge into the one with more backlinks; everything else that holds links or history redirects to the closest live page.

Half a year later, the question "was the old pricing page bringing anything in?" has exactly one source that can still answer it, and it is this export.

What new templates do to ranking pages

A redesign replaces a site one template at a time, and the template is the unit of damage. A page loses rankings in a redesign when the template it sits on stops linking to it, renames it or slows it down, and every other page on that template loses with it. That is also why the loss arrives as a pattern in the Performance report, a whole folder sagging together. One page dropping on its own is the rarer case.

The internal-link diff

The crawl taken before the project has a unique-inlinks count for every URL. That count is what the new templates are about to change, and nobody on the design side will see it happen.

Where the links usually go: a footer that linked every service page now links four; a mega-menu becomes a dropdown with half the entries; a related-content block that an editor curated now shows "latest posts," which means the pages that need links least get the most.

Load the baseline crawl and the staging crawl into Screaming Frog's Compare mode and sort by the change in unique inlinks; whatever sits at the top of that column is the finding.

The pass condition applies per ranking page. No page with clicks in the baseline loses more than half its inbound internal links, and no internal link resolves through a redirect. The second condition is the quieter one: a site that changes its URLs and leaves the navigation pointing at the old ones has made every crawl go through the redirect map, and that shows up as crawl stats before it shows up as rankings.

The diff reads the other way too, and that is where a template-only redesign can earn something. On the Bali site the old menu listed the sections and nothing else: villas, apartments, penthouses, townhouses, land. The new one opens each section into what people search with: eight areas from Canggu and Seminyak to Ubud and Sanur, bedrooms one to five, leasehold or freehold, and a column of popular attributes such as private pool, ocean view and off-plan.

The footer gained a popular-searches block (villas in Canggu, Seminyak, Ubud and Uluwatu; freehold, leasehold and luxury villas) and links to three buyer guides. Area and attribute pages that used to be reachable only through the listing filters now take a link from every page on the site, and their positions went up a little after launch.

After the redesign. Before it, this menu held the five section names on the left and nothing else. The footer of the same site. "Popular searches" points at area and ownership pages that have search demand of their own.

How much of that lift came from the menu I can't say. The same release added links from the guides into the listing pages (more on that below), and two changes shipped together can't be separated afterwards; it is the same problem as a launch inside an update window, made in-house.

The column in a menu like this that needs checking before launch is bedrooms. If 1 to 5 resolve to filter parameters on the listing page, with no title or copy of their own, a sitewide link to each of them sends every crawl into thin facets. A navigation link should point at a page that can rank for something.

Title and H1 parity

A title element and an H1 that rank are assets, and a "copy refresh" replaces them wholesale because the new tone of voice asked for it. Google builds the title link it shows in results from more than the title element: headings and the anchor text of links pointing at the page feed it too ( documented ), so an H1 rewrite alone can change what searchers see while the title element is untouched.

My rule is to carry the old title and H1 over by default and treat each change as a decision with a date next to it, because a drop three weeks after launch is only diagnosable if there is a log to match it against. The list comes from comparing the Page Titles and H1 tabs of the two crawls; a ranking page passes when both are unchanged or the change is in the log.

Meta descriptions, alt text and structured data carry over by the same rule, deliberately and in a log, and none of them moves a ranking the way the title does.

Intent drift

Neither diff catches this one. A guide that ranked for years gets rewritten as a sales page because the new site "doesn't do blog-style content," or two intents are folded into one URL because the sitemap looked cleaner that way. To a crawler the page still has a title and an H1, so the diff passes it.

What settles it is the query set per URL in the Performance report, four weeks before launch against four weeks after: when the "what is" and "how to" queries have gone and nothing replaced them, the intent left with the old copy and needs its own URL again. This is the single check that cannot be closed before the site is live, and it is the reason the baseline export carries queries per URL, not just clicks.

Changing the stack: what Google reads when the HTML is built in the browser

A move from a server-rendered CMS to a JavaScript framework is a second migration, and it rarely gets its own line in the plan. The redesign changes what the pages look like; the stack change changes what Googlebot receives, which is an initial HTML response and then, if the page qualifies, a rendered version produced by Google's Web Rendering Service some time later. Everything the page decides in that gap, in JavaScript, is at the mercy of whether the render happens at all.

Google revised its JavaScript SEO documentation three times in one week in December 2025, and each revision answers a line that turns up in redesign plans built on a JavaScript framework.

"We ship noindex on every page in the HTML and strip it on hydration in production." The 15 December 2025 note says that when Goo