I Quit Manual Search Console Mondays — The AI Scripts That Took Over

For a long time I treated Search Console like a ritual. Monday morning, kopi still too hot, sixteen tabs, export CSV, squint at positions, pretend I “audited” the site. Then I’d miss a cannibalisation issue for three weeks and wonder why the blog from last month just… evaporated.

If you manage more than one property — say a Tokopedia seller blog, a company site, and a client on WordPress that nobody wants to touch — the ritual becomes a second job. The interface is fine for poking around. It is a terrible weekly operating sytem.

This is the setup I actualy use now. Not a fantasy stack. Apps Script or Python to pull the data, a small SQLite or Sheet to keep history, and an AI pass that writes the audit in human langauge so I can act on it before standup. You dont need a data team. You need one boring pipeline and a prompt that doesnt hallucinate rankings.

Why clicking around Search Console is quietly wasting you

The UI caps tables at 1,000 rows. On a site with real query volume that is not even the intresting part of the iceberg. Glenn Gabe has been yelling this for years: if you only live in the Performace report, most of your long-tail is invisible. You think traffic is “stable” becuase the head terms look fine, while twenty supporting URLs are rotting in positions 8–14.

There’s also the new mess. AI Overviews and AI Mode queries show up in wierd ways. Some clicks land, alot of the query strings get anonymised, and the built-in AI helper inside Search Console can set filters from a sentance — but it still cannot sort a table the way you want, export the result, or join anythign with GA4. Google even warns that the helper can misread your request. Cute, not sufficient.

I used to screenshot the Coverage graph and call it an audit. That is not an audit. An audit answers: what changed, why it probably changed, and what I should do this week. Humans are bad at that when the data is 40,000 rows. Models are decent at it if you feed them structured diffs, not vibes.

What a real weekly audit should actually answer

Forget the 40-point checklists that look like they were written for an enterprise RFP. For most sites — including Indonesian UMKM shops that rank for a mix of Bahasa and English queries — you need five questions, every week:

1. Which URLs lost clicks vs the previous 7 and 28 days, with enough volume that it isnt noise?
2. Wich queries rose in impressions but CTR fell — classic “you’re showing up and nobody wants you” pattern, often AI Overview suppression or a bad title.
3. Which pages rank for overlapping queries (cannibalisation), expecially near-duplicates in Bahasa and English.
4. What is newly excluded or not indexed, and is it a template problem or one-off?
5. Are there conversational / AI-ish queries appearing that your content never bothered to anwser?

If your script (and the model after it) cannot answer those, you built a dashboard, not an audit. Dashboards make you feel informed. Audits make you change a title tag before lunch.

A note on “AI Mode” traffic you cannot fully see

As of mid-2026, several practitioners have re-checked this: the Search Analytics API and even the BigQuery bulk export do not cleanly expose generative AI trafic the way the UI sometimes hints at. Jean-Christophe Chouinard’s regex trick for conversational strings inside the Query filter is still one of the few free ways to surface prompt-like queries. If you automate, bake a similar classifier into the pipeline instead of pretending Google handed you a perfect “AI clicks” dimension.

That gap is annoying. It is also why a script plus a model still beats staring at the Generative AI report once a month and guessing.

Pick a stack you will still maintain in November

I see peopel jump straight to MCP servers talking to Claude Desktop. That’s fun if you already live in Cursor. If you are a content lead who opens Sheets more than a terminal, start smaller. The data layer matters more than the chat UI.

Option A — Google Apps Script into a Sheet

Best when you already live in Workspace. You authenticate once, pull searchAnalytics.query, dump rows into a tab, and keep a rolling 16 months if you want. The Search Console API is the same one everyone else uses. Rate limits exist. Dont request 25,000 rows for five dimensions on fifteen properties at 7:00 every morning or you will recieve the kind of errors that make you think the API “is down.”

I like this for Indonesian in-house teams becuase nobody has to babysit a VPS in Singapore. The Sheet is the database. Ugly, visible, shareable with a founder who only speaks in screenshots.

Option B — Python + SQLite on a tiny box

This is what I moved to once I had more than three domains. Service account, webmasters.readonly scope, nightly pull of date / query / page, store aggregates, then a decay query: URLs whose clicks dropped 30% week over week with a minimum of 20 clicks in the prior window. That last filter matters. Without it you will “alert” on a blog post that got 4 clicks becuase someone in Bandng searched a wierd brand typo.

The decay idea in plain langauge: compare last 7 days of clicks per URL against the 7 days before that. Ignore anythign tiny. Rank the losers. That list is your Monday. Not the whole property.

Option C — MCP if you already chat with your repo

There are Search Console MCP servers now that list sites, run search analytics, and inspect URLs. Fine for exploratory work. I would not make MCP the only copy of truth. Models are sloppy with date ranges. Keep the pull in a script you can rerun withotu a chat window.

The first script: pull, don’t philosophise

Your v1 should do three things and then shut up.

1. Authenticate like an adult

Service account is cleaner than OAuth-in-a-browser for cron. Add the service account as a user on the Search Console property. Use the property URL exactly as GSC knows it — sc-domain:tokobaju.id versus https://www.tokobaju.id/ are not the same object and you will stare at empty rows for an hour. I have done this. It is not a personality trait I am proud of.

2. Pull a boring, wide extract

Dimensions: date, query, page. Maybe device later. Country if you sell across SEA and want to see Malaysia leaking into your Indonesian content. Row limit: start at 5,000 while you test, then climb. Search Console data has a delay of a cuople days, so your “yesterday” pull is often incomplete. Most nightly jobs I trust pull through today-minus-3 as the end date.

startDate: today - 16 days
endDate: today - 3 days
dimensions: ["date", "query", "page"]
rowLimit: 25000

Store raw-ish rows. You can always aggregate later. If you only store weekly totals you cannot debug a single Tuesday when a category page fell off after a template deploy.

3. Compute diffs, not vibes

For each page and each query, compute clicks, impressions, CTR, average position for this week vs last week vs the previous 28 days. Flag:

• position worsened by 3+ with impressions still healthy (you’re still being shown, you’re just loosing the click)
• impressions up, CTR down 20%+ (snippet problem or AI Overview eating the SERP)
• two URLs both in top 10 for the same query (cannibalisation, very common when you have /blog/cara-daftar-npwp and /panduan/daftar-npwp)
• queries with 0 clicks and position under 8 — the “almost” pile, gold for title rewrites

That flagged table is what you send to the model. Not the entire extract. If you paste 80,000 rows into a chat you get a poetic summary of nothing.

The AI pass: make it an analyst, not a novelist

This is where people get lazy and the output turns into “consider improving your content quality.” I would rather read a parking ticket.

Give the model a role, the flagged rows, a short note on what shipped last week, and a rigid output format. Something like:

You are a technical SEO reviewing Search Console diffs for a Bahasa-first ecommerce site selling skincare from Jakarta, shipping nationwide. Data is alredy filtered to material changes. Do not invent ranking factors Google never stated. For each issue, write: (1) what moved, with numbers, (2) the most likely on-site cuase, (3) one action I can do today, (4) confidence high/med/low. Group by URL. Max 12 issues. If the data is thin, say so.

Notice what I did not ask for: a full rewrite of the homepage, a backlink fantasy, or “add more keywords.” The model is great at grouping and narrating tables. It is average at strategy if you let it freewheel.

I also paste a tiny changelog. “Tuesday: new related-prodcuts module on /serum-niacinamide. Thursday: title tests on 8 category pages.” Without that, every trafic dip becomes “maybe a Google update.” Sometimes it is your own JavaScript.

URL Inspection in bulk, but gently

The URL Inspection API is tempting. You want to know index status for 2,000 PDPs. The quota will humble you. Use it for the losers and the new URLs from the last sitemap ping, not the whole catalog. Agencies that loop inspection across every client property overnight learn this the expensive way.

A practical pattern: nightly performance pull is wide. Inspection is a second job that only runs on URLs the first job marked as “dropped out of top 20” or “new this week.” Keep a log so you dont inspect the same URL daily. Google is not your staging server.

What I actually look at for a site like a local brand

Let me make this concrete. Imagine “Sari Daun,” a made-up but very real-feeling brand selling jamu and herbal drinks, content in Bahasa, some English for expats in Jakarta Selatan. Typical Search Console picture:

• Head terms: jamu kunyit asam, manfaat temulawak — stable-ish, CTR getting chewed when AI Overviews appear.
• A cluster of recipe posts ranking for overlapping questions. Two posts both want “cara buat jamu beras kencur.” Neither wins.
• Prodcut URLs with impressions from generic queries they should not rank for, stealing crawl attention.
• A handful of “write me a” style queries leaking in — peopel pasting chatbot prompts into Google. Weird, but useful. It tells you the queston behind the keyword.

The automated audit for Sari Daun last month (hypothetical numbers, the shape is real) said: recipe URL A lost 38% clicks week-over-week, position 4 → 9; URL B gained impressions for the same query. Action: pick a canonical winner, 301 the weaker recipe or retarget it to a diffrent modifier (“untuk anak” vs “untuk diet”). Second finding: category page CTR fell while position held — title still read like 2019, no number, no benefit. Third: 14 products excluded as “alternate with proper canonical” after a plugin “helpfully” canonicalised variants. That last one a human mgiht notice in Coverage. The script noticed it on Wedensday, not three weeks later when sales felt “a bit off.”

Relatable? If you have ever launched a flash sale landing page on a .id domain and forgotten to add it to the sitemap, you alredy know the feeling.

Alerts that dont train you to ignore them

Email is a graveyard. If your script mails a 40-page PDF, you will mute it. I send:

• a Slack (or WhatsApp via a tiny gateway, becuase that is how Indonesian teams actualy work) with the top 5 URL losers and 5 query opportunities
• a link to the Sheet tab for peopel who want to poke
• silence if nothing crossed the threshhold

Silence is a feature. A pipeline that always screams is just another dashboard. Set floors: minimum clicks, minimum impressions, ignore branded queries if you only care about non-brand growth. For a national brand, branded queries will dominate and make every report look like a victory lap.

I also seperate “indexing fires” from “performace weather.” A spike in 404s after a migration is a page-the-engineer issue. A slow CTR bleed on five articles is a writer issue. Mixing them in one blob means nobody owns it.

Mistakes I keep seeing (and have made)

Pulling only 28 days and calling it history. You need a baseline from before the last redesign. Keep at least 90 days in storage, 16 months if you can. Seasonality on Indonesian sites is real — Lebaran wrecks ecommerce comparables. Week-over-week during Ramadan is how you scare yourself for no reason.

Letting the model invent causes. If you dont constrain it, it will blame “E-E-A-T” for a robots.txt accident. Force it to point at the row. “Clicks 120 → 61, position 5.2 → 11.4, no indexing change” is a story. “Google updted the algorithm” is a shrug.

Ignoring langauge duplicates. hreflang mistakes show up as two URLs sharing queries. Bahasa pages ranking in en-ID Google and vice versa. Your audit should group by query similarity, not only exact match. A cheap trick: normalise queries (lowercase, strip punctuation) before clustering. You dont need BERT on day one.

Auditing everythign at the same cadence. News homepages need daily. A company profile that gets 80 clicks a month needs monthly, plus an indexing watchdog. If you run the full AI essay every day on a tiny site you will overfit noise and “optimise” titles into oblivion.

Forgetting that Search Console is not analytics. Clicks are not sessions. Position is an average accross a mess of appearances. When the AI writes “traffic dropped 12%,” check GA4 before you rewrite the whole cluster. I have watched peopel “fix” a healthy page becuase GSC and GA4 attributed a branded campign differently.

A lightweight weekly ritual that replaced my tab circus

Sunday night the cron runs. Monday I open a 12-issue brief, not the GSC UI. I pick three actions max. One technical, one snippet, one content merge. I write those three lines in the changelog so next week’s model knows what we already tried. Firday I glance at whether those URLs moved — knowing full well CrUX and ranking changes both lag, so I am looking for direction, not a TED Talk about causation.

Once a month I do a slower pass: sitemap vs indexed counts, a sample of URL Inspection on new templates, and a look at those conversational queries. That monthly pass is where you decide if you need FAQ schema on the jamu pages or a new comprison article. The weekly pass is just not dying.

If you are an agency, run properties in a loop but isolate clients in seperate databases or Sheet files. Mixing Client A’s decay into Client B’s prompt is how you send a very confident, very wrong Slack message. Ask me how I know. Or dont.

What to build this afternoon, not “someday”

You do not need the perfect platform. You need a first honest extract.

1. Enable the Search Console API on a Google Cloud project. Add a service account to one property you actualy care about.
2. Write the smallest pull: last 14 days, query + page, 5,000 rows, dump to Sheet or SQLite.
3. Compute week-over-week click deltas. Sort. Stare at the top 20 with your own eyes once, so you trust the numbers.
4. Only then wrap an AI summary around the flagged rows, with the strict output format above.
5. Set one alert: “URL lost ≥30% clicks, prior week ≥20 clicks.” Live with it for two weeks. Tune the floor.

After that you can get fancy — BigQuery bulk export, cannibalisation clustering, a regex for prompt-like queries, MCP for ad-hoc questions. Fancy is optional. The extract is not.

Honestly, the win is psychological. I used to open Search Console to feel responsible. Now I open a brief that already did the squinting. I still go into the UI when something looks cursed. I just dont live there.

If you only do one thing after reading this: stop exporting a fresh CSV every Monday and starting from zero. History is the whole point. Google will not keep your memory for you. The script will.

A last, slightly unglamorous thought

Automation does not replace judgment. It replaces the part of the job that made you late to the 10:00 call. The model will miss sarcasm in a query, misread a brand name, and occassionally treat a prodcut URL like an article. You still decide wether to merge, noindex, or leave it alone becuase it’s a seasonal page that allways dips after 17 Agustus sales.

Build the pipe. Keep the changelog. Make the AI write short. Then go drink the kopi while it’s still warm. That was the orignal goal, remember?