Website Redesign SEO Checklist

TL;DR — A “redesign” here means your URLs and domain stay exactly the same — only the look, the templates, and maybe the CMS theme change. That sounds safe, but it’s where SEO quietly breaks: new templates can drop your page titles, your headings, your internal links, and your image alt text without changing a single URL. So before you launch, write down what your current pages look like, make sure the new design keeps all of it, and check the new theme didn’t make your pages slow. If any URLs are actually changing, that’s a migration — use the migration checklist instead.

Evidence for this claim Google can use title elements, prominent visual titles, and headings to generate title links. Scope: Preserving meaningful titles and headings during template changes. Confidence: high · Verified: 2026-07-14 Google Search Central: Title links Evidence for this claim Google recommends monitoring Core Web Vitals and improving page experience without treating any single signal as a complete ranking guarantee. Scope: Google page-experience guidance. Confidence: high · Verified: 2026-07-14 Google Search Central: Page experience

Redesign or migration? Pick the right checklist first

These two words get used interchangeably, and it matters which one you’re actually doing:

• A redesign (this checklist) keeps the same domain and the same URLs. You’re changing the visual design, the templates, or the CMS theme — how the pages look and how they’re built — but a visitor’s browser bar shows the same address before and after.
• A migration changes the URLs, the domain, or the platform underneath. If /blog/my-post becomes /articles/my-post, or you move to a new domain, or you replatform in a way that restructures URLs, that’s a migration — and it needs the redirect-heavy website migration checklist, not this one.

The tripwire question: did any URL change? If yes — even one — stop and use the migration checklist. Redesigns and migrations often happen together (a rebrand that also moves domains, say), and it’s usually smarter to do them one at a time so you can tell which change caused what.

Why a “just a redesign” can still hurt rankings

Here’s the trap. Design and dev teams often treat SEO as out of scope for a redesign — “we’re not touching the URLs, so SEO is fine.” But your title tags, your headings, your navigation links, and your structured data all live inside the templates. Swap the templates and you can lose all of them while every URL stays put.

So the whole game in a redesign is: don’t let the new design silently throw away the on-page elements that were earning your rankings.

The short version

1. Write down what you have now. Before anything launches, save your current page titles, meta descriptions, headings (the H1 especially), and internal links — the easiest way is to run a crawl of your live site and export it. That’s your “before” picture.
2. Keep the important pages intact. A redesign is a tempting moment to “clean up” old content. Find your best pages first (the ones that get search traffic and the ones other sites link to) and protect them from being trimmed, merged, or reworded.
3. Preserve the on-page elements. The new design must keep the same titles, the same H1s, the same internal links and their wording, your schema, your canonical tags, and your image alt text.
4. Test the new design on a private staging site first. Compare the staging site to your live site page-by-page, and check it’s fast on mobile before it goes live — not after.
5. Don’t lazy-load your biggest image. New themes love to add “lazy loading” to every image, but the big hero image at the top of the page should load immediately, or your page-speed scores suffer.
6. Have an undo plan. Keep a full backup of the old site, and decide in advance what size of traffic drop would make you roll back.

Want the full audit version — the exact fields to compare between staging and live, the server-side rendering trap that breaks schema on modern frameworks, and a structured rollback threshold? Switch to the Advanced tab.

TL;DR — A redesign in scope here is a same-domain, same-URL change to templates, visual design, CMS theme, or on-page presentation — nothing else. If URLs, the domain, or the platform’s data structure change too, it’s a migration; use the website migration checklist instead (tripwire: did any URL change?). Redesigns feel lower-risk than migrations, but Mueller has said the opposite can be true — you’ll potentially see more fluctuation from a redesign than from a straight domain move, because templates silently control your titles, H1s, internal links, schema, and alt text. The checklist: (1) benchmark with a full pre-redesign crawl and flag your Top pages + Best by links; (2) preserve titles, meta descriptions, H1s/heading hierarchy, internal links + anchor text, schema, canonical tags, and alt text; (3) hold content parity — don’t let a “streamlined” redesign cut ranking content; (4) protect Core Web Vitals from heavier hero images, web fonts, and animations (never lazy-load the LCP image); (5) crawl-diff staging vs. live and confirm schema/titles render server-side, not client-side only; (6) launch with staging blocks removed, sitemap resubmitted, IndexNow pinged; (7) monitor with a pre-defined rollback threshold and a backup ready before launch.

Evidence for this claim Google can use title elements, prominent visual titles, and headings to generate title links. Scope: Preserving meaningful titles and headings during template changes. Confidence: high · Verified: 2026-07-14 Google Search Central: Title links Evidence for this claim Google recommends monitoring Core Web Vitals and improving page experience without treating any single signal as a complete ranking guarantee. Scope: Google page-experience guidance. Confidence: high · Verified: 2026-07-14 Google Search Central: Page experience

Redesign vs. migration — the scope line, drawn hard

This checklist covers exactly one thing: a redesign that keeps the same domain and the same URLs, and changes only the templates, visual design, CMS/theme, and on-page presentation. That’s it.

If the project also changes URLs, the domain, or the platform’s underlying data structure — even alongside the visual refresh — it stops being a same-URL redesign and becomes a migration, which needs a 301-redirect map and the website migration checklist’s whole apparatus. The tripwire is one question: did any URL change? If the answer is yes for even a handful of pages, treat those as a migration.

This distinction is a real advantage, because most redesign guides blur it — they’ll warn that “CMS migrations can break URL structures” in the middle of a “redesign” guide, which just confuses which checklist you actually need. Ahrefs’ own risk list even names “Broken redirects: redirects leading to non-existing or inaccessible pages” as a redesign risk — which is really a sign the redesign quietly became a migration. Catch that early and route it to the right process.

Why “just a redesign” is riskier than it sounds

The instinct is that a redesign is the safe cousin of a migration: the URLs don’t move, so what could go wrong? John Mueller’s answer is the load-bearing point of this whole article:

“You’ll potentially see more fluctuations from the redesign / revamp than from the domain name change. Moving things 1:1 from one domain to another is – for the most part – a non-issue.”

A 1:1 domain move is mechanical and reversible: same content, same structure, new address, redirects carry it. A redesign is not mechanical — it rewrites the actual pages. As Mueller put it, “Moving between CMSs, rebuilding a site, restructuring it: changing URLs, significantly changing the design, changing the internal linking, all of those things can significantly impact a site’s performance in search (and it can go up too, it’s not always down — you can do things to improve SEO after all).” The design and internal-linking changes are exactly what a redesign touches — and exactly what a domain move leaves alone.

Phase 1 — Pre-redesign benchmarking

You cannot verify preservation without a “before” to compare against. Build it first.

• Full crawl of the current live site. Export titles, meta descriptions, H1s and the full heading structure, canonical tags, hreflang, structured data, internal links and their anchor text, status codes, and indexability directives. This export is the baseline for the staging-vs-live diff later — it is the single most useful artifact in the whole project.
• Identify the pages you must not touch carelessly. Don’t rely on memory. Ahrefs’ own redesign guidance names the exact technique: “use two reports in Ahrefs’ Site Explorer: Top pages and Best by links.” Top pages sorts by organic traffic; Best by links sorts by external and internal links, which catches pages that don’t yet rank top-100 but carry real link equity a redesign shouldn’t quietly delete. Flag every one of these as protected.
• Snapshot the reference set. Keep the exported titles, metas, H1s, schema, and canonicals somewhere the redesign team can check their work against — not just in your head.

Phase 2 — What must be preserved (the core checklist)

Each of these has a verification method, not just a “remember to keep it.” Templates control all of them, so a template swap is where they die.

• Exact URLs. The tripwire again: if any URL changed, that page is a migration. In a true redesign every URL stays byte-for-byte identical.
• Title tags. Verify old vs. new via the crawl diff, not by eyeballing a few pages. A new template can prepend or append brand strings, truncate, or auto-generate titles differently across thousands of pages at once.
• Meta descriptions. Same — diff them. New templates frequently drop custom meta descriptions and fall back to an auto-generated excerpt.
• H1s and heading hierarchy. Watch for a new page builder that defaults the H1 to the raw page title instead of your curated H1, or demotes your old H1 to an H2. Diff the heading structure, don’t assume it survived.
• Internal link structure and anchor text. This is the most commonly broken element, because nav, breadcrumbs, footers, and related-content modules are entirely template-driven — and templates are what you’re replacing. A redesigned nav can drop the deep links that were passing authority to your best pages. Preserve descriptive anchor text too; Search Engine Land’s guide stresses “descriptive anchor text that tells both users and crawlers what they’ll find when they click.”
• Structured data / schema. Two checks, not one: that the schema still exists after the template swap, and that it renders server-side (see Phase 5’s JS trap). A timely accuracy note: don’t build the redesign’s schema plan around FAQPage rich results — Google retired that feature, and “This feature will no longer appear in Google Search starting May 7, 2026.” A template redesign is exactly the kind of event (alongside CMS updates and schema-plugin swaps) that warrants a full structured-data re-audit, since any one of them can silently break markup across hundreds of pages.
• Canonical tags. Confirm self-referencing canonicals survived the swap. A new template that hard-codes a canonical, or points every page at the homepage, is a classic redesign regression.
• Image alt text. Redesigns routinely re-crop, re-format, and re-host images through a new CDN or media library — and lose the alt attributes in the process. Google’s guidance is worth keeping in view here: “The most important attribute when it comes to providing more metadata for an image is the alt text (text that describes an image), which also improves accessibility for people who can’t see images on web pages, including users who use screen readers or have low-bandwidth connections.” Preserve the alt text you already had; don’t let a rushed “SEO-ify the new copy” pass stuff keywords into it — “Avoid filling alt attributes with keywords (also known as keyword stuffing) as it results in a negative user experience and may cause your site to be seen as spam.”

Phase 3 — Content parity

A redesign is a magnet for “let’s clean this up” — and that’s where rankings quietly bleed out. Ahrefs is direct: “Redesigns often include some kind of content pruning or simply arbitrary deleting of older content” — but “it’s crucial that you keep the pages that are already ranking high.”

The subtle version isn’t deleting whole pages — it’s a copywriting refresh that reworks titles, H1s, and body copy. “changing keywords can alter the page’s relevance for corresponding queries.” A product page ranking for “kick scooter for kids” can lose that ranking if a copy refresh edits that exact phrase out of the title, H1, or body — even though the URL and everything structural stayed the same. Use your Phase 1 Top pages / Best by links list as the “do not rewrite carelessly” list.

The rule of thumb from the same source: “expanding or reducing content should be done with the intent to serve user needs better, provide more value, or clarify existing information” — not just to look cleaner or more modern. And the same care applies to links: “changing/cutting a few internal links shouldn’t do any harm, but you need to be tactical about it.”

Phase 4 — Core Web Vitals impact of the new design

New themes routinely introduce heavier assets. Ahrefs’ guidance: “don’t overuse heavy graphics, animations, and video. Again, make sure to pre-test the staging site for CWV,” and “Testing your site for Core Web Vitals (CWV) and mobile friendliness before it goes live is the best way to ensure that your new site will comply with Google’s page experience guidelines.” The three redesign-specific offenders:

• Hero images (LCP). A big new hero is usually the Largest Contentful Paint element. Serve it in a modern format, compress it, and hint its priority with fetchpriority="high". Above all, never lazy-load it. New themes and page builders love to apply blanket loading="lazy" to every image — including the hero — and Google is blunt about the cost: “Never lazy-load your LCP image, as that will always lead to unnecessary resource load delay.”
• Web fonts. A rebrand’s new typography often adds render-blocking font loads. Preload the critical fonts and set font-display so text stays visible during load — per web.dev, “If you set a font-display value of anything other than auto or block, then text will always be visible during load.”
• Animations and heavy JS. Scroll effects, sliders, and animation libraries add main-thread work that hurts responsiveness. Test the staging build for CWV before launch — see the web performance cluster for the metrics and fixes.

Phase 5 — Staging audit: crawl staging vs. live and diff

This is the single most mechanically useful phase. A visual QA pass will not catch a stripped meta description, a broken canonical, or schema that only renders after JavaScript runs. A structured crawl diff will.

• Crawl the staging site and diff it against the Phase 1 baseline. Compare, field by field: titles, meta descriptions, H1s and heading structure, canonical tags, hreflang, structured data, internal link counts and anchor text, status codes, and indexability directives (meta robots and robots.txt). Every unexpected difference is a bug to fix before launch.
• The JS-rendering trap. Redesigns built on a new frontend framework (React, Vue, Next.js and friends) commonly render titles and schema client-side only. Search Engine Land names this exact failure: “Ensure schema and meta tags render server-side, not just client-side. If Google’s crawler sees empty title tags because JavaScript hasn’t loaded yet, you’re in trouble.” Verify with the URL Inspection tool’s rendered HTML or the Rich Results Test — not just view-source — so you’re seeing what the crawler actually gets.
• Keep staging out of the index — with noindex, not a robots.txt block. Google’s site move without URL changes guidance applies to a redesign staging site: “Allow for public testing with a temporary hostname for your new infrastructure” and, to keep it out of the index, “add the noindex robots rule to the HTML or the HTTP headers of your pages.” That doc does not recommend a robots.txt disallow for this — and for good reason: Google’s own indexing guidance warns that “for the noindex rule to be effective, the page or resource must not be blocked by a robots.txt file… If the page is blocked by a robots.txt file… the crawler will never see the noindex rule, and the page can still appear in search results, for example if other pages link to it.” Combining noindex and a robots.txt disallow on the same staging site is the trap, not the safeguard — it silently disables the noindex you think is protecting you. Use noindex alone to keep staging out of the index; if you also want to stop it from being crawled or found at all, put it behind HTTP authentication or an IP allowlist instead of robots.txt. Remove the noindex (and any HTTP auth) at launch — a staging block left live is one of the most common causes of a post-launch traffic collapse.

Phase 6 — Launch day

• Remove every staging block. Double-check no noindex, no robots.txt Disallow: /, no HTTP auth left on the production site.
• Resubmit your sitemap in Google Search Console so recrawling of the changed templates starts promptly.
• Bing: submit changed URLs via IndexNow. Bing’s own IndexNow FAQ is narrower than some redesign guides suggest — it says to publish only URLs that actually changed, not a blanket historical resubmission. A same-URL redesign does change the on-page content of essentially every URL (new titles, headings, markup), so submitting your full URL list is a defensible read of that rule, not a documented Bing “redesign trigger” — treat it as reasonable practice, not a cited exception. Spot-check with Bing’s URL Inspection tool that Bing sees the new content, and Bing Webmaster Tools’ recommendations/SEO reports as a lightweight Bing-side technical check.
• If the redesign also brought new hosting or a CDN: lower DNS TTL ahead of the switch, and check firewall / DoS protection isn’t blocking crawlers — Google’s caution transfers directly: “Check your firewall configuration or denial of service (DoS) protection. Make sure it does not block Googlebot’s ability to reach the DNS or the hosting provider’s servers.” Expect a temporary crawl-rate dip right after launch.
• Bing’s own migration guidance on log monitoring generalizes to any large content change: “Log files are critical…and must be monitored on a daily basis once the actual website migration has been initiated for a period of at least three months.”

Phase 7 — Post-launch monitoring and rollback

Don’t improvise this during a panic. Decide the plan before you launch.

• Crawl-diff the live site against the Phase 1 baseline immediately after launch — the same comparison as staging, now against what actually shipped. When a page drops, this diff tells you which on-page element regressed instead of leaving you guessing.
• Watch GSC — Page Indexing (Coverage) for new exclusions, and Performance filtered to your Phase 1 top pages, which are the ones a regression will hurt most and fastest.
• Define a rollback threshold in advance. Competitors say “do some SEO debugging,” which is useless mid-crisis. Instead: pick a specific drop (traffic or rankings on the protected pages) sustained over a specific window that flips you from “wait and diagnose” to “revert now.” A clear, sustained drop isolated by the crawl diff to a specific broken element is a rollback trigger; day-one noise is not.
• Keep a full backup and a rollback path ready before launch, not after. Ahrefs’ framing: “A backup ensures you can restore the original site if anything goes wrong.” A hosting-level snapshot or a plugin like UpdraftPlus for WordPress does the job — the point is that the safety net exists before you need it.

For the broader migration-type taxonomy (domain moves, HTTPS, replatforms, and the rest), the Site Migrations hub is the companion to this checklist — and if any URLs are changing, its website migration checklist is the one you actually want.

AI summary

A condensed take on the Advanced version:

• Scope: a redesign here is a same-domain, same-URL change to templates, visual design, CMS theme, or on-page presentation. Tripwire — did any URL change? If yes, it’s a migration; use the migration checklist instead.
• Why it’s not “safe”: Mueller has said you’ll potentially see more fluctuation from a redesign than from a straight domain move, because templates silently control titles, H1s, internal links, schema, and alt text.
• Phase 1 — Benchmark: full pre-redesign crawl (titles, metas, H1s, canonicals, hreflang, schema, internal links, status/indexability) as the diff baseline; flag Top pages + Best by links as protected.
• Phase 2 — Preserve: exact URLs, title tags, meta descriptions, H1s/heading hierarchy, internal links + anchor text, structured data, canonical tags, and image alt text — each verified via the crawl diff, not eyeballing.
• Phase 3 — Content parity: don’t let a “streamlined” redesign cut ranking content; even editing a target phrase out of a title/H1 can cost that ranking.
• Phase 4 — Core Web Vitals: new hero images (never lazy-load the LCP image; use fetchpriority="high"), new web fonts (font-display, preload), and animations/heavy JS — pre-test staging for CWV.
• Phase 5 — Staging diff: crawl staging vs. the baseline field-by-field; confirm schema/titles render server-side, not client-side only (the JS-framework trap); keep staging noindexed via HTML/HTTP header (not a robots.txt block, which would hide the noindex from Google entirely) and remove it at launch.
• Phase 6 — Launch: remove staging blocks, resubmit the sitemap, submit changed URLs via IndexNow for Bing; if new host/CDN, lower DNS TTL and don’t let firewall/DoS block crawlers.
• Phase 7 — Monitor & rollback: crawl-diff live vs. baseline, watch GSC Page Indexing
  • Performance on the protected pages, and set a rollback threshold and a backup before launch, not after.
• Note: Google retired FAQPage rich results (gone from Search as of May 7, 2026) — don’t build the redesign’s schema plan around them.

Official documentation

Primary-source documentation relevant to a same-URL redesign.

Google

• Do You Need an SEO? — Google’s framing that a redesign is a great time to involve an SEO, the earlier the better.
• Site move without URL changes — the closest official doc to a same-URL redesign: temporary-hostname staging, DNS, firewall/DoS caution, and crawl-rate expectations.
• General Structured Data Guidelines — the schema-preservation rules to re-check after the template swap.
• Search Central changelog — FAQ rich result removal — Google removed the dedicated FAQPage doc itself in June 2026 after the rich result stopped appearing in May 2026; don’t rebuild a redesign’s schema plan around it (or link to the old doc page, which now 301s here).
• Google Images / Image SEO best practices — alt-text guidance, directly relevant since redesigns re-crop and re-host images.
• web.dev — Optimize Largest Contentful Paint — hero-image and web-font CWV guidance for a new theme, including “never lazy-load your LCP image.”

Bing / Microsoft

• Website Migration with Bing — server-log monitoring principle that generalizes to any large content change (verify current Bing tooling; the old Site Move Tool no longer exists in the console).
• IndexNow — Getting Started — submit changed URLs quickly after a site-wide content change.
• Bing URL Inspection tool — spot-check that Bing sees the new templates and content post-launch.
• Bing Webmaster Tools — Recommendations / SEO Reports — a lightweight Bing-side technical check, distinct from GSC’s Page Indexing report.

Quotes from the source

On-the-record statements, each with its source. Deep links jump to the quoted passage where the source page supports it.

John Mueller, Google — redesign risk vs. a domain move (via Search Engine Journal)

• “You’ll potentially see more fluctuations from the redesign / revamp than from the domain name change. Moving things 1:1 from one domain to another is – for the most part – a non-issue.” Read the coverage
• “Moving between CMSs, rebuilding a site, restructuring it: changing URLs, significantly changing the design, changing the internal linking, all of those things can significantly impact a site’s performance in search (and it can go up too, it’s not always down — you can do things to improve SEO after all).” Read the coverage
• On staggering a redesign and a move so you can diagnose what caused what: “If you need to do both, I’d try to split it time-wise so that you can recognize any negative effects in each part, and take action to improve them. If you do everything at once, you’ll never know what to fix… Keep things controllable & trackable.” Read the coverage

Google — hiring an SEO for a redesign

• “a great time to hire is when you’re considering a site redesign (the earlier, the better), or planning to launch a new site.” — and “That way, you and your SEO can ensure that your site is designed to be search engine-friendly from the bottom up.” Jump to quote

Google — image alt text (preserve it through the redesign)

• “The most important attribute when it comes to providing more metadata for an image is the alt text (text that describes an image), which also improves accessibility for people who can’t see images on web pages, including users who use screen readers or have low-bandwidth connections.” Source
• “Avoid filling alt attributes with keywords (also known as keyword stuffing) as it results in a negative user experience and may cause your site to be seen as spam.” Source

Google — FAQPage deprecation (the dedicated doc page has since been removed — quoted from the changelog)

• “Deprecating the FAQ rich result feature. This feature will no longer appear in Google Search starting May 7, 2026.” Google removed the standalone documentation page itself on June 15, 2026, once the feature was gone: “The FAQ rich result feature is no longer shown in Google Search results, as announced in the changelog entry in May 2026.” Source

Google (web.dev) — LCP and the new theme

• “Never lazy-load your LCP image, as that will always lead to unnecessary resource load delay.” Source
• “If you set a font-display value of anything other than auto or block, then text will always be visible during load.” Source

Google — site move without URL changes (staging & hosting)

• “Allow for public testing with a temporary hostname for your new infrastructure.” Source
• “Check your firewall configuration or denial of service (DoS) protection. Make sure it does not block Googlebot’s ability to reach the DNS or the hosting provider’s servers.” Jump to quote

Ahrefs — content parity and backups (Mateusz Makosiewicz, not Patrick Stox)

• “Redesigns often include some kind of content pruning or simply arbitrary deleting of older content.” — followed by: “it’s crucial that you keep the pages that are already ranking high.” Source
• “use two reports in Ahrefs’ Site Explorer: Top pages and Best by links.” Source
• “A backup ensures you can restore the original site if anything goes wrong.” Source

Search Engine Land — the server-side rendering trap (Insight Engine byline, ed. Anna Sonnenberg)

• “Ensure schema and meta tags render server-side, not just client-side. If Google’s crawler sees empty title tags because JavaScript hasn’t loaded yet, you’re in trouble.” Source

The website redesign SEO checklist

Same-URL redesigns only. If any URL changed, stop — use the migration checklist.

Phase 0 — Scope check

• Confirmed no URLs are changing (tripwire: if any did, this is a migration).
• Confirmed the domain and platform data structure are staying the same.
• If a redesign and a move are happening, planned to split them time-wise.

Phase 1 — Pre-redesign benchmark

• Ran a full crawl of the live site and exported titles, meta descriptions, H1s + heading structure, canonical tags, hreflang, schema, internal links + anchors, status codes, and indexability directives.
• Pulled Top pages (by organic traffic) and Best by links (by link count) as the protected “do not touch carelessly” list.
• Saved a reference set of the old on-page elements for the redesign team to check against.

Phase 2 — Preserve on-page elements (verify via crawl diff)

• Title tags identical (no new brand prefixes/suffixes, no auto-generation drift).
• Meta descriptions preserved (not replaced by auto-excerpts).
• H1s and heading hierarchy intact (page builder didn’t re-derive the H1).
• Internal links + anchor text preserved in nav, breadcrumbs, footer, and related modules.
• Structured data present and rendered server-side (not schema plans built on the retired FAQPage feature).
• Canonical tags still self-referencing (not pointed at the homepage).
• Image alt text carried over through re-crops / re-hosting / new CDN.

Phase 3 — Content parity

• Protected pages not trimmed, merged, or cut without deliberate review.
• No target phrases removed from titles/H1s/body during a copy refresh.
• Content changes serve user needs, not just a cleaner look.

Phase 4 — Core Web Vitals of the new theme

• Hero / LCP image NOT lazy-loaded; modern format, compressed, fetchpriority="high".
• Web fonts preloaded with a sensible font-display.
• Animations / heavy JS don’t blow past CWV — pre-tested on staging.

Phase 5 — Staging audit

• Crawled staging and diffed it field-by-field against the Phase 1 baseline.
• Confirmed schema and titles render server-side (URL Inspection rendered HTML / Rich Results Test, not view-source).
• Staging is noindexed (HTML meta or HTTP header) — not additionally blocked by robots.txt, which would stop Google from ever seeing the noindex tag. Access-restricted via HTTP auth or an IP allowlist if it needs to stay unreachable, and the noindex/auth is removed at launch.

Phase 6 — Launch day

• All staging blocks removed (no stray noindex, robots disallow, or HTTP auth).
• Sitemap resubmitted in Search Console.
• IndexNow pinged for Bing; spot-checked with Bing URL Inspection.
• If new host/CDN: DNS TTL lowered, firewall/DoS not blocking crawlers.

Phase 7 — Post-launch monitoring & rollback

• Crawl-diffed the live site against the Phase 1 baseline.
• Watching GSC Page Indexing + Performance on the protected pages.
• Rollback threshold defined before launch (drop % over a set window).
• Full backup / rollback path ready before launch, not improvised after.

Redesign myths and mistakes to avoid

The failure modes that quietly cost rankings during a same-URL redesign:

“A redesign is lower-risk than a migration since the URLs don’t change.” Mueller: “You’ll potentially see more fluctuations from the redesign / revamp than from the domain name change.” A redesign can be riskier precisely because on-page elements get silently rewritten by new templates — a 1:1 domain move doesn’t touch them.

“As long as the URL stays the same, SEO is fine.” Templates control your title tags, H1s, internal links, schema, and alt text. A same-URL redesign can lose every one of those while the URL itself never changes.

“A visual QA pass is enough — we don’t need a staging-vs-live crawl diff.” Visual QA doesn’t catch a stripped meta description, a broken canonical, or schema that only renders after JavaScript. A structured crawl diff is the only reliable check.

“Our new framework renders everything, so schema is fine.” If the new frontend renders titles and schema client-side only, “Google’s crawler sees empty title tags because JavaScript hasn’t loaded yet.” Verify with rendered HTML, not view-source.

“Cutting some old content to make the site cleaner is basically harmless.” “Redesigns often include some kind of content pruning” — but “it’s crucial that you keep the pages that are already ranking high.” Even editing a ranking phrase out of a title or H1 during a copy refresh can cost that ranking.

“The new theme’s built-in lazy-loading is always a performance win.” “Never lazy-load your LCP image, as that will always lead to unnecessary resource load delay.” Blanket lazy-loading applied to the hero by a new theme directly hurts LCP.

“Preserve the FAQ schema for the rich results.” Google retired the FAQPage rich result — it “will no longer appear in Google Search starting May 7, 2026.” Plan the redesign’s schema around currently supported types.

“If something breaks we’ll obviously notice and just fix it.” Without a pre-defined rollback threshold and a pre/post crawl diff, teams can’t pinpoint which element regressed, and they wait too long to decide whether a drop is normal fluctuation or a real regression. Decide the threshold before launch.

Prove the redesign preserved search-visible output

Staging-to-baseline crawl diff

• Test to run: Crawl staging with JavaScript rendering configured the same way as the Phase 1 live baseline, then diff URLs, status, titles, meta descriptions, H1s/headings, canonicals, hreflang, schema, robots directives, internal links, and anchor text.
• Expected result: Every URL remains identical, and every unexpected field-level difference has an approved product/content reason rather than a template regression.
• Failure interpretation: Repeated differences across one page type mean the new template or CMS mapping stripped or rewrote a search-visible element at scale.
• Monitoring window: Before launch on the release candidate; rerun after every template-level correction until the diff is approved.
• Rollback trigger: Do not launch while protected pages have unexplained URL, indexability, canonical, content, or internal-link regressions.

Rendered metadata and structured-data test

• Test to run: Inspect representative staging templates with rendered HTML in URL Inspection or the Rich Results Test, not only view-source.
• Expected result: Titles, canonicals, robots directives, and applicable structured data are present in crawler-visible rendered output and match the crawl-diff baseline.
• Failure interpretation: Values that appear only after client-side interaction—or disappear from rendered output—indicate a JavaScript rendering or hydration regression.
• Monitoring window: Before launch, then immediately on representative live URLs after deployment.
• Rollback trigger: Critical metadata, canonicals, directives, or schema are absent across a protected template and cannot be restored safely with a prompt fix.

Production parity and rollback-tripwire test

• Test to run: Crawl production immediately after launch and repeat the approved staging/baseline diff; monitor the preselected protected pages in Search Console and analytics against the rollback rule agreed before launch.
• Expected result: Production matches the approved release candidate, staging blocks are gone, protected pages remain indexable, and observed performance stays within the project’s pre-agreed tolerance after normal short-term noise.
• Failure interpretation: A production-only diff identifies a deployment defect; sustained performance loss isolated to a broken field identifies the likely cause.
• Monitoring window: Immediate technical verification, followed by the project’s defined observation window for the protected page set.
• Rollback trigger: The pre-agreed threshold is met and the crawl diff ties it to a reversible redesign defect; day-one fluctuation without a diagnosed regression is not sufficient by itself.

Test yourself: Website Redesign SEO

Five quick questions on running a same-URL redesign without losing rankings. Pick an answer for each, then check.

Resources worth your time

My related writing

• Site Migrations — the hub covering all seven migration types, the universal process, and per-type checklists (redesign is Type 5).
• Website Migration Checklist — the checklist to use instead of this one if any URLs, the domain, or the platform are changing.
• Core Web Vitals — LCP, INP, CLS, thresholds, and the fixes for a heavier new theme.
• Largest Contentful Paint — the LCP deep dive, including the hero-image lazy-loading trap.
• The Beginner’s Guide to Technical SEO — where redesigns fit in the wider technical picture.

Official

• Google — Site move without URL changes.
• Google — Do You Need an SEO?.
• web.dev — Optimize Largest Contentful Paint.
• Google — Search Central changelog: FAQ rich result removal.

From around the industry

• How to Avoid Ruining SEO During a Website Redesign (Ahrefs, Mateusz Makosiewicz) — the content-parity and backup guidance, including the Top pages + Best by links technique.
• Google Advises On How A Redesign Can Impact SEO (Search Engine Journal) — Mueller on why a redesign can fluctuate more than a domain move, and on staggering changes.
• Site redesign checklist to preserve SEO & improve visibility (Search Engine Land) — the server-side rendering trap for new frontend frameworks.
• r/TechSEO — the community for redesign crawl/render/parity debugging.

Website Redesign SEO Checklist

A website redesign SEO checklist is the step-by-step task list for refreshing a site's visual design, templates, or CMS theme while keeping the same URLs — without silently losing the on-page and technical SEO elements (titles, meta descriptions, headings, internal links, structured data, canonical tags, alt text) that were earning rankings under the old design.

Related: Site Migration, Canonical Tag, Alt Text, CLS

Website Redesign SEO Checklist

A website redesign SEO checklist is the task list used to change how a site looks and how it’s built — its visual design, templates, or CMS theme — while keeping the same domain and the same URLs, without stripping out the on-page elements that were quietly earning rankings under the old design. It’s the same-URL sibling of a site migration checklist: a migration changes URLs, the domain, or the platform and leans on 301 redirects; a redesign changes the presentation layer and leans on preservation of titles, meta descriptions, H1s and heading hierarchy, internal links and anchor text, structured data, canonical tags, and image alt text.

The reason a dedicated checklist exists is that a redesign feels safer than it is. Because the URLs don’t move, teams often assume SEO is out of scope. But those on-page elements all live inside the templates, so swapping the templates can drop every one of them while each URL stays identical. John Mueller has said you’ll potentially see more fluctuation from a redesign than from a straight domain move for exactly this reason.

In practice the checklist runs in phases: benchmark the current site with a full crawl and flag the pages that must not be touched carelessly; verify each preserved element against that baseline via a staging-vs-live crawl diff (including a check that schema and titles render server-side, not client-side only); hold content parity so a “streamlined” redesign doesn’t cut ranking content; keep the new theme’s hero images, web fonts, and animations from wrecking Core Web Vitals; and launch with a pre-defined rollback threshold and a backup ready, not improvised after a traffic drop.

Related: Site Migration, Canonical Tag, Alt Text, CLS

Changelog