Technical SEO & Core Web Vitals Recovery After a Redesign
A B2B software vendor launches a redesigned website and watches organic traffic fall over the following weeks. This blueprint shows how we find what the redesign broke, fix crawling, rendering and performance at the source, and put monitoring in place so the next release does not repeat the problem.
This is a solution blueprint: a representative engagement showing how we approach this kind of project. It is not a specific client story.
IndustryB2B Marketing & Content
Timeline2–3 weeks of audit, then 2–4 months of fixes and monitoring
Teamtechnical SEO lead, 2 front-end engineers, content strategist, part-time designer
The Challenge
Old URLs were changed or removed at launch without a complete redirect map, so links and indexed pages now return 404s or redirect chains.
The new front end renders key content and internal links in client-side JavaScript that crawlers do not reliably see.
Large hero images, web fonts and third-party scripts push LCP, INP and CLS into the "needs improvement" or "poor" range.
Hundreds of articles and resource pages have no clear structure, so topics compete with each other instead of supporting each other.
What the Solution Delivers
Every legacy URL mapped to a live equivalent with single-hop redirects
Primary content and internal links present in server-rendered HTML
Core Web Vitals measured on real-user data and checked on every release
Content organized into topic clusters with a clear internal-linking model
Architecture
Recovery workflow and site architecture
Crawl data, Search Console and field performance data feed a prioritized audit. Fixes ship through a static or server-rendered build behind a CDN, and a monitoring pipeline catches regressions before they affect search visibility.
The situation
A redesign usually changes more than the look of a website. URL patterns change, templates are rebuilt, a new JavaScript framework replaces the old CMS theme, and content is merged or dropped. If nobody owns search during the migration, the damage shows up weeks later: indexed pages disappear, rankings slide for terms the site used to own, and the marketing team cannot tell whether the cause is the redesign, an algorithm update or seasonality.
Teams in this situation need two things quickly: a clear diagnosis of what changed, and a set of fixes ordered by impact rather than by whichever tool reported the most warnings.
Our approach
1. Establish what changed
We crawl the current site with JavaScript rendering on and off, and compare it against the pre-launch URL inventory rebuilt from old sitemaps, analytics, backlink data and the Search Console export. This gives a page-by-page view of which URLs were removed, redirected, consolidated or left orphaned, and which ones lost clicks and impressions after launch.
2. Repair crawling and indexation
Every legacy URL with traffic or backlinks gets a mapped destination. We implement redirects as single-hop 301s at the CDN or server layer, remove redirect chains, fix canonical tags that point to the wrong version, and clean up sitemaps so they list only indexable, canonical pages. Soft 404s, parameter duplicates and accidental noindex directives are resolved at the template level so they do not come back.
3. Make content visible without JavaScript
When the main copy, headings or internal links only appear after client-side rendering, crawlers may index a thin version of the page. We move those templates to server-side rendering or static generation, with frameworks such as Astro or Next.js, so the first HTML response contains the content that matters. Interactive components still hydrate on the client, but they no longer hide the page from search engines.
4. Engineer for Core Web Vitals
We work from field data (Chrome UX Report and real-user monitoring), not only lab scores. For LCP, that usually means preloading the hero image, serving responsive AVIF or WebP from the CDN and removing render-blocking CSS. For INP, we break up long tasks, defer non-critical third-party scripts and reduce hydration cost. For CLS, we reserve space for images, embeds and fonts and stop late-loading banners from shifting the layout.
5. Add structure to content and markup
We group articles and resource pages into topic clusters, each with a pillar page and supporting pages that link to it and to each other. Overlapping pages are merged or differentiated so they stop competing. Templates emit Schema.org JSON-LD for organization, articles, breadcrumbs, FAQs and software products where it genuinely applies, and we validate it on every build.
6. Monitor so it does not happen again
Search Console data is exported daily to BigQuery, joined with crawl and performance data, and surfaced in Looker Studio dashboards with alerts for drops in indexed pages or clicks. Lighthouse CI runs performance budgets on every pull request, so a heavy new script or an unoptimized image is caught before it ships.
How we deliver it
The first two to three weeks produce a prioritized audit: each issue has an owner, an estimated effect and a fix. Redirects and indexation problems go first because they block everything else. Rendering and performance work follows in sprints, released gradually and checked against crawl results and field data after each release. Design changes, such as simpler hero layouts or lighter components, are handled with our web design team so the site still looks and works the way the brand intends.
Search engines take time to recrawl and reassess a site, so we set expectations honestly. We can fix the technical causes of lost visibility and make the site easier to crawl and faster to use, but no one can guarantee specific rankings.
Is this relevant to you?
If organic traffic dropped after a redesign or platform migration, or your Core Web Vitals report shows a growing number of poor URLs, this approach is a good fit. Explore our SEO services or talk to us about what changed on your site.
Building something similar?
We'll walk through your requirements and share how we'd approach architecture, timeline and team for your project.
We use essential technologies to run this site. With your OK, we also use cookieless analytics and Google Maps, which may set cookies. No ads, and we never sell your data. Cookie Policy
Privacy preferences
Choose which optional technologies we may use. Strictly necessary ones are always on because the site can’t work securely without them. Details are in our Cookie Policy.
Your browser sends a Global Privacy Control signal, so optional technologies are off by default.
Strictly necessary
Security and spam protection (Cloudflare, Google reCAPTCHA), form delivery, and remembering these choices.
Always on
Cloudflare Web Analytics counts page views without cookies or cross-site tracking.
Shows our office on Google Maps. Google may set cookies and receive your IP address.