Should you really compare the actual state of your pages before and after a traffic drop?

Why does this statement seem so obvious?

Because it is. Martin Splitt isn't breaking new ground here. He's refocusing the debate on a basic reflex: before crying Core Update, you check if you haven't broken something yourself.

The problem is that too many sites blame Google for everything when a template modification, a CMS change, or a poorly managed redesign explains the drop. Google didn't move — your site did.

What constitutes a "real change" on a page?

Here we're talking about technical or editorial modifications visible to Googlebot. Not just a button in a different color.

This includes: content restructuring, deletion of text blocks, JavaScript rendering blockers, title/meta tag modifications, misconfigured redirects, content accidentally set to no-index, server changes with increased latency, and so on.

How does Google detect these changes?

Google crawls, indexes, and compares. If the rendered HTML content differs between two crawls, the algorithm can reassess the page's relevance.

The delta can be subtle: a canonical tag that changes, poorly formatted schema markup, load time that explodes. All of this impacts ranking — independent of any update.

• A traffic drop coinciding with a Google update doesn't necessarily imply an algorithmic penalty.
• Comparing the actual state of pages (HTML, response time, rendered content) before/after is essential to diagnose a drop.
• Historical crawl tools (Wayback Machine, internal archives, server logs) are critical for this analysis.
• Google doesn't communicate on every micro-adjustment — so attributing a drop to "the algo" without proof is a methodological error.

Is this statement truly useful or just common sense?

Both. It's common sense, yes — but common sense often neglected under client pressure. When traffic drops 40%, the urgency pushes you to find an external culprit (Google) rather than methodically audit your own changes.

Martin Splitt reminds us of a basic discipline: keep a log of modifications. Without it, you can't correlate a drop to a specific action. How many sites have no traceability of their deployments? Too many.

In what cases does this rule not apply?

If the site has changed absolutely nothing (neither content, nor technical, nor hosting) and a sudden drop occurs on the day of a confirmed Core Update, then yes, the algo is probably responsible.

But even then, you must cross-reference with competitor data: if the entire sector drops, it's sector-wide. If only your site tanks, it's you. [To verify]: Google doesn't provide an official tool to compare a page's indexed state at two precise dates — you have to improvise with Google Cache (when it still exists), archives, and crawls.

What is the real practical difficulty?

Reconstructing the exact state of a page as Googlebot saw it at an earlier date. The current source code isn't enough if JavaScript modifies the DOM afterward.

You need to crawl with a tool that renders JS (Screaming Frog in JavaScript mode, OnCrawl, Botify, etc.), compare HTML snapshots, cross-reference with server logs to see if Googlebot properly recrawled after the modification. It's time-consuming — and often overlooked due to lack of internal resources.

What should you do concretely when facing a traffic drop?

First step: build a timeline of modifications. Git commits, JIRA tickets, deployment logs, CMS/plugin updates, server changes. Everything must be dated.

Second step: compare the crawled state before/after. If you don't have historical crawl data, use Wayback Machine, Google Cache (if still available), or snapshots from your SEO tool (Oncrawl, Botify, Semrush Site Audit sometimes keep history).

What tools should you use for this comparison?

For content and HTML structure: Screaming Frog in crawl comparison mode, diff tools (WinMerge, Beyond Compare) on HTML exports. For JS rendering: a headless crawler (Puppeteer, Playwright) that captures the final DOM.

For server logs: Botify Log Analyzer, OnCrawl, or custom scripts (Python + pandas) to cross-reference Google crawl dates and modification dates. If Googlebot didn't recrawl after your modification, the drop can't come from there.

How do you avoid repeating the mistake?

Implement a pre-deployment SEO validation process. Technical checklist (tags, redirects, canonicals, response time), staging crawl, diff comparison, sandbox testing before production.

Automate as much as possible: unit tests on critical tags, real-time post-deployment monitoring (alerts if the number of crawlable pages drops, if titles change dramatically, etc.).

• Maintain an exhaustive log of all modifications (code, content, infrastructure, third-party plugins)
• Crawl the site regularly and archive HTML snapshots (minimum monthly, ideally weekly)
• Set up Search Console alerts on indexation errors and sudden click variations
• Cross-reference the drop date with server logs to verify if Googlebot recrawled right after a modification
• Compare rendered HTML (post-JS) not just the raw source
• Audit external dependencies (CDN, third-party scripts, plugins) that can change without you knowing
• Don't systematically attribute a drop to a Core Update without objective proof