Step 2: Create a service account and grant it property access
Posted on July 19, 2026 by Abhay khant
Key Takeaways
Create a Google service account, grant it Full access to your Search Console property, and point gsc-indexer at its JSON key to stop 403 errors.
This is the step that unblocks 90% of users. If you've seen
403 You do not own this site, you're in the right place.
Why a service account (not your login)?
The CLI runs on your machine or a server, unattended. It can't "sign in as
you" with a browser. Instead it uses a service account. a robot identity
with its own credentials stored in a JSON file (sa.json). The tool presents
that file to Google to prove it's allowed to inspect your property.
Step 1. Create a Google Cloud project
- Go to the Google Cloud Console.
- At the top, create a new project (or pick an existing one).
- Note: a project is free for the Inspection API at normal volumes. You don't need to enable billing to follow this guide.
Step 2. Enable the API
- In the Cloud Console, open APIs & Services → Library.
- Search for Google Search Console API and click Enable.
- Forgetting this step causes auth errors later. don't skip it.
Step 3. Create the service account
- Open IAM & Admin → Service Accounts.
- Click Create Service Account.
- Give it a name (e.g.
gsc-indexer) and click Create and Continue. - Skip the role grant for now; click Done.
- Click the service account you just created, then the Keys tab.
- Add Key → Create new key → JSON → Create.
- A file downloads. that's your
sa.json. Keep it secret. Anyone with this file can inspect (and read stats about) your property. Don't commit it to git.
What the key file looks like
The downloaded sa.json is a JSON document. The one field you actually need
is client_email — that's the address you'll paste into Search Console in the
next step. A real key looks like this (values shortened; never share your
actual file):
{
"type": "service_account",
"project_id": "your-project-id",
"private_key_id": "a1b2c3d4e5f6...",
"private_key": "-----BEGIN PRIVATE KEY-----\nMIIE...\n-----END PRIVATE KEY-----\n",
"client_email": "[email protected]",
"client_id": "123456789012345678901",
"auth_uri": "https://accounts.google.com/o/oauth2/auth",
"token_uri": "https://oauth2.googleapis.com/token",
"auth_provider_x509_cert_url": "https://www.googleapis.com/oauth2/v1/certs",
"client_x509_cert_url": "https://www.googleapis.com/robot/v1/metadata/x509/gsc-indexer%40your-project-id.iam.gserviceaccount.com"
}
Copy the client_email value exactly — including the
@…iam.gserviceaccount.com suffix. gsc-indexer reads the same file at runtime
through -creds, so keep it on disk and out of git.
Step 4. Share the property with the service account
This is the exact fix for the 403 error.
- Go back to Google Search Console.
- Open your property → Settings → Users and permissions.
- Click Add user.
- In the email field, paste the service account's email. You'll find it in
sa.jsonas theclient_emailvalue. it looks like[email protected]. - Permission: Full (not "Restricted"). This is the critical choice. "Restricted" cannot inspect URLs and will still 403.
- Click Add.
If you only add the SA as Restricted, or forget this step entirely, you'll get
403 You do not own this site, or the inspected URL is not part of this property.Re-do Step 4 with Full access to fix it.
Step 5. Point the tool at the key
Either pass it on every run:
./gsc-indexer -creds /path/to/sa.json "https://www.toolsura.com/"
Or set it once as an environment variable:
export GSC_CREDENTIALS=/path/to/sa.json
./gsc-indexer "https://www.toolsura.com/"
Did I do it right? (pre-flight checklist)
- Cloud project exists and the Search Console API is enabled
-
sa.jsondownloaded and kept private - SA email added to the GSC property as Full user
- Property prefix exactly matches the URL you'll inspect (
www,https)
If all four are checked, you're ready. Next: install the tool and run your first inspection.
Sources
- Google Search Console
- URL Inspection API documentation
- Google Search APIs overview
- Service account OAuth (Google Identity)
- About service accounts (Google Cloud IAM)
- Verify site ownership
- Property types: URL-prefix vs Domain
- URL Inspection tool help
- Indexing API (JobPosting/BroadcastEvent only)
- Request indexing / inspect a URL
Frequently Asked Questions
Why do I need a service account instead of an API key?
The URL Inspection API requires OAuth, and an API key returns 401. A service account is an OAuth identity you can grant to the property. gsc-indexer reads the account's JSON key with -creds, so the tool authenticates as that account without any interactive login.
My 403 says 'you do not own this site'. What did I miss?
In 9 out of 10 cases the service account's client_email was never added to the property, or was added as Restricted instead of Full. Go to GSC Settings, Users and permissions, and add the client_email as a Full user. Restricted users cannot inspect URLs at all.
Where do I create the service account?
In Google Cloud Console, under IAM and Service Accounts, for the project that has the Search Console API enabled. Create the account, generate a JSON key, and download it as sa.json. Then enable the Search Console API for that project, or every call fails before it reaches indexing.
Does the service account need any special scope?
gsc-indexer requests the webmasters.readonly OAuth scope. Even with that scope, the account still needs Full property access inside Search Console itself; scope alone is not enough to inspect. Both the Cloud grant and the Search Console grant have to be in place.
Is my sa.json safe to keep on disk?
It is a credential. Anyone with the file can inspect and read stats about your property, so keep it private, never commit it to git, and store it as a secret in CI. Rotate it from Google Cloud the moment you think it has leaked, because the key alone is enough to act as your account.