How to Create a Google Indexing API Key (Service Account)

A Google Indexing API key is a JSON file for a service account that lives in a Google Cloud project where the Web Search Indexing API is enabled, and whose email address is an Owner of your Search Console property. Creating one takes about ten minutes and costs nothing: a project, two APIs, a service account, a key file, and one entry under Users and permissions. The steps below follow the Google Cloud Console as it looks in 2026, and end with a curl call that proves the key works before you hand it to any plugin or tool.

What you are building

Five pieces, each needed by the next:

Piece	Where	Why
Google Cloud project	console.cloud.google.com	Quotas and API access are counted per project
Web Search Indexing API, enabled	APIs & Services, Library	Without it every call answers 403
Service account	IAM & Admin, Service accounts	The robot identity that signs the requests
JSON key	The service account's Keys tab	The private key your code or plugin uses to get access tokens
Owner permission	Search Console, Settings, Users and permissions	The Indexing API only accepts notifications from an owner of the property

If you want the background on what the API does, how the 200 per day quota works and who Google says it is for, read the Google Indexing API guide first.

Step 1: create a project

1. Open console.cloud.google.com and sign in with the Google account you use for Search Console. It does not have to be the same account, but it keeps things simple.
2. If this account has never used Google Cloud, accept the terms of service when asked. No billing account is needed.
3. Click the project picker in the top bar (it shows the current project name or "Select a project"), then New project.
4. Give it a name you will recognise in a year, such as indexing-yoursite. The project ID underneath is generated from the name and cannot be changed later.
5. Click Create, wait for the notification, then make sure the new project is selected in the top bar. Everything below happens inside this project, and the most common mistake in this whole process is enabling an API or creating an account in the wrong one.

Step 2: enable the two APIs

1. Open the left menu, APIs & Services, then Library.
2. Search for indexing. Open Web Search Indexing API and click Enable. The button changes to Manage once it is on.
3. Go back to the Library, search for search console, open Google Search Console API and enable it as well.

The second API is not required by the Indexing API itself. It is how you, or a tool, can ask Google "which properties does this service account own?" and get a definite answer, which is the fastest way to debug an ownership 403 later.

Step 3: create the service account

1. Open IAM & Admin, then Service accounts.
2. Click Create service account.
3. Enter a name, for example indexing. The email address below it is generated: [email protected]. Copy it somewhere, you will paste it into Search Console in step 5.
4. Click Create and continue.
5. The next two screens, roles and user access, are optional. The account needs no role in the project to call the Indexing API. Click Continue, then Done.

Step 4: create the JSON key

1. In the service accounts list, click the account you just created.
2. Open the Keys tab.
3. Click Add key, then Create new key.
4. Choose JSON and click Create.

Your browser downloads a file named something like indexing-yoursite-1a2b3c4d5e6f.json. This is the only copy. Google does not store the private key and cannot give it to you again; if you lose the file, you create a new key and delete the old one. The file contains client_email, which is the address from step 3, and private_key, which is the secret.

If the Add key menu is greyed out or the creation fails with a policy error, your organization blocks service account keys (see the FAQ). You cannot fix that from the project.

Step 5: add the service account as Owner in Search Console

1. Open Search Console and pick the property for your site. A Domain property (sc-domain:yoursite.com) covers every subdomain and protocol; a URL-prefix property only covers URLs that start with that exact prefix, so https://yoursite.com/ does not cover https://www.yoursite.com/page.
2. Click Settings at the bottom of the left menu, then Users and permissions.
3. Click Add user in the top right. If the button is missing, you are not an owner of this property and need someone who is.
4. Paste the service account email into Email address.
5. Open the Permission list and choose Owner. The list starts on Full, and Full is not enough.
6. Click Add. The account now appears in the table with the permission Owner.

Google's APIs can take a minute or two to see the new owner. If the test below fails straight away with an ownership error, wait and try again before changing anything.

Step 6: test the key with curl

The quickest check uses the gcloud command line tool to turn the key into an access token, then calls the getMetadata endpoint, which costs no publish quota:

gcloud auth activate-service-account --key-file=indexing-yoursite-1a2b3c4d5e6f.json
TOKEN=$(gcloud auth print-access-token --scopes=https://www.googleapis.com/auth/indexing)

curl -s -H "Authorization: Bearer $TOKEN" \
  "https://indexing.googleapis.com/v3/urlNotifications/metadata?url=https%3A%2F%2Fwww.example.com%2Fjobs%2F123"

The URL in the query string must be percent encoded. Read the answer like this:

Response	What it means
404 with "Requested entity was not found"	Everything works. The key authenticated, the API is enabled, the account owns the property, and you have simply never sent a notification for this URL
200 with latestUpdate or latestRemove	Same, and a notification for this URL was sent before
403 "Permission denied. Failed to verify the URL ownership."	Step 5 is missing or wrong: not Owner, wrong property, wrong host or protocol, or the key belongs to a different service account than the one you added
403 "Web Search Indexing API has not been used in project ... or it is disabled"	Step 2 was done in another project, or not at all
401	The token is bad or expired. Re-run the two gcloud lines

If you prefer not to install gcloud, any of the client libraries can do the same call; there are complete Python, PHP and Node.js examples in Google Indexing API code examples. To send a real URL_UPDATED as a test, pick a page that returns 200, is not noindex and is canonical; the indexability checker confirms that in seconds, and it saves you spending one of the day's 200 on a page Google cannot use.

Keep the key safe

The JSON file gives whoever holds it Owner-level API access to your Search Console property. Treat it like a password:

• Store it outside the web root, never in a theme folder, a public repository or a shared drive.
• Give a tool or plugin the file once, then keep your own copy somewhere encrypted.
• Create a separate key for each tool, so you can revoke one without touching the others. The Keys tab lists every key with its creation date.
• Delete keys you no longer use: select the key, click the bin icon. Deleting a key breaks nothing except the tool that used it.
• Rotate on a schedule if your company requires it: create a new key, swap it in, delete the old one.
• If a key leaks, delete it immediately in the Keys tab. The service account itself can stay.

Removing the service account from Users and permissions in Search Console stops all submissions at once, whatever keys still exist.

One project per site

Quota is per project: 200 publish requests per day, shared by every site the service account is an owner of. If you manage three sites and each needs its own 200, create three projects and three service accounts, and add each one as Owner on its own property. What you should not do is create ten projects for one site to send 2,000 URLs a day. Google's documentation says attempts to exceed the quota through multiple accounts can lead to access being revoked, and the proper route is the quota increase form described in Google Indexing API quota. For job sites, which are the official use case, that form is worth filling in; see Indexing API for job postings.

How the same steps appear in TurboIndex

TurboIndex can run with a shared key or with a key of your own, and the own-key path is exactly this page. With Upload your key you do steps 1 to 4 by hand, upload the JSON file, and the wizard shows the client_email for you to add as Owner (step 5), then runs the same ownership check as the curl call above. With Set it up for me you grant a one-time Google Cloud permission and the wizard performs steps 1 to 5 in your account: one project named after the site, the two APIs, the service account, one JSON key stored encrypted, and the owner entry. The project and the key belong to you either way, and you can delete them from Google Cloud whenever you want.

What to do next

1. Run the curl test and keep going only when you see the 404 "not found" answer or a 200.
2. Give the key to one tool or plugin, and note which key went where.
3. Send one URL_UPDATED for a real page and inspect that URL in Search Console two or three days later to see the crawl.
4. Put a reminder in your calendar to review the Keys tab twice a year and delete what is unused.