This article covers the ten mistakes that cause it, in the order they're usually made, and a checklist for each stage of the project. The migration plan itself (mapping every URL, 301 redirects, rebuilding tracking and checking after launch) is set out on the website redesign page. This is about the design decisions underneath it.
Why redesigns lose search traffic
Google ranks pages, not websites. The signals a page has built up over years, the searches it shows for, the links pointing at it, its place in your site's structure, belong to that page at that address. Change the address, the content or the links around it, and those signals have to be found and passed on again. Some of them don't make it.
Google is plain about what to expect. Its guide to moving a site with URL changes says visibility "may fluctuate temporarily during the move", and that a small to medium-sized site can take a few weeks for most pages to move. Some movement after launch is normal. Rankings that never come back are a different problem, and they usually trace to one of the decisions below.
The pattern behind them is sequencing. A business decides to redesign, a designer draws the new site, a developer builds it, and somebody asks about SEO during testing. By then the sitemap is agreed, the navigation is built and the heading styles were chosen for looks. Every SEO fix at that stage means reopening work that was signed off, so most of them don't happen.
The ten mistakes, in the order they're made
1. Planning the sitemap around the org chart
New sitemaps tend to mirror how the business sees itself: divisions, teams, product families. Searchers don't look for your divisions. They search for a service, a problem or a product. If the new structure has no page that answers a search your old site ranked for, that traffic has nowhere to land.
Start the sitemap from what people search for and what the site already ranks for. Each service or topic that people search for gets its own page with one clear focus.
2. Cutting or merging pages that rank
"Simplify the site" is in nearly every redesign brief, and it's often right. But a page that looks thin to the business may be the one bringing in a third of the search traffic. Merging five service pages into one tidy overview usually means one page competing for five different searches, and doing all of them less well.
Before any page is cut or merged, check what it earns in Search Console and analytics: clicks, enquiries and links from other sites. Pages that earn their keep stay, or move with their content intact.
3. Changing URLs that didn't need to change
Every changed URL needs a redirect, and every redirect is something that can be missed. Platform defaults are the usual cause: a new CMS adds a folder, drops a file extension or changes the way it builds slugs, and suddenly every address on the site is different.
Keep good URLs where you can. Where they must change, Google recommends permanent redirects (301 or 308), straight to the final address rather than through a chain, kept in place for at least a year (Google Search Central). The full mapping process is on the redesign page.
4. Treating headings as type styles
In many builds, heading levels get picked for how they look: an H1 for the big banner line, an H4 because that size suited the card. Search engines and AI assistants read the heading levels, not the font sizes, to work out what a page is about and how it's organised.
Agree the rule before design starts: one H1 per page that states its main topic, H2s for the main sections and H3s inside them. Then design the type styles separately, so a designer can make any heading look however the layout needs without changing its level.
5. A simpler navigation that drops internal links
A cleaner menu is often the most visible change in a redesign. It's also where internal links quietly disappear. A page that used to be linked from every page in the site menu, and is now three clicks deep or only reachable through search, has lost much of what told Google it mattered.
Check that every important page is still linked from the navigation or from related pages, and that those links are real links. Google says it can generally only crawl a link if it's an <a> element with an href attribute (Google Search Central). Menus and cards that navigate with JavaScript click handlers can look fine and still be invisible to the crawler.
6. A mobile version with less on it
Google uses the mobile version of your site for indexing and ranking (mobile-first indexing). Its guidance asks for the same content, the same headings, the same titles and meta descriptions, the same structured data and the same image alt text on mobile as on desktop.
Designs drift from this in small ways: a section hidden on small screens, a shorter mobile menu, text that only loads when someone taps to expand it. Google says it won't load content that needs a swipe, click or tap to appear. The layout can differ between phone and desktop. The content and markup can't.
7. A hero that slows the page
The hero is usually the largest thing on the first screen, so it usually decides largest contentful paint (LCP), one of Google's three Core Web Vitals. The targets for a good page are LCP within 2.5 seconds, interaction to next paint (INP) within 200 milliseconds and cumulative layout shift (CLS) of 0.1 or less, measured at the 75th percentile of real visits, on mobile and desktop separately.
Three design and build choices push LCP out:
- A huge image. A photo exported at full resolution and sent to a phone that shows it a few hundred pixels wide.
- A late image. A hero set as a CSS background, loaded by a slider script or marked to lazy-load is found later by the browser. When WordPress lazy-loaded images by default, Google's own testing on web.dev found it delayed LCP.
- A crowded head. Stylesheets, scripts and fonts that must download before anything appears.
Speed is measurable in sales, not just scores. In a 2021 A/B test, Vodafone Italy rendered key HTML on the server, cut render-blocking JavaScript and resized its hero image. The faster version had a 31% better LCP and 8% more sales than the identical-looking original.
8. Fonts, sliders and scripts nobody budgeted for
Each typeface, weight and third-party tool looks small in a design file. Together they decide whether a page responds quickly to a tap (INP) and whether it jumps about as it loads (CLS). Chat widgets, cookie banners, video embeds and tags added in Google Tag Manager are the usual causes.
Set a budget at the design stage: how many font families and weights, which third-party scripts are allowed and who approved each one, and space reserved in the layout for anything that loads late, such as banners and embeds. If a page is already failing, what to fix when the Core Web Vitals assessment fails goes through it metric by metric.
9. Staging settings that reach production
A staging site has to be kept out of Google while it's being built. The settings that do that are the ones most often left behind at launch: a robots.txt that blocks the whole site, a noindex tag on every template, or canonical tags pointing at the staging domain.
Google says robots.txt "is not a mechanism for keeping a web page out of Google", and recommends noindex or password protection instead (Google Search Central). A password on staging is the safest choice, because it can't be copied to production by accident. On launch day, check the live robots.txt, the robots meta tags and the canonicals before anything else. Canonicals should be absolute production URLs; Google recommends absolute rather than relative paths (Google Search Central).
10. Leaving titles, meta descriptions and structured data out of the templates
If the new templates don't give editors a field for the page title and meta description, every page gets whatever the template generates. On large sites that often means hundreds of pages sharing one title. Structured data, such as Organisation, BreadcrumbList, Product or FAQPage, goes the same way: easy to plan into a template, slow and patchy to retrofit after launch.
List the SEO fields and schema each template needs in the specification, so they're built and tested with everything else.
What it looks like when the order is right
When I was in-house as Head of Digital at a large residential home builder, my first job was an audit of the existing site, and I ran technical SEO audits on it every week. The evidence showed the problems were structural, so I recommended a rebuild and wrote the brief before any agency saw it. An agency built the new site and I owned delivery through to launch.
After launch, organic rankings dipped slightly, as we'd expected, because the new site was built for better-qualified visitors rather than more of them. The conversion rate went up 75%. That's the trade a redesign should make on purpose, decided in the brief, not discovered in Search Console a month after launch. The home builder case study has the full story.
The website SEO design checklist
Before scoping
- Export every URL. Crawl the current site with a tool such as Screaming Frog, and add the URLs from your XML sitemap and the Search Console Pages report, so nothing is missed.
- Pull performance by page. From Search Console, export at least the last 12 months of clicks, impressions and top queries for every page.
- Mark the pages that earn. Flag every page that brings in search traffic, enquiries or links from other sites. These pages are protected in the redesign.
- List the links in. Note which of your pages other sites link to (Search Console's Links report shows this). Each one needs a working destination after launch.
- Record a baseline. Save current Core Web Vitals for your main templates, rankings for your main searches and conversions by page, so you can compare after launch.
- Check the tracking works. Test your forms and GA4 conversions now. If the numbers are wrong before the redesign, you can't tell what changed after it.
During scoping
- Sitemap from searches. One page for each service, product or topic people search for, each with a named target search term.
- A URL plan. Keep good URLs. For each one that changes, note the new address and its single 301 redirect.
- A decision for every page. Keep, rewrite, merge or retire, with a redirect target for every page that goes.
- Templates specified for search. Editable title and meta description, one H1, absolute canonical URLs, breadcrumbs and the structured data each template needs.
- A performance budget. Core Web Vitals targets on mobile for every key template, written into the brief as acceptance criteria, with limits on fonts and third-party scripts.
- A tracking plan. The GA4 events and conversions the new site must record from launch day.
- An owner. One named person who signs off search before launch, because in most projects it falls between the designer and the developer.
At design and build
- Headings by structure. One H1 per page, H2 and H3 in order, with type styles kept separate from heading levels.
- Navigation keeps the links. Every important page is linked from the menu or related pages, with real
<a href>links, on mobile as well as desktop. - Mobile parity. The same content, headings, alt text and structured data on phone and desktop, with no primary content loaded only on a tap.
- A fast hero. The main image is a real image, sized for each screen, never lazy-loaded and not hidden in a slider or CSS background.
- Space reserved. Width and height set on images and embeds, and room kept for banners and notices, so the layout doesn't jump.
- Fonts and scripts on budget. Only the families and weights in the brief, and only approved third-party scripts.
- Staging locked. Staging behind a password, and a launch-day check of robots.txt, robots meta tags and canonicals.
- Redirects tested. Every URL on the list tested before launch: one hop, landing on a live, relevant page.
- A clean sitemap. The XML sitemap lists only live, canonical pages, and is submitted in Search Console on launch day.
Where to start
Most redesigns start with a design brief. Better ones start with evidence about what the current site does well in search, so the redesign keeps it.
A Website Health Check gives you that. It's an independent review of seven areas: design and UX, conversion paths and forms, performance and Core Web Vitals, technical and on-page SEO, off-page SEO and search opportunity, analytics and tracking, and your CMS, integrations and hosting. You get a written report with every fix ranked, and a call to walk through it.
From there, website redesign scoping turns it into a reverse brief and a tech spec, usually in 1 to 2 weeks, including the search and tracking plan. The scope is yours, written so any agency can quote on it. If you'd like me to build it, I quote too, leading Keal Collective, a team of vetted people I bring in, on larger builds. You deal with me from the first call to the finished work.
Pricing starts with a free 20-minute call. When the scope is clear I can usually send a ballpark by email. When the work means learning your internal systems, such as a CRM integration, it starts with paid scoping, credited against the build if I build it. Nothing starts until you've agreed the price.
