Diagnosing & Recovering a Post-Update Traffic Drop

The challenge

Organic traffic dropped sharply within a window that overlapped a Google core update, so the team's assumption was reasonable on its face — 'we got hit by the update.' Months of generic E-E-A-T-focused content revisions followed, aimed at a cause that had never actually been confirmed. Traffic kept declining. By the time this engagement started, the team had spent real budget chasing a diagnosis that was, at best, half right.

What made it harder

• A site redesign had shipped roughly three weeks before the core update rolled out, which meant two plausible causes were tangled together in the same timeline
• Server logs existed but had never been analysed — the team had been working entirely from Search Console graphs, which don't distinguish cause from correlation
• Some of the 'E-E-A-T improvements' already made had actually introduced new technical issues (added JavaScript-rendered author bios that weren't indexing correctly)
• The drop wasn't uniform — some sections held steady while others fell hard, a pattern that pure algorithmic impact rarely produces on its own

The approach

• Pulled and analysed raw server logs alongside Search Console data to see what Googlebot was actually doing — crawl frequency, response codes, rendering behaviour — not just ranking outcomes
• Segmented the traffic drop by URL pattern and template type to find where the decline concentrated, rather than treating it as one uniform site-wide event
• Found that the redesign had introduced a client-side rendering dependency on several key templates that Googlebot was intermittently failing to render — a technical regression, not an algorithmic one
• Separately assessed genuine core-update-correlated impact on the sections that were unaffected by the rendering issue, to avoid over-fixing what wasn't actually broken
• Reverted the newly-introduced JavaScript rendering issue via server-side rendering fixes and fixed the incorrectly-indexing author schema from the earlier 'E-E-A-T' pass
• Built a prioritised, sequenced recovery roadmap — rendering fix first (fastest fix, clearest win), then targeted content and entity work for the genuinely update-affected sections

The outcome

• Delivered an honest, evidence-based root-cause diagnosis instead of continuing to guess — roughly two-thirds of the drop traced to the rendering regression, not the core update
• The rendering fix alone produced measurable recovery within weeks, well before any content work had time to take effect
• Remaining update-correlated sections responded to targeted E-E-A-T and entity work over the following months
• Left the team with server-log monitoring as a standing practice, so a future drop gets diagnosed in days, not months