Service account setup for Search Console access
· 4 min read
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, 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 (request indexing)
- Indexing API (JobPosting/BroadcastEvent only)
Written by
Abhay Khant
Hi, I'm Abhay Thakor
I'm a developer, builder, and technology enthusiast interested in turning ideas into useful products.
I enjoy working across web development, cybersecurity, automation, SEO, and content creation. Rather than only learning technologies individually, I like putting them together to build things that people can use.
One of my main projects is Toolsura, a free online utility platform that brings practical tools into one place. I'm building Toolsura as a product and a learning project where I can explore development, infrastructure, SEO, content distribution, automation, and product growth.
What I Build
My work currently revolves around several areas:
Web development with Next.js, React, Tailwind CSS, and modern web technologies
Backend development with Go, APIs, databases, and server-side systems
Automation using n8n, APIs, Docker, and connected services
SEO and content systems for building organic search traffic
Cybersecurity including web security, bug bounty, SOC concepts, and malware analysis
Content creation including video editing, YouTube content, graphics, and promotional videos
I enjoy going beyond tutorials and experimenting with complete systems, from the frontend interface all the way to the backend, deployment, automation, and distribution.
Toolsura
Toolsura is one of the projects I'm most actively building.
The idea is simple: create useful, accessible online tools that solve small problems quickly.
Toolsura includes utilities for things such as text, JSON, URLs, PDFs, images, security checks, and other everyday technical tasks.
Building it has also become a practical way for me to learn how a modern web product works.
That means working on:
Product → Development → Infrastructure → SEO → Content → Distribution → Automation → Growth
Technology & Learning
I'm particularly interested in understanding how systems work rather than simply learning how to use them.
My development work has included technologies such as:
Next.js · React · TypeScript · Tailwind CSS · Go · Gin · GORM · PostgreSQL · MongoDB · Docker · RabbitMQ · MinIO · Strapi
I've also worked with Linux environments and tools such as Kali Linux, Termux, and related security tooling.
My cybersecurity interests include web application security, bug bounty research, SOC analysis, and malware analysis.
Building in Public
I also create content around the things I build and learn.
This includes:
Tutorials and technical articles
YouTube videos
Product demonstrations
Visual explainers
Promotional videos
SEO-focused educational content
My goal is to turn projects and experiments into useful resources that other people can learn from.
Why I Build
For me, building is one of the best ways to learn.
Instead of learning a technology in isolation, I prefer starting with a real problem and figuring out what is required to solve it.
Sometimes that means writing code. Other times it's debugging a deployment at midnight, or working out why a page isn't being indexed, why an API isn't behaving correctly, or how to automate something that would otherwise take hours.
Those problems are part of the process.
Every project gives me another opportunity to understand how technology works in the real world.
What I'm Working Toward
I'm continuing to develop my skills across software engineering, cybersecurity, automation, and digital products.
At the same time, I'm building Toolsura into a useful platform and experimenting with different ways to create, distribute, and grow technical products.
There is still a lot to learn, but that's exactly what makes building interesting.
Let's Connect
If you're interested in web development, cybersecurity, automation, SEO, online tools, or building products, feel free to connect.
I'm always interested in learning, experimenting, and building something useful.
Build. Learn. Improve. Repeat.