Google updated its Indexing API quota documentation on 16 October 2026. The change may sound relevant to any business waiting for a new page to appear in search, but the API still has a very narrow purpose.
Google says the Indexing API can only be used for pages containing a JobPosting or a livestream BroadcastEvent embedded in VideoObject structured data. An ordinary page about extensions, boiler repairs, rewiring, roof replacements or bathroom fitting does not become eligible because it is important to the business.
That distinction matters because “instant indexing” is often presented as a technical shortcut. For most builders and trades, the real job is less dramatic: publish a useful page, make it crawlable, link to it properly, include it in the sitemap and remove any technical contradiction that prevents indexing.
This guide explains what Google actually changed, when the Indexing API may be legitimate and how to diagnose a service page that is not being indexed without paying for the wrong solution.
What Google changed on 16 October 2026
Google’s Search documentation update log records an update to the Indexing API quota page “to reflect the current quota limits and process” and remove an outdated form. The current quota documentation lists these defaults for each project:
- 200 publish requests per day, including URL updates and deletions
- 180 read-only metadata requests per minute
- 380 requests per minute across all endpoints
Google also states that the API is free to use. Those figures describe how an eligible implementation is limited; they do not expand the types of page that may use it.
The same-day Indexing API quickstart still says the API can only be used for job-posting or livestream pages. It also warns that submissions are subject to spam detection and that attempts to exceed quotas through multiple accounts or other methods may result in access being revoked.
This is a documentation and quota-process update, not a confirmed ranking-system change. Google’s Search Status Dashboard shows no October core or spam update at the time of publication.
What the Indexing API actually does
For eligible pages, the API lets a verified site owner notify Google when a URL has been added, updated or removed. Google can then schedule that URL for a fresh crawl.
That final phrase is important. A notification is not a command to rank a page, and it does not turn weak or inaccessible content into a search result. Google still has to crawl the URL, process its content and decide whether it belongs in the index.
The narrow eligibility makes sense when you consider the approved page types. A vacancy may close quickly. A livestream may only be useful for a short period. Prompt notification helps Google keep these time-sensitive results current.
A builder’s extension service page is different. It may remain useful for years and should be part of a stable website structure. Google’s normal crawling and indexing routes are designed for that situation.
Why “instant indexing” is the wrong promise for most trade pages
Waiting for a page can be frustrating, especially after paying for new content or launching a redesigned website. A tool that promises immediate inclusion appears to solve the visible problem.
However, indexing delay is often a symptom rather than the fault itself. Typical causes include:
- the page has no crawlable internal link pointing to it
- the URL is missing from the XML sitemap
- a
noindexinstruction remains from staging - the canonical tag points to another page
- the server returns an error or inconsistent response
- several location pages repeat the same content
- the page adds little beyond an existing service page
- the page is new and Google has not crawled it yet
Submitting the same URL repeatedly does not repair any of these conditions. Google’s recrawl guidance says that crawling may take from a few days to a few weeks, a request does not guarantee inclusion and repeated requests will not make crawling faster.
A sensible technical SEO audit should therefore identify what Google can access and which signal is conflicting. “We submitted it again” is not a diagnosis.
Use the normal discovery route for service, location and project pages
Most trade websites do not need an indexing system built around an API. They need a dependable publishing process.
1. Give the page a clear customer purpose
Indexability is not the same as usefulness. Before checking technical settings, ask whether the page helps a customer make a distinct decision.
A dedicated rewiring page can explain occupied-home planning, inspection stages, disruption and the information needed for a quote. A separate page that merely rearranges the homepage’s electrician copy provides a much weaker reason to exist.
This is particularly important for town pages. Creating dozens of near-identical pages and trying to force them into the index does not solve the underlying quality problem. Use a defensible location-page plan based on real service differences, local evidence and customer needs.
If the page idea is sound but the copy is vague, improve the content around the decision before looking for faster submission methods.
2. Link to it from pages people and crawlers already use
Google discovers many URLs through links. A new page should sit within the website’s navigation and subject structure rather than exist only in a content-management screen.
For example, a bathroom installation page might receive links from:
- the main services page
- a renovation or home-improvement hub
- relevant project case studies
- an appropriate location page
- a guide discussing bathroom planning or quote preparation
The anchor text should explain the destination naturally. “See our bathroom installation service” is more useful than “click here”. A coherent service-page structure also helps customers move between the main offer, evidence and enquiry route.
Use ordinary HTML links that a browser can follow. Buttons driven only by scripts, search boxes and on-page filters are not substitutes for a stable link to an important URL.
3. Include the preferred URL in the XML sitemap
Google recommends a sitemap when many URLs need to be discovered, including after a launch or site move. The sitemap should contain the canonical, indexable URLs the business actually wants in search.
Do not treat it as a storage list for every URL the website has ever produced. Remove redirects, error pages, staging addresses, parameter variations and intentionally non-indexable pages. If the sitemap says one URL is preferred while the canonical tag identifies another, the implementation is giving mixed instructions.
After a website redesign or URL change, compare the new sitemap with the redirect map and internal links. They should all point towards the same final destinations.
4. Check what the URL actually returns
Open the page in a private browser window and test it without relying on an administrator login. Confirm that it:
- returns a successful HTTP response
- loads its main content on mobile and desktop
- does not contain a
noindexinstruction - declares the intended canonical URL
- is not blocked from crawling
- uses the final public hostname and protocol
- has working navigation and an enquiry path
A page can look correct while its source sends a different instruction. This is why the source and rendered output matter when a site changes tags with scripts. The JavaScript metadata audit explains how to check titles, robots rules and canonicals without assuming that the visible page tells the whole story.
5. Use Search Console for a small number of important URLs
For a newly published service or project page, inspect the exact URL in Google Search Console. The URL Inspection tool can show whether Google knows the page, which canonical it selected and whether indexing is allowed. If the live test is successful, an owner or full user can request indexing.
This is the appropriate manual route for a few important URLs. It still does not guarantee inclusion or an immediate result, but it provides more useful evidence than a third-party “submitted” badge.
When publishing many pages, use the sitemap and internal-link structure rather than requesting every URL one by one. A batch of pages that remains undiscovered usually indicates a template, navigation or sitemap problem.
6. Diagnose patterns instead of chasing a green tick
Record the page type, publication date, internal links, sitemap inclusion, inspection result and eventual impressions. Patterns make the next decision clearer.
If all project pages are “Discovered – currently not indexed”, review how much distinct project evidence they contain and where they are linked. Strong construction project case studies should document the brief, constraints, work and outcome rather than reuse a generic gallery caption.
If one whole service template is excluded, inspect the template’s robots and canonical output. If old and new URLs compete after a migration, inspect redirects and internal links. If pages are indexed but produce no impressions or enquiries, the next question concerns demand, relevance and the offer—not submission speed.
When could a trade business legitimately use the API?
A construction or home-improvement company may have one eligible section even though its ordinary marketing pages are not eligible.
The clearest example is a careers area publishing genuine vacancies with valid JobPosting structured data. The API may help notify Google when a vacancy opens, changes or closes. That does not make the API suitable for the company’s roofing, plumbing or renovation pages.
A business running qualifying livestream pages with BroadcastEvent inside VideoObject may also be eligible for those URLs. A recorded project video, testimonial or standard embedded video is not automatically a livestream event.
Eligibility should be checked against Google’s current documentation before implementation. Do not add job or event markup merely to gain access. Structured data must describe the visible page accurately.
Questions to ask an “instant indexing” supplier
If a developer, plugin or SEO provider proposes an indexing service, ask:
- Which official Google documentation makes our service pages eligible?
- Are you using the Indexing API, Search Console, a sitemap or a separate third-party system?
- What will you check if Google crawls the URL but does not index it?
- Will we retain ownership of the Search Console and cloud project accounts?
- Are you creating extra accounts to work around a quota?
- How will you prove that a page was indexed rather than merely submitted?
Vague answers such as “our private method works for every URL” should prompt caution. Submission activity is easy to manufacture; a transparent diagnosis is more valuable.
The right supplier should also be willing to say when indexing is not the commercial problem. A page that already appears in search may need a clearer offer, better proof or stronger local SEO foundations instead.
A practical publishing checklist
Use this sequence for the next important service, location or project page:
- confirm that the page serves a distinct customer decision
- publish the final URL with a successful response
- check the title, visible heading, robots rule and canonical
- add contextual links from at least two relevant existing pages
- include the canonical URL in the XML sitemap
- test the page and enquiry route on a real phone
- inspect the URL in Search Console
- request indexing once if the page is important and the live test passes
- monitor discovery, indexing, impressions and qualified enquiries separately
- investigate the cause before resubmitting or rewriting
This process is slower than an “instant” promise because it deals with the website Google and customers actually encounter. It is also more likely to expose the problem that needs fixing.
Final thoughts
Google’s October quota update does not turn the Indexing API into a shortcut for builders and trades. It remains a specialist notification tool for eligible job-posting and livestream pages.
For normal commercial content, focus on the durable route: publish something worth finding, connect it to the site, keep technical signals consistent, submit a clean sitemap and use Search Console to inspect important URLs. If a page still does not appear, diagnose why instead of trying to submit it more aggressively.
Frequently Asked Questions
Can the Google Indexing API be used for a builder’s service pages?
No, not under Google’s current guidance. The API is limited to pages with JobPosting or a livestream BroadcastEvent embedded in VideoObject. Normal building, plumbing, electrical, roofing and renovation service pages are not listed as eligible.
Does requesting indexing guarantee that a page will appear on Google?
No. Google says a crawl request does not guarantee immediate inclusion or inclusion at all. The page must still be accessible, indexable and useful enough for Google’s systems to process and select.
How long does Google take to index a new service page?
There is no fixed deadline. Google says crawling can take from a few days to a few weeks. A new page with clear internal links, sitemap inclusion and consistent technical signals is easier to discover, but timing is not guaranteed.
Should I keep requesting indexing in Search Console?
No. Google says repeated crawl requests for the same URL do not make it faster. Request once after confirming the live page works, then investigate technical or content problems if the URL remains excluded.
Is an XML sitemap enough to make a page rank?
No. A sitemap helps Google discover preferred URLs; it does not guarantee indexing or rankings. The page still needs a clear purpose, useful content, crawlable internal links and consistent canonical and robots signals.
