A single week in August 2026 cost one SaaS website 72% of its daily Google impressions, and four weeks later nothing had come back. The rankings were mostly still there. The pages behind them were not.
This post walks through that investigation step by step, using real Search Console data, crawl results and live HTTP checks from an anonymized B2B data extraction company. The brand, domain and identifying URLs are hidden. The numbers are not. The same method works after a CMS migration, a framework rewrite, a CDN change or a routine template update.
A website release quietly turned the site's best-performing articles into redirects, mostly pointing at a generic blog page. Google kept ranking the old addresses, so impressions looked fine at first. But searchers who clicked landed on the wrong page, and clicks collapsed. A crawl comparison found it. The fix is to restore those pages or redirect each one to a true equivalent.
Step 1: Pin Down What Changed and When
The first job is to find the changepoint, the exact day the search performance series broke. Do not start from a hunch about a Google core update or a competitor. Start from the data.
Here, a sigma test (a simple statistical check for the day a trend breaks sharply away from its normal range) on the Search Console daily series located one sharp break on 2 August 2026.
Why the average position number misleads. Average position moved from 12.7 to 43.0, which looks like a 30-place collapse. It is not proof of one. Imagine a site that ranks #3 for one big query and #50 for one small query. Its average is about 26. If the big query stops being reported, the average jumps to 50, even though no page actually dropped. Treat it as a supporting clue only.
Once you have the date, ask the engineering team one question: what shipped between 1 and 3 August? A release, a CMS change, a content migration, a robots.txt or XML sitemap edit, a CDN or edge worker change. That deployment log is the single most valuable document in a traffic drop investigation, and only the site owner has it.
A timing match is a hypothesis, not a verdict. The rest of the investigation exists to confirm it or rule it out.
Step 2: Decide Whether It Is an Indexing Event or a Ranking Event
Compare the queries Google reported before the changepoint with the queries it reported after. This one comparison decides your whole response.
The same queries are still reported, just at worse positions. Look at content quality, competitors and algorithm updates.
Whole query groups stop appearing. Something stopped Google from serving the page. Look at the deployment.
In this case, entire query clusters vanished. That pointed away from a core update and toward the site itself. Next, gather three independent sources of evidence for the affected URLs:
- Search Console URL InspectionCoverage state and last crawl date. The API is capped at 2,000 calls a day at roughly seven seconds per call, so inspect the highest-impression URLs first.
- A full site crawlStatus codes, redirect targets, canonical tags, titles and internal links for every URL.
- A live fetch with a Googlebot user agentRedirects not followed, so you see the raw response the crawler gets.
One honest caveat: index status was known for 122 of 1,584 ranking URLs, or 7.7%. Every count below is a floor across the pages that matter most, not a site total. State your denominator the same way in your own reports.
Step 3: Run the Crawl Comparison Checks
A crawl comparison (also called a crawl diff) means crawling your site twice, once before and once after a release, and listing every difference: status codes, redirects, titles, canonical tags and internal links. No pre-release crawl? Use the URLs Search Console still shows impressions for as your baseline. Those are the addresses Google expects to work.
Check 1: Status codes that changed from 200
Filter for URLs that returned 200 before and now return 301, 302, 404, 410 or 5xx. In this audit, 193 of 435 crawled blog and use case URLs now answered a 301 to a bare /blog or /usecase listing page instead of a replacement article.
Check 2: "Page with redirect" in Index Coverage
Google recorded 48 inspected pages as "Page with redirect", carrying 1.1 million impressions between them. They still ranked, the biggest at position 5.6, but click-through rates were 0.40%, 0.00% and 0.01%. Only 10 of the 48 had unusual characters in the URL, so URL normalization did not explain the pattern.
Check 3: Redirect destinations and redirect chains
Look at where redirects land, not just that they exist. Three distinct articles about different consumer proxy tools all pointed to one generic explainer. Two other URLs pointed at a destination that itself returned 404, a redirect chain ending in nothing.
Check 4: Soft 404s hiding behind a 200
A soft 404 is a page that should say "not found" but returns a normal 200 "OK" status instead, often showing the homepage. A status code check alone will miss it, so compare page titles and content, not just response codes.
This example comes from a different site, an HR software company, not the case above. There, 72 dead article links, broken deep links and URL variants all returned 200 while showing the exact homepage. Google saw 72 copies of the homepage, which became the largest duplicate content problem on the site.
Check 5: Pages that fail under load (send this one to your developers)
In plain terms: some pages simply failed to load when Google or visitors asked for them. Of 52 random pages tested, 10 (19%) failed, and 5 showed a "temporarily unavailable" server error (HTTP 503). One page template failed 29% of the time.
The site built every page from scratch on every request and told its CDN (the network that normally stores copies of pages) not to keep any copies. With nothing stored, ordinary traffic overloaded the server.
For developers: HTML was served with Cache-Control: no-store, so the CDN returned a cache MISS on every request and the rendering worker hit its resource limits. A worker that dies mid-render can also return an empty page with a 200 status, which status code checks cannot catch.
This also confused the crawl report. Nineteen URLs shared the title "worker exceeded resource limits", which first looked like a duplicate title problem. It was actually an outage.
Step 4: Separate What Is Confirmed From What Is Not
The redirects are proven. Why they happened is not, and that is normal at this stage. Only the site owner's release history can answer it, which is why Step 5 starts by asking them.
| Status | Finding |
|---|---|
| Confirmed | 99% of the site's page-one impressions sat on URLs that redirect away |
| Confirmed | One redirected article alone held 43% of all the site's impressions |
| Confirmed | 11 deleted pages had the site's best click-through rates and earned 22% of all clicks |
| Confirmed | 1 in 5 sampled pages failed to load under normal traffic |
| Ruled out | Unusual URL formats as the main cause |
| Unknown | Whether the pages were deleted, merged, unpublished or moved on purpose |
The cost: page-one results normally earn several times more clicks than this site got. The gap added up to roughly 23,500 lost clicks a month. This was not a ranking problem. The rankings were already won. The click was lost at the last step because the URL forwarded instead of answering.
A redirect onto a listing page is arguably worse than a 404. Google sees a live page with the wrong content, so the address is not released and ranking signals are not transferred. The searcher lands on an index of posts and leaves.
Step 5: Fix the Pattern, Not the List
When the same fault keeps appearing batch after batch (53% of URLs in the first batch, still 26% in the second), you have a systemic problem. Scope it as one pattern to fix once, not 48 separate tickets.
- Find the cause firstAsk whoever ran the last content migration or CMS change what happened to the articles. One answer usually explains all of them.
- Work in impression orderThe top four redirected URLs carried 955,918 impressions. They are the whole first day.
- Restore what should existRepublish the content at the exact URL Google already ranks, returning 200 with its own content. Pull it from a CMS draft, an export, git history or the Wayback Machine.
- Redirect what should notSend a 301 to the closest page that answers the same query. Never to /blog, never to a generic explainer, and never more than one distinct topic to the same destination.
- Retire cleanlyIf no equivalent page exists, return a 410 status ("gone for good"), which tells Google to drop the address faster than a 404.
- Fix broken redirect chainsNo redirect should end on a 404.
- Make pages cacheable (developer task)Replace
no-storewith a policy such aspublic, max-age=0, s-maxage=300, stale-while-revalidate=86400, disable caching of error responses, and serve stale content when the origin fails.
Step 6: Verify the Fix
- Re-crawl the affected URLs and confirm each returns the expected status code and its own title.
- Run
curl -sItwice on a key page (or ask a developer to). The CDN cache header should read HIT on the second request, meaning the page is now being stored and served fast. - Request indexing in URL Inspection for every restored page.
- Watch the click line, not the impression line. Impressions were never lost. Clicks were.
- Recovery from an indexing event is usually visible within two weeks. If clicks do not move, revisit the ranking event hypothesis.
Step 7: Prevent It on the Next Release
Most of this damage was avoidable with a pre-deploy and post-deploy crawl comparison.
Diff every release
Crawl staging before release and production right after. Compare status codes, redirect targets, canonicals, titles, meta robots and internal link counts.
Protect your top URLs
Keep a list of high-impression URLs from Search Console. Any status change on that list blocks the release until someone signs off.
Flag lazy destinations
Alert on any redirect whose destination is a listing page, the homepage or another redirect.
Catch homepage clones
Flag 200 responses whose title or content matches the homepage.
Re-check the Search Console daily series weekly after major releases so the next changepoint is caught in days, not a month.
FAQ
- How soon after a deployment should I run a crawl comparison?
- Immediately after the release reaches production, and again a few days later. Some issues, like edge worker failures under load, only appear once real traffic arrives.
- Can a traffic drop after a deployment be a Google core update instead?
- Yes. That is why you compare the reported query sets. If the same queries remain at lower positions, suspect a ranking change. If whole query groups disappear, suspect the deployment.
- Is a 301 redirect always safe for SEO?
- Only when the destination answers the same search intent. Redirecting specific articles to a blog index or homepage loses the click and often the ranking.
- What if I do not have a crawl from before the release?
- Use the URLs Search Console reports impressions for as your baseline. Those are the pages Google expects to serve, so any that no longer return 200 with their own content need attention.
Data: anonymized Search Console, crawl and live HTTP measurements from two client audits, June to September 2026. Brands and domains withheld.