Three months, 12,491 search impressions, 53 clicks. A 0.42% click-through rate. I spent an afternoon pulling this Search Console export apart looking for what was broken — and found nothing broken, but did find a split I had not expected: at identical rank positions, tool pages get 6.4x the click-through rate of article pages.
1. The data, stated plainly
This is the Search Console performance export for a bilingual (Chinese/English) technical blog, covering 2026-05-30 to 2026-08-29, 92 days. 188 pages received at least one impression in that window.
Site total 12,491 impressions 53 clicks CTR 0.42% avg position 23.30.42% looks terrible, but a CTR only means anything alongside a position. So the first step is bucketing all 188 pages by rank:
| Position | Pages | Impressions | Clicks | CTR |
|---|---|---|---|---|
| 1–5 | 9 | 33 | 0 | 0% |
| 5–10 | 51 | 1835 | 18 | 0.98% |
| 10–20 | 77 | 2991 | 20 | 0.67% |
| 20–30 | 34 | 5549 | 12 | 0.22% |
| 30+ | 17 | 2083 | 3 | 0.14% |
The first conclusion falls straight out of that table: 61% of impressions sit at position 20 or worse. That is page three and beyond, where 0.22% is an entirely ordinary CTR. The 0.42% site average is largely an arithmetic consequence of most content ranking too low — not a copywriting problem.
But the 5–10 bucket is off. 0.98% at the bottom of page one is far below the 3–5% usually seen there, and with 1835 impressions the sample is not tiny. So the real question became: why does nobody click even when the page does reach page one?
2. The usual suspects, ruled out one at a time
Before drawing any conclusion I measured the standard culprits. This section holds no surprises, but it is worth writing down, because eliminating these is what makes the later finding stand up.
Truncated titles? No
Google truncates desktop titles at roughly 580–600px. I fetched the rendered titles of the 32 highest-impression pages and estimated pixel width per character:
narrowest 308px (a Chinese title)
widest 575px Backpropagation Computation Graph: ReLU, Softmax Cross-Entropy...
over 600px: 0 pagesChinese titles are more at risk because full-width characters are wide, but in practice the widest was an English one, still with 25px of headroom.
Missing descriptions? No
All 32 pages carry a meta description, 51–256 characters. Thirteen are under 80 characters — short, but not absent.
Mobile suppression? No
I briefly thought this was the culprit:
Desktop 10,589 impressions 49 clicks CTR 0.46% position 23.24
Mobile 305 impressions 4 clicks CTR 1.31% position 11.11Mobile is 2.8% of impressions. For a technical blog that is normally 30–60%. And the mobile position (11.1) is more than twice as good as desktop (23.2) — ranking better while barely being served looks a lot like mobile demotion.
That inference is wrong. The query list explains it:
"cloudflared tunnel --config" "ingress validate"
rfc 9110 connect method proxy tunnel
matrix calculus output only result exam style gradient -site:wikipedia.org
-site:book118.com -filetype:pdf -filetype:xls
"1/sqrt(d_k l)" transformerNobody types -site:wikipedia.org -filetype:pdf on a phone. The 97% desktop skew is the query mix, not a fault. And if mobile really were demoted, the position would be worse, not better.
Structured data? Genuinely broken, but not the cause
Here I did find a real defect: every article page carried three conflicting JSON-LD blocks. Yoast emitted a complete @graph (including Article and BreadcrumbList), a hand-written SEO plugin emitted another BreadcrumbList, and the site’s own mu-plugin emitted a third block with BlogPosting + BreadcrumbList. Two entity types describing the same article on one page leaves Google to pick one arbitrarily.
Mostly fixed. The genuinely unique properties (articleSection, keywords) now merge into Yoast’s node through the wpseo_schema_article filter, and the site’s own duplicate block is gone — three JSON-LD blocks down to two. The remaining BreadcrumbList still comes from that hand-written plugin, which lives outside the deployment pipeline; if you view source on this page you will still see it. But to be honest about the whole thing: this is hygiene, and its expected click gain is approximately zero.
Internal links? Tool pages actually have more
24 tool pages: median 4 in-body inbound links
164 article pages: median 1
orphans: 0“Page-one pages with zero clicks”? Just small samples
Five pages sit at position ≤14 with ≥100 impressions and zero clicks. That looks anomalous — but against this site’s own measured 0.98% for the 5–10 bucket, the probability of seeing zero clicks on those pages is 11%–35%. Entirely inside the noise. Things that “look wrong” on small samples usually dissolve the moment you compute the probability.
3. The real split: at the same rank, tools and articles are different animals
With those eliminated I cut the data a different way — not by language or topic, but by page type: interactive tools versus read-only articles. Looking only at the 1–10 bucket, so rank cannot confound the comparison:
| Position 1–10 | Pages | Impressions | Clicks | CTR |
|---|---|---|---|---|
| Tool pages | 12 | 105 | 5 | 4.76% |
| Article pages | 48 | 1763 | 13 | 0.74% |
6.4x.
Five clicks. The correct first reaction is “sample too small, ignore it.” So compute it: if tools and articles shared the same true CTR of 0.74%, 105 impressions would be expected to produce 0.77 clicks. The probability of observing 5, under a Poisson model:
import math
lam = 105 * (13 / 1763) # 0.774
p = 1 - sum(math.exp(-lam) * lam**k / math.factorial(k) for k in range(5))
# p = 0.00122p = 0.0012. The sample is small, but the gap is not something a small sample explains away.
Across the whole site the direction holds: tool pages 420 impressions / 7 clicks (1.67%), article pages 12,071 / 46 (0.38%) — 4.4x. The 1–10 bucket shows a larger multiple because it removes the confound that tool pages happen to rank better on average.
4. This does not prove AI Overviews, but the shape matches
The easy explanation is AI Overviews: someone searching “what is backpropagation” reads the summary and leaves; someone searching for a dQ/dV analysis tool cannot have the summary run their CSV for them, so they have to click.
That explanation fits the shape of the data: the CTR shortfall is concentrated at good positions. The 20–30 bucket at 0.22% is about what that position normally yields; the 5–10 bucket at 0.98% is 3–4x below normal. AI Overviews occupy the top of the results page, and the top is exactly where the clicks went missing.
But the full statement has to include this: Search Console does not tell you which impressions had an AI Overview above them. So this is an inference, not a measurement. And there is an equally sound alternative:
People searching for a tool simply have higher click intent than people searching for a concept. Someone who searches “online dQ/dV analysis” intends to open a page and do work; someone who searches “what is incremental capacity analysis” may only want the gist. That difference exists independently of AI Overviews — it was true in 2015 too.
I have no way to separate those two explanations with the data I have. What is solid is the fact itself: at the same rank, tool pages take several times the clicks that article pages do. Whether the cause is “AI ate informational queries” or “tool queries always had stronger intent,” the decision it implies is the same either way.
5. A by-product: the Chinese/English rank gap is systematic
Every article on this site exists in both languages. Across 75 paired pages, the English version ranks better in 53 of them:
Chinese side 8374 impressions 26 clicks CTR 0.31% median position 17.2
English side 3225 impressions 19 clicks CTR 0.59% median position 11.2The widest gaps:
neural-networks-basics zh 30.8 -> en 10.9 (+19.9)
feature-engineering-sklearn zh 31.2 -> en 11.9 (+19.3)
matrix-calculus-neural-networks zh 26.4 -> en 9.1 (+17.3)
backpropagation-computation-graph zh 28.4 -> en 13.4 (+15.0)Same content, same author, same domain: page three in Chinese, page one in English. The reason is not hard to guess — the head of Chinese technical search is saturated by a few enormous content platforms that a new domain cannot displace, while the same topics in English face a more fragmented field.
Note the trap, though: the English versions rank better but draw only 40% of the impressions. Ranking well is not the same as having volume. Which is the next section.
6. What I changed, and one attempt that failed
After finding that tools convert better, the obvious move was to build more tools. I built two — a dQ/dV incremental capacity analyser and an HPPC pulse resistance analyser, both for battery cycling data. My selection criterion was “no comparable browser tool appears in the search results.”
Thirteen days after launch:
/en/dqdv-analyzer-en/ position 3.4 5 impressions
/en/hppc-analyzer-en/ position 5.78 9 impressions 1 click
/dqdv-analyzer/ position 9.1 10 impressions
/hppc-analyzer/ position 9.9 10 impressionsAll on page one. The competitive read was right — that slot really was empty. But it was empty because nobody searches for it. 34 impressions in 13 days; no position converts that into traffic.
This was the most expensive lesson in the dataset: “nobody has built it” and “somebody needs it” are different claims, and I treated the first as evidence for the second. The right criterion is “there is demand, and what exists is bad” — not “I cannot find a competitor.” Often you cannot find a competitor precisely because there is no demand.
A quick check in the other direction: search for a confusion-matrix calculator, a genuinely common need, and the first page carries nine or more dedicated tool sites. Slots with volume are already taken. That is the normal case.
7. If you are looking at your own Search Console data
A few things from this analysis that transfer directly:
- Always bucket CTR by position. A site-wide average CTR carries almost no information; it mostly reports what page your content averages onto.
- Use your own data as the baseline, not industry averages. Every “normal / not normal” judgement above is made against this site’s own position-to-CTR curve, because absolute levels vary enormously across topic, language and country.
- Compute the probability before calling something an anomaly. Those five “page one, zero clicks” pages looked suspicious; the probability of zero clicks turned out to be 11–35%. Eyeballing anomalies on small samples is almost always wrong.
- Cut the data by “interactive vs read-only.” That is the only statistically significant finding here, and it is not a dimension any standard SEO report offers — Search Console will not group by page type for you.
- Origin access logs cannot count readers. This site sits behind Cloudflare; edge caching means a page hits the origin at most once an hour. My first attempt at counting humans from nginx logs classified 42 hits from my own cache-warming cron, 12 from my own link-graph script, and 36 curl verification requests as “real browsers.”
References
- Search Console performance report: data scope and limits
- Google structured data policies
- AI features and your website on Google Search
Related: dQ/dV incremental capacity analyser and HPPC pulse resistance analyser (the two tools described above), and measuring your own site’s template sameness (another measurement that used this site as its own dataset).