Request indexing in Search Console: the limits and when it works

Request indexing sits in Search Console's URL Inspection tool: inspect a URL, then click Request indexing, and Google runs a quick live check before adding the page to its crawl queue. It has a daily quota per property that Google does not publish, asking again for the same URL does not move it forward, and "Indexing request rejected" means the live check found something stopping indexing, such as a noindex, a robots.txt block, or a page that returns an error.

Used on the right pages, once, it is the most direct way to ask Google to look at one page. Used as a routine, it burns quota and changes nothing.

Where is Request indexing and how do you use it?

It is a button on the URL Inspection result for a single URL. You need to be an owner or full user of the property; Google says so in its recrawl guide. The button triggers a quick live test, and if the page "passes a quick check to test for immediate indexing errors, it will be submitted to the indexing queue."

1. Open the property in Search Console and paste the full URL into the inspection bar at the top.
2. Read the result. If you changed the page since Google last crawled it, click Test live URL to see the current version.
3. Click Request indexing. Search Console runs its quick check against the live page.
4. If it passes, the URL is submitted to the indexing queue. If it fails, the result shows why.
5. Come back later and inspect the URL again. Google's help says "you can check the progress using this tool."

The live test and the indexed result answer different questions. The indexed result shows what Google stored at its last crawl; the live test fetches the page now. Only the indexed result shows the canonical Google chose and the sitemaps and referring page Google knows about.

What is the daily quota?

Google confirms there is one and does not publish the number. The URL Inspection help says "there is a daily limit to how many index requests you can submit," separate from "a daily limit of inspection requests for each property" and "a per-property daily limit of live inspections." When you hit a limit, the only fix is to wait for the daily allowance to come back.

The Indexing API row is there for contrast only. Google supports that API just for pages with JobPosting or BroadcastEvent markup, so it is not a way around the Request indexing quota for ordinary pages; the Indexing API guide explains why.

Because the quota is limited and its size unpublished, spend it on the few URLs that matter most: a new homepage, a key landing page, a page you just fixed.

Does requesting indexing again make it faster?

No. Google's recrawl guide says "requesting a recrawl multiple times for the same URL won't get it crawled any faster." The first request puts the URL in the queue; later requests for the same unchanged page add nothing except another deduction from your quota.

The same guide sets expectations for the first request too: "Requesting a crawl does not guarantee that inclusion in search results will happen instantly or even at all. Our systems prioritize the fast inclusion of high quality, useful content." The URL Inspection help says "indexing typically takes only a day or so, but can take much longer in some cases," and elsewhere gives "up to a week or two." For the broader timeline, see how long Google takes to index a page.

If a request went through, the page stayed out of the index, and nothing blocks it, requesting again is the wrong lever. The status in URL Inspection tells you which one to pull instead.

Why was the indexing request rejected?

Because the live check found the page non-indexable. Google's help: "You cannot request indexing if the page is considered to be non-indexable in the live test." That is what an "Indexing request rejected" message means, and the Page indexing section of the live result names the reason. Fix it, re-run the live test, then request again.

Two cases look like rejections but are not. A URL that redirects is tested at its target, because the live test "follows any redirects implemented by the page, then tests the page" without saying so; request indexing for the final URL instead. And a URL outside the property you are in cannot be inspected there at all, so check you are in the right property, including www versus non-www for URL-prefix properties.

If the live test passes and you still cannot submit, the usual reason is the quota. Wait a day and try again. The URL is not on Google guide walks through each status URL Inspection can report.

When is Request indexing worth using?

When one specific page changed in a way you need Google to see soon. It suits a handful of URLs at a time, not a site. Google's help points to the alternative directly: "If you want many pages indexed, try submitting a sitemap to Google."

Worth a request:

1. A new page that matters commercially, such as a launch page or a new pricing page.
2. A page you substantially rewrote, where the old version is what Google shows.
3. A page you just unblocked: removed a noindex, fixed a robots.txt rule, fixed a 5xx.
4. Your homepage on a brand-new site, so Google has a starting point for discovery.

Not worth a request:

1. Dozens or hundreds of URLs, which the quota cannot cover.
2. A page sitting in Crawled - currently not indexed with no changes; Google read it and declined, and its help says "no need to resubmit this URL for crawling."
3. Pages you have not linked to from anywhere on your site.
4. Minor edits such as a typo fix or a footer change.

What should you use for many URLs?

A sitemap with accurate <lastmod> dates, plus internal links. The URL Inspection help says "to request indexing of many new or updated pages, your best choice is to submit a sitemap, with the updated pages marked by <lastmod>." Google's sitemap documentation says it uses lastmod when it is "consistently and verifiably" accurate, so the date is what tells Google which of your known URLs changed.

1. Make sure every page you want indexed is in the sitemap, with its canonical URL.
2. Set <lastmod> from each page's real last significant edit, not the build time.
3. Keep the sitemap submitted in the Sitemaps report and referenced in robots.txt.
4. Link new pages from pages Google already indexes, so discovery does not depend on the sitemap alone.
5. After a large batch of fixes to one issue, use Validate fix in the Page indexing report, which asks Google to recrawl every affected URL.

After any request, check the result in URL Inspection rather than with a site: search. Google's own documentation says the site: operator "doesn't necessarily return all the URLs that are indexed," so a page missing from site: results tells you little. For choosing a tool that checks whether pages can be indexed in the first place, see the indexability checker tools guide.

Check the page before you spend a request

Since a request is rejected when the live test finds a blocker, check for blockers first. Run the free scan on LaunchScaler: give it the URL, no account needed, and it runs 156 checks across 6 of its 7 categories at no cost. Its search checks cover the same blockers that get a request rejected: a noindex in the meta robots tag or the X-Robots-Tag header, a robots.txt rule blocking the page, a soft 404, redirect chains, a canonical pointing at another or broken URL, and main content that only appears after JavaScript runs. Fix what it flags, run Test live URL once, then use your request.