Your Redesign Tanked Your Rankings. Here’s How I Diagnose the Damage.
Published: February 27, 2026 · Last updated: April 7, 2026
A site redesign paired with an algorithm update is the fastest way to lose half your organic traffic. I see at least one of these a quarter. The owner launches a beautiful new site, the traffic graph drops a cliff within weeks, and by the time I’m called in, everyone is blaming everyone else.
Before we fix anything, we have to figure out what actually broke. Here’s the five-step diagnosis I run on every post-redesign recovery engagement.
Step 1: Start in Google Search Console, not Google Analytics
The first place I look is not Google Analytics. It is the Pages report inside Google Search Console. GA4 tells you that traffic dropped. GSC tells you why.
Pull up the Indexing > Pages report and look at the ratio of indexed pages to not-indexed pages. On a healthy site, most of your submitted URLs should be in the indexed column. On a broken post-redesign site, I have seen the ratio flip completely. One recent commercial photography site I audited had 11 pages indexed and 54 not indexed after a January redesign. That’s 83 percent of the site missing from Google’s index.
The reasons a page lands in “not indexed” tell you the story. “Page with redirect” means your new URLs didn’t get the redirect map right. “Alternate page with proper canonical tag” is usually fine. “Crawled, not indexed” means Google saw the page and decided it wasn’t worth keeping. “Soft 404” means your page is technically loading but Google thinks it’s empty. Each of these points to a different fix.
Step 2: Identify your top 50 URLs from the year before and audit each one
Open your analytics, pull the top 50 pages by organic sessions from the 12 months before the redesign, and check each one on the new site. Does it return a 200? Does it redirect to the right place? Or is it a 404?
Any 404 is direct traffic loss. The URL had traffic, the URL had backlinks, and now the URL is gone. A 301 redirect to the homepage is better than a 404 but worse than a 301 to the right new page. A 301 to a closely related page is the target.
This is the single most important audit step on a post-redesign recovery. If your redirect map was built from the old sitemap instead of from landing-page traffic data, you probably left value on the floor. Fix this first.
Step 3: Compare the old sitemap to the new one
Orphaned pages are pages that used to be in your sitemap and are not anymore. Missing pages are pages that should have been ported over and weren’t. Non-canonical paths are pages that still live on the server but are now only reachable through old URLs that aren’t linked from anywhere.
I compare both sitemaps side by side. If a page I expected to see is missing, I check whether it was deleted intentionally or lost in migration. If a page I don’t recognize shows up in the new sitemap, I investigate whether it’s a new marketing page or an auto-generated template artifact that shouldn’t be public.
Worth saying: some CMS platforms auto-populate the sitemap with non-canonical variants of pages that exist under multiple paths. If you see the same page at both `/services` and `/services-1` in the new sitemap, you have a consolidation problem.
Step 4: Compare the old on-page signals to the new
Pick five pages that used to rank well and compare the on-page signals from before and after. You can use the Wayback Machine to see the old version and a live view for the new one.
What to compare: the H1 tag text, the title tag, the meta description, the total word count, the H2 structure, the internal link count, and whether schema was implemented. If the new template gutted any of these, you have a signal integrity problem, not a technical problem.
This is the place I most often find the real culprit. A redesign that replaces long-form service page copy with three bullet points and a photo strips the page of the content that was actually earning the rankings. No amount of technical fixes will bring back rankings that were earned by content that no longer exists on the page.
Step 5: Overlay the launch date with algorithm update dates
Google runs core updates several times a year. Some are gentle, some are significant. If your redesign launched within two weeks of a core update, you may be looking at two problems stacked on top of each other: a redesign that lost on-page signal integrity, and a core update that rewarded the competitors who kept theirs.
Separating these two is important because the fixes are different. A redesign problem is fixable through restoration: bring back the lost content, fix the redirects, restore the schema. A core update problem is fixable through improvement: strengthen your EEAT signals, improve topic depth, demonstrate real expertise.
Do both at once and you will recover. Do neither and you will blame the wrong thing for the next 12 months.
The schema you lost without noticing
One finding I surface on almost every post-redesign audit is schema loss. The old template had JSON-LD schema configured, either manually added or generated by a plugin. The new template either dropped it entirely, replaced it with a different type that doesn’t match the page, or kept the plugin active but broke the data flow so the schema renders with empty fields.
Schema loss is invisible to most site owners. The front end looks fine, the page loads, nothing is visibly broken. Meanwhile Google Rich Results Test shows zero valid items, and the rich results that used to appear in search listings are quietly gone. The fix is to rebuild the schema into the new template and validate it page by page.
On a recent recovery engagement for a commercial photography site, the old template had generated Organization, Person, and Service schema automatically. The new template kept Organization but dropped the other two. The site had been signaling its creative expertise to Google through Person schema and its service offerings through Service schema, and the redesign erased both signals. Restoring them was part of the recovery roadmap, and the team would never have noticed without looking.
When you’re diagnosing a post-redesign drop, pull up Rich Results Test and check a handful of your most important pages. If schema is gone or broken, add it to the fix list alongside the redirect work and the content restoration.
Coordinating with the design agency on the next one
If you’re reading this after a redesign has already happened, the most valuable thing you can take away is not how to recover. It’s what to require on the next redesign so this doesn’t happen again.
My short list for any redesign scope of work:
- SEO audit of the current site before the redesign begins, with a full inventory of top-traffic URLs, top-ranked keywords, and current schema.
- A redirect map built from landing page traffic data, not from the old sitemap. Delivered before launch, not after.
- On-page signal preservation: the H1, title tag, meta description, and content length of every page that has traffic must be preserved or improved, not stripped.
- Schema parity: whatever schema was present on the old site is rebuilt or improved on the new one.
- A staging environment where the SEO consultant can audit pages before launch.
- A launch day monitoring plan: GSC crawl stats, organic traffic by landing page, keyword rankings. Check daily for the first two weeks.
Any redesign contract that does not include all six is a redesign contract that can lose you traffic. It is not the design agency’s fault if they were not asked to protect it. Build the ask into the scope at the start. If you want context on how the three legs of SEO work actually support each other through a transition, I wrote about that in The SEO Triangle.
My honest take on redesign recovery
Most “the redesign killed my SEO” stories are actually three problems stacked together. A redirect map that was built from the wrong source data. A template that stripped on-page signals from the pages that were earning rankings. An algorithm update that rewarded the sites that kept their content integrity.
Clients usually arrive angry at the design agency. Sometimes they’re right. More often, the design agency did what they were hired to do, which was make the site look better, and nobody was hired to protect the SEO during the transition.
The fix is to make that hire at the start of the next project, not at the end of the current one.
The realistic recovery timeline
New content takes 4 to 8 weeks to rank. Recovery from a redesign and a core update stacked together takes 2 to 12 weeks to stabilize after the fixes are in. That’s a long time to wait with traffic on the floor, but rushing the diagnosis rarely ends well. Give the fixes time to propagate and re-crawl before you panic again.
The single biggest mistake I see on post-redesign recovery engagements is that nobody was hired to protect the SEO during the redesign itself. If you’re planning a redesign in the next six months, build that role into the scope from the start. It is the cheapest version of this problem, and every dollar you spend on SEO oversight before launch saves ten on recovery work after it.
If you’re currently inside a post-redesign drop and want a second set of eyes before you start making changes, the contact form is open and I’m taking a small number of recovery engagements this quarter. Here’s where to start.
About the author
Victoria Temiz is the founder of Vita Digital, an independent SEO consultancy based in Minneapolis. She is certified in Digital Marketing and in Project Management from the University of St. Thomas, and holds an SEO credential from UC Davis Extension. She has been building and running her own websites since 2007 and has focused specifically on SEO and search since 2020. She is also a working jazz vocalist. More about her work.