Google's own documentation tells job sites to use the Indexing API rather than sitemaps, because it "prompts Googlebot to crawl your page sooner."
Operators applying for that access report waiting six to nine months. No approval, no rejection, no acknowledgement of any kind.
Matt Southern collected the reports for Search Engine Journal this week. SEO consultants Nick LeRoy and Alexander Chukovski say they have visibility across more than 100 job boards and hypothesise that Google has not approved any submissions in 2026, while acknowledging they cannot fully confirm it.
The documentation is blunt about the mechanics. There is a default quota of 200 for onboarding and testing, and anything beyond that "requires additional approval for usage and resource provisioning." It gives no timeline for a decision.
A recommendation is not a commitment
The interesting part is not the queue. Queues happen, and Google runs at a scale where any manual review process will drown.
The interesting part is that the recommended method and the available method have quietly stopped being the same thing, and the documentation still says otherwise.
John Mueller offered an explanation back in May, saying the API is "inundated by bloggers trying to act like legitimate sites, so I imagine they're just a bit more cautious nowadays."
That is a reasonable operational answer. It is also an admission that legitimate businesses are being screened by a process designed to filter abuse, with no mechanism to tell them which side of the line they landed on.
For a job board, freshness is the product. A listing indexed four days late in a market where roles fill in a week is not a degraded result, it is a worthless one.
The category of risk nobody budgets for
Most companies I work with have a reasonable handle on two kinds of platform risk. Price risk, where the cost of access goes up. Policy risk, where the rules change and something you do becomes forbidden.
There is a third kind that rarely appears on any register. Permission risk: your operating model depends on a gate that someone else controls, with no service level, no appeal, and no obligation to respond at all.
Silence is the worst version, because it is unfalsifiable. You cannot escalate a non-answer, you cannot fix a rejection you never received, and you cannot tell your board whether the plan is broken or merely slow.
I have written before about the reminders that you rent your AI rather than own it. The same lease applies to distribution, and it always did. We just got comfortable.
The job board case is vivid because the dependency is explicit. Most dependencies are not. They are a feed integration, a review platform API, a shopping catalogue approval, a business profile that got suspended by an automated classifier at 3am.
How to price a dependency you cannot control
The practical exercise takes an hour and is worth doing with your leadership team rather than your technical one.
List every external permission your revenue passes through. Not every integration, only the ones where a third party can say no or say nothing. For most businesses the list runs to between five and fifteen items.
Against each, write three things: what happens the day it stops working, how long the fallback takes to stand up, and whether you would find out immediately or three weeks later.
That third column is the one that produces silence in the room. A surprising number of critical dependencies have no monitoring at all, because they have never failed, so nobody built an alert for them.
Then build the fallback for the top two, even if it is worse than the primary path. Sitemaps are slower than the Indexing API, and a slower method you actually have beats a faster method you are waiting on.
The word I would avoid in that meeting is contingency, because it makes the work sound optional. The accurate framing is that you are buying the right to keep operating on a day you did not choose.
How to notice a door closing quietly
The job board operators found out by talking to each other. That is not a monitoring strategy, it is luck with a network attached.
Three cheap habits close most of that gap.
Run a canary. Pick one measurable outcome that only works if the dependency works, and check it on a schedule. For an indexing path, that is time from publish to first appearance in results, tracked weekly on a handful of URLs.
Date your assumptions. Any process that depends on an external approval gets a note recording when it was last confirmed working and by whom. A dependency nobody has verified in eleven months is not working, it is unexamined.
Keep one peer conversation alive per critical platform. Not a networking activity, an early warning system. In this case, a hundred job boards collectively knew something that no single one of them could prove.
None of this prevents the gate from closing. It changes the discovery lag from months to days, and the lag is where the real damage accumulates.
What this signals more broadly
Zoom out and this fits a pattern that has been building all year. Access to the fast lane on major platforms is narrowing, and it is narrowing quietly through process rather than loudly through policy.
No announcement was made. No rule changed. A queue simply stopped moving, and the people affected found out by comparing notes with each other.
That is how most of these shifts will arrive from now on. Not as a documented change you can plan against, but as a gradual increase in the number of doors that are technically open and practically shut.
I looked at the same instinct when Google asked advertisers to test the black box before trusting it. Same principle, different door.
The documentation says to knock. Nobody said anyone has to answer.