Alessio's G-SEO Suite: One Google App So My Scripts Can Read (and Fix) My SEO

That morning started with a stupid bug. A school-register script had silently died because the Google connection was never set up. Not broken code. Not a weird edge case. Just no OAuth consent. Classic.

So I made a decision: I will have exactly two Google apps, forever. One for my workspace stuff — Gmail, Calendar, Drive, Contacts — which I wrote about in the companion article on Alessio’s G-Suite. And one for SEO. This one.

Search Console. Google Analytics. Google Tag Manager. I called it Alessio’s G-SEO Suite.

The point is simple: one consent, one mental box, one place where all my SEO scripts can ask Google for permission without me rebuilding the same mess every time.

Why SEO Gets Its Own App

At first, the lazy solution was obvious. One big Google app. Everything inside. Gmail, Drive, Search Console, Analytics, Tag Manager. Boom. Done. Except no.

The name on the consent screen is per Google Cloud project. So if I want one app called “Alessio’s G-Suite” and another called “Alessio’s G-SEO Suite”, that means two projects. And honestly, that is better.

One app touches my mail and files; the other touches websites’ data. Different stuff, different risk, different blast radius.

Do we want everything technically possible? Or do we want something we can still understand after coffee number two? I prefer the second one.

The Setup (Claude Code Did the Boring Part)

The project is owned by my company’s Google account, ISH Consulting, and linked to the company billing account. Before someone panics: these APIs cost nothing at this volume.

I had Claude Code driving Chrome while I watched. Which still feels a little strange, but also… yeah, this is exactly the kind of boring UI clicking I want a machine to do. Both apps together took 12 minutes. I only logged in.

The real win was not speed; it was removing all the tiny manual steps where I usually forget one checkbox and waste an hour later.

The flow was:

1. Create the Google Cloud project from the terminal.
2. Enable 4 APIs:
   • Search Console
   • Analytics Admin
   • Analytics Data
   • Tag Manager
3. Open the Google console.
4. Set the app name.
5. Add the support email.
6. Choose External.
7. Add the contact email.
8. Accept the policy checkbox.
9. Add the home page.
10. Add the privacy policy link.
11. Add the authorized domain.
12. Publish.
13. Create the Desktop client.

The home page and privacy policy are not optional if you want to publish. Without them, the Publish button stays greyed out. Nice little trap.

The app is External and In production, but unverified. This means a few important things:

• It is listed nowhere.
• It works only for accounts that consent.
• There is no 7-day expiry like Testing mode.
• Google shows the “Google hasn’t verified this app” screen at consent.
• There is a 100-user cap.

For me, this is fine. I am not building a public SaaS OAuth app here. I am giving my own scripts a stable door into Google data, for the accounts I choose.

Read Is Nice. Write Is the Point.

I did not ask only for read access. I asked for write access too. Search Console full. Analytics edit. Tag Manager edit containers, edit container versions, and publish. Seven scopes in total.

Read-only is comfortable, but write access is where a script can stop being a dashboard and start saving real time.

Example. Let’s say a client’s site I work on is missing its GA4 tag in Tag Manager.

With read-only, my script can tell me: “Hey Alessio, the tag is missing.” Great. Now I still need to open Tag Manager, find the container, create the tag, check the trigger, create the version, and decide what to do.

With write access, the script can add it. I still decide when it publishes. That part matters. I don’t want scripts randomly pushing changes like a drunk intern with admin access. But I do want the boring part prepared for me.

One Command Per Repo

Now every repo can use the same pattern.

Authenticate:

node tools/google-access.mjs auth seo <email>

Then check:

node tools/google-access.mjs check seo <email>

That’s it. The first check after consent gave me this:

• Search Console sees 1 site.
• Analytics sees 4 accounts.
• Tag Manager sees 0 accounts under that mailbox.

And that last one is actually the point. The Tag Manager containers I care about live under other accounts. Fine. I add that mailbox later, consent once, and nothing changes in Google Cloud.

One consent per mailbox is boring in the best possible way: predictable, repeatable, no new Google project every time.

What I Want To Do With It

My own site uses Umami for analytics. My own site now uses PostHog for analytics, because it is free up to a million events a month. Cookieless. Simple. On purpose. So this G-SEO Suite is not a religion. I am not suddenly putting Google Analytics everywhere because I made an OAuth app. It is a tool for the Google side of things where the Google side already exists.

I want my scripts to bring SEO data into the place where I work, not force me to keep clicking through Google UIs like it is a daily workout.

The things I want next: Pull Search Console queries into my own tools. Check indexing status without opening another tab. Read GA4 numbers next to the content they belong to. Look at Tag Manager containers and see what is missing.

And when something obvious is missing, prepare the fix. Not publish blindly. Prepare. There is a responsibility line here, and I want it visible.

The Other Half: DataForSEO

I need to say this, because it would be weird to talk about my G-SEO Suite and pretend it lives alone. For SEO work, DataForSEO is probably the best tool I have tested so far. I used to connect Search Console, Google Analytics, all the Google stuff, and yes, even Keyword Planner when needed. Then I started using DataForSEO and the level of depth was just different.

Google tells me what is already happening on my site. The clicks, the queries, the pages, the mess I already created. DataForSEO is what I use when I need to plan: look at SERPs, understand keywords, estimate what I am going against, and shape the content pillars before writing random articles because “content strategy” sounds nice. For me, the G-SEO Suite is the control room, but DataForSEO is the radar.

So no, it does not replace the app. It complements it. And honestly, when it comes to SEO planning, it is one of those secret powers I don’t want to work without anymore.

The Uncomfortable Part

The comfortable default is read-only. It feels safe. It makes everyone sleep better. It gives you dashboards, reports, alerts, and a false sense that work happened. Sometimes that is enough.

But many times the real time saving starts exactly where read-only stops. Also where you need discipline. Because giving write access to automation is not a small thing. It is a sharp tool. Useful, dangerous, and absolutely not something you leave around without thinking.

So the question for me is not “should scripts write or not?” Too simple.

The better question is: Where do I want the machine to stop, and where do I still want my finger on the button?