Because the work is assembly, not analysis. Someone exports Search Console data, exports analytics data, pastes both into a sheet, rebuilds the same charts, then writes a summary that says roughly what last month's said. The thinking takes an hour. The assembly takes the rest of the day.
That is exactly the shape of problem automation is good at. The data lives behind APIs, the format is stable, and the judgment is only needed at the end.
Here is how we would build it, which parts genuinely benefit from an AI model, and the guardrails we would insist on before anyone sends the output to a client.
AI is good at turning a table into a paragraph and at spotting which numbers moved most. It is bad at knowing why they moved. So the honest split is that automation handles collection, calculation, and first-draft narration, while a human supplies the cause and the recommendation.
That boundary matters because the failure mode of an automated SEO report is confident nonsense. A model given a traffic drop will happily attribute it to a core update it has no evidence for.
Our position is that the model should describe and never diagnose. Describing is verifiable against the data in front of it. Diagnosing requires knowing what shipped, what changed, and what a competitor did, which the model cannot see.
Start with Google Search Console, because it is the only source that tells you what happened in Google rather than what happened after someone arrived. Add your analytics platform for behaviour after the click, and a rank tracker only if you genuinely act on position data.
Resist the urge to pull everything. A report drawing on six sources takes six times as long to break, and something always breaks.
The practical minimum we would build first is Search Console clicks, impressions, and average position, split by page and by query, compared against the same period last month and the same period last year. That covers most of what a monthly report needs to say.
Two routes, and the choice depends on volume. The Search Console API is the direct one, and Google documents generous limits. Its quota page lists the Search Analytics endpoint at 1,200 queries per minute per site and per user, with a project ceiling of 40,000 queries per minute and 30,000,000 per day.
The URL Inspection API is much tighter, at 2,000 queries per day and 600 per minute per site. That constraint shapes what you can automate. Pulling performance data for every page is fine. Inspecting indexing status for every page on a large site is not.
For anything larger, use the bulk data export into BigQuery. Google's documentation says the first export happens up to 48 hours after you configure it, and that the first export includes data for the day of the export.
The catch is worth knowing before you set it up. There is no historical backfill, so if you want data from before you turned the export on, Google directs you to the API or the reports instead. Set it up now even if you do not need it yet, because the data you skip today is gone.
Google added dedicated generative AI performance reports. In June 2026 Google Search Central introduced reports that give you views of your impressions within generative AI features on Search, meaning AI Overviews and AI Mode, along with generative AI features in Discover.
The reports show impressions and the pages that appeared, and let you break the view down by page, country, device, and date. Google also states that clicking a link to an external page in AI Mode counts as a click, and the same applies to a link in an AI Overview.
One important qualifier. Google said these reports are being rolled out to a subset of websites so it can test them and gather feedback before making them widely available. So if your property does not show them yet, nothing is wrong with your setup.
For an automated report, this is the section worth adding first when it becomes available to you, because it is the only first-party view of AI search visibility any of us have. Our notes on measuring AI search traffic cover what to do in the meantime.
Through an automation platform for simple pipelines, or through a model connected to your tools for richer ones. Platforms like Zapier, Make, and n8n can call the Search Console API on a schedule, drop the result into Google Sheets or Airtable, then send that table to a model with a fixed prompt.
The alternative, which we prefer for anything ongoing, is to give the model direct access to the data source instead of shuttling files around. Model Context Protocol servers exist for exactly this, letting an assistant query a database or an API in place rather than working from a stale export.
That distinction changes the quality of the output more than any prompt trick. A model working from a pasted table can only describe that table. A model that can query can check its own claim before writing it.
If you want the background on that plumbing, our explainer on what an MCP server is and why web teams should care covers how the pieces fit.
Four short sections, and no more. What changed, stated as numbers with the comparison period named. Which pages moved most in either direction. Which queries gained or lost impressions. And a list of things that need a human to look at, phrased as questions rather than conclusions.
Keeping the output structured is what makes it reliable. An open instruction to summarise the month produces a different shape every time, which defeats the point of a recurring report.
We would also have it flag what it could not explain. A report that says impressions fell 18 percent on three product pages and it does not know why is far more useful than one that invents a reason.
Write the prompt once, keep it in version control, and change it deliberately. A prompt that drifts is the reporting equivalent of a spreadsheet formula nobody remembers writing.
Constrain it at three points. Give the model only the data it is allowed to talk about. Tell it explicitly that it may not name a cause it cannot see in that data. Then check the numbers in the output against the source before anyone reads it.
That last check is worth automating too. If the model writes that clicks fell 12 percent, a simple script can recompute that figure from the same table and flag any mismatch. Numbers are the easiest hallucination to catch mechanically, so catch them mechanically.
Attribution language is the other thing to police. Phrases like this is likely due to a core update or competitors have improved their content should be banned outright in the prompt, because they read as findings and are actually guesses.
We take this seriously because a wrong report is worse than no report. A client who acts on an invented cause spends real money on the wrong fix, and the trust cost lands on whoever sent it.
Monthly for the narrative, weekly for the alerts, and never daily for either. SEO data is noisy at short intervals, and a daily report trains everyone to ignore it. Search Console data also lags by a couple of days, so a report run too soon reads as a decline that is just missing data.
Alerts are the genuinely valuable automation and they are separate from reporting. A weekly check that flags any page losing more than a set share of its clicks catches problems long before a monthly summary would.
Keep the alert threshold high enough that firing means something. An alert that goes off every week is a newsletter.
Build the boring half first. Get Search Console data flowing automatically into one place on a schedule, with the bulk export to BigQuery switched on so history starts accumulating. That alone removes most of the manual work, and it is useful even if you never add a model.
Then add the narration layer, tightly constrained, and read its output yourself for two or three cycles before anyone else sees it. You will find the failure patterns quickly, and they are usually the same two or three each time.
The mistake we would avoid is starting with the model. Teams get excited about the writing and end up with an eloquent report built on data someone still exports by hand every month, which automates the fun part and leaves the tedious part alone.
If you want to understand the underlying data better before you automate anything, our guide to using Google Search Console is the right place to start, because you cannot automate a report you could not write yourself.
If you want help designing the pipeline, or a second opinion on where the human judgment needs to stay, we are happy to walk through it. Reach out at phoenix.studio.
Tell us where you want to go. We'll tell you how we'd get you there.