Six Things Worth Building on the Search Console API
The web interface truncates at 1,000 rows and cannot alert you to anything. The API does neither.
· 8 min read
Most people only ever meet Search Console through its web interface, which is a shame, because the interface is the most limited way to consume the data. The API has no 1,000-row ceiling, can be scheduled, and can do the one thing the web app fundamentally cannot: tell you when something changed without you going to look.
Six things worth building. None takes more than an afternoon.
1. An indexed-page-count alarm
The single highest-value thing you can build, and probably the simplest. Poll your indexed page count daily. If it drops by more than a few percent, wake someone up.
This one check catches nearly every catastrophic SEO bug — canonical errors, accidental noindex, a robots.txt that shipped with a Disallow: /, a migration that quietly 404'd a section. All of them show up here first, and all of them are silent everywhere else. Traffic will eventually reveal them, six weeks later, once the damage is done.
2. A complete data export, past the 1,000-row limit
The UI truncates exports at 1,000 rows per dimension. On any site with real long-tail traffic that is a small and badly biased sample — it keeps your head terms and discards the tail, which is exactly the part you cannot reconstruct from anywhere else.
The API paginates:
POST https://www.googleapis.com/webmasters/v3/sites/{siteUrl}/searchAnalytics/query
{
"startDate": "2026-06-01",
"endDate": "2026-06-30",
"dimensions": ["date", "query", "page"],
"rowLimit": 25000,
"startRow": 0
}Increment startRow by rowLimit until you get back fewer rows than you asked for. Store the results somewhere you own — and do this before you need it, because Search Console deletes everything after 16 months and there is no way to get it back.
3. Striking-distance monitoring
Queries where you rank 5–15 with meaningful impressions and poor CTR are the best optimization targets in SEO: you already rank, so a title rewrite needs no new content and no links. The problem is that they appear and vanish, and nobody manually re-checks for them.
Automate it. Weekly, pull queries by page, filter to position between 5 and 15, impressions > N, sort by potential clicks gained. Email yourself the top ten. You have just built the highest-return part of an SEO consultant's job as a cron job.
4. Query-to-page cannibalization detection
When two of your pages rank for the same query, they split their signals and both do worse than one strong page would. This is genuinely hard to spot by hand and trivial with the API.
Query by the query and page dimensions together, then find queries that map to more than one page with meaningful impressions on each. That set is your consolidation backlog — and consolidating is usually a bigger win than writing anything new.
5. A deploy-time canonical check
Not strictly the API, but it belongs on the list because it is the cheapest insurance in this whole post. Add a CI step that crawls your built site and asserts that every page's canonical tag points at its own URL.
for path in $(find .next/server/app -name "*.html"); do
url=$(canonical_from "$path")
expected=$(url_for "$path")
[ "$url" = "$expected" ] || { echo "BAD CANONICAL: $path -> $url"; exit 1; }
doneWe shipped a canonical bug that deindexed our entire site and did not notice for two months. Twenty lines of CI would have caught it in the pull request. There is no clever lesson here — just do it.
6. Weekly digest instead of a dashboard
Dashboards fail for a boring, human reason: they require you to remember to open them. A dashboard you check monthly is worse than an email you read weekly, because the email arrives whether or not you thought about SEO that week.
Build the smallest possible digest — five lines, no charts. Indexed pages and the change. Clicks and impressions, 28 days versus previous 28. Any new exclusion reason. Top three striking-distance queries. Anything that broke.
If it takes more than thirty seconds to read, you will start skimming it, and a digest you skim is a digest you do not read.
Practical notes before you start
| Thing | What to know |
|---|---|
| Auth | OAuth 2.0, or a service account added as a user on the property. The service account is much easier for cron jobs. |
| Quotas | Generous for this kind of use. You will not hit them unless you are polling far more often than is useful. |
| Data lag | 1–3 days. Always query a window that ends at least three days ago, or you will alert on incomplete data. |
| Anonymized queries | Rare queries are withheld. Your per-query rows will never sum to your total. This is expected, not a bug. |
| Bulk export | Search Console can stream to BigQuery daily with no row limits — but it is not retroactive, and BigQuery is billed. |
If you would rather not build the digest, that is more or less what our app is — the same official API, checked in ten seconds instead of never. But the alarm in item one is worth building either way.