If you want Google to discover changes on a static site, the reliable foundation is still a sitemap and good crawlable pages. I added a small notification workflow around that foundation, but the key caveat is easy to miss: Google’s Indexing API is officially for pages with JobPosting or livestream BroadcastEvent structured data. It is not a general-purpose indexing endpoint for ordinary pages.
For my site, the public pages include the about page and the main site. I wanted a repeatable way to signal updates after publishing, without treating an API response as proof that a URL had been indexed.
What the Google API response means
The Indexing API exposes urlNotifications:publish. I sent URL update notifications for the pages I changed and received HTTP 200 responses. That confirmed Google accepted the notifications. It did not confirm that Google crawled the pages, selected them for indexing, or would show them in search.
That distinction matters. A successful request is a delivery result, not an indexing guarantee. For a normal static page, using this API is outside Google’s documented scope, so I treat the response as an experiment rather than a supported indexing workflow.
The API also has quota limits. Those limits are not the same thing as a promise that a certain number of pages will be indexed per day.
The “8/day” button is a different mechanism
The manual “Request indexing” action in Google Search Console is often described as an eight-URL-per-day button. It is a limited manual submission path in the URL Inspection tool, not an API endpoint and not a daily indexing allowance. Google can change limits, and the interface does not promise indexing after a request.
I use that action sparingly for a few important URLs when investigating a specific crawl or indexing issue. It is not practical as a publishing pipeline, and it does not replace checking whether the page is accessible, canonicalized correctly, and linked from the site.
Resubmitting the sitemap
For routine static-site updates, I also resubmit the sitemap through the Google Search Console webmasters API. This is a lightweight notification that the sitemap may have changed; it does not force a crawl of every listed URL.
The sitemap remains the durable inventory of canonical URLs. I keep it generated from the site build, verify that it contains only intended public pages, and submit its location after deployment. If a page is missing from the sitemap or blocked from crawling, an API notification cannot fix that underlying problem.
A practical publishing sequence is:
- Build and deploy the changed pages.
- Confirm the deployed URLs return the expected content and status.
- Regenerate and validate the sitemap.
- Notify Google about the sitemap update.
- Optionally send URL notifications where appropriate, while remembering the Indexing API’s documented scope.
- Check Search Console later for crawl and indexing status.
Running it with launchd
I wired the workflow into a macOS launchd job so it can run on a schedule without keeping a terminal session open. The job invokes a script that reads its credentials from protected local configuration, submits the sitemap notification, and logs the response and timestamp.
The useful engineering detail is making the job observable and safe to rerun. I log HTTP status codes and errors, avoid printing credentials, and make repeated submissions harmless. A scheduled job should report what it sent and whether Google accepted the request; it should not report “indexed” unless that status was actually verified separately.
What I’d keep
For a static site, I’d prioritize a valid sitemap, internal links, stable canonical URLs, and pages that Googlebot can fetch. The Search Console URL Inspection request is useful for occasional manual checks. Sitemap resubmission is a reasonable automated nudge. The Indexing API can return 200s, but its official job-posting and livestream scope means ordinary-page use should be described honestly.
Automation can reduce repetitive work. It cannot turn a notification into a ranking or indexing guarantee.