.jpg)
A website redesign is one of the most effective ways to lose organic traffic. Not because redesigns hurt SEO inherently, but because they involve the exact changes that do: URL structure updates, content reorganisation, new templates, changed meta fields, and a new technical stack. Every one of those changes is a way to break something that was working inadvertently.
This checklist covers every SEO task across the full redesign lifecycle -from pre-project audit to 30-day post-launch monitoring, with 2026-specific updates for Core Web Vitals, mobile-first indexing, and AI search signals. Work through it in order. The phases build on each other.
Why SEO must be built into a redesign, not added at the end
The most common redesign mistake is treating SEO as a launch-day task: writing meta tags, submitting a sitemap, and calling it done. By the time you reach launch day, the decisions that determine your post-launch rankings have already been made: which URLs changed, which content was cut, how page speed was affected, and whether metadata fields were configured in the CMS.
SEO needs to be in the room when URL structure decisions are made, when the content audit determines what gets cut, and when the developer chooses how to implement the technical stack. That is when the work happens. Launch day is verification, not implementation.
Pre-redesign phase: audit and baseline
The pre-redesign audit is the single most important SEO investment in the entire project. It takes 1-2 days. Skipping it costs weeks of post-launch recovery.
Content and traffic audit
1. Export all current URLs. Run Screaming Frog on the current site. Export every URL, status code, title, meta description, H1, word count, and internal link count.
2. Identify top-traffic pages. Pull organic sessions by page from GA4 for the past 90 days. Any page driving more than 1% of total organic traffic is a protected asset. These pages cannot change URL, lose content, or have metadata deleted without a plan.
3. Identify top-ranking pages. Export keyword rankings from Ahrefs or SEMrush for your top 50 ranking pages. Document the keyword, position, and search volume for each.
4. Document existing redirects. Export any 301 redirects already configured in your current CMS or server. These must be preserved in the new site.
5. Identify pages to cut. Flag low-traffic, thin, or outdated pages. Cutting them is fine -but each needs a redirect to the closest relevant page, not a 404.
Technical baseline
6. Core Web Vitals baseline. Run Google Search Console's Core Web Vitals report and PageSpeed Insights on your top 10 pages. Record LCP, CLS, and INP scores. These are your post-launch benchmarks.
7. Mobile usability report. Check Google Search Console's mobile usability report for any existing issues. Fix them before the redesign, not after.
8. Structured data audit. Run Google's Rich Results Test on representative pages. Document every schema type in use. You will need to rebuild these in the new design.
9. Backlink profile. Export your top 100 referring domains and the pages they link to from Ahrefs. These target pages are high-value and need careful URL handling.
During redesign: build SEO in from the start
URL structure decisions
Make URL structure decisions in the first week of the project, not the last. Every URL change after this point creates redirect work.
• Preserve existing URL structure wherever possible. The path of least SEO risk is identical URLs on the new design
• If URL structure must change (e.g., moving from /blog/category/post to /articles/post), document every old URL and its new equivalent in the redirect map now
• Avoid unnecessary subfolder changes. Moving /services/web-design to /web-design seems minor but breaks every internal and external link to the old URL
• Standardise trailing slash handling and ensure it matches the canonical tag and sitemap format
Content decisions
• Never delete a page without redirecting it. A deleted page with inbound links sends equity to a 404
• Preserve word count on top-traffic pages. Redesigns often condense copy for visual reasons. If a page ranks partly because of content depth, cutting it damages rankings
• Rebuild meta title and description fields in the new CMS before launch. Do not allow the platform to auto-generate them from the first line of content
• Review heading structure (H1, H2, H3) in the new design. A redesign that converts H2s to styled divs for visual effect removes semantic structure
Technical SEO configuration
• robots.txt: confirm the staging environment uses Disallow: / (to block indexing). Confirm the production environment removes this disallow before launch. This is the most common catastrophic launch error
• Canonical tags: every page should have a self-referencing canonical. If the new platform uses query parameters for filtering, pagination, or sorting, configure canonical tags to point to the clean URL
• XML sitemap: generate and review the sitemap before launch. Confirm it includes all pages you want indexed and excludes any you do not
• Schema markup: rebuild any structured data types from the audit. Article schema for blog posts, Organisation schema on the homepage, FAQ schema on support content
• Open Graph and Twitter Card tags: verify these are configured for social sharing on all key page types
• Analytics: verify GA4 tracking fires on all pages in staging before launch. Confirm conversion events are tracking correctly
Pre-launch checklist
Run this checklist in the week before launch. Nothing launches without it being complete.
10. Redirect map is complete and tested (every old URL returns 301 to its target)
11. robots.txt production file reviewed and confirmed (no blocking of key pages or entire site)
12. XML sitemap reviewed, correct, and ready to submit
13. Meta titles and descriptions reviewed for every page (no auto-generated, blank, or duplicate fields)
14. H1 present on every page, unique, and matching the page topic
15. Canonical tags correct on all pages, including paginated and filtered views
16. Structured data validated on all key page types via Google Rich Results Test
17. GA4 tracking verified firing on all pages and conversion events
18. Google Search Console property set up for the new domain/URL pattern
19. PageSpeed Insights run on top 10 pages; LCP under 2.5s, CLS under 0.1
20. Mobile usability tested on real device (not just responsive design mode)
21. All internal links updated to reflect new URL structure
22. 404 page configured and returns a true 404 HTTP status code
Launch day checklist
23. Point domain to new server / CDN
24. Confirm SSL certificate activates and HTTPS is working
25. Verify robots.txt is live and not blocking indexing
26. Submit new sitemap to Google Search Console
27. Run Screaming Frog on the live domain and check for 404s and redirect errors
28. Verify GA4 is tracking sessions on the live domain
29. Check top 10 pages load correctly at correct URLs
30. Verify all 301 redirects return correct status codes on the live domain
Post-launch monitoring
The 30 days after launch require active monitoring. Do not assume a clean launch means everything is working.
If organic traffic drops more than 20% and does not recover by week 3, investigate in this order: redirect completeness (run a crawl comparing old URLs to 301 status), metadata completeness (check for blank or auto-generated meta on high-traffic pages), and content completeness (verify no content was cut from top-ranking pages).
Advanced tips for 2026
Core Web Vitals as a ranking signal. Google continues to use page experience signals in ranking. LCP (Largest Contentful Paint) under 2.5s and CLS (Cumulative Layout Shift) under 0.1 are the thresholds that matter. INP (Interaction to Next Paint) replaced FID in 2024 and is now the interactivity metric; target under 200ms.
Mobile-first indexing. Google indexes the mobile version of your site. If the mobile version has less content, fewer internal links, or lower-quality structured data than the desktop version, your rankings reflect the mobile version. Verify mobile and desktop parity in content and structured data during the redesign.
AI search signals. Google's AI Overviews and other AI-driven search features prioritise structured, clearly organised content. Clean heading hierarchy, FAQ schema, and well-structured long-form content improve visibility in AI-generated search results. A redesign is an opportunity to improve content structure, not just visual design.
Page experience for Webflow sites. Our Webflow SEO capabilities cover this directly. Webflow sites on the Business or Enterprise plan with global CDN and optimised assets typically score well on Core Web Vitals by default. Heavy Webflow interactions, custom lottie animations, and unoptimised video backgrounds are the most common sources of performance regression.
The biggest SEO mistakes during a redesign
Work with Belt Creative on your redesign
A redesign that loses organic traffic is a redesign that failed the business, regardless of how the design looks. Belt Creative builds Webflow sites with SEO built into the process from day one -URL planning, redirect mapping, technical setup, and post-launch monitoring included.
See our work to understand how we approach redesigns, or get in touch to talk through your project.
A note on sources
Google Search Central documentation: developers.google.com/search. Core Web Vitals thresholds sourced from web.dev/vitals. Google PageSpeed Insights: pagespeed.web.dev. Screaming Frog: screamingfrog.co.uk. All tool pricing verified at time of writing; confirm with vendors before purchase.
Frequently asked questions
How long does a website redesign SEO process take?
The SEO process runs the full length of the redesign project. Pre-redesign audit: 1-3 days. SEO input during build: ongoing throughout. Pre-launch QA: 3-5 days. Launch day tasks: a few hours. Post-launch monitoring: 30 days minimum. The total calendar time depends on the project scale, but SEO cannot be compressed into the final week without significant risk.
What are the most common SEO mistakes in a redesign?
In order of frequency and impact: (1) changing URLs without 301 redirects; (2) deleting high-traffic pages; (3) launching with a robots.txt that blocks Googlebot; (4) not verifying GA4 tracking before launch; (5) allowing the new CMS to auto-generate meta tags rather than migrating existing ones. All five are preventable with the pre-launch checklist above.
Do I need to redirect every page, or just the important ones?
Every page that exists in your current crawl and will have a different URL on the new site needs a redirect. Low-traffic pages without inbound links are lower priority, but they still need redirects if you want to avoid 404 errors for users who have bookmarked or linked to them. Pages being deliberately removed should redirect to the most relevant existing page, not to the homepage.
How do Core Web Vitals affect redesign SEO?
Google uses Core Web Vitals as a ranking signal. A redesign that degrades LCP, CLS, or INP scores can cause rankings to drop even if everything else is correct. Run PageSpeed Insights on key pages in staging before launch. If scores are worse than the current site, investigate before launching. The most common causes are hero images not lazy-loaded, third-party scripts blocking render, and animations that cause layout shifts.
Should I tell Google about the redesign?
Yes, through Search Console. If the domain changes, use Google Search Console's Change of Address tool. If URLs change on the same domain, submit the new sitemap immediately after launch. You cannot directly notify Google of a redesign, but submitting an updated sitemap accelerates re-crawling of the new pages.
How much traffic loss is normal after a redesign?
A 10-20% temporary dip in organic traffic in the first 2-4 weeks after launch is within the normal range as Google re-processes the site. Traffic should recover and ideally improve within 4-8 weeks if the migration was executed correctly. A sustained drop beyond 4 weeks on specific pages indicates a specific issue with those pages that warrants investigation.
Do I need to update my Google Analytics tracking code during a redesign?
If you are staying on GA4, no code change is needed unless the tracking implementation changes. Verify that the GA4 tag fires on all pages of the new design by checking the GA4 real-time report during QA. If you are migrating from Universal Analytics to GA4 (which should have happened already), that is a separate project that should be completed before the redesign, not during it.
What should I prioritise if the redesign has a very tight timeline?
In strict priority order: (1) complete redirect map for all changed URLs; (2) metadata migrated for top 50 traffic pages; (3) robots.txt verified; (4) sitemap ready to submit; (5) GA4 tracking verified. If time is genuinely constrained, these five items protect the majority of your SEO value. Everything else can be addressed in the days immediately after launch.
Sources: Google Search Central (developers.google.com/search); web.dev/vitals (Core Web Vitals); Google Search Console Help (support.google.com/webmasters); Screaming Frog (screamingfrog.co.uk).
