Website redesign SEO checklist: how to relaunch without losing your rankings

The central rule of a safe redesign is simple: inventory what already works before you replace it.

Your current website is more than its design. It is a collection of known URLs, linked pages, search results and conversion paths. A redesign can improve all of that—or erase parts of it without producing an obvious visual error. The project therefore needs two plans: one for the site you want and one for transferring the value you already have.

Does a website redesign affect SEO?

It can, but “redesign” covers different projects. Replacing layouts while keeping the same URLs and content is not the same operation as changing a domain, CMS, host, navigation and copy at once.

Google describes URL changes as a site move and warns that visibility can fluctuate during recrawling and reindexing. It also states that 301 and other permanent redirects do not cause a loss of PageRank. The danger is incomplete implementation: pages disappear, redirects misfire, links break, or staging controls reach production. See Google’s site-move guidance.

Migration type	What changes	Main SEO risk
Visual redesign	Layout, styling, components and possibly copy; URLs stay the same	Important content, headings, links or metadata disappear inside the new design
CMS move	Publishing system, templates and generated HTML	The new CMS changes URLs, canonicals, metadata, structured data or crawlability by default
Host move	Servers, CDN, DNS or hosting provider; visible URLs stay the same	Downtime, slow responses, blocked crawlers, SSL errors or shutting down the old host too early
URL change	Slugs, folders or information architecture	Old URLs return errors or redirect to weak, irrelevant or chained destinations
Domain change	Every public URL moves to a new domain or subdomain	Search engines must discover the new host, process redirects and transfer signals page by page

A project can include several rows. A new design on a new CMS and domain is a compound migration. Avoid simultaneous changes the business does not need.

How to use this website redesign SEO checklist

Use it as a website migration SEO checklist whenever the CMS, host, URLs or domain changes. If your goal is to redesign a website without losing SEO value, start before anyone removes a page or changes a URL.

The checkboxes use two kinds of advice:

Google guidance refers to controls Google documents directly, such as permanent redirects, self-referencing canonicals, updated internal links, sitemaps and Search Console monitoring.
Implementation practice covers operational safeguards such as baseline exports, launch gates, form receipts and a rollback plan.

Google can explain how its systems interpret a move; your team still has to prove that the site, analytics and lead flow work.

Before design: preserve the evidence

The safest time to make SEO decisions is before a new sitemap or layout has acquired momentum.

Export search baselines. Save Search Console performance by page and query: clicks, impressions, click-through rate and average position. Record the date range and seasonal context.
Export business baselines. Record organic sessions, landing pages, form submissions, calls, bookings, purchases and other meaningful conversions. A ranking is useful only if the page produces the right kind of visit.
Create a complete URL inventory. Combine a public-site crawl with the XML sitemap, CMS export, Search Console and analytics landing pages, campaign URLs, backlinks and server logs where available.
Mark the pages that already perform. Flag URLs with organic traffic, rankings, conversions, external links, local visibility or essential customer information. Protecting these pages should be a design requirement, not a cleanup task.
Give every current URL a decision. Keep, improve, merge, redirect or intentionally remove it. Do not let pages vanish merely because they were absent from a wireframe.
Decide which changes are necessary. If a URL is clear, relevant and working, keeping it avoids an unnecessary migration step. Google’s SEO Starter Guide supports logical site organization and descriptive URLs, but it does not say every redesign needs a new URL structure.
Write success and rollback criteria. Define the launch blockers, rollback trigger, decision-maker and old-site assets that must remain available.

If the current site is not appearing in search at all, diagnose that before treating the redesign as the cure. Start with this Google visibility checklist.

Before build: turn decisions into specifications

Put redirects, canonicals and analytics events into the build plan, not just the design files.

Freeze the approved URL list. Assign one production URL to every new page and one owner to approve later changes.
Build an old-to-new URL map. Each useful old URL needs the closest relevant new destination. Google advises against sending many unrelated pages to the new homepage because those redirects can be treated as soft 404s.

Old URL	New URL	Action	Reason
`/air-conditioning-repair`	`/services/ac-repair`	Permanent redirect	Same service, clearer structure
`/blog/ac-maintenance-tips`	`/guides/ac-maintenance`	Permanent redirect	Updated version of the same topic
`/2019-coupon`	—	Return 410 or 404	Expired with no relevant replacement

Specify server-side permanent redirects. Google recommends permanent HTTP redirects such as 301 or 308 when a URL has moved permanently. Point each old URL directly to its final destination and avoid chains. Do not rely on a canonical tag as a substitute for a required redirect.
Create a content parity sheet. For every priority page, carry forward its purpose, essential copy, title, description, main heading, useful images and alt text, FAQs, downloads and calls to action. Improve weak content deliberately; do not shorten a proven page to neaten the layout.
Specify canonical URLs. Every indexable new page should normally name its own preferred production URL. Google recommends self-referencing canonicals and consistent signals across canonical tags, internal links and sitemaps in its canonicalization documentation.
Preserve accurate structured data. Transfer relevant markup, update URLs and values, and test the rendered output. It must describe visible content; parity does not mean copying stale markup.
Plan internal links. Navigation, breadcrumbs, body copy and related modules should point directly to final URLs. Google says links aid discovery and context; internal clicks should not pass through redirects.
Define analytics events before templates are finished. List the submissions, calls, emails, bookings, purchases and downloads the site must measure. Keep existing event names where continuity matters, or document their replacements.
Protect staging properly. Prefer restricted access. If noindex is used, create a launch task to remove it. A robots.txt disallow does not reliably keep a URL out of search; Google explains why in its robots.txt guidance.

This work belongs inside the development scope, alongside templates and integrations, and inside the SEO scope, where search performance and indexing are checked.

Pre-launch: test the site that will actually ship

Do not approve launch from screenshots. Crawl and use the built site.

Launch day: control the change

Take a final backup and crawl. Save the last public URL inventory, database or content export, redirect file and key configuration before switching.
Launch during a staffed window. The developer, decision-maker and analytics owner should be able to respond.
Switch DNS and confirm HTTPS. Check domain variants, SSL, mixed content and critical assets from more than one network or device. For host-only moves, Google recommends keeping both infrastructures available until the old host no longer serves users or Googlebot in its hosting-change guide.
Activate and sample redirects. Test top landing pages, deep URLs, PDFs, case variants and meaningful query strings.
Remove staging controls. Confirm there is no global noindex, crawler block, password wall or firewall rule preventing public access.
Confirm canonicals, robots and sitemap on production. Fetch the live output. Do not assume a passing staging test survived deployment.
Submit the new sitemap in Search Console. If the domain or subdomain changed, use Change of Address after redirects and verification are in place. The tool is not for path changes, HTTP-to-HTTPS moves, or www changes on the same domain.
Verify analytics in real time. Visit the live site, complete the core journeys and confirm page views and conversion events reach the correct property. Google recommends the Realtime report to confirm data collection in its Analytics setup documentation.
Check every revenue path. Send a form, make a test booking or order, click the phone number on mobile and verify receipt.

First 72 hours: look for breakage before trends

Three days is too soon to judge rankings, but the right time to catch failures.

Crawl production and the old URL list. Confirm status codes, destinations, redirect depth, internal links, canonicals and orphan pages.
Inspect priority URLs in Search Console. The URL Inspection tool shows indexed information and can test a live page. Check crawl access, indexing eligibility and selected canonicals.
Watch server and CDN logs. Look for 404, 5xx, timeouts, blocked Googlebot and unexpected load.
Review analytics by landing page and channel. Confirm traffic reaches expected URLs and conversions still fire. Separate tracking failure from real change.
Check leads manually. Reconfirm forms, calls, bookings, payments and CRM routing. This is deliberately repetitive because missed enquiries cost money immediately.
Update controlled links. Change campaigns, email templates, profiles and directory listings to final URLs. Update important external links where practical.
Keep rollback assets available. Do not cancel old hosting or delete the old site because the homepage appears to work.

First 4–8 weeks: monitor the migration page by page

Compare against the baseline weekly. Review Search Console performance, landing-page sessions, rankings and conversions. Segment by page type and old-to-new mapping, not only sitewide totals.
Review the Page Indexing report and sitemap processing. Investigate unexpected increases in not-indexed pages, soft 404s, server errors, duplicate canonicals or blocked resources.
Follow unresolved old URLs. Use crawls, logs and Search Console to find misses. Add a relevant redirect when one exists; let genuinely removed pages return 404 or 410.
Check content and internal-link parity. If one page loses visibility, compare its old and new copy, intent, headings, title, links and rendered content before blaming the whole migration.
Review conversion quality. A relaunch can preserve visits while weakening enquiries through new forms, calls to action or navigation. Compare completed outcomes, not just sessions.
Review field performance when data appears. Real-user Core Web Vitals are more useful than one launch-day lab score, but field reports take time to populate.
Keep permanent redirects in place. Google recommends keeping them for as long as possible, generally at least one year, and notes that users may benefit from keeping them indefinitely. Do not remove them when the launch project closes.

Temporary movement is possible while Google processes changed URLs page by page. Google says small and medium sites may take a few weeks for most pages to move, and larger sites longer—but that is not a recovery guarantee. Judge performance against the baseline, seasonality and scope.

Five mistakes that look harmless until launch

Redirecting every old page to the homepage. It is quick to configure, but it removes relevance and may produce soft 404s. Map pages to the closest real replacement.
Leaving one global noindex setting on. The site looks perfect to humans while asking search engines not to include it.
Publishing mixed signals. A new URL that redirects correctly but names the old or staging URL as canonical—and appears beside different URLs in the sitemap—forces search engines to interpret a contradiction.
Replacing useful copy with a short design block. The new page may look cleaner while no longer answering the query that earned its traffic.
Checking that analytics exists, not that it works. A tag in the source does not prove the right property receives page views, conversions fire once, or a form reaches the business.

What to require from a redesign vendor

“SEO included” is not evidence. Before final approval, ask the vendor to provide:

The old and new URL inventories, with a keep, redirect, merge or remove decision for every discovered old URL.
The redirect map and tests showing status, final destination and chain length.
Before-and-after crawl reports, plus a list of defects found and resolved.
Template checks for metadata, canonicals, robots directives, links, sitemap and structured data.
Search Console ownership confirmation, sitemap submission evidence and Change of Address confirmation when a domain changed.
Analytics proof from the correct property, including real-time visits and successful test events.
End-to-end proof that forms, calls, bookings or purchases reached their destination.
Mobile and desktop performance results for representative templates, with limitations recorded.
A launch log naming who checked DNS, SSL, redirects, indexing, analytics and lead flow.
A rollback plan and a post-launch report covering the first 72 hours and agreed monitoring period.

The evidence need not be a hundred-page audit. It should let another competent person reproduce the checks. If a vendor cannot show what was tested, you are accepting the migration on trust.

CMT Web treats migration as part of the build: redirect mapping, DNS, SSL, analytics and Search Console are handled at launch, and the old site remains reachable until the replacement is verified. You can see how project scope affects pricing. If you already have a redesign underway and want a second set of eyes on the migration plan, ask for a migration review. We will tell you what is covered, what is missing and what needs to be proved before launch.