Website redesign SEO checklist 2026: how to keep your rankings when you rebuild

Every year, thousands of business owners approve a new website design, go through weeks of revisions and development, launch with genuine excitement — and then watch their organic traffic collapse in the weeks that follow. The website looks beautiful. The team is proud of it. And yet, somewhere between the old site and the new one, something broke that Google cannot forgive.

What broke is almost always predictable, almost always preventable, and almost always overlooked because the project team was focused on design and functionality rather than the invisible infrastructure that search engines depend on. URL structures changed without redirects. Page titles were rewritten without considering the keywords they ranked for. Schema markup that existed on the old site was not transferred. The sitemap was not updated. The robots.txt blocked indexing during staging and was never changed.

This checklist is organized into three phases — before launch, during launch, and after launch — because the work is different in each phase and the sequence matters. Do not skip to the "after launch" section on the assumption that you can fix things retroactively. With SEO migrations, prevention is orders of magnitude cheaper than recovery.

Phase 1: Before launch (the most important phase)

The most valuable SEO work in a redesign happens weeks or months before the new site goes live. If you do this phase well, the launch itself becomes almost routine.

Step 1: Audit the current site before you touch anything

Before a single page of the new design is approved, crawl the existing site and document it completely. You need to know what you are protecting.

Run a full crawl of your current site. Use Screaming Frog (free up to 500 URLs) or any similar crawler. Export the complete list of URLs, their page titles, H1 headings, meta descriptions, canonical tags, internal links, and status codes.

Export your top-performing pages from Google Search Console. In the Performance report, sort by Impressions and then by Clicks. Make note of every page that receives meaningful organic traffic. These are your "protected assets" — pages that must be preserved or redirected with extraordinary care.

Export your backlinks. Using Ahrefs Webmaster Tools (free), Semrush, or Google Search Console's Links report, collect the list of URLs on your site that have backlinks pointing to them. These URLs are particularly important — a broken link pointing to your homepage matters less than a broken link pointing to a product page that has twenty backlinks and ranks for a commercial keyword.

The deliverable from this step is a master spreadsheet with: every URL on the current site, its traffic and ranking data where available, its backlink count, and a status column where you will track what happens to it in the redesign.

Step 2: Map old URLs to new URLs

If the redesign involves any URL structure changes — and most do — you need a redirect map before development begins, not after.

A redirect map is simply a spreadsheet with two columns:

Old URL: the current URL as it exists today
New URL: the corresponding URL on the new site (or the closest equivalent if the page is being consolidated or removed)

For pages that are staying essentially the same (content preserved, perhaps with a different path), the redirect is a permanent 301 from old URL to new URL.

For pages that are being removed entirely, identify the most thematically relevant remaining page and redirect there — or redirect to the parent category, or to the homepage as a last resort (though a homepage redirect is a weak signal and should be used sparingly).

Critical rule: never allow your high-traffic, high-backlink pages to return a 404 error. The SEO and UX cost of a broken link on a page that earns meaningful traffic is significant and takes months to recover from.

Also critical: avoid redirect chains. If Page A redirects to Page B, which redirects to Page C, Google and users lose value at each hop. On the new site, every redirect should point directly to the final destination — even if that means updating redirect tables that previously had multiple hops.

Step 3: Preserve your page titles and meta descriptions (or improve them deliberately)

One of the most common and most damaging mistakes in redesigns is allowing a designer or developer to rewrite page titles and meta descriptions based on aesthetics rather than SEO data.

Before the new site is built, document every page title and meta description from the current site. Then, for each high-performing page:

If the current title contains keywords the page ranks well for, preserve those keywords in the new title — you can rephrase for clarity or brand voice, but do not eliminate the target term
If the current meta description has a good CTR (you can see this in Search Console), preserve its structure and key message
For pages that are performing poorly, the redesign is an opportunity to deliberately improve titles and descriptions — but do this intentionally, not by accident

Step 4: Document all existing schema markup

Schema markup — structured data that helps search engines understand your content — is frequently lost in redesigns because it lives in the page templates or a plugin, and when the templates are rebuilt, the markup is not carried over.

Run your current site through Google's Rich Results Test (search the current URL to test it) and document every type of schema that exists:

LocalBusiness schema (critical for local businesses)
Product schema (for ecommerce sites)
FAQ schema (if you have FAQ sections)
Article/BlogPosting schema (for blog posts)
BreadcrumbList schema (for site navigation)
Review/AggregateRating schema (if you display reviews)

Every schema type that exists on the current site must exist on the new site. If your developer is not aware of this requirement, specify it explicitly in the project brief.

Step 5: Configure the staging environment correctly

Developing the new site on a staging server is standard practice, but staging configurations routinely create SEO problems when the settings bleed into production.

Ensure the staging environment is blocked from search engines via one of:

A noindex meta tag in the <head> of all staging pages
A Disallow: / in the staging robots.txt
HTTP authentication (password protection) on the staging domain

Create a specific checklist item for your developer or whoever manages the launch: "Remove all staging noindex/disallow settings and confirm the production site is crawlable." This one item, if missed, results in a site that is completely invisible to Google. It happens more often than you would believe.

Step 6: Prepare your new sitemap in advance

The XML sitemap for the new site should be prepared before launch, reflecting the new URL structure. This allows you to submit it to Google Search Console immediately upon launch, rather than waiting for the new sitemap to be generated and tested after the fact.

Verify the sitemap includes all important pages and excludes pages that should not be indexed (thank-you pages, duplicate content pages, utility pages).

Phase 2: Launch day and the first 48 hours

The launch phase, when done correctly, is brief and mechanical. Every consequential decision should already be made.

Step 7: Confirm the staging block is removed

Before traffic is pointed at the new site, verify:

The robots.txt does not disallow search engine access
No pages carry <meta name="robots" content="noindex"> from staging
If the staging site used a temporary domain (staging.yoursite.com), that domain is either still blocked or redirected to production

Use a browser extension like "NoIndex? NoFollow?" or simply view-source on a few key pages to verify no noindex tags remain.

Step 8: Implement all redirects before switching DNS

Every redirect in your redirect map should be live before you point DNS to the new server. The sequence is:

Implement redirects on the new server
Test every redirect in the map (tools like Screaming Frog's "List" mode can bulk-test hundreds of redirects)
Confirm each 301 hits the correct destination with no intermediate hops
Only then update DNS

Launching the new site and then implementing redirects "in the next few days" is a significant mistake — search engines and users encounter 404 errors in the gap, and every hour counts.

Step 9: Submit the updated sitemap to Google Search Console

Immediately after DNS propagation:

Update your Google Search Console property if the domain changed (or add the new domain as a new property)
Submit the new sitemap via the Sitemaps report
Request indexing for your highest-priority pages via the URL Inspection tool

Do not wait for Google to discover the new site organically. Every hour of delay in getting the new URL structure indexed is an hour your traffic may route to 404 errors or old cached versions.

Step 10: Verify Core Web Vitals on the new site

New designs frequently change Core Web Vitals scores — sometimes dramatically. If your old site had reasonable LCP and CLS scores and the new site has heavy animations, large hero images, or complex JavaScript, performance may have regressed even as the design improved.

Use Google PageSpeed Insights (free) or run a Lighthouse audit on:

Your homepage
Your highest-traffic pages
At least one page type for each template (service page, blog post, product page)

Note the scores. If LCP (Largest Contentful Paint) is above 2.5 seconds or CLS (Cumulative Layout Shift) is above 0.1, the new site will underperform in search relative to its potential. Address these within the first two weeks if possible.

Phase 3: Post-launch monitoring (weeks 1–12)

The launch is not the end. Most migration issues emerge in the first ninety days as Google recrawls and reindexes the site.

Step 11: Monitor crawl errors daily for the first two weeks

In Google Search Console, check the Coverage report daily. You are specifically looking for:

New 404 errors — pages Google tries to access that return "not found." These indicate missing redirects.
Soft 404 errors — pages returning 200 status but with no meaningful content (common when old page templates exist on the new site as empty shells)
Redirect errors — redirect chains that fail
Blocked by robots.txt — any important pages accidentally blocked

Fix any new errors within 24 hours. The longer they persist, the more crawl budget is wasted and the more link equity is lost.

Step 12: Track ranking changes for protected pages

Using Google Search Console's Performance report, monitor the rankings for your previously top-performing pages. Specifically:

Filter by page to see each important URL's impressions and position over time
Compare the first 28 days post-launch against the last 28 days pre-launch
Flag any page that loses more than 30% of impressions within the first two weeks

A temporary dip (10–20% over weeks 1–2) is normal as Google processes the new site. A sharp drop that persists beyond week 3 or 4 indicates a problem: a missing redirect, a page title change that disrupted keyword relevance, a schema removal, or a robots.txt issue.

Step 13: Verify schema markup is rendering correctly

Run your new site's key pages through Google's Rich Results Test after launch to confirm schema markup is being parsed correctly. Specifically check:

LocalBusiness or Organization schema on the homepage
Product schema on product pages
Article/BlogPosting schema on blog posts
FAQ schema on any FAQ sections

If any schema that existed before is now missing or producing errors, flag it for immediate developer attention. Rich results (star ratings, FAQs, product prices in search results) provide a measurable CTR advantage and losing them is directly measurable in Search Console.

Step 14: Monitor page speed under real conditions

Staging and PageSpeed Insights tests run in controlled conditions. Real traffic on production infrastructure can reveal performance issues that tests do not capture.

Within the first two weeks of launch, install Google's Chrome User Experience Report (CrUX) data monitoring (visible in Search Console's Core Web Vitals report) and verify that real-user metrics align with lab data. If there is a significant discrepancy — lab tests show good scores but CrUX shows poor — investigate server response time, third-party scripts (analytics, chat widgets, pixels), and image loading under real network conditions.

Step 15: Resubmit disavow file if applicable

If your site previously had a disavow file submitted to Google, and the domain changed as part of the redesign, the disavow file does not transfer automatically. It must be resubmitted to the new Search Console property.

If the domain stayed the same but the Search Console property was reconfigured, verify the disavow file is still active in the Disavow Links tool.

Common mistakes that cause traffic crashes

Beyond the checklist, it is worth naming the most frequent culprits explicitly — the mistakes that cause the dramatic traffic drops that make redesigns the subject of anxious retrospectives.

Forgetting to remove noindex from production. This is number one. The site launches, traffic stops, nobody notices for a week, and by the time it is caught, Google has partially deindexed the site.

Changing URL structure without implementing redirects. Especially common when switching CMSs (from WordPress to Webflow, for example). The new platform uses different URL patterns and nobody mapped the old ones.

Removing content that was earning traffic. "Cleaning up" the site by removing old pages that seemed outdated, not realizing they were ranking for terms that drove meaningful traffic.

Rewriting title tags without considering SEO. New branding guidelines lead to completely new page titles that no longer match any search query.

Launching a heavier, slower design. Beautiful new sites with autoplay video, complex CSS animations, and large hero images frequently fail Core Web Vitals tests, impacting both rankings and user experience.

Not updating internal links. Old URLs remain in the site's navigation or body content as hardcoded links, pointing to pages that now redirect — creating redirect chains rather than direct links.

Running a redesign alongside an active SEO program is genuinely complex. If you want to understand the current state of your site's technical health before committing to a redesign — including crawlability, indexation status, page speed, schema, and internal link structure — the Licheo free SEO check gives you a baseline in thirty seconds. That baseline, taken before the redesign begins, is the most valuable reference point you will have throughout the entire process.