Your traffic dropped after the website redesign

The first question is whether search demand fell or your measurement did. A redesign is exactly the moment analytics breaks: a tag that never made it into the new templates, a consent banner behaving differently, a purchase event firing on a page that no longer exists. Analytics sessions are the wrong instrument for this diagnosis. Open Search Console, take the Performance report, and compare clicks and impressions over a window long enough to be stable — sixteen months if you have it — against the same period last year rather than the fortnight before launch. Those clicks come from Google's own logs and do not care whether your tags survived. Then read the shape: impressions holding steady while clicks fall points at titles, snippets and lost rich results; impressions falling alongside them points at indexing or ranking. That distinction decides everything you do next.

• Compare Search Console clicks, not analytics sessions
• Use year-over-year windows to rule out seasonality
• Check whether impressions fell too, or only clicks
• Break the loss down by page group and by query

The most expensive causes are also the dullest, and they sit at the top of the list because they can remove a site from search entirely within days. A staging environment is usually blocked with a noindex tag or a disallow rule, and when the new build is promoted to production those blocks travel with it. In WordPress the same thing happens through the 'Discourage search engines' checkbox in Reading settings. Check three places before anything else: fetch your robots.txt in a browser and read it line by line, run the URL Inspection tool's live test on your homepage and three deep product pages, and look at the Pages report for a spike in 'Excluded by noindex' or 'Blocked by robots.txt'. Also check response headers for an X-Robots-Tag, which is invisible in page source and routinely missed. Pages missing from Google covers the same checks outside a redesign.

If any URL changed, every old address needs a permanent redirect to its closest equivalent. Google's site move documentation is explicit that a 301 is how ranking signals move to the new URL, and its absence is why a launch that looks perfect to a visitor reads as a mass deletion to a crawler. Four failure modes account for most of the damage. Redirects that were never written, so old URLs return 404. Redirects that chain through two or three hops, diluting and slowing everything. Temporary 302s used because they were easier to configure. And the blanket rule that sends every old URL to the homepage, which Google treats as a soft 404 rather than a match. Pull your old URL list from the previous sitemap, Search Console and server logs, then request each one and record the final status.

• Every old URL returns 301, not 404, 302 or a homepage bounce
• No redirect chains: one hop from old address to final page
• Trailing slash, case and www variants resolve consistently
• The new sitemap lists only live, canonical, indexable URLs

Redesigns quietly change the shape of a site, not only its skin. Permalink structures get tidied, a category base is dropped, a product prefix is added, and every affected page starts again from zero unless it was mapped. Content disappears the same way: long category descriptions that did not fit the new layout, buying guides nobody could place in the navigation, filter and comparison pages the new template did not support. Then there is the link graph. A slimmer menu and fewer cross-links mean deep pages that used to receive internal links now receive none, and they drift down regardless of their own quality. Crawl the archived version of the old site, crawl the new one, and diff the two URL lists and their internal link counts. Redesigning without losing SEO explains how that parity is protected before launch instead of after.

This is the cause behind the pattern where impressions stay flat and clicks collapse. Title and description templates usually live in the SEO plugin but can be overridden by a theme, so a new theme can silently replace years of tuned titles with a generic pattern, or duplicate one title across a whole catalogue. Headings suffer similarly when a hero graphic takes the H1 slot and the real product name becomes an H2. Structured data is the other half: product markup with price and availability, breadcrumb markup, FAQ markup, all of it typically emitted by templates that were just rewritten. Lose it and you lose the rich results that earned the click. Crawl both versions, export titles, descriptions, H1s and detected schema types, and diff them page by page. Fix the templates rather than individual pages, or you will do it twice.

The quieter causes take longer to surface and longer to reverse. A canonical tag left pointing at the staging domain, or every page canonicalising to the homepage, tells Google to consolidate your entire catalogue into one URL. Broken hreflang return tags split signals across language versions instead of joining them. Paginated category pages that lost their crawlable links strand everything beyond page one. Then rendering: if the new storefront serves an empty shell and builds content in the browser, indexing depends on a rendering step that is neither instant nor guaranteed, so check what Google actually sees in the live test rather than in your browser. Speed matters too, though it is rarely the primary cause of a sharp drop — a slower build erodes results gradually. Core Web Vitals covers what the thresholds are and how field data updates.

• Every page canonicalises to itself on the production domain
• Hreflang pairs return to each other, with a valid x-default
• Paginated and filtered pages keep crawlable links
• Rendered HTML in the live test contains the real content

The diagnosis has to survive one more test before you rebuild anything. Core algorithm updates roll out over weeks, and a launch that happened inside that window will be blamed for a decline it did not cause. Competitors relaunch too, and one of them expanding into your best category will show up as your loss. Search result layouts change, and informational queries in particular now lose clicks to answers shown above the results even when positions are unchanged. Test it this way: is the drop site-wide or confined to one page group, does the curve fall off a cliff on launch day or slide from a date that has nothing to do with you, and did anything technical actually change on the pages that lost the most. If nothing technical changed and the timing does not match the launch, the honest answer is that this is a content and competition problem, and the cheapest response is to wait for a full update cycle before spending anything.

Work strictly in order: indexability, then redirects, then URL and content parity, then metadata and structured data, then speed and design. Nothing cosmetic matters while a robots rule is still blocking the crawler. Once the fix ships, recrawling large sites takes days to weeks, and full recovery usually runs several weeks to a few months. Be prepared for partial recovery — pages whose content genuinely changed may settle at a different level, and that is not a fixable defect. Prevention is cheaper than any of this: before the next launch, crawl the current site, map every URL to a destination, diff titles, H1s and schema between staging and production, protect staging with a password rather than a noindex tag, and crawl the live site the hour it ships. What this work costs is published so you can judge whether the recovery is worth outsourcing.