More and more, discussions and questions about the possibilities of SEO and AEO automation via MCP, but in the context of self-driving – i.e., decision-making through execution.
Today we are going to focus on pure strategy, decision-making.
The only thing we ask is that it be justified on real data.
In fact, this is a question that we have also been asking ourselves, as an SEO agency in Montreal, for the past 2 years. Automating everything that can be automated, in a fair way, i.e. based on data – is something that we would not hesitate to use and exploit – this is the purpose of our Prediict project.
Now, we have to ask ourselves how much this is possible, if our data is heavy – and it is for you too, you can believe us.
Avoiding AI Holes – Magicians and Childhood
We have all been fascinated, at one time or another, by magicians or magic formulas. Abracadabra and presto, – sparkles in the eyes: an apparent solution to a complex problem.
Then comes adulthood….A priori.
Since the beginning of the month I have had at least 5 different discussions with clients asking me for an opinion on automating certain parts of on-site SEO on autopilot via MCP. All of them, in charge of a site of several hundred or thousands of pages and with good traffic, well distributed – important detail.
Then, my cat sent me this article: https://hackernoon.com/i-stopped-asking-ai-for-seo-ideas-and-started-feeding-it-search-console-data-instead
Do you see the parallel?
I’m the same way— I’d love to fully automate my bookkeeping, my marketing, my backlinks, my hacks, my follow-ups, my site redesigns, my meager social media accounts and what’s posted on them, the emails I send to clients, and everything else that takes up time and money.
In principle, in pure SEO / AEO, it can be tested in several ways.
MCP and typical magic project:
- The client (Host app): This is the AI application that we use on a daily basis.
- The MCP server: This is the bridge that acts as an intermediary…
- Data, tools and prompts: These are the external elements (datasets, files, web searches, commands) that artificial intelligence can finally access directly and cleanly.
Reality of SEO and AEO: LARGE data sets.
On how many lines was this answer produced, and who chose which ones?
So let’s get into the hard stuff. The Search Analytics API documentation contains a sentence that not many people read before plugging in their AI tool.
Google specifies that the API does not guarantee to return all rows of data, only those at the top. It’s all there. The Search Console data that you entrust to a language model is already sorted, filtered and capped before the first line of analysis.
In recent months, tutorials have been multiplying: Search Console is linked to ChatGPT or Claude via an MCP connector, a daily task is scheduled, and the AI monitors the site. The latest one, published on HackerNoon on October 3, 2026, is careful and well constructed.
But it is a showcase site and it covers a period of 25 days.
At this scale, any method seems to work.
We work on sites with thousands of pages and hundreds of thousands of queries.
In fact, your site is, in all likelihood, larger than the one mentioned in the article. Over 12 months, all your queries or pages—including clicks, impressions, CTR, and rankings (the BASICS for proper analysis)—represent a huge volume of data.
We’ve also built our own GSC analytics app—and we’ve broken it several times.
So… here’s what we’ve learned, one misconception at a time.
The context window, THE limit
First and foremost; the context window is the maximum amount of text that a model can process at one time: the question, the instructions, the data transmitted, and the answer itself.
Depending on the model, it ranges from 200,000 to 1 million tokens, which seems huge until you put Search Console data into it.
Dense, encrypted and repetitive, they are divided into less than 3 characters per token, so that a single year of queries and pages from a medium-sized site is enough to saturate the widest window. Beyond that, there is no visible overflow: the data is truncated upstream, or the model responds with what it has been able to load.
Even under this ceiling, the reading is not uniform. Research has shown that models make better use of information placed at the beginning and end of a long context than information in the middle. IN SHORT, a phenomenon called lost in the middle … So, filling the window does not guarantee that everything is read with the same attention. This is why the MCP does not solve anything…
Your Search Console data is already sorted before AI
Illusion No. 1: AI Has Access to All My Data
False on three levels. First, Google excludes so-called anonymized queries, which are too rare to be displayed without risk to privacy. They disappear as soon as you break down by query or apply a filter. Then, the interface export stops at 1,000 lines, and the API at 50,000 lines per day, per site and per type of search, recoverable in increments of 25,000. Finally, as the documentation cited above reminds us, what the API returns are the top lines. On a site with content, or on an e-commerce with a strong long tail, the less visible part is not a detail: this is where the opportunities lie.
Illusion 2: An impression is an impression
Not in Search Console. Property or page aggregation rules change the meaning of the numbers. The graph aggregates by property: If two of your pages appear on the same results page, it counts as a single impression, and only the highest position is retained. The per-page table, on the other hand, counts each URL separately. The result: CTR and average position are generally better at the property level when multiple pages cannibalize each other.
A language model that adds up rows of table to compare them to the total of the graph will produce a discrepancy. Then it will explain it, with aplomb, by an invented cause.
We have seen him do it.
Context, the blind spot of all automation
Illusion 3: MCP gives access, so AI reads everything
An MCP connector doesn’t open a database to the model. It returns a textual result to the model, which should fit in its context window. Pipedream’s GSC connector documentation is one of the few that makes it clear: stay under 200 lines per call, knowing that 100 lines weigh about 13,000 characters and that beyond 400 lines the response overflows.
Brex’s team has published an even more telling calculation, applied to business expenses: a 200,000 token window contains about 500 rows, a million window contains 3,000 to 4,000 rows.
Do you realize what this implies on a 4-metric analysis on 2 dimensions? I remind you that QUERIES + PAGES with CLICKS, IMPRESSIONS, CTR and RANKING is the vital minimum.
Beyond that, they write, the model stops reading without signaling it and responds with what it has. Their solution is instructive. The data is loaded into a temporary database, queried in SQL, and only a result of about ten lines enters the context. The model no longer reads the data. It reads the response to a specific query.
Illusion 4: A single RAG solves the problem
That’s the first thing we believed. Prediict is still collecting via the API and branching into the BigQuery export is the next step. So briefly, the initial version of Prediict, our analytics application plugged into Search Console, sliced the data into blocks, vectorized it in Supabase, and an agent retrieved only the most relevant blocks for each question. On a bounded question, such as keywords that progressed in August in Canada, the result was good.
On an annual trend, it was wrong. A vector search returns passages that are semantically close to the question. Not all passages. Ask for an evolution over 12 months, you will get an analysis built on a few months chosen by similarity. The RAG did not remove the sampling… In other words, one in ten questions could be dealt with with the wrong strategy, without the user knowing it.
GSC data is dense: less than 3 characters per token, which blew our first caps calculated in characters.
Without this data, we guess, we ramble, we are in esotericism…
So MCP+RAG= a little… but not much better than a copy-paste of your exports in chatGPT. Not enough for a real SEO proposal.
What a language model will never do for us
Illusion n° 5: AI calculates variations
It doesn’t calculate, it reads and reformulates. Isolating the queries that appeared this month, measuring the difference in clicks between two periods, filtering pages in positions 11 to 20 with a lot of impressions: these are joins, differences, filters. A SQL query executes them identically a thousand times in a row. A language model, queried twice on the same data, can produce two different lists. For a customer report, this is a problem. For a redesign decision, or a web strat, it’s a mistake.
Illusion 6: Automation keeps the memory of tests
An experimentation loop assumes a history: which page was modified, when, on which element, with what starting situation. A scheduled task that starts every morning without a persistent state has none of this. Our own specifications provided tables dedicated to conversations, messages, and summaries, precisely because no model retains anything from one session to the next. Without a change log kept outside the model, you don’t experiment. You comment.
Illusion No. 7: If it goes up after the change, it’s because of the change
It’s the most expensive. A new site sees Google test its pages on niche queries in the first few weeks, no matter what you do. A seasonal site goes up and down with its market. An algorithm update moves everyone at the same time. Five impressions in position 6 proves nothing, and neither does a 15% increase over three weeks, if you don’t have a year-over-year comparison or untouched control pages. A language model will never refuse to conclude. It should be forbidden to do so.
Four architectures, four levels of truth
Not all “AI + Search Console” solutions are created equal. The real question is not which model they use, but what that model actually sees when responding.
| Architecture | What the model sees | Adapted | Main | Our verdict |
| Direct MCP on the API | A few hundred lines; the first ones have been returned | Specific questions about a small website | Silent truncation | Useful for exploring, never for making decisions |
| Vector | Blocks deemed close to the question | Precise | Invisible sampling on trends | Good assistant, bad analyst |
| Exhaustive batch | Everything, but summarized batch by batch | Trends, overall | Cumulative errors in intermediate | Correct if controlled by SQL |
| SQL pipeline and then model | A result already calculated and reduced | , even on large volumes | Depends on the quality of the queries written | The only reliable option at scale |
| Automatic routing between policies | Varies according to the router’s | Consumer use | A bad strategy chosen without warning | To be logged systematically |
The observation is simple. The earlier the model intervenes in the chain, the more the answer depends on what it has had the chance to read.
The later it intervenes, the more it does what it does well: EXECUTE and, why not, help us process or interpret certain things.
This is clearly the direction we are taking.
Analyze Search Console data without lying to
yourself Our method is based on a few principles, applied differently depending on the site. First of all, raw data: the bulk export from Search Console to BigQuery delivers two tables every day, one aggregated by property, the other by URL, without the API row cap. Anonymized queries are not deleted but grouped into rows identified by a dedicated indicator, which at least allows us to measure the dark side.
Then the calculations, in SQL: differences between periods, minimum thresholds of impressions before any conclusion, comparison from one year to the next for seasonal markets. The change log, kept separate and time-stamped. And the language model last, based on results already calculated, with an explicit instruction: to report any missing data rather than fill it in.
These principles do not apply in the same way everywhere. On a bilingual SaaS publisher like eZsign, which is spread over several domains and whose crawl reveals thousands of URLs set up by third-party tools, the first step is to clean up and segment, otherwise noise dominates everything else. At Innovation Solaire Québec, with a main store and regional sites with modest volumes, the challenge is the opposite: avoid conclusions based on samples that are too thin and read each variation in terms of region and season.
It is this framing work, more than the tool, that makes the value of an SEO analysis based on real data.
There is still one question that we now ask every service provider, every tool demonstration, every enthusiastic tutorial.
On how many lines was this answer produced, and who chose which ones?
In my opinion, as long as no one knows how to answer it, it is not an analysis. It is a well-written text on some of your data.
Experience decides – AI executes
Even with all the data actually read, calculated and verified, an AI does not make an SEO strategy. It executes tasks, and the challenge is to know which ones to entrust to it, in what order, on what data perimeter and with what conclusion limit. This division cannot be improvised: it requires the discernment of someone who has already seen sites rise, fall and rise, and who knows how to recognize cannibalization, seasonality or a false signal before the model transforms them into certainties. A few hours of human framing are enough to guide weeks of automated work…
It takes relatively little time but hey, a little more than a magic formula….
FAQ
Can you do predictive SEO or an editorial calendar with a sample of Search Console data?
No. A traffic projection, a seasonality analysis or an editorial calendar based on demand peaks are based on the complete history: all queries and all pages, over a minimum of 12 to 16 months, with clicks, impressions, CTRs and positions. On a snippet, the model does not see annual cycles, nor long-tail queries that emerge, nor pages that decline slowly. It then projects a trend that only exists in the lines that have been sent to it. To predict, you need everything and even it is not enough:)
Why does the Search Console data in the API differ from the interface?
Because the two don’t always aggregate in the same way (by property or by page), anonymized queries disappear as soon as a filter is applied, and the API only guarantees the top rows, up to a limit of 50,000 per day.
Can we trust ChatGPT or Claude to analyze Search Console?
To calculate variations on thousands of lines himself, no: he reads an excerpt, does not always report it, and his answers vary from one execution to another.
What is the difference between an MCP and a RAG for SEO analysis?
The MCP passes the result of a tool call to the model, limited by the context window. The RAG selects the passages closest to the question in a vector database. Neither guarantees a complete reading of the data.
Do you have to use BigQuery to analyze a large site?
As soon as the site exceeds a few hundred or thousands of pages or the long tail weighs a minimum, this is the safest way: no limit on lines, history kept and reproducible calculations in SQL…. This is something we will come back to because our prediict methodology is derived from it; complete analysis, followed by controlled division of tasks.
Leave A Comment