The fastest way to understand forensic SEO is to watch one investigation happen from start to finish. Below is a step-by-step walkthrough built from the patterns we see repeatedly at Salterra, composited into a single representative case so the method is clear without exposing any one client’s data.
- Step One: Establish the Symptom, Precisely
- Step Two: Build the Change Timeline
- Step Three: Diff the Old Site Against the New Site
- Step Four: Crawl for Technical Regressions
- Step Five: Confirm With Server Logs
- Step Six: Prescribe the Fix, Not Just the Diagnosis
- Step Seven: Monitor the Recovery Curve
- What This Case Illustrates
The scenario: a regional home-services company relaunches its website on a new platform, and organic traffic falls off a cliff in the following weeks. The in-house team assumes it’s a Google penalty. It isn’t.
Step One: Establish the Symptom, Precisely
Before touching a single tool, we define exactly what “traffic dropped” means. Is it clicks, impressions, or both? Is it every page or a subset? Is it every query or specific ones? Vague symptoms lead to vague investigations. In Google Search Console, we pull the Performance report, split by date, and compare the eight weeks before the reported drop against the eight weeks after — not just “before vs. now,” since ranges chosen carelessly can hide or exaggerate the real shape of the decline.
In this case, impressions held roughly steady but clicks fell sharply, and average position for the site’s core service pages slipped from the first page to the second. That single distinction — impressions steady, clicks and position down — already rules out a full deindexing event and points toward something changing on-page or in how pages were being served.
Step Two: Build the Change Timeline
Next we build a literal calendar. On one axis: the Search Console performance line, plotted weekly. On the other: every known change to the site — the relaunch date pulled from the client’s project files, any DNS or hosting migration dates from the registrar, and confirmed Google algorithm update windows from Google’s own Search Central update history.
The relaunch date lines up almost exactly with the start of the decline, three days ahead of the first visible dip in Search Console (expected, since Google needs to recrawl before performance data reflects a change). No confirmed algorithm update falls in that window. That’s the first strong signal: this is self-inflicted, not something Google did to the site.
Step Three: Diff the Old Site Against the New Site
This is where the Wayback Machine earns its keep. We pull the last Wayback snapshot of the top ten highest-traffic URLs before the relaunch and compare them line by line against the live pages today. We’re checking:
- Title tags and H1s — did they change, and did target keywords get diluted or dropped entirely?
- URL structure — did slugs change without redirects?
- Internal linking — do the old contextual links between service pages still exist, or did the new template strip them?
- Word count and on-page content — did the new design compress long-form service descriptions into short marketing blurbs?
In our composite case, the new template preserved URLs (good) but replaced descriptive, keyword-rich H1s with a generic branded tagline used site-wide, and cut internal links between related service pages from an average of six per page down to one. Both are classic relaunch casualties — decisions made by a designer optimizing for visual cleanliness with no idea they were dismantling the internal link graph that told Google which pages mattered.
Step Four: Crawl for Technical Regressions
We run a full Screaming Frog crawl of the live site and compare it against an archived pre-relaunch crawl (if one exists) or a Wayback-reconstructed URL list. This step catches what manual comparison misses at scale:
- Canonical tags pointing to the wrong URL, or all pointing to the homepage — a shockingly common CMS-migration default.
- Noindex tags accidentally left on from a staging environment.
- Broken or missing redirects from old URLs that changed after all.
- New render-blocking scripts or bloated page weight tanking Core Web Vitals.
The crawl in our case surfaced the real smoking gun: the new CMS was auto-generating canonical tags that pointed every service page to the homepage. Google was correctly reading the signal it was given — that the homepage was the canonical version of every page — and consolidating ranking signals there instead of the individual service pages that used to rank.
Step Five: Confirm With Server Logs
Whenever the client can provide them, server logs remove ambiguity. We check Googlebot’s crawl frequency and behavior on the affected URLs before and after the relaunch. In this case, log analysis (via Screaming Frog’s Log File Analyser) showed Googlebot still crawling the service pages regularly — confirming the pages weren’t deindexed or ignored, just being consolidated under the wrong canonical, exactly matching the crawl findings.
This step matters because it turns a hypothesis into a confirmed cause. Without it, “the canonical tags are probably the problem” is still a guess, however well-supported by circumstantial evidence.
Step Six: Prescribe the Fix, Not Just the Diagnosis
A forensic investigation isn’t complete until it produces an actionable, prioritized fix list, ranked by evidence strength and effort:
- Fix the canonical tag logic so each page self-canonicalizes — the highest-confidence, highest-impact item.
- Restore descriptive, keyword-relevant H1s on the top service pages.
- Rebuild the contextual internal linking between related services that the new template stripped.
- Re-submit the corrected URLs for recrawling via Search Console’s URL Inspection tool to accelerate recovery.
Each item traces directly back to a piece of evidence gathered in steps one through five — nothing on the list is a generic best practice bolted on for good measure.
Step Seven: Monitor the Recovery Curve
The investigation doesn’t end at the fix. We track weekly Search Console data for the following weeks to confirm the diagnosis was correct — clicks and average position should begin recovering roughly in line with Google’s recrawl cadence for the affected URLs. If the curve doesn’t move, that’s a signal the root cause wasn’t fully identified, and the investigation reopens rather than assuming “SEO just takes time” will paper over an unresolved technical fault.
What This Case Illustrates
The pattern here — a well-intentioned redesign quietly breaking canonical logic and gutting internal links — repeats constantly across relaunches, regardless of platform or industry. The forensic method doesn’t need to know the answer in advance. It needs a precise symptom, a reliable timeline, and enough historical evidence to turn a hypothesis into a confirmed cause before a single hour is spent on a fix.
Frequently Asked Questions
What's the first thing to check in any forensic SEO case study?
The exact shape of the symptom in Google Search Console — whether it's impressions, clicks, or position that changed, and for which pages and queries. This determines which direction the rest of the investigation takes.
Why compare the old site to the new site using the Wayback Machine?
It's often the only surviving record of exactly what a page looked like before a change, including title tags, headings, and internal links that live crawls of the current site can't show you.
Do you always need server logs to confirm a diagnosis?
No, but they remove ambiguity that crawl and Search Console data alone can leave. When available, logs confirm exactly how Googlebot behaved during the incident window, independent of any dashboard's interpretation.
How do you know when a forensic investigation is actually finished?
When the identified root cause is fixed and the performance curve begins recovering in a way that matches the timeline evidence. If the metrics don't respond, the diagnosis wasn't complete and the case reopens.
Can a forensic SEO case study apply to a site that didn't just relaunch?
Yes — the same six-step method applies to algorithm-update hits, negative SEO attacks, and slow organic decay with no obvious trigger. The relaunch scenario is simply one of the most common and clearest to illustrate.
What's the biggest mistake teams make when investigating a traffic drop?
Jumping straight to a fix based on a guess — usually "we need more content" or "it's an algorithm update" — without building the timeline or diffing the site first. That skips the evidence-gathering that makes the eventual fix reliable.
Terry has 30+ years in software and SEO. He’s the founder of Salterra Digital Services and SEO Spring Training, host of the Roundtable SEO Mastermind, and lead instructor at SEO University — teaching the exact tactics his team uses on client work.
Continue learning
Ready to master this?
This guide is one lesson from the Forensic SEO course. Get every lesson, framework and checklist — plus the full 38-course catalog — inside SEO University.
Practitioner-focused training across the full digital marketing stack — from technical SEO to conversion optimization and the AI search era. By Salterra Digital Services, since 2011.