調查流量下跌時，我在 Search Console 遇到的三個數據陷阱

My Site Grew While One Page Lost Search Visibility. Three Search Console Data Traps Explained

The first number I saw was good news: Google Search clicks to my site had increased.

The next number complicated it. One article on that same site had lost most of its impressions.

I run Local Waifu and built GSC Magic, an MCP connector I use to examine search data through an AI assistant. I used it to investigate an article about running an AI companion offline.

This is a field note from that investigation. There’s no claimed fix at the end. What I found instead was a good example of why an agent needs to know how a number was produced before it tries to explain it.

I compared two consecutive 28-day periods:

At the property level, clicks were growing. At the article level, impressions had fallen sharply. Both observations were real.

Figure 1. The property and the article moved in opposite directions. The two rows use independent scales; compare each row over time, not one bar against another.

Trap 1: “Site clicks” depended on how I grouped the data

My first traffic-drop report, grouped by page, gave me 298 → 472 clicks for the site. I almost carried those figures into the article.

Then I queried Search Console for the property without a grouping dimension:

{
  "site": "sc-domain:localwaifu.com",
  "start_date": "2026-09-02",
  "end_date": "2026-09-29",
  "dimensions": [],
  "limit": 10
}

I repeated the call for September 30–October 27. The property-level results were 293 → 467, not 298 → 472. Both calls returned a single row and reported that the result was not truncated.

This isn’t a dramatic discrepancy. It is a useful one. The page-grouped report and the property-level query weren’t measuring the total in exactly the same way. Google documents that totals can differ when data is aggregated by page rather than by property.

If I’m building an agent workflow around this, I don’t want it to pass around a bare value called clicks. I want the answer to retain at least:

• the property and exact date range;
• the grouping dimension;
• whether a page filter was applied;
• whether the returned rows were truncated.

Otherwise two legitimate numbers can turn into a false contradiction — or, worse, one can silently replace the other in a published case study.

For the rest of this investigation, I use property-level totals for the whole site and page-level results for the exact article URL.

Trap 2: The 28-day comparison hid an outlier

The article went from 476 to 123 impressions. It’s tempting to turn that straight into a headline about a 74% collapse.

I queried the page by date before deciding what the decline meant. The daily series revealed that September 11 alone produced 142 impressions. That one day made the earlier period look considerably stronger.

But dismissing the entire change as an outlier would also be wrong. In the last seven days of the earlier period, the article received only 30 impressions. The following four seven-day blocks recorded 24, 37, 23 and 39.

Figure 2. Actual daily impressions, with the September 11 spike visible rather than smoothed away. The smaller bars sum the same data into non-overlapping seven-day blocks.

The useful observation is more precise than “traffic suddenly fell between two months.” Visibility had already dropped toward the end of the first window and remained lower through the next one. The unusual September 11 result magnified the period-to-period difference, but it didn’t create the entire pattern.

This is why I wanted the daily data, not just an agent’s summary of two totals. A summary can tell me that a metric changed. The series tells me when the question changed.

It still doesn’t tell me what caused the spike or the lower level afterward.

Trap 3: The query table was much smaller than the page total

I next queried the exact article URL, grouped by page, for the earlier period. It returned 12 clicks and 476 impressions.

When I grouped that page’s data by query, the visible rows added up to only 1 click and 79 impressions. For the later period, the page had 4 clicks and 123 impressions, while the visible query rows accounted for just one impression and no clicks.

Figure 3. The previous period’s page-level total beside the impressions represented in its visible query rows. The unitemized remainder is **not* a list of known lost keywords.*

Google says some rare queries are omitted to protect users’ privacy. It also documents other reasons query-table totals can differ from broader totals, including row limits and aggregation effects.

That distinction matters for an AI-assisted investigation. It would be easy to ask, “Which keyword lost 353 impressions?” The available rows cannot answer that question. They do not account for all the page’s impressions in either period.

I can use the visible queries as clues. I cannot treat them as a complete accounting of the decline or ask the model to reconstruct the missing queries.

One more check: did the page leave Google’s index?

Before recommending an indexing fix, I inspected the URL itself with gsc_inspect_url.

The result reported submitted and indexed. Crawling was allowed, the page fetch succeeded, and Google’s selected canonical matched the article URL. Its recorded last crawl was October 27.

That check removed one simple explanation: the page had not merely fallen out of the index. It did not establish why its impressions fell.

The average position moving from 6.7 to 7.0 doesn’t settle the matter either. It is an average over the searches in each period, not proof that the article held the same position for every relevant query.

What the investigation actually produced

I haven’t rewritten the article, requested indexing, or measured a recovery. Claiming a successful SEO fix here would be fiction.

What I can say is that the next step is better defined. I would review the search results for the article’s relevant topics, compare the article with what currently appears there, examine any useful device or country splits, and then watch another comparable period.

The workflow also gave me a useful standard for an agent’s answer:

Observed: the exact URL lost impressions and clicks.

Checked: it remains indexed.

Limited: visible query rows do not account for the page total.

Unknown: the cause of the lower visibility.

That is a more useful answer than a confident paragraph about an algorithm update that the data never demonstrated.

I built GSC Magic so I could run these checks from an AI client without manually moving exports between tools. This case is also a reminder of the boundary: connecting an agent to real data makes its questions better. It does not make incomplete data complete.

Method: Search Console property sc-domain:localwaifu.com, queried through GSC Magic on October 29, 2026. Periods: September 2–29 and September 30–October 27. Whole-site figures use property-level aggregation; article figures use its exact URL. Graphics reconstruct returned data and are not screenshots of the app.