You’d think “average position” meant something useful — like, where you’re generally showing up in search. It doesn’t. It’s a strange aggregate of impressions across all queries that trigger the page, weighted by clickless ghosts. If your article accidentally ranks #1 for a super long-tail query one user searches in Saskatchewan, that skews the position weirdly. You might see something like “Average Position: 11.3” but not crack page one for your actual target keywords.
What freaked me out once: I had a post showing an average position of 6. It wasn’t in the top 20 if I searched manually from five regions. Turned out it was being found by users typing in full, literal paste-from-ChatGPT titles. Zero value, but tracked in Search Console.
Only way around it: Filter by individual query. Too annoying for large sites, but essential if you’re trying to make sense of how a post is really doing.
The Query-Level CTR Mirage
There’s an annoying behavioral bug here: When you click a filter for a query, Search Console shows CTR values that don’t always match what you think they should based on the impressions + clicks. Found one case where the CTR was showing as “2.0%” but impressions were under 15 and I had one click logged. That’s… not 2%.
Here’s the thing — Search Console sometimes includes legacy CTR values from a shifted query grouping in the display even when the main table doesn’t. They cache query groups oddly for low-volume searches. I wish I were kidding. It means the UI lies (not maliciously, just… imprecisely) for narrow-range queries or fringe pages.
“CTR data for individual queries isn’t strictly numerical — it’s modeled when the sample size is limited.” – quietly mentioned on a forum’d product thread by someone with a G icon next to their name.
Don’t base decision-making on anything below 50 impressions unless you want to overfit your strategy to randomness.
“Pages” and “Queries” Don’t Always Add Up
The interface lets you filter queries by page, but not the inverse — unless you emulate it by filtering URLs after exporting. If you’ve tried exporting CSVs and dropping them into Looker Studio, you’ve probably hit incoherence in cumulative click totals. You’re not crazy.
Here’s what’s not told clearly: A single URL can appear under multiple canonical versions, even when all indexing is consistent AND declared. When Google tests alternate URL schemes (e.g., with and without trailing slashes), those variations can misattribute query linkages unless the canonical logic resolved prior to indexing.
I once found a canonical conflict between [e.g] https://site.com/page and [e.g] https://site.com/page/ throwing off search data enough that queries were logged against the slashless version — even though /page/ was visibly indexed. The impressions were split between the two in Search Console but canonical tags were properly set in headers AND sitemaps. Still happened.
Use Inspect URL and Coverage to cross-check which version Search Console actually thinks is ranking. Don’t trust the table IDs alone.
Click-Through Rate Goes Bonkers With Sitelinks
If your site gets navigational traffic, and your brand starts picking up sitelinks (those nested links under main results), your homepage’s CTR numbers will skyrocket — but ONLY in Web Search data. The weird part is: these sitelink click impressions don’t expose their identity as “sitelink vs non-sitelink” anywhere in the Search Console exported data.
I had one homepage URL that looked like it had an insane 78% CTR surge in one week. Freaked me out — thought we tripped an algorithmic wire or maybe hijacked someone else in error. Turned out, it coincided with a news mention and surge in navigational search, where users typed in our site name. The sitelinks inflated clicks disproportionately since they offered recognizable options (About, Blog, Contact).
There’s no unique flag in the performance data to identify a sitelink vs. regular organic click. You only catch this if you notice bizarre CTR heights on homepage URLs while total impressions stay flat or rise slightly. Frustrating if you want to attribute traffic to SEO effort when it’s closer to brand equity or media pickup.
Wildly Delayed Data Propagation
Here’s the kicker: Just because Search Console updated “today’s” data, it doesn’t mean that all sub-assets are showing their complete data sets. You can view last 7 days, and Monday might show 12 impressions for a new post… then tomorrow, the same Monday shows 64. The lag isn’t just delay — it’s uneven propagation per URL.
Search Console does a weird load-leveling wherein data for older posts appears earlier than data for brand new pages — even for the same domain. Probably an optimization thing on their backend, but it leads to phantom testing traps. I’ve launched pages that showed no traffic for 3 days, assumed they were failing… then watched them pick up retroactive visibility on day four.
If you check daily like I do, you’ll gaslight yourself into thinking you’re seeing the “latest.” You’re not. Always re-check a page’s first 72h performance at least 4 days after launch before making any tweaks.
“New” URLs That Actually Exist Already
Here’s an especially dumb one that cost me a serious headache on a client project. Created what I thought was a new post: unique slug, distinct meta, fresh content, manually requested indexing. Showed no impressions in Search Console for weeks. When I dug into the raw logs via server logs + link crawls, turns out the content was triggering Google’s duplicate detection because of a 2021 campaign landing page we’d 410’d but never properly removed from GSC property.
I couldn’t see the old version in the index using site: search, nor showed up in reports. But internal logs showed some URLs were disqualified from impressions due to content duplication signals — it never counted the newly indexed page as useful, even though it technically was there. You have to actually remove old legacy URLs using the removals tool, not just 410 them at the server level. Search Console hangs on to stuff if it’s verified in your history.
What fixed it: Went in, used the Removals tool, flushed the old legacy landing page path, resubmitted the new one. Page indexed, traffic appeared within 2 days. Should not have taken that long to figure out.
Exported Data Doesn’t Match On-Screen Data
This one makes me want to bite things. You click “EXPORT > CSV” on the top-right thinking you’re going to have this nice, raw version of what you see… then you load the thing and find that the queries are sorted differently, some values disappear (!), and impressions/clicks don’t match the on-screen subsets.
Small detail I discovered while debugging: The UI often presents pre-aggregated groupings of identical queries (e.g., with/without trailing punctuation or capitalization). The export doesn’t. The mismatch can throw off comparisons if you’re trying to reconstruct visibility per keyword.
If you really want consistent data between UI and export:
Use only date ranges that are a multiple of 7 (like 7, 14, or 28 days)
Avoid overlapping filters (e.g. country AND device) — stick to one or the other for clarity
Don’t trust click totals from summaries — recalculate from row data after export
Match dimensions exactly: don’t export Queries + Pages unless you really mean to analyze combo frequency
If you’re using Looker Studio, re-normalize apostrophes and smart quotes — some exports encode them inconsistently
Account for long-tail query rows being aggregated under “Other” in UI but individually distinct in CSV
Check line endings — Mac exports sometimes misalign with Excel parsing
The weirdest mismatch I’ve seen? Query strings showed 0 impressions in export, while UI had 19. Only difference was punctuation: “what’s the best SSL certificate” vs. “whats the best ssl certificate”. Case closed. Or not.
The Language Filter Isn’t What You Think
That little language filter in the Performance tab? Doesn’t do what you’re expecting. It’s not the language of your page — it’s Google’s best guess at the searcher’s interface language. I didn’t realize this until I was helping debug a bilingual nonprofit site and got totally misleading impressions: site showed only 30 clicks from English users, 600+ from Spanish. But the page was 70% English content. Bad translation? Nope.
Turned out donors in Central and South America use browser settings defaulted to Spanish, even when reading English-labeled interfaces. The Search Console language field just pulls browser language headers, not page intent or content language matchups. You’ll fall into the wrong conclusions if you think it maps directly to your Hreflang logic.
I don’t even use that filter anymore unless I need to detect anomalous traffic surges from mismatched locales. Most of the time, just tracking GEO + device gives a more accurate picture.
Ranking Fluctuations Triggered by Cache Invalidation
I wouldn’t have believed this if we hadn’t tested it. On a site hosted behind Cloudflare, we started clearing the edge cache aggressively (every content update triggered a purge). Then rankings for updated posts dipped for 3–5 days, like clockwork. These weren’t soft edits either — mostly metadata or widget positioning.
Turns out Google recrawlers sometimes treat cache invalidation as a mini-signal, especially if timestamps change or server headers fluctuate. We had changed the Last-Modified header behavior in our cache plugin without planning. The result? Search Console showed impressions flatlining the day after each update, while coverage stayed valid.
Reverted to a smarter cache strategy using differential purges by tag/category instead of all-invalidation. Rankings stabilized within the week. Feels like one of those things where Google’s behavior isn’t entirely documented — but it lines up too cleanly to ignore.
Large Language Models Will Decimate Search Intent Categorization Search used to be about keywords and underlying intent buckets: informational, transactional,…
