An SEO called GSC's average position bollocks. Here's how my MCP calculates it.

Releases

A couple of weeks ago, Nikki Pilkington, an SEO from the UK, went off on LinkedIn about people wiring Claude into Google Search Console.

I immediately knew which post she was talking about. I’d seen it and cringed too.

Nikki Pilkington’s LinkedIn post arguing that average position in Google Search Console is bollocks and that people should talk to an SEO, not a chatbot

One line stood out. “Your average position in GSC is bollocks.

The advice was to keep Claude away from your search data.

I made one of those Google Search Console MCPs for Claude…

A toddler walking slowly into the room, caught out

My GSC MCP had roughly 7,700 npm downloads last month, and average position runs through nearly every tool in it.

So I ran it on my own site to show exactly what it does with the number.

Ask for the average position of my blog posts and you can get two answers.

Treat all 48 posts equally and the answer is 11.5. Weight each post by its impressions and the answer is 9.3.

Same posts, 28 days. Different answers.

BigQuery result for the same 48 posts, 11.5 with every post counted once and 9.3 weighted by impressions

The second answer is the correct one because of what average position actually measures.

Every time someone sees a search results page containing one of your URLs, Google records the position of your highest result. Average position is the average of all those recordings.

That means a page seen 40,000 times has to count for more than a page seen 40 times.

The MCP weights the data the same way Google does across every tool. With the BigQuery export, the formula is

SUM(sum_position) / SUM(impressions) + 1

That + 1 matters. BigQuery stores positions from zero. Miss it and your tool makes every page look one full position better than it is.

I then check the result against Google.

My top query reports an average position of 3.5 through the MCP and 3.5 in the Search Console interface. If those numbers ever disagree, the MCP is wrong. That’s the standard I hold every tool in it to.

MCP output

Raw output from the GSC MCP’s advanced_search_analytics tool, the query google search console mcp at position 3.5

Interface

Search Console performance report filtered to the query google search console mcp, average position 3.5

Deeper positions need more careful handling.

A position of 12 is only recorded when somebody opens page two. Almost nobody does, so the further down you go, the less data sits behind the number.

Every position returned by the MCP includes guidance that Claude has to read first.

Treat absolute positions as directional and trust movement between periods more than the raw number. The same guidance warns that anything beyond page one rests on thin data.

Then there’s the part you can’t see.

Google anonymised 56.1% of my impressions during those 28 days. No tool can reveal those queries, but the BigQuery MCP can measure the blind spot.

So when Claude makes a recommendation using the visible queries, you know how much of the complete picture it actually saw.

If you doubt any number Claude gives you, make it prove it.

That’s what verify_claim is for.

Give it a claim Claude has made, such as “This page ranks 6.2”, and it checks the figure against the live API. I tried that exact claim on my GSC MCP post. The page actually sits at 5.1, and the tool said so.

verify_claim output for the GSC MCP post, expected 6.2, actual 5.1, verified false

That’s the whole approach.

The numbers match what Google reports. Anything that requires careful interpretation comes with the warning attached.

Pipe raw metrics into an LLM without any rules and you’ll get confident nonsense, exactly as Nikki said.

Attach the right calculation, context and verification, and Search Console data beats any rank tracker because it’s the only record of what real searchers actually saw.

It’s all open source. The formulas are in the repository if you want to check my working.

Share this note

← All notes