Everyone agrees you should "let AI do your SEO." Few people explain what that looks like when you actually build it. This is the setup I run on my own site: an AI agent with read-only access to Google Search Console, a dedicated service account via gcloud, and one small, verified improvement per run — every thirty days.
The article below is a crosspost from my site. It covers the full loop: setup, prioritization, one-change-per-run, measurement, and the honest learning curve before anything runs on its own.
Automating SEO with AI, in practice, means: an AI agent with read access to your Google Search Console that pulls the real search queries from your data every thirty days and makes one small, verified improvement to your pages. That is not a robot that lifts your website to the top of Google while you drink coffee — that robot does not exist. It is a loop: pull data, prioritize, improve, measure, and again thirty days later. Not everything at once, not on a hunch — one thing per run, measured and logged.
That approach works because SEO is not a one-time project but a habit. Anyone who looks at the same data every month and makes one targeted intervention each time will see their pages gradually align better with what people actually search for. The agent makes that habit affordable: it does the heavy lifting — pulling data, prioritizing, preparing — while you make the decisions. At first you supervise every run. After a few months, most of it runs automatically on a cron job.
An agent like Hermes can query an API, read and write files, run a build, and inspect the result. For recurring GSC analysis, I combine those tools with a dedicated service account: gcloud handles the Cloud setup, and Search Console grants that account read access to the property. The agent can then retrieve data without waiting for me to sign in through a browser again.
SEO is an ideal application for this, for three reasons: The source data is objective. Search Console shows literally how people find you: queries, impressions, clicks, positions. That gives the agent source data, but does not prevent hallucinations or incorrect interpretation. Check its conclusions against the export; anonymized queries and API limits make the data incomplete. The feedback loop already exists. Thirty days after every change you see in the same data whether it had an effect. That is a perfect learning loop for a step-by-step process. The work is repetitive but requires judgment. Pulling and organizing data is pure routine. Interpreting and prioritizing takes judgment. That exact mix is where a supervised agent shines.
Done manually, most people pick this up once a quarter with a spreadsheet and good intentions. The agent turns it into a fixed rhythm — and rhythm is the most underrated success factor in SEO.
For scheduled SEO runs, I use gcloud with a dedicated service account. The agent gets its own Google identity, added as a read-only user to the Search Console property, rather than relying on my personal login. You need: A Google Cloud project and gcloud, with an administrator who can enable the Search Console API and create the service account. A Search Console property owner who can add that account under Users and permissions. An agent that can use tools, such as Hermes from Nous Research, Claude Code, Cursor agents, or your own application around a language model. A git repository for small, reviewable website changes, separate from the Google credentials.
Run these setup commands as a human administrator with the required Cloud permissions. Replace YOURPROJECTID with your existing project ID; the example account name is seo-reader:
The account's email address will be seo-reader@YOURPROJECTID.iam.gserviceaccount.com. Do not give it broad Cloud Owner or Editor roles. A Cloud IAM role does not grant access to your Search Console property; you add that separately. If it needs permission to consume the quota project, grant the narrow Service Usage Consumer role there, not project-wide administration. See Google's service account setup guide.
In Search Console, the property owner opens the exact property, then Settings → Users and permissions → Add user. Enter the service account's full email address, choose Restricted, and add it. You do not need to make the account an owner or verify the domain again. Google's permissions table confirms that Restricted users can read the Performance report, which is what this loop needs.
Configure the API client to request https://www.googleapis.com/auth/webmasters.readonly, as documented in Search Console authorization. The property role limits what the account can do; the OAuth scope limits what its API token can do. That scope is not tied to one website, so add the account only to properties the workflow needs. A domain property uses an identifier such as sc-domain:example.com; a URL-prefix property uses its exact URL prefix.
Use an attached service account or Workload Identity Federation when the runtime and GSC client support it. These avoid storing a long-lived private key. If your local runner needs a JSON key, create one in Google Cloud under the service account's Keys → Add key → Create new key. Follow your organization's key policy and store the file outside your repository. The following path is a placeholder for that protected file:
Set these variables in the environment that actually starts the agent or its GSC connector, including scheduled runs. A cron job does not automatically inherit your interactive shell's exports. Use a client that supports Application Default Credentials (ADC), with the read-only scope above. ADC locates the credentials; it does not choose the permissions for you. ADC and the gcloud CLI also use separate credential configurations: being logged into gcloud does not configure the application's credentials.
Google's authentication library obtains and renews short-lived access tokens for the service account without an interactive browser login. Personal OAuth can also refresh tokens, but it ties the job to a person's authorization. A service account removes that dependency, making unattended runs easier to maintain. It is not maintenance-free: rotate keys, revoke unused credentials, and review access. Keep keys and tokens out of prompts, logs, Git, and browser code; Google's key-management guidance explains the risks.
Before scheduling the loop, run a small Performance-data query through the same client and environment the scheduled job will use. Confirm the intended property and service account, and stop if access fails rather than falling back to your personal credentials. Isolate the runner from other credentials too. Website changes still go through your codebase and review flow; GSC read access does not authorize publishing.
Every run starts the same way: the agent pulls fresh Search Console data for a bounded period — say the last thirty days, or a comparison with the thirty days before that. It requests the top queries per page, with impressions, clicks, CTR, and average position, and writes that away as a structured file in the repo. From that moment it no longer works with live APIs but with a snapshot you can inspect and compare against previous runs.
One important detail: Search Console data only becomes final after a few days. Google itself says about fresh data points: "Each fresh data point will be replaced with the final data point after a few days" (Google Search Central Blog on data freshness). Measure too early and you draw conclusions from numbers that still shift. That is why the agent works with closed periods and preferably compares month over month, never day over day.