Search Console tells you everything and asks nothing. So I built a tool that tells me what to fix.

If you run a website, you probably have Google Search Console. And if you're like most people I work with, you open it now and then, scroll through the charts, nod, and close it again. I did exactly that for years across fourteen sites, mine and my clients'. I always knew what was going on, and I rarely did anything about it.

So I built something that works the other way around. Every night it checks all my sites. Once a week it tells me the few things actually worth my time, and the urgent ones go straight onto my to-do list.

This post is for two kinds of readers. If you're a marketer or you own a site, it's about turning Search Console from a report you read into a list you work through. If you're curious about building your own automations with AI, it's an honest account of what that took and where the real effort went.

The surprise was that the technical part went quickly. The sentence that took longest to write was a short one: a highlight you mark as done reopens after thirty days if the condition is still there. That rule is what separates a tool that gives advice from one that holds you to it. More on that below.

Why the world needs no more dashboards

It doesn't, and I know it. I've already written about putting client KPIs on an e-ink screen instead of a dashboard nobody opens, and that post was about where a number should live so a human actually sees it.

This is a different complaint. Search Console shows you everything and asks nothing of you. It has no opinion about which of your fourteen properties deserves an hour this week, and no memory of what it told you last month. You can open it every morning for a year, be fully informed the whole time, and change nothing — because reading is not a workflow. The gap isn't visibility. It's obligation.

Suggestions are the easy part

There are nine rules in the thing: striking distance (pages ranking just below the top results, where a small push pays off), a click-through rate below what the position should earn (people see the page but don't click), decaying pages (traffic slowly sliding), rising queries (new searches starting to find you), cannibalisation (two of your own pages competing for the same search), a content gap where the homepage ranks for a non-brand term that deserves its own page, zero-click pages (seen often, clicked never), a week-over-week traffic drop, and sitemap health (whether Google can find all your pages). Writing those took one sitting. Any competent analyst could list them, and increasingly any model will list them for you on request.

The hard question is what happens to a suggestion after it's been read, and almost no reporting tool has an answer. Most offer two states: unseen and seen. Real life has three. A highlight can be genuinely fixed. It can be a thing you've considered and rejected for good reasons. Or it can still be completely true and simply ignored — and that third state is where every insight dashboard I've ever used quietly goes to die, because clicking a checkbox feels identical to doing the work.

So: you can mark a highlight done, or you can dismiss it. Dismissed stays dismissed, because a deliberate "no" deserves to be respected permanently. Done reopens in thirty days if the underlying condition is still measurable. The list can't fill up with advice I've already declined, and it can't be emptied by clicking.

Cal Newport, borrowing the four disciplines of execution in Deep Work, names the two I kept getting wrong: "Act on the Lead Measures" and "Create a Cadence of Accountability."

The rule I stole from site reliability engineering

Google's own SRE book has the cleanest statement of the problem I've found anywhere, and it isn't about marketing at all. "Every page should be actionable." "If a page merely merits a robotic response, it shouldn't be a page." And the one I pinned above the rule engine: "you should never trigger an alert simply because something seems a bit weird."

That book also argues for spending far more effort catching symptoms than causes. A highlight list is an alerting system wearing a marketing hat, and it degrades in exactly the same way — the book notes that when pages come too frequently, people "second-guess, skim, or even ignore incoming alerts". Which is a precise description of every weekly SEO report I have ever been sent.

So every rule had to pass two tests before it shipped: can I take an action in response to this, and would that action differ from the one I took last week? Two candidate rules failed and were cut. I've been on the wrong end of this before — a weekly check that could never run, and a Claude Code routine that failed three weeks running while reporting itself fine.

How it's built

Under the hood, it's a Cloudflare Worker with a D1 database behind it. It discovers every property in my Google Search Console account, syncs them nightly at 03:30 UTC, and holds sixteen months of daily totals plus a ninety-day query-by-page backfill. A weekly Claude routine then reads all of it, writes a ranked list of suggestions into the dashboard, and files the urgent ones into Todoist as actual tasks. The rest — the charts, the CSV export, the mobile layout — was plumbing I could describe in an afternoon.

The boring decisions that mattered most

Two choices shaped the product more than any feature. The first was authentication. I asked for "least friction when adding a project", which sounds like a preference and is actually an architecture decision: with OAuth against my own Google account, a new property appears on the next nightly sync with no setup at all, whereas a service account would need adding to every property by hand, forever. The same sign-in locks the dashboard to one account, so the convenience and the access control come from the same mechanism.

The second was accepting what the API will and won't give you. Search Console's Search Analytics endpoint returns at most 25,000 rows per request and, in Google's own words, "does not guarantee to return all data rows but rather top ones". Fresh data has to be asked for explicitly, and when you do, the response tells you which date is still incomplete. A build that pretends otherwise produces a number that looks authoritative and moves overnight — the failure mode I keep writing about, most recently when file timestamps couldn't see staleness coming from outside the folder. The dashboard shows provisional days as provisional.

The honest caveat: on the free Workers plan the CPU ceiling is ten milliseconds, and a large property may not finish its sync. That's a five-dollar fix rather than a code fix, which is the right kind of problem to have left open.

What's still unproven

It's built, tested end to end against a mock API, and deployed. None of that is the real test. The real test is week six, when the novelty is gone and the list has eight items on it and I don't feel like doing any of them. The reopen rule is a bet placed against my own future laziness, by the version of me that still had energy.

That's the whole trick of agentic tooling at the moment, and it has very little to do with models. A routine that reports on its own work is cheap to build and easy to believe. A routine that refuses to let you lie to yourself takes one extra rule and an uncomfortable afternoon deciding what "done" is allowed to mean.

Advice expires when you've read it. A condition expires when it stops being true. Build for the second one.

Sources & further reading

External
Google SRE book — Monitoring Distributed Systems
Google Search Console API — Search Analytics: query reference
Cloudflare Workers — Cron Triggers
Cloudflare D1 — serverless SQL database