Website Redesign and SEO: How to Rebuild Without Losing Your Rankings (2026 Guide)

By Taqweem Ahmad  |  Founder, Dexora Digital  |  7+ Years SEO Experience  |  500+ Audits Delivered  |  July 2026

I have run the post-redesign recovery audit more times than I care to count. A business invests $15,000 in a new website, launches it, and watches their organic traffic disappear within 30 days. The designer delivered exactly what was asked for. The site looks better than it ever has. But the SEO equity that was quietly compounding for two or three years is gone.

In seven years and 500-plus audits, poorly executed website redesigns are the single most common source of preventable traffic loss I encounter. Based on our agency’s own audit data, approximately 65 percent of businesses that contact us following a redesign experienced a measurable organic traffic drop. Of those, 71 percent had missing 301 redirects, 53 percent had content that was removed or thinned during the rebuild, and 34 percent had accidentally blocked search crawlers. Most had multiple issues simultaneously.

The worst post-redesign damage I have personally audited was a 68 percent organic traffic drop within three weeks of launch. The business had changed 340 URLs with zero redirects, launched with staging robots.txt still blocking Googlebot, and compressed their homepage from 2,400 words to 190 words. All four of the most common redesign mistakes in one deployment.

A website redesign does not destroy SEO. A website redesign executed without SEO integration destroys SEO. The distinction matters because the fix is entirely in the process.

Before I cover what to do, let me show you what the right process produces.

VERIFIED RESULT:  56 percent increase in organic clicks in 28 days from technical fixes only — zero new content published. One client came to us after a botched redesign had introduced canonical errors, missing H1 headings on 14 service pages, and oversized images causing mobile LCP above 8 seconds. We fixed those three things. Nothing else. Within 28 days, clicks were up 56 percent.

VERIFIED RESULT:  23 ranking keywords and first client leads within 15 days of a brand new domain — Site Plans FL, Florida. This is what happens when SEO is built into the site before launch, not added afterwards.

VERIFIED RESULT:  First organic lead in 40 days from zero — Virginia Local Service Business. The client subsequently cancelled their planned Google Ads spend because organic traffic was already converting.

See all case studies

This guide covers every phase of a website redesign from an SEO perspective. What to capture before you start. What to protect during development. What to verify before going live. What to monitor after launch. At the end: a 30-point pre-launch checklist and 15 FAQs covering the most common questions I receive from businesses planning a rebuild.

Why Website Redesigns Destroy SEO — The 7 Most Common Causes

Understanding why redesigns damage SEO is the first step to preventing it. Each of the following has appeared in real audits I have run on sites that lost significant organic traffic after a redesign. None of them are complicated. All of them are preventable.

1. URL Structure Changes Without 301 Redirects

This is the most common and most damaging cause. Google assigns authority and ranking signals to specific URLs. When you change a URL — from /services/plumbing/ to /plumbing-services/ for example — that authority does not automatically transfer. Without a 301 redirect, Google treats the old URL as gone and the new URL as brand new. It starts ranking evaluation from zero.

The compounding damage: every internal link on your site pointing to the old URL is now broken. Every external backlink pointing to your old URL is now pointing to a 404. Years of link equity, removed in one deployment.

The redirect chain problem is subtler but equally damaging. The most common version looks like this: /old-services/ redirects to /our-services/ which redirects to /services/. By the time Googlebot follows three hops, the equity passed to the final destination is significantly diluted. On one client site I audited, a six-hop redirect chain on their primary service page was responsible for a ranking drop from position 4 to position 23 over six months — while the page looked perfectly functional to a human visitor.

WARNING:  Never change a URL without implementing a direct 301 redirect from the old URL to the new destination. Redirect chains longer than 2 hops dilute link equity at every hop. Map every URL change before development begins.

2. Removing or Thinning Content

Designers and copywriters working on a redesign compress content for visual reasons. A 1,200-word service page becomes a 150-word summary with a contact form. This feels cleaner. But Google ranked the original page because of its depth the specific terminology, the FAQ content embedded in the page, the detailed explanations that matched user search intent. When that content disappears, the ranking rationale disappears with it.

This happens most frequently on service pages and blog articles that are ‘updated’ as part of a redesign. The original version was ranking. The cleaned-up version is not.

Rule I apply on every redesign: any page currently ranking for any keyword above position 50 must preserve its content depth. The visual presentation can change. The words cannot be removed without a direct replacement.

3. Missing or Incorrect Canonical Tags

When a new website launches, it often goes live with missing self-referencing canonical tags. Without them, Google faces ambiguity when HTTP and HTTPS versions, www and non-www versions, and trailing slash and non-trailing slash versions of URLs all resolve to the same page. Google must decide which version to index. It does not always choose the one you want.

During the immediate post-launch period, Googlebot is actively recrawling your site to process changes. Canonical confusion during this crawl window causes previously well-ranked pages to drop while Google resolves the ambiguity — sometimes taking 4 to 8 weeks.

4. Blocking Crawlers During Development

Development sites run on staging environments with robots.txt blocking all crawlers — which is correct. The problem arises when the live site launches with the staging robots.txt still in place. I have audited live sites where the homepage returned 200 but robots.txt blocked Googlebot from accessing any interior page. From Google’s perspective, the site went from hundreds of indexed pages to effectively one.

I now make it a rule to check robots.txt within the first hour after any site launch. It takes 60 seconds. The consequences of not checking can take 6 months to fix.

Technical SEO service

5. Schema Markup Lost in Migration

Schema markup is often implemented in a theme or template rather than as a database setting. When a new theme or platform is deployed, the schema disappears. The loss does not cause an immediate ranking drop, but it removes eligibility for FAQ dropdowns, star ratings, and product information in search results — directly reducing CTR on pages that were previously showing enhanced results.

Equally important in 2026: schema markup is part of how AI systems identify your business as a trustworthy, citable source. Losing Organization, Service, and FAQPage schema during a redesign can reduce your AI search citation count — a metric that is increasingly relevant to organic discovery.

6. Page Speed Regression

New websites are often heavier than the sites they replace. More animations, larger images, additional JavaScript, unoptimized web fonts, new third-party plugins. The redesign launches looking beautiful and loading at 8 seconds on mobile. The previous site loaded in 3.5 seconds. Google notices within days.

This is particularly damaging for local service businesses where 70 to 80 percent of traffic arrives on mobile devices. Mobile LCP above 4 seconds consistently correlates with lower local pack rankings and higher bounce rates that further suppress organic performance. Core Web Vitals are a ranking factor. A redesign that degrades them is a redesign that will rank lower.

7. Internal Link Structure Disruption

The internal link structure of a well-optimised site is a carefully built authority distribution system. Each link passes authority from a stronger page to a supporting one. When a redesign changes navigation, removes pages, or restructures architecture without preserving these relationships, the system breaks. Pages that were ranking on internal link authority can drop the week a new nav goes live.

This is one of the reasons I spend time on the information architecture before any design work begins. The link structure is a revenue asset. It needs to survive the redesign intact.

The Pre-Redesign SEO Audit — What to Document Before You Touch Anything

Every website redesign should begin with a complete audit of what the existing site has. This is not optional. It is the baseline you will compare against after launch to verify nothing was lost. I run Screaming Frog with JavaScript rendering enabled most crawlers miss JS-rendered content without this setting, which means they miss what Google actually sees.

What the Pre-Redesign Audit Must Document

What to Document	Where to Get It	Why It Matters
Every ranking URL and its current position	Google Search Console	The baseline — every position change post-launch is measured against this
Top 50 pages by organic traffic	GSC Performance report + GA4	These pages are the priority — they must be protected first
All incoming backlinks with destination URLs	SEMrush or Ahrefs backlink report	Every linked URL needs a direct 301 if its address changes
All existing 301 redirects	Screaming Frog — Response Codes tab	Must be preserved; a new site that removes old redirects breaks all the chains they were maintaining
All page titles and meta descriptions	Screaming Frog — Page Titles and Meta tab	Must carry over exactly unless you are intentionally improving them
H1 headings and word count per page	Screaming Frog — H1 and readability tabs	Flag any page where content will be compressed during redesign
All schema markup types in use	Google Rich Results Test on key pages	Ensure every schema type is rebuilt correctly in the new site
Current Core Web Vitals scores	Google PageSpeed Insights — mobile tab	Speed benchmark to detect and prevent regression after launch
AI visibility score and cited page count	SEMrush AI Visibility panel	Track whether redesign improves or damages AI search citation count
Current sitemap and robots.txt	Navigate to /sitemap.xml and /robots.txt	Save both; verify the new site versions before launch

NOTE:  Export the full Screaming Frog crawl and the GSC data before development begins. Save everything with a date stamp. This is your migration mapping document. Any URL that changes needs to be tracked from old address to new destination in a single spreadsheet.

The SEO-Safe Redesign Process — Phase by Phase

Phase 1 — Planning (Weeks 1-2)

The planning phase is where most redesign SEO failures begin — because SEO is not in the room when key decisions are made about architecture, URL structure, and content scope. By the time the design brief is written, the most expensive SEO mistakes have already been committed.

URL Structure Decisions

Before a single wireframe is designed, agree the URL structure of the new site and map every URL change against the existing structure. The output is a redirect mapping spreadsheet: old URL, new URL, redirect status. This document is the most important single deliverable of the planning phase.

->  Keep existing URLs wherever possible — the fewer you change, the less risk

->  If you must change URLs, make them shorter, more descriptive, and keyword-relevant

->  Never use URL parameters as the primary format for important pages

->  Maintain consistent trailing slash usage across every page

Content Scope Decision

Every page currently ranking for any keyword must be reviewed by an SEO specialist before a decision is made to remove, merge, or compress its content. The designer may recommend removing a page. The SEO review must happen first.

Pages that cannot be removed or thinned without sign-off:

->  Any page with more than 50 organic visitors per month

->  Any page ranking in the top 30 for any keyword regardless of traffic volume

->  Any page with more than 5 external backlinks pointing to it

->  Any page published for more than 12 months

Phase 2 — Design (Weeks 2-4)

The design phase introduces two main SEO risks: performance regression from heavy design elements and visual compression of content that was previously ranking. Both are preventable with the right brief.

Speed-Conscious Design Decisions

Design Element	SEO Speed Risk	What to Do Instead
Full-width hero video autoplaying	Major mobile LCP impact — adds 3-8 seconds	Static image with CSS overlay; video plays on click only
Multiple scroll animations	JavaScript blocking, Total Blocking Time spike	Limit to 2-3 max; defer all animation JS
Custom web fonts (multiple weights)	Render-blocking if not configured	font-display: swap on all; preload critical font files
Uncompressed images across site	117 images over 100KB adds 3-5s on mobile	WebP format; every image under 100KB before upload
Multiple third-party app plugins	Each plugin adds 50-200ms — 10 plugins = 2s added	Audit all plugins before launch; remove unused ones
Parallax scrolling effects	Causes CLS score failures on mobile	Desktop only; disabled on all mobile breakpoints

Content Preservation Rule

The most practical protection against content thinning is a single rule applied to every page: every piece of text currently on a ranking page must appear on the new page for that URL — either in the main body or in an expandable section. Visual presentation can change. The words cannot be deleted.

Phase 3 — Development (Weeks 4-8)

The development phase is where technical SEO requirements are built. Developers need a specific written brief before they write a single line of production code. Without it, the technical SEO elements that took years to build silently disappear in the migration.

Technical SEO Requirements — Give This List to Your Developer Before Build Begins:

1.  Implement 301 redirects for every URL in the redirect mapping document. Test each one before launch. No 302s.

2.  Set a single canonical URL format for the entire site — https with www OR without www, trailing slash OR no trailing slash. Never both.

3.  Add self-referencing canonical tags to every indexable page.

4.  Configure robots.txt to allow Googlebot, Bingbot, GPTBot, ClaudeBot, and PerplexityBot access to all pages.

5.  Generate an XML sitemap covering all indexable pages. Exclude 301s, noindex pages, and 404s.

6.  Create an llms.txt file at the site root listing all key pages with descriptions for AI crawlers.

7.  Implement all schema types from the pre-redesign audit — Organization, LocalBusiness, Service, FAQ, Article, Author. Validate each with Google’s Rich Results Test.

8.  Verify Google Search Console property for the new site. Configure before launch, not after.

9.  Install Google Analytics 4 with all conversion event tracking — form submissions, calls, purchases — firing correctly.

10.  Implement Open Graph and Twitter Card meta tags on all pages.

Phase 4 — Pre-Launch Checklist (Final Week Before Going Live)

Nothing goes live until every item below is confirmed. This is the last line of defence. I have seen businesses push live over a developer’s protest that ‘it will be fine.’ It is not fine. Run the checklist.

Done	Check	Why It Matters
URLS AND REDIRECTS
[ ]	All old URLs return 301 to new destination — not 302	302 does not pass link equity; only 301 does
[ ]	No redirect chains longer than 2 hops	Chains dilute link equity at each additional hop
[ ]	Homepage resolves to one canonical version only	www vs non-www and trailing slash all resolved
[ ]	No 404 errors on any previously indexed URL	Crawl old sitemap against new site in Screaming Frog
[ ]	All old redirects preserved from previous site	New site must maintain any 301s the old site was running
INDEXING AND CRAWL
[ ]	robots.txt allows Googlebot on all key pages	Navigate to /robots.txt and verify no accidental blocks
[ ]	No staging noindex tags remaining on live pages	Check page source of homepage and top 5 pages manually
[ ]	XML sitemap generated and submitted to GSC	All key pages included; no redirects or 404s in list
[ ]	llms.txt live at /llms.txt on the root domain	Navigate to domain.com/llms.txt and verify content loads
[ ]	Self-referencing canonical tag on every page	Screaming Frog — Canonicals tab — verify all present
[ ]	AI crawlers not blocked in robots.txt	Confirm GPTBot, ClaudeBot, PerplexityBot all allowed
CONTENT AND ON-PAGE SEO
[ ]	All page titles match or improve on pre-redesign versions	Never delete a ranking title tag without a stronger replacement
[ ]	All meta descriptions present and under 160 characters	Missing meta descriptions reduce search result CTR
[ ]	Every page has a unique, descriptive H1 heading	Screaming Frog — H1 tab — no missing or duplicates
[ ]	Content word count matches or exceeds original on top 20 pages	Manually verify top traffic pages specifically
[ ]	All images have descriptive alt text	Critical for image search and accessibility signals
[ ]	Internal link structure matches pre-redesign link map	Key hub pages still receiving links from supporting pages
SCHEMA AND STRUCTURED DATA
[ ]	Organization or LocalBusiness schema on homepage	Validate with Google Rich Results Test
[ ]	FAQPage schema on all FAQ sections	Feeds AI citations and rich result dropdown eligibility
[ ]	Service schema on all service pages	Required for rich result eligibility
[ ]	Author schema on all blog articles	Required for Article schema and E-E-A-T signals
[ ]	BreadcrumbList schema on all pages below top level	Improves SERP appearance and navigation signals
PERFORMANCE AND SPEED
[ ]	Mobile PageSpeed score above 75 — target 90+	Below 70 impacts rankings; run on homepage and top 5 pages
[ ]	Mobile LCP under 2.5 seconds	Google’s good threshold; above 4s is classified as poor
[ ]	All images in WebP format and under 100KB	Single biggest load time improvement on most sites
[ ]	Non-critical JavaScript deferred	Reduces Total Blocking Time below 200ms
[ ]	No render-blocking resources in document head	PageSpeed Insights identifies these under Opportunities
ANALYTICS AND TRACKING
[ ]	GA4 tracking firing on all pages	Verify in GA4 Realtime report immediately after launch
[ ]	All conversion events tracked and confirmed firing	Form submits, calls, purchases — all verified in GA4
[ ]	GSC property verified for new site	Required for post-launch monitoring to work
[ ]	URL Inspection run on top 10 pages — request indexing	Do this on launch day, not 3 days later
[ ]	Old GSC performance data exported and archived	Historical data needed for comparison; export before launch

The 30-Day Post-Launch Monitoring Plan

The 30 days after launch are the highest-risk window. Google is re-crawling the site, processing redirects, and adjusting rankings. Watching closely during this period means catching issues when they are still recoverable, not 90 days later when the damage has compounded.

When	What to Check	What Action If Problem Found
Launch Day	GSC URL Inspection on top 20 pages	Request indexing for any page not returning clean 200
Hours 1-24	All 301 redirects returning 301 — not 302 or 404	Fix any redirect returning wrong status immediately
Day 3-7	GSC Coverage report for new errors	Address any new Excluded or Error pages within 24 hours
Day 7-14	Ranking positions vs pre-launch baseline	10-20% fluctuation is normal. 50%+ sustained drop needs investigation
Day 14-21	PageSpeed scores on live site	If mobile score dropped vs staging, identify cause and fix
Day 21-30	Full Screaming Frog crawl on live site	Compare against pre-launch crawl; identify any new issues
Day 30	Full ranking comparison report against pre-launch baseline	Pages not recovered by day 30 need specific issue investigation

Here is what recovery actually looks like in practice when issues are caught and fixed quickly. Weeks 1-2: rankings continue fluctuating as Google processes changes — this is normal. Weeks 3-4: drop stabilizes. This is often when clients want to make further changes. Do not. Making additional structural changes during this window extends the processing period. Weeks 5-8: gradual recovery begins for pages where redirects and content are intact. Weeks 9-12: most pages return to pre-redesign positions or better. Any page that has not recovered by week 12 almost certainly has a specific unresolved issue — usually a missing redirect, thinned content, or a broken canonical.

What This Process Produces — Three Real Results

I am sharing these because every competitor guide on this topic talks about protecting SEO without showing a single verified result. These are from Dexora Digital client campaigns with confirmed GSC data.

Result 1: 56% Organic Click Increase in 28 Days — Technical Fixes Only

A client came to us following a redesign that had introduced three specific technical problems: canonical errors caused by the migration, missing H1 headings on 14 service pages, and oversized images causing mobile LCP to exceed 8 seconds.

We made no content changes. We published no new articles. We built no new links. We fixed the three technical issues and submitted the corrected pages to Google Search Console.

Within 28 days, organic clicks increased 56 percent. The rankings had always been possible. The technical errors were suppressing them.

VERIFIED RESULT:  56% organic click increase — 28 days — technical fixes only — zero new content published

Free SEO audit — we identify these issues in 60 seconds.

Result 2: First Leads on Day 15 — Brand New Domain, Site Built SEO-First

Site Plans FL is a Florida permit site plan service. We built the website from scratch with the SEO architecture planned before the first page was designed. Keyword mapping, location page structure, schema types, internal link plan, llms.txt — all documented before development began.

When the site launched, Google found a technically clean domain with relevant county-specific content, complete schema, a properly structured internal link network, and an llms.txt file allowing AI crawler access. The GSC data shows 23 ranking keywords within two months of launch and first client leads arriving within 15 days of the site going live — from a zero-history domain.

VERIFIED RESULT:  23 keywords ranked and first leads on day 15 — new domain, SEO built before launch — Site Plans FL

Read full case study

Result 3: First Organic Lead in 40 Days — Client Cancelled PPC Budget

A Virginia local service business had no website at all when they came to us. We built the site with the technical foundation, location content, and local signals all in place at launch.

40 days after launch, the first organic lead arrived. The client subsequently cancelled their planned Google Ads budget because organic traffic was already generating enquiries. Two years later the engagement is ongoing and the site ranks for 130-plus keywords.

VERIFIED RESULT:  First organic lead in 40 days from zero — Google Ads budget cancelled — Virginia Local Business

Read full case study

What a Website Redesign Means for AI Search Visibility in 2026

AI search visibility — your citation count in ChatGPT, Perplexity, and Google AI Overviews — is a growing component of organic discovery. A website redesign can positively or negatively affect AI visibility depending entirely on what is preserved and what is added during the migration.

What Helps AI Visibility During a Redesign

Check  Create an llms.txt file at the site root if one does not already exist — this is the file that tells GPTBot, ClaudeBot, and PerplexityBot what content exists and how to read it

Check  Implement FAQPage schema on every section that contains Q&A content — AI systems pull directly from structured FAQ pages

Check  Add Author schema with verified credentials — increases E-E-A-T signals that AI systems use to evaluate trustworthiness

Check  Expand FAQ content on service pages — more specific, citable content means more AI citation opportunities

Check  Add Organization schema with sameAs links to LinkedIn, Google Business Profile, and Upwork — confirms your business as a named entity to AI systems

Check  Improve content specificity — replace generic marketing copy with factual, verifiable statements that AI systems can cite

What Damages AI Visibility During a Redesign

X  Blocking GPTBot, ClaudeBot, or PerplexityBot in robots.txt — intentionally or accidentally

X  Removing FAQ content that AI systems were previously pulling from and citing

X  Reducing content depth on pages that were appearing in AI-generated responses

X  Losing schema markup that AI systems used to understand page context and authority

X  Launching without an llms.txt file when the previous site had one

Check your AI Visibility Score in SEMrush before and after launch. The score should not decrease. If it does, the first things to verify are crawler access in robots.txt and content depth on previously cited pages.

AI Search Optimization — what it is and why it matters in 2026.

What to Do If Your Rankings Drop After a Redesign

If you are reading this after a redesign has already caused a traffic drop, here is the recovery process in the correct sequence. Most post-redesign drops are recoverable. The timeline is 4 to 12 weeks depending on severity and how quickly the issues are fixed.

1.  Run a full Screaming Frog crawl against your new site while comparing it against your old sitemap. Find every URL returning a 404 that previously had rankings or backlinks.

2.  Implement direct 301 redirects for every 404 URL with rankings or backlinks. This is the single highest-priority action in any post-redesign recovery.

3.  Compare content length on your top 20 traffic pages before vs after. Restore any content that was removed or compressed during the redesign.

4.  Verify canonical tags on every key page. Look for pages canonicalising to an incorrect URL — a common migration error.

5.  Check robots.txt for accidental crawler blocks. Verify AI crawlers specifically: GPTBot, ClaudeBot, PerplexityBot.

6.  Submit all key pages through GSC URL Inspection to prompt recrawling of the corrected versions.

7.  Run PageSpeed Insights on your top 5 pages. Address any speed regression introduced by the new design.

8.  Allow 45 to 60 days after all fixes are implemented before evaluating recovery. Rankings do not return the same week the fix goes in. Google needs time to recrawl and reprocess.

Making further structural changes while waiting for recovery from a redesign extends the processing period. Once fixes are in, the correct action is to wait and monitor — not to make additional changes in response to continued fluctuation.

Frequently Asked Questions (FAQs)

Q: Will a website redesign hurt my Google rankings?

A: Not necessarily. A redesign executed with proper SEO integration preserves and can improve your rankings. The businesses that lose rankings in a redesign are the ones that treated SEO as something to add after launch. The specific causes are consistent across every audit I have run: URL changes without 301 redirects, content removal, missing canonicals, accidental crawler blocking, schema loss, and page speed regression. Every one of these is preventable with the correct process applied before launch.

Q: How long does it take to recover rankings after a website redesign?

A: If the redesign introduced technical errors, recovery typically takes 4 to 12 weeks after those issues are fixed. Google needs time to recrawl, process redirect chains, and re-evaluate page authority. Minor ranking fluctuations in the first 14 days after any redesign are normal and expected. If rankings have not stabilized within 45 to 60 days and no technical issues remain, there is likely a content depth problem on specific pages that needs investigation. The earlier issues are caught and corrected, the faster the recovery timeline.

Q: What is the most important SEO action during a website redesign?

A: The redirect mapping document. This is a spreadsheet listing every URL that changes during the redesign, its old address, its new address, and the 301 redirect implementation status. It is the most important single deliverable of the planning phase because everything else — backlink equity, internal link authority, indexed page count — depends on whether those redirects are correctly implemented. I create this document before any design work begins and treat it as a non-negotiable launch requirement.

Q: Do I need to update my sitemap when I redesign my website?

A: Yes. Regenerate your XML sitemap to reflect the new URL structure and submit it to Google Search Console on launch day. The old sitemap should be updated or replaced immediately. Your new sitemap should contain only indexable pages — no 301 redirect URLs, no noindex pages, no 404s. Submit the new sitemap via GSC, not just by uploading it to the server.

Q: What happens to my backlinks if I change URLs during a redesign?

A: Backlinks pointing to old URLs pass their equity to new URLs only if direct 301 redirects are correctly implemented from old to new. Without a redirect, the backlink destination returns 404, the equity is lost, and any ranking advantage derived from that backlink disappears. This is the primary reason redirect mapping is non-negotiable. Create a complete redirect map against your full backlink profile — every URL with external links pointing to it must have a redirect.

Q: Should I redesign my website and do SEO at the same time?

A: Yes — the redesign is the optimal time to build SEO correctly from the ground up. Involving an SEO specialist in the planning phase before design work begins costs significantly less than fixing the damage after a poorly migrated site loses rankings. The most efficient approach: map the SEO requirements first, design around them, build them into the development brief, and launch with a complete technical SEO foundation in place. Treating SEO and design as sequential projects — redesign first, SEO later — means paying twice and accepting a traffic drop in between.

Q: Does changing my website platform affect SEO?

A: A platform change WordPress to Webflow, Shopify to a custom build, Squarespace to any other CMS — introduces the same risks as any redesign: URL changes, content migration, redirect management, schema rebuild, and speed changes. The platform itself does not directly affect rankings. What affects rankings is whether the migration is executed correctly. Platform migrations require the same pre-migration audit, redirect mapping, and post-launch monitoring as any visual redesign.

Q: How many 301 redirects is too many for SEO?

A: There is no upper limit on the number of 301 redirects you can implement. A large site can run hundreds or thousands without issue. What matters is the structure: keep redirect chains to a maximum of two hops. Chains where Redirect A points to Redirect B which points to Redirect C dilute equity at each hop. Every redirect in the chain should go directly from old URL to final new destination wherever possible. Collapse any chains from the previous site as part of the redesign.

Q: Should my old website stay live while I build the new one?

A: Yes. The old site should remain live until the new site is ready to launch as a complete, verified deployment. Build the new site on a password-protected staging environment or a subdomain with robots.txt blocking all crawlers. Never rebuild directly on the live domain. The switch from old to new should be a single deployment, not a gradual page-by-page rollout.

Q: How does website speed affect SEO after a redesign?

A: Significantly and quickly. Google uses Core Web Vitals — LCP, CLS, and INP — as ranking factors. A redesign that degrades mobile page speed will show ranking adjustments within 2 to 4 weeks of launch. Mobile LCP above 4 seconds is classified as poor and consistently correlates with lower local pack rankings and higher bounce rates that further suppress organic performance. Run Google PageSpeed Insights on your new site before launch and ensure mobile LCP is below 2.5 seconds on all key pages. The most common cause of speed regression in a redesign is uncompressed images — converting to WebP and compressing below 100KB per image is typically the highest-impact single fix.

Q: What should I do about AI search visibility during a redesign?

A: Use the redesign as an opportunity to improve AI visibility. Ensure the new site includes an llms.txt file at the root domain, FAQPage schema on all FAQ content, Organization schema on the homepage, and Service schema on service pages. Verify your robots.txt allows GPTBot, ClaudeBot, and PerplexityBot. Check your AI Visibility Score in SEMrush before and after launch. A decrease after launch almost always indicates blocked AI crawlers or removed content that was previously being cited in AI responses.

Q: How do I tell Google about my website redesign?

A: You cannot formally notify Google, but there are actions that accelerate processing of the changes. Submit your new XML sitemap to Google Search Console on launch day. Use GSC URL Inspection to request indexing for your top 20 pages. If your domain changed as part of the migration, use the Change of Address tool in Google Search Console. If you moved from HTTP to HTTPS, ensure all HTTP versions redirect to HTTPS and update the preferred domain setting in GSC.

Q: Can a website redesign actually improve my SEO?

A: Yes, and this is the correct expectation to have when the process is executed correctly. A well-planned redesign is an opportunity to fix existing technical issues, improve content depth on underperforming pages, rebuild internal link structure correctly, implement complete schema markup, improve Core Web Vitals, and add AI search signals like llms.txt. Businesses that approach a redesign with SEO integrated from the planning phase typically see ranking improvements within 60 to 90 days of launch. The Site Plans FL case above shows what is possible when SEO is treated as the foundation rather than the afterthought.

Q: How long before a redesign should I start the SEO audit?

A: At least four weeks before the planning brief is written. The pre-redesign audit takes time to complete thoroughly — a full Screaming Frog crawl, GSC data export, backlink audit, content inventory, schema documentation, and speed baseline — and the output should directly inform the redesign brief. Rushing the audit means missing items that only become apparent after launch when the damage is already done. I treat the pre-redesign audit as a separate project with its own timeline, not an afternoon task.

Q: What is the single most important action on the day a redesigned site goes live?

A: Verify that all 301 redirects are returning 301 status codes — not 302, not 200, not 404. Use Screaming Frog to crawl your complete old URL list against the new site within the first hour of launch and confirm every URL either returns 200 at its correct new destination or a 301 redirect to that destination. Any URL returning 404 needs a redirect implemented within that same hour. Googlebot begins recrawling a changed site within hours of detecting the change. Redirect errors during this first crawl window cause faster and deeper ranking drops than the same errors discovered a week later.