An AI agent in Google Cloud: Search Console access and what the API cannot do

An AI agent can keep an eye on how a website is doing in Google. To do that it needs access to Search Console, Google's tool for search and indexing data. Our agent gets that access through a service account in Google Cloud. We work this way on our own website, so this article covers how to set it up, what the API can do and what it cannot. It ends with safeguards, because the agent is handed a key to company data.

It is written for website owners who want to know what they are agreeing to. Technical readers will find the API's scope and limits here too. The agent could be Claude Code or Codex, for example. What an agent is and when it helps is covered in AI agents in a company.

What a service account is

A service account is an account for a program rather than a person. It has its own email address and signs in without anyone present. An agent on an ordinary computer can sign in with a key for that account. The key is a file holding a private key, and you can download it only once.

Treat that key with care. Google says having it is similar to knowing a user's password, because whoever holds it acts as the account. By default, keys never expire. In Google Cloud organisations created on or after 3 May 2024, an organisation policy blocks key creation by default. If key creation is refused, that policy may be the reason.

How the agent gets access

Setting it up takes a few steps:

1. A Google Cloud project. In it, you enable the Search Console API.
2. A service account. A separate one, used for this task only.
3. A way to sign in. A key, for example, although Google recommends safer options, covered below.
4. A user in Search Console. The property owner opens Settings, then Users and permissions. There they add the service account's address and pick a permission level.

That is how we granted access. Without the last step, the API shows the agent no property at all.

According to Search Console Help, a restricted user can view most data but cannot submit a sitemap. A full user can view all data and submit sitemaps, but cannot add other users. An owner has full control of the property. A service account does not need the owner role for reports or for sitemaps.

The second layer is the scope a program asks for when it signs in. The API has two scopes, read-only and read/write. Our script asks for write access only when it submits a sitemap. Every read uses the read-only scope.

What the API can do

The API reference lists four areas:

• Search data. Clicks, impressions, CTR and average position, grouped by query or page, for example. One request returns up to 25,000 rows. Google notes that it does not guarantee every row, only the top ones. By default you get finalised data, and the freshest data has to be requested separately.
• Sitemaps. A list of submitted sitemaps with their status, submitting a new one and deleting an old one.
• Properties. The properties the account can access, and adding them to or removing them from the account.
• URL inspection. A URL's status in Google's index, such as whether it is indexed and when Google's crawler last visited it.

The URL inspection API only reports the version stored in the index and cannot test a live URL.

For a small website the limits are generous. URL inspection allows 2,000 requests a day and 600 a minute per property. On a shop with thousands of products, the agent has to spread checks over several days or pick the most important addresses. Search data has its own load limits. Requests grouped by both page and query weigh the most, and so do long date ranges.

This is how we use it. When our new website launched, the agent checked all 38 addresses in the sitemap and recorded a baseline of search data. That record is there to compare against after a week and after 28 days. After every deployment, the agent sends the updated sitemap to Google.

What the API cannot do

• Requesting indexing. The API has no such method. You request indexing by hand in the URL Inspection tool in Search Console. Google says that only an owner or full user of the property can do this, and that there is a quota. Requesting the same address again will not get it crawled faster. For many addresses, Google recommends a sitemap.
• Live tests. The tool in the interface fetches a page in real time and checks whether it can be indexed. The API cannot do that.
• The Indexing API for ordinary pages. Google has a separate Indexing API, but it can only be used for job postings and livestreams. Every submission goes through spam detection, and abuse can lead to access being revoked. It is not meant for articles or company pages.
• Removing results. The Removals tool hides a URL from results for about six months. It works only in the Search Console interface, and the API has no such method.
• Users and settings. Adding users and most settings stay with the owner. The API has no methods for them.

We take these steps by hand in the interface. Sometimes we submit new and changed addresses there, sometimes we leave it to the sitemap. Either way, Google decides when to visit. Its documentation says this takes anywhere from a few days to a few weeks, with no guarantee that the address will appear in results.

Safeguards

• One account for one task. Google recommends a dedicated service account for each application, with only the permissions it needs. Keep sensitive information out of the account's address. Disable an account you no longer use.
• The lowest level that works in Search Console. Start at the lowest level and raise it only when the task needs it.
• The key stays out of the code. It does not go into a repository, a chat or a log. Google reminds you not to leave a copy in your downloads folder or the recycle bin. If a key is committed to a repository, delete it in Google Cloud, because removing the file is not enough. Google also advises keeping the key off the file system, in a key store on the computer or in a hardware module, and advises against Secret Manager in Google Cloud.
• Keys as the exception. Google treats keys as the exception and recommends safer ways to sign in where they are available. One of them is impersonating the service account with your own credentials, so the logs show which person acted as the account. Our agent uses a key, which is all the more reason to keep to the other rules.
• Rotation and housekeeping. Google recommends rotating keys regularly, which also makes it easier to act quickly if a key leaks. Disable an unused key first, then delete it.
• The agent sees what the script sees. An agent that runs a script with the key can also read the key. That is why the key has narrow permissions and can be deleted at any time.
• Consent for writes. The agent reads data on its own. It submits the sitemap only after a deployment the owner has agreed to.

Where else this helps

Other Google services that accept a service account can be connected in a similar way. With Search Console alone, you could build:

• A weekly report. The agent gathers last week's queries and pages and shows what changed.
• A post-deployment check. After every change to the website, it checks whether the new addresses are indexed.
• A watch list. It keeps an eye on key addresses and flags any that drop out of the index.
• A link to your own data. It sets search data against orders or form enquiries, if your system can export them.

A task like this starts with reading only. Write access comes later, once the results have been checked and someone at the company is responsible for them.

This describes the position on 7 November 2026. If you would like Search Console data to reach your reports without copying it by hand, tell us what they should show.