I Built a Local GSC + GA4 Tool to Find the Next Content Improvement Worth Making
I keep running into the same awkward moment in content work.
Search Console says a page lost clicks. GA4 says engagement changed. The dashboard looks serious. Everyone looks at it for a bit. Then someone asks the question that actually matters:
What should we do next?
The honest answer is usually: not enough to rewrite the page yet.
That is not a satisfying dashboard answer. It is often the correct one.
So I built Site Signal: a small, open-source command-line tool and local MCP server that turns GSC and GA4 data into a short investigation queue.
It does not promise a magic “SEO score”. It does not publish anything. And it does not quietly shovel your analytics into somebody else’s SaaS dashboard. You connect your own properties, and the token, cache, reports, and snapshots stay on your machine.
The dashboard is not the decision
Google Search Console is excellent at showing search performance. GA4 is useful for showing what happened after a visit. The trap is treating them as one clean story.
They are not.
A GSC click is not a GA4 session. You cannot attribute a search query to a person, a conversion, or a later page view. High impressions and a low CTR do not automatically mean your title is bad. And a page with three days of data has not “failed”. It has barely arrived at the party.
I still have to actively edit for this when I look at my own data. A metric changing is an observation. A page rewrite is a decision. There should be a bit of evidence between those two things.
What Site Signal actually does
The default report compares the last 28 complete days with the previous 28, while leaving a short reporting lag at the end. It then:
- fetches finalized page-level GSC performance;
- fetches GA4 landing-page and source/medium rows separately;
- normalizes URLs locally before comparison;
- shows bounded Search Console query examples for a selected page in both periods;
- highlights the observed movement in those returned query rows;
- applies transparent review gates; and
- saves a compact Markdown and JSON report locally.
The output is an investigation queue, not a queue of automatic fixes.
For example, it might flag a page that lost clicks and impressions at enough volume to be worth checking. Your next step is still to inspect the query mix, position, reader intent, and page context. You might update the article. You might add an internal link. You might decide nothing changed that warrants work. All three outcomes are healthier than blindly changing a title because a chart moved down and to the right.
An early Site Signal report from my own site. The important bit is the wording: these are evidence-backed investigations, not automatic content changes.
From a page decline to the queries that moved
This is the part I wanted most when I built the first version.
If a page lost clicks, you can now inspect up to five Search Console query examples for that page in the current period and the previous period. Site Signal shows the observed click, impression, and position movement for the returned rows.
That does not turn the API into a complete keyword database. Search Console returns top rows and can withhold low-volume queries. A missing row is new/no baseline, not proof that the query vanished. But it is enough to replace “this page declined” with a more useful question: which visible query theme changed, and does the page still deserve to answer it?
On one of my own articles, that quickly showed the meaningful movement was not a mysterious site-wide event. The query “chatgpt prompt” moved from 10 to 3 clicks, 353 to 78 impressions, and average position 11.8 to 19.2 across equivalent periods. That gives me a specific investigation to run before I touch the page copy.
Why I made it local-first
There are plenty of tools that can collect more SEO data than you will ever have time to interpret. That was not the problem I wanted to solve.
I wanted something small enough to run against one site, private enough to use with real reporting data, and explicit enough that I could hand its output to an AI assistant without turning the prompt into a full-site data dump.
Site Signal has no cloud database, paid SEO subscription, background model call, or hidden LLM bill. It asks Google only for read-only Search Console and Analytics access. It never edits your website, changes GA4 configuration, creates an event, or messages another system.
Think of it as a content preflight check. It tells you which investigations are worth bringing onto the runway. It does not fly the plane for you.
What you can use it for
If you own content, SEO, or growth work, Site Signal is useful when you need to:
- identify material page-level search changes without filling a backlog with noise;
- keep search performance and on-page behaviour evidence separate;
- record what you changed, the baseline you used, and when to review it; or
- give Codex a bounded local report to interpret instead of pasting an analytics account into chat.
It is deliberately not a measure of “AI visibility”, total query coverage, or causal impact. I would rather a tool says “insufficient evidence” than produce three generic recommendations to make a report look busy.
Try it on your own site
Site Signal is available on GitHub. It includes a synthetic demo report, setup instructions for Google Desktop OAuth, an MIT licence, and a local stdio MCP mode for Codex or another MCP host.
You bring your own GSC property and numeric GA4 property ID. The data stays yours.
If you are doing content work from Search Console data, start with one page. Ask what changed. Ask what you can actually infer. Then decide whether the next move is a content edit, an internal link, a distribution test, a measurement fix, or no action at all.
That last option is underrated. It has saved me from a lot of very productive-looking SEO side quests.
Recommended next
More writing connected to this topic, based on shared tags.