A website redesign can keep its rankings when the URLs, content, and technical setup that earned them are protected, and migration is planned as project work rather than checked the night before launch. Colours and layout rarely affect search visibility. Changing a page's content, URL or internal links can, especially if the page already earns traffic or backlinks.
This checklist is for marketing managers, site owners and developers planning a relaunch. It follows the order in which a real project runs, from the baseline you capture before design to 90 days of monitoring after launch.
Four risks cause most redesign losses:
URLs change without working redirects.
Content is cut or rewritten on pages that ranked.
Staging blocks, such as noindex tags or robots.txt disallows, reach the live site.
Tracking breaks, which hides the damage from the other three.
Will a website redesign hurt your SEO?
Sometimes, but it doesn't have to. A website redesign alone rarely costs rankings. The damage stems from changes to URLs, content, internal links, rendering, and tracking. If those stay protected, you should only see short-term changes while Google recrawls.
Some volatility is normal. Google's site move guidance says rankings can fluctuate during a move, and for medium-sized sites it can take weeks or longer for new URLs to replace old ones. Nobody can promise a fixed recovery date. It depends on site size, how much changed, crawl frequency, and any new errors. Large or persistent losses on important pages need investigating, and Phase 5 sets out when.
Redesign, migration or both: which are you doing?
What you need to protect depends on what is changing:
Visual redesign, same URLs: the risks are content parity, rendering, internal links, metadata and page speed.
CMS or hosting migration, same URLs: add server responses, tracking, crawl capacity and anything the old platform handled automatically, such as redirects, canonicals and sitemaps.
URL, domain or structure change: add a complete redirect map, destination checks and migration-specific monitoring.
Change one thing at a time where possible. Google recommends splitting a move into steps so issues are easier to trace. If a deadline forces a combined launch, widen the SEO scope and tighten the pre-launch gate.
Phase 1: before design starts (6 to 8 weeks out)
Get SEO into the kickoff
Give each risk a named owner: who signs off URLs and redirects, who owns templates and metadata, who checks staging, and who is on call at launch. The cheapest time to protect a URL is before anyone designs around it.
Benchmark before you change anything
Without a baseline, a drop becomes an argument instead of a measurement. Save exports in a dated, read-only location.
Data | Source | Export |
Clicks, impressions, queries | Search Console | Pages and queries, last 16 months |
Organic sessions, conversions | GA4 | Organic landing pages with key events |
Indexing | Search Console | Page indexing and sitemap reports |
Core Web Vitals | Search Console, PageSpeed Insights | LCP, INP and CLS per template |
Site structure | A crawler such as Screaming Frog or Sitebulb | Every URL with status, title, H1 and canonical |
Backlinks | Search Console, a backlink tool | Linked pages with referring domains |
Swipe to see more →
Build a URL inventory and a priority list
Combine a crawl, the XML sitemap, Search Console, GA4 landing pages, server logs, and backlink data into a single sheet to identify orphan pages that a crawl may miss because they have no internal links pointing to them. Google's guidance recommends a similar mix. Then flag pages you can't afford to lose: top organic landing pages, pages with strong backlinks, pages that drive conversions, and pages ranking in the top ten for commercial queries. On a typical business site, that is 50 to 100 URLs, and they get the closest checking at every later stage.
Phase 2: decisions that protect rankings during design
Keep URLs the same wherever possible
The safest redirect is the one you don't need. If a URL ranks, keep it unless there is a strong reason to change it. Record the reason in the redirect map.
Check content parity on ranking pages
Compare the old and new versions of every priority page and every template, since a single template change can alter hundreds of URLs. Check:
main copy and headings
internal links in the body and navigation
indexability and canonical tags
structured data
images and alt text
supporting sections such as FAQs and reviews
The usual problems are copy trimmed for a cleaner layout, text hidden behind elements that load only after a click, and content rendered client-side that crawlers may not see.
Preserve metadata and internal links
Ask developers for a template-level spec showing where titles, meta descriptions, H1s, canonicals, and schema come from. Structured data must match what is visible on the page. Also compare the new navigation with your baseline crawl. Removing a menu item can leave a ranking page with almost no internal links.
Set performance and mobile targets
Treat Core Web Vitals as targets for new templates: LCP of 2.5 seconds or less, INP of 200 milliseconds or less, and CLS of 0.1 or less at the 75th percentile. Test staging with lab tools under realistic mobile conditions, since field data won't be available until real visitors arrive. Confirm the mobile version has the same content, links, and structured data as desktop.
Phase 3: redirect mapping
Build the map from the full inventory, one row per old URL. Have someone familiar with the content review it. If your URLs aren't changing, skip the new map and audit existing redirects instead.
Map one to one. Send each old URL to its closest equivalent. Google advises against redirecting many pages to an unrelated page such as the new homepage.
Use server-side permanent redirects, normally 301 or 308, for permanent moves. Use 302 or 307 only for temporary ones. Use JavaScript redirects only as a last resort because they depend on rendering to work.
Redirect straight to the final destination. Avoid chains; Google suggests keeping them to three hops at most. Check for loops.
Capture existing redirects first, such as HTTP to HTTPS and www rules, then point them at the final URLs.
Keep redirects live for at least a year, and longer where backlinks still point at the old URLs.
Where a page has no equivalent, let it return a 404 or 410 instead of forcing a redirect. When pages merge, make sure the destination covers what each old page did.
Old URL | New URL | Response | Reason |
/services/web-design-nairobi | /services/web-design | 301 | Merged into one service page |
/blog/2019/seo-tips | /blog/seo-tips | 301 | Date removed from path |
/contact-us | /contact | 301 | Renamed |
/team/former-member | None | 410 | Removed, no replacement |
Swipe to see more →
Phase 4: staging, pre-launch QA and launch day
Protect staging, then crawl it
Put staging behind authentication rather than relying on a noindex tag, which can be copied to production by accident. Crawl it, test every row of the redirect map against it and compare the results with your baseline crawl. Look for missing pages, changed titles, lost H1s, canonicals pointing at the staging address, and new status codes.
The 48-hour pre-launch gate
This is the readiness check. Nobody launches until every row has an owner's name against it.
Check | Owner | Pass condition |
Redirect map | SEO lead | Every redirecting URL reaches its mapped 200 page in one hop, and unchanged URLs return 200 |
Indexing settings | Developer | Production config has the intended robots rules and no noindex |
Canonicals and sitemap | Developer | Canonicals self-reference live URLs, and the sitemap lists only indexable, canonical URLs |
Metadata and schema | SEO lead | Match the spec on a sample from each template |
Tracking | Analyst | A test conversion appears in GA4 |
Performance and capacity | Developer | Templates meet targets on mobile, and the server can handle a crawl spike |
Sign-off | Project owner | A named person approves in writing |
Swipe to see more →
Launch day
Launch in a low-traffic period with the whole team available. Deploy the new site, redirects, robots rules, and sitemap together so the live site is never exposed half-configured. Then verify:
No staging authentication, noindex tags, or robots.txt disallows remain on the live site.
Your top 50 priority URLs behave as mapped: status, destination, canonical, title and rendering.
A live crawl matches the baseline except for intended changes.
The XML sitemap is submitted to Search Console, along with a Change of Address if the domain has changed.
Analytics and conversion tracking are recording.
Phase 5: after launch (days 1 to 90)
Compare everything against the Phase 1 baseline.
When | Check | Look for |
Day 1 | Live crawl, server logs, Search Console | Correct status codes, redirects firing, Googlebot requesting new URLs |
Week 1 | Page indexing and sitemap reports, GA4 landing pages | Valid pages rising, errors not rising, organic sessions broadly near baseline |
Week 4 | Search Console queries and pages, Core Web Vitals field data | Clicks and impressions on priority pages, CTR changes where titles changed |
Day 90 | Full baseline comparison, organic conversions | Priority pages at or near baseline, gaps explained or on a fix list |
Swipe to see more →
When a dip is normal, and when to escalate
Some fluctuation is expected during Google's recrawl. Don't panic and make changes on day three. Escalate when:
priority pages drop out of the index or return errors.
traffic to priority pages keeps falling, or sits well below baseline after the first few weeks.
organic conversions fall faster than organic sessions.
Search Console shows rising redirect errors, soft 404s, or noindex exclusions.
Treat these as launch defects first and ranking questions second. Agree your thresholds before launch, because the right numbers depend on your site.
Traffic dropped after your redesign? A diagnosis flow
Work through these in order, ruling out the cheaper explanations first.
Tracking error or real drop? Compare GA4 organic sessions with Search Console clicks for the same pages and dates. If only GA4 has fallen, check the tag, consent banner, filters, and conversion events. If both have fallen, treat the decline as real and continue investigating.
Launch or algorithm update? Compare when the drop began with your launch date and Google's Search Status Dashboard. A drop starting on launch day is a strong clue the build is involved but not proof. If the two overlap, fix launch defects first because you control them.
Which pages lost traffic? In Search Console, compare pages and queries before and after launch. A few pages suggest page-level problems, a whole template suggests the template, and the whole site suggests crawling, indexing, or blocking.
Check the usual causes:
noindex tags or robots.txt blocks
missing, chained or misdirected redirects
error responses, including soft 404s
content removed or shortened on ranking pages
removed internal links or orphaned pages
wrong canonicals or broken structured data
rendering and performance problems
Fix the issues, then ask Google to recrawl. Request indexing for the most important fixed pages, update the sitemap, and keep comparing against the baseline.
Still stuck? Read why a website isn't showing on Google.
Protecting AI search visibility during a redesign
A website redesign can reduce visibility in AI search results for the same reasons it reduces visibility in traditional search: pages become uncrawlable, content disappears, or links break. Google says there are no additional requirements to appear in AI Overviews or AI Mode and no special markup or machine-readable files are needed. So the checks are the ordinary ones:
Keep clear, direct answers in text that renders without scripts.
Make sure structured data is accurate and matches the visible page. Don't expect it to earn visibility on its own.
Check that robots.txt, CDN and hosting rules aren't blocking the crawlers you want. Decide on a service-by-service basis, using each provider's documentation.
Leave crawlable internal links in place, so every page you want cited is reachable.
Google includes AI Overviews and AI Mode traffic in normal Web search reporting in Search Console, so you can't isolate it. Use a repeatable check of the questions you want cited on day 30 and day 90 as a supplementary signal and look for patterns rather than a single missing citation.
Common redesign SEO mistakes
Mistake | Effect | Fixed in |
Changing URLs without redirects | Errors on old addresses and lost backlink value | Phase 3 |
Cutting copy on ranking pages | Pages stop matching the queries they ranked for | Phase 2 |
Launching with noindex or robots.txt blocks | Pages drop out of the index | Phase 4 |
Redirecting everything to the homepage | Irrelevant destination and wasted link value | Phase 3 |
Dropping titles, schema or internal links from new templates | Relevance signals and link flow change | Phase 2 |
Broken analytics or conversion tracking | The damage can't be measured | Phase 4 |
Swipe to see more →
Frequently Asked Questions
What is a redirect map?
A spreadsheet that pairs every old URL with the new URL it should point to, along with the response code. It is the main working document of any migration.
What is a 301 redirect?
A server instruction that a page has moved permanently. Google treats the new URL as the canonical one. A 308 works the same way, and a 302 signals a temporary move.
What is a noindex tag?
A directive, set in a meta tag or HTTP header, that tells search engines to keep a page out of their index. It suits staging sites and does harm if it reaches the live one.
What is content parity?
Keeping the old and new versions of a page equivalent in the elements that earned its ranking: copy, headings, links, structured data, and indexability.
What is the most common website redesign SEO mistake?
In practice, it usually involves changing URLs without a tested redirect map, followed by launching with staging blocks still in place. A full URL inventory and a pre-launch gate prevent both.
Next step
Planning a website relaunch? Cralite Digital offers a redesign SEO audit and pre-launch review to help protect your rankings, organic traffic, and visibility during the transition.
Need a new website, too? Explore our web design service or learn how much a website costs in Kenya.
