When a new URL is missing from Google, the two tools people reach for are the Request indexing button inside URL Inspection and the Google Indexing API. Both can ask Google to look at a URL again. They are not substitutes. One is a manual control on any URL you have verified, with a small allowance. The other is a programmatic notification channel for two kinds of short-lived pages. Using the API because it sounds faster, on pages it does not cover, does not create a second, bulk version of the button.
Neither one indexes the URL by itself. Google's Indexing API quickstart says a notification lets Google schedule a fresh crawl. The URL Inspection live test says a page can be fetched. Google's status-code documentation says a successful response still does not guarantee indexing. Speed, in this article, means "how you ask for a crawl", not "how you force a ranking".
What the manual button is for
URL Inspection shows Google's indexed view of one URL on a property you verified: index status, discovery, crawl permission, index permission, and the two canonicals. From that screen you can run a live test and, after it, request indexing.
The request puts the URL on a priority crawl queue. It works for any page type on the verified property. Google does not publish a fixed daily number for the button. The limit is small enough that it fits a handful of important URLs, not a migration of tens of thousands. A repeated request on the same URL does not stack.
Use the button when a person has already looked at the live test and the page is worth a crawl soon: a correction on a story that is already important, a new canonical after you fixed a duplicate, or a page that was blocked by a staging noindex and is now clean. Do not use it as the last step of every CMS publish. Ordinary discovery is the sitemap and the links. The button is the exception. How to read the screen is the URL Inspection guide.
What the Indexing API is for
The Indexing API notifies Google that a page was updated or removed. The quickstart limits that page to one of two kinds: a page with JobPosting structured data, or a page with a BroadcastEvent embedded in a VideoObject. Jobs and livestreams change quickly, expire, and go stale in results if the crawl waits. The API exists so those URLs can be pushed one by one.
You can send URL_UPDATED or URL_DELETED, read the last notification Google stored for a URL, and batch up to 100 calls in a single HTTP request. The default quota is 200, for onboarding and for testing submissions. More quota is a request to Google, not a setting in your project. Attempts to exceed quota with extra accounts can get the access revoked. The calls are authenticated with a Cloud service account that is an owner of the Search Console property.
The quickstart is also clear that, for a site made of those short-lived URLs, the API can prompt a crawl sooner than a sitemap update alone. You should still submit a sitemap for the whole site. The API is not the discovery method for the article archive, the category pages, or the static guides.
If you do not publish jobs or livestreams, you do not have a faster Google button hiding in Cloud Console. You have an API you are not supposed to point at the blog. The IndexNow comparison separates this API from the protocol that notifies other engines about ordinary URLs.
Which one is faster, for which page
For an eligible job or livestream URL, the Indexing API is the tool Google built for a prompt crawl, and it is the one that can run from a publish hook without a person at the keyboard. Send URL_UPDATED when the posting goes live or the broadcast page changes, and URL_DELETED when the page is removed so Google can drop it and stop fetching it. Check the notification metadata if you need to know what Google last accepted. Then confirm the URL in Search Console. A successful API response is not the Pages report.
For an ordinary article, the manual request can put one important URL on a priority queue after a person has checked the live test. It is faster than waiting only when Google honors the request with a crawl soon, and it is unavailable in bulk. The durable way to get articles crawled without a queue of manual clicks is still an accurate sitemap lastmod and a link from a page Google already fetches. Those two are the sitemap guide and the internal linking guide.
| Request indexing | Indexing API | |
|---|---|---|
| Page types | Any URL on a verified property | Job postings and livestream video pages |
| How it runs | A person, in Search Console | Authenticated HTTP, including batches of up to 100 |
| Volume | A small per-property allowance Google does not publish as a fixed number | 200 by default, more only with approval |
| What you learn | The full indexed view and a live test | Notification status, not a rendered screenshot |
| What it guarantees | A crawl request, not an index entry | A notification Google may use to schedule a crawl |
A sequence that does not mix them
- Publish the canonical URL. It should return
200, allow crawling, allow indexing, and match the sitemap and the internal links. - If the page is a job or a livestream, send the Indexing API notification from the same publish step, and keep the sitemap entry anyway.
- If the page is an article, rely on the sitemap and the section link. Inspect it when it matters. Request indexing once if the live test is clean and the URL is one you would notice tomorrow.
- If the URL stays out of the index after a successful crawl, stop sending notifications. Read the reason. Duplicates, soft 404s, and thin pages do not become eligible because the API returned
200. The indexing diagnostic is that branch.
Inspect before you notify when the template is new. A job page that is noindex, or that canonicals to the home page, will accept a notification and still fail to appear as the URL you wanted. The live test is the cheap check. The API is not a debugger. Inspection is.
Ways the API feels faster and is not
Sending every new article through the API because the quota is 200 and you publish 20 stories a day. You will exhaust the default allowance on pages outside the documented types, and you will have nothing left if you later add real job pages. Approval for more quota is for the use the API describes.
Counting a batch of 100 as 100 guaranteed crawls. The batch reduces HTTP overhead. Each URL is still a notification, still subject to spam checks, and still limited to the page types.
Treating URL_DELETED as optional. A filled job or a finished livestream that stays fetchable will be crawled again as a normal URL. Tell Google it was removed when you remove it, and return a real 404 or 410 on the URL itself so ordinary crawling agrees. Status codes are not replaced by the API.
Comparing the API's speed to IndexNow's speed and concluding Google is the slow one. IndexNow does not submit to Google. A fast IndexNow 200 and a quiet Google index can both be true. Measure Google in Search Console.
Using the manual button on hundreds of parameter URLs after a release. You will hit the allowance on copies that should have been canonicalised or blocked. Fix the template, then request the preferred URL. The canonical guide is the template work.
What to measure afterward
For API URLs, record the notification time and the next time URL Inspection shows a new crawl. If eligible pages are notified and never crawled, the structured data may not match the page type, the service account may not own the property, or the URL may be blocked. For manual requests, record the same crawl time and stop if a second request is your only idea.
For articles, measure something else: the share of new URLs that are indexed a week after publication, split by section. If one section lags, inspect two URLs and then fix links, canonicals, or the articles. A week of manual requests on that section hides the lag without explaining it. The Page indexing report will show the shared reason if you filter to the section's sitemap.
Request indexing is a checked, manual crawl ask for any page, used rarely. The Indexing API is an automated crawl ask for jobs and livestreams, used whenever those pages change. Articles get sitemaps and links. If a vendor promises that one of these tools will index the whole site by tonight, they are describing a queue Google did not offer.
CrawlFaster sends eligible Indexing API notifications and keeps the status of those URLs in one place. The manual button stays a human step for the occasional article you have already inspected, which is a different job and should stay one.
