Automating gsc-indexer in CI with -json and exit codes
Posted on July 19, 2026 by Abhay khant
Key Takeaways
Automate gsc-indexer in CI: cron or GitHub Actions, parseable -json output, non-zero exit codes, and sa.json stored as a secret.
gsc-indexer is built to run unattended. in a cron job, a GitHub Action, or
any pipeline. Two features make that safe: machine-readable output and
predictable exit codes.
-json: parseable output
-json emits a single JSON array of results at the end, with no progress
noise in between (so the output stays valid JSON):
./gsc-indexer -creds sa.json -batch urls.txt -json
Each element looks like:
{
"url": "https://www.toolsura.com/post/",
"indexed": true,
"coverage_state": "Submitted and indexed",
"fetch_state": "SUCCESSFUL",
"last_crawl_time": "2026-07-18T07:05:51Z"
}
Pipe it into jq or your own script to act on the results.
Exit codes
- Exit 0. the run finished. This includes URLs that are merely
NOT INDEXED. that's a normal result, not a failure. - Exit non-zero. at least one URL failed (network error, HTTP error, or unparseable response).
This makes the tool CI-friendly: a pipeline step fails only when something genuinely broke, not just because a page isn't indexed yet.
Example: nightly sitemap re-index (cron)
## m h dom mon dow command
30 3 * * * cd /opt/gsc-indexer && ./gsc-indexer -creds /etc/sa.json "https://www.toolsura.com/sitemap.xml" -delay 10s -q -report /var/log/gsc-report >> /var/log/gsc.log 2>&1
Example: GitHub Action
name: reindex
on:
schedule:
- cron: "30 3 * * *"
jobs:
index:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-go@v5
- run: go build -o gsc-indexer .
- run: ./gsc-indexer -creds "$GSC_CREDS" "https://www.toolsura.com/sitemap.xml" -delay 10s -q
env:
GSC_CREDS: ${{ secrets.GSC_CREDS }}
Store
sa.jsonas a secret (file or env var). Never commit credentials to the repo.
-color: never breaks piped output
Color is auto by default (on for terminals, off when piped). You can force
it with -color always or disable it with -color never. Color is decorative
only. the INDEXED / NOT INDEXED text always carries the meaning.
Next
- Still seeing errors in automation? Troubleshooting.
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
Can I schedule gsc-indexer with cron?
Yes. A cron line that runs the binary against a batch file or sitemap, with sa.json available to the job, works fine. Use -json for parseable output and rely on the exit code so the job can alert when a real failure occurs rather than a mere NOT INDEXED.
How do I run it in GitHub Actions?
Store sa.json as an encrypted secret, write it to a file in a step, then call the binary with -creds and -json. Make the step fail on a non-zero exit so the workflow flags genuine network or API errors. The guides link to the source for a copy-paste workflow.
Why use -json in automation?
Because -json emits a single valid JSON array at the end and suppresses the progress text, so your downstream script can parse results reliably. Human-readable progress is useful interactively but gets in the way of machine consumption in a pipeline.
What should I do with the credentials in CI?
Never hardcode the key. Load it from a secret store, write it to a temp file the job deletes, and keep it out of logs. Rotate it if the secret ever leaks. The service account only needs Full property access; nothing broader is required.
How do I know the automation actually failed vs just found unindexed pages?
Check the exit code. URLs merely NOT INDEXED are not failures and return success. Only network, HTTP, or parse errors produce a non-zero exit, so a red build means something genuinely broke, not that Google had not indexed a page yet.