Organic traffic falls 30% overnight. Nothing in the error logs looks wrong, the homepage loads fine, and a spot check of a few URLs shows nothing unusual. Someone suggests an algorithm update. Someone else blames last week's release. Nobody has evidence.
SEO incident investigation is the process of identifying an unexpected SEO change, establishing when it started, determining what it affected, and gathering enough evidence to identify the most likely cause. The goal isn't to find something that looks suspicious. It's to connect a chain of evidence:
Every link in that chain needs its own evidence. A deployment that happened before a drop is a lead, not a conclusion.
What Is an SEO Incident?
An SEO incident is an unexpected change that affects a website's ability to be crawled, indexed, understood, or shown in search. Common examples include a sudden drop in clicks or impressions, important pages disappearing from the index, a spike in excluded URLs in Search Console, canonicals or titles changing across a template, a robots.txt change, a migration that behaves differently in production than in testing, and search performance shifting right after a release.
The incident is the symptom, not the cause. "Organic traffic dropped 35%" describes what happened. It doesn't say why. The cause could be a deployment, a template change, an indexing shift, a manual action, a core update, seasonality, a tracking failure, or several of these at once. Investigation separates the symptom from the cause.
Step 1: Run the Five-Minute Checks First
Before building a full investigation, rule out the causes that are fast to confirm and serious when present:
- Manual Actions report in Search Console
- Security Issues report (hacked content, malware)
- robots.txt still allows Googlebot
- Key pages return
200and are indexable - Google Search Status Dashboard for active updates
- Analytics tag still firing on all templates
Any one of these can explain a sudden drop on its own. If all six are clean, move to the full investigation.
Step 2: Build the Timeline
The first question isn't "what is broken?" It's "when did this start?" Build a timeline before changing anything. Include deployments, CMS releases, template changes, redirect and robots.txt edits, sitemap updates, CDN or hosting changes, firewall rule changes, tracking changes, and confirmed search engine updates.
| Event | Date and time | Relationship to incident |
|---|---|---|
| Website deployment | Monday 09:00 | Before decline |
| Product template changed | Monday 09:15 | Potentially relevant |
| Impressions begin falling | Tuesday | Incident begins |
| Traffic decline visible in reports | Thursday | Impact confirmed |
| Rollback | Thursday | Possible recovery point |
Also remember that core updates roll out over roughly two weeks. Impact may not land on the announcement day, and a deployment during a rollout window makes timing alone even less conclusive.
Step 3: Define Exactly What Changed
"SEO is down" can't be investigated. Break the incident into measurable changes: clicks, impressions, average position, CTR, indexed pages, crawl requests, excluded URLs, status codes, canonicals, titles, internal links, and rendered content.
SEO traffic dropped.
Organic clicks dropped 28% from Tuesday while impressions held steady, concentrated in product pages.
The second statement already rules out large indexing loss and points toward CTR, snippets, or SERP changes. Search Console's comparison mode and regex filters on page and query make this split fast.
Step 4: Determine the Scope
Scope is one of the strongest clues in any investigation. One URL suggests a page-level cause. Every product page suggests a template. Every URL suggests site-wide configuration or infrastructure.
| Pattern | Investigation direction |
|---|---|
| One URL | Page-specific edit, redirect, or content change |
| One template | CMS or template change |
| One directory | Directory rules, robots.txt, or a scoped deployment |
| Most URLs | Site-wide config, CDN, firewall, or manual action |
| One country | hreflang, localization, or regional serving |
| Mobile only | Mobile rendering or mobile-specific templates |
| Impressions down | Visibility loss or falling demand (check Google Trends) |
| Clicks down, impressions stable | CTR, snippets, or SERP features such as AI Overviews |
These are directions, not diagnoses. The last row deserves special attention: when a new SERP feature, especially an AI Overview, starts appearing for your queries, clicks can fall with no change on your site at all.
Step 5: Identify the Layer
An apparent SEO incident can originate in three different places, and they can overlap. Jumping straight from "traffic dropped" to "the site is broken" sends investigations in the wrong direction.
The site changed
Noindex added, canonicals changed, links removed, URLs erroring, content removed, Googlebot blocked by a firewall.
Reporting changed
Tag removed, GA4 configuration edited, consent mode reducing tracked sessions, attribution changed.
Search changed
Core or spam update, SERP layout change, AI Overviews, competitor gains, shifting demand.
A quick test for the measurement layer: if Search Console clicks are stable but GA4 organic sessions fell, the problem is almost certainly tracking, not search. To check the search layer, look at whether competitors and unrelated sites in your niche moved on the same dates.
Step 6: Compare Against a Known-Good State
A current crawl only shows what exists now. An investigation needs a comparison with a crawl from before the incident. If you have audit history from regular monitoring, that's your first piece of evidence. Compare status codes, redirects, canonicals, robots directives, X-Robots-Tag, titles, headings, internal links, structured data, hreflang, and rendered content.
The question isn't simply "what is different?" It's "which differences appeared at the same time as the incident and could reasonably explain it?"
Two more sources help here. Search Console's URL Inspection tool shows the indexed version of a page next to a live test, which quickly exposes a canonical or rendering change Google has already picked up. And if you have no prior crawl, the Wayback Machine can often supply historical HTML for key templates.
Step 7: Check the Server Logs
Logs show what Googlebot actually received, which a browser test can't. Look for changes in Googlebot request volume, response codes served to Googlebot, and crawl activity by directory around the incident date.
403 or challenge pages, you've likely found the cause. Verify that requests claiming to be Googlebot are genuine using reverse DNS before drawing conclusions.Step 8: Find the Shared Mechanism
When thousands of URLs are affected, don't inspect them one by one. Group affected pages by template, directory, content type, and deployment, then look for what they have in common.
8,000 pages lost traffic.
8,000 product URLs on the same template lost impressions within days of a template deployment, while category pages stayed flat.
Large-scale incidents usually trace back through a shared dependency:
Check whether the affected URLs share canonical logic, robots directives, a JavaScript component, or an API or data source that changed.
Step 9: Test the Suspected Cause
Once you have a leading hypothesis, test it rather than stopping at correlation:
- What exactly changed in the suspected component?
- Which URLs use it, and did those URLs decline?
- Did URLs without it stay stable?
- Does the change affect crawling, indexing, relevance, or snippets?
- Can the behavior be reproduced in a crawl or URL Inspection test?
- Did reverting the change alter the behavior?
The more independent answers point to the same explanation, the stronger the conclusion.
Step 10: Rank Your Evidence
Strong
- Change shipped right before impact
- Affected pages share the changed component
- Unaffected pages don't have it
- Logs or URL Inspection confirm Google saw it
Moderate
- Close timing
- Affected pages share a template
- Similar pages stayed stable
- Crawl comparison shows a difference
Weak
- Someone remembers a change
- Timing is roughly related
- One page looks unusual
- A change "could have" mattered
Preserve Evidence Before Fixing
The most common investigation mistake is fixing everything at once. Someone sees a drop and immediately rewrites titles, changes canonicals, edits robots.txt, and updates internal links. Now the original cause is buried under new changes, and nobody can tell which fix worked.
Before changing anything, save the affected URLs, a crawl of the current state, screenshots, Search Console exports, relevant log extracts, and deployment details with timestamps. Then make the smallest corrective change you can, and change one variable at a time where possible.
When You Can't Reproduce the Problem
Some incidents disappear. The deployment was already rolled back, the CDN cache expired, or the problem only lasted a few hours. Every test now looks normal. That doesn't mean the incident wasn't real.
The question changes from "can we reproduce it?" to "what evidence shows what happened during the incident?" Look at previous crawl data, server and CDN logs, deployment logs and Git commits, CMS revision history, monitoring alerts, Search Console and analytics data, historical HTML captures, and archived page versions.
Write the Root-Cause Timeline
Summarize the finding as a sequence, not a label. "The site had canonical problems" explains nothing. A timeline explains what happened:
| When | Event |
|---|---|
| Mon 09:00 | New product template deployed |
| Mon 09:30 | Template begins outputting category URLs as canonicals |
| Tue | Product pages begin losing impressions |
| Thu | Drop visible in reports; investigation isolates the template |
| Thu | Template rolled back |
| Following 1 to 3 weeks | Google recrawls; indexed canonicals and impressions recover |
Document the Incident
Every incident should leave a record behind. A short postmortem turns an isolated problem into operational knowledge:
| Section | What to record |
|---|---|
| Impact | Pages, queries, directories, and traffic affected |
| Detection | How and when the incident was discovered |
| Timeline | Relevant changes and impact, with dates |
| Evidence | What was collected and what it showed |
| Root cause | The change that caused the incident |
| Contributing factors | What made it possible or slow to detect |
| Resolution | What was changed to restore normal behavior |
| Prevention | Monitoring, testing, or process changes to stop a repeat |
The prevention line matters most. If the incident took three days to notice, the fix isn't just the rollback. It's a staging crawl, an alert threshold, or a release check that catches the same change next time.
The Investigation Workflow at a Glance
- 1Quick checksManual actions, security issues, robots.txt, key page status, update dashboard, tracking.
- 2TimelineDate the incident from the data and list every change around it.
- 3Define and scopeName the exact metric that changed and which pages, templates, or segments it affects.
- 4Identify the layerWebsite, measurement, or search.
- 5Compare and inspectCrawl comparison, URL Inspection, server logs.
- 6Test and rank evidenceConfirm or weaken the leading hypothesis with independent signals.
- 7Fix, monitor, documentMake the smallest change, watch recovery, and write the postmortem.
The Goal Is Evidence, Not a Guess
Incidents create pressure to name a cause quickly. A drop becomes "an algorithm update," a deployment becomes "the cause," a crawl error becomes "the problem." None of those conclusions should be automatic.
A good investigation asks what changed, when, where, what else changed at the same time, what supports the suspected cause, and what contradicts it. The result is a precise fix instead of a round of guesses, and a record that makes the next incident faster to solve. If you don't have crawl history yet, the best time to start monitoring with SiteAuditLint is before the next incident, so the evidence already exists when you need it.
What changed, when, where, and what proves it.