How to Request Indexing in Google Search Console (and When It Helps)

To request indexing in Google Search Console, open URL Inspection, paste the full URL, wait for the result, and click Request indexing. Google runs a quick live check and, if the page is indexable, adds it to its indexing queue. That is the whole procedure. What the button can and cannot do is the part worth reading.

How do you request indexing in Google Search Console?

Four steps, one URL at a time. The URL must belong to the property you have open, and inspection and index requests both have a daily limit per property. ^{[1]Google Search Console Help. URL Inspection Tool}

1. Open URL Inspection

In Search Console, pick the property that contains the page. Paste the full URL into the search bar at the top, or open URL Inspection in the left menu and paste it there. Protocol and subdomain matter: https://www.example.com/page and https://example.com/page are different URLs, and only the one inside the property can be inspected.

2. Read the indexed result first

The tool first shows what Google has in its index for that URL, not the live page. The verdict is one of "URL is on Google", "URL is on Google, but has issues" or "URL is not on Google". Below it you see when the page was last crawled, whether robots.txt or a noindex directive blocked it, the user-declared canonical and the Google-selected canonical. ^{[1]Google Search Console Help. URL Inspection Tool}

If the verdict is "URL is not on Google", the Availability section names the reason. "URL is unknown to Google" means Google has never seen the URL, and this is the case where Google's help page itself tells you to request indexing. ^{[1]Google Search Console Help. URL Inspection Tool}

3. Fix blocks before you click

Requesting indexing is not available when the live test finds the page non-indexable. A robots.txt block or a noindex tag has to be removed first; Google will not index the page until it is. ^{[1]Google Search Console Help. URL Inspection Tool} If you changed the page just now, click Test live URL to confirm the fix is visible to Googlebot before you spend a request.

4. Click Request indexing

Click Request indexing. Google runs a quick check and, if the page passes, queues it for indexing. Submitting a request does not guarantee that the page will appear in the index. ^{[1]Google Search Console Help. URL Inspection Tool}

The thing people get wrong: "URL is on Google" means the page is eligible to appear in results. It does not mean the page ranks, and the help page says it does not even guarantee the page will appear. ^{[1]Google Search Console Help. URL Inspection Tool} Whether it shows up for a query is a question for the Performance report, not for URL Inspection.

How long does Google take to index a page after a request?

Google does not commit to one number. Its own pages give three ranges, and all three are worth knowing before you refresh the tool every hour:

Two more sentences from the recrawl page settle the usual follow-up questions. Requesting a recrawl multiple times for the same URL will not get it crawled any faster, and requesting a crawl does not guarantee that inclusion in search results will happen instantly or even at all. ^{[2]Google Search Central. Ask Google to recrawl your URLs} So: one request per changed URL, then wait, then inspect again.

How do you ask Google to recrawl many pages?

URL Inspection handles one URL per request and the requests are rationed. For a redesign, a batch of updated articles or a new section, Google's answer is a sitemap. Its help page puts it plainly: for many URLs, your best choice is to submit a sitemap with the updated pages marked by lastmod. ^{[1]Google Search Console Help. URL Inspection Tool}

Submit or resubmit the sitemap

Post the sitemap file on your site, then enter its URL in the Sitemaps report. You cannot upload a sitemap to Google; the report only tells Google where to fetch it. Google fetches a newly submitted sitemap right away and keeps recrawling it on a schedule that is independent of the site's crawl schedule. ^{[4]Google Search Console Help. Sitemaps report} Submitting a sitemap is a hint. It does not guarantee that Google downloads the file or uses it for crawling. ^{[3]Google Search Central. Build and submit a sitemap}

Resubmit after big changes to the file. For minor updates, Google's advice is to let it follow its regular crawling schedule. ^{[4]Google Search Console Help. Sitemaps report}

Make lastmod mean something

Google uses the lastmod value when it is consistently and verifiably accurate, for example by comparing it with the last modification of the page. The value should reflect the last significant update to the main content, structured data or links; bumping a copyright year does not count. Google ignores priority and changefreq. ^{[3]Google Search Central. Build and submit a sitemap} A sitemap whose every URL carries today's date tells Google nothing, so a CMS that rewrites lastmod on each build costs you the one signal that makes resubmission useful.

Keep each file under 50 MB uncompressed and 50,000 URLs; split larger sets and list the parts in a sitemap index. ^{[3]Google Search Central. Build and submit a sitemap}

Give the pages internal links

A sitemap gets URLs discovered. Internal links from pages Google already crawls often are what gets them crawled soon and understood in context. If an updated page sits three clicks from anything, link to it from a hub or a related post before you wait on the sitemap. How to pick those donor pages is covered in internal linking for underperforming pages.

The Indexing API is not a shortcut

Google's Indexing API can only be used to crawl pages with JobPosting or BroadcastEvent structured data. ^{[7]Google Search Central. Indexing API quickstart} For an ordinary article, product or category page it is not an option, whatever a plugin promises.

Why request indexing does not fix "Crawled - currently not indexed"

The Page indexing report defines the status as "The page was crawled by Google but not indexed." Google's recommended action is not a request. If the page is important, use URL Inspection and other tools to diagnose possible site issues. ^{[5]Google Search Console Help. Page indexing report}

The logic is in the status name. Google already fetched the page and decided not to keep it. Requesting indexing asks for another fetch, which gives Google the same page to evaluate again. Unless something changed, the outcome usually does not either. Google's own help page lists the conditions that a live test cannot check and the page still has to meet: it must not be a duplicate and it must have enough quality. ^{[1]Google Search Console Help. URL Inspection Tool}

So before you click, change what Google will see:

• Near-duplicate of another URL you own. Two posts that answer the same question compete for the same queries, and Google may treat one as a duplicate of the other. Inspect the URL and compare the user-declared canonical with the Google-selected canonical; if Google already points at the other page, the fix is a merge or a canonical, not a request. The options are compared in how to fix keyword cannibalization. Keylogs' keyword cannibalization checker reads your Search Console data and lists the pairs of your own pages that compete on the same queries, with a merge, canonical, de-optimize or differentiate recommendation per pair.
• Thin page. A tag page with two items, a stub, a page whose text is mostly boilerplate. Add the content first, then request.
• No internal links. A page nothing links to has little evidence of mattering. Link it from relevant pages, then request.

"Discovered - currently not indexed" is different. Google defines it as "The page was found by Google, but not crawled yet." ^{[5]Google Search Console Help. Page indexing report} For one or two important URLs, a request can trigger the crawl that has not happened. For hundreds, the request quota runs out long before the queue does, and the answer is again internal links and a sitemap whose lastmod is honest.

After a merge or redirect: which URLs to inspect and request

Consolidating two competing pages is the case where practitioners most often reach for URL Inspection, and the case where it is most often used on the wrong URL. Google's rule for a site move applies to a single redirect too: Googlebot has to visit every old and new URL at least once before the move is complete. ^{[6]Google Search Central. Site moves with URL changes}

The surviving URL: request indexing

Inspect the page that kept the merged content. If the live test passes, request indexing once. The next indexed result should show a fresh last-crawl time and the surviving URL as the Google-selected canonical.

The retired URL: inspect it, and read the result carefully

Inspect the redirected URL too. You can request indexing on it as well, and the fix guide above suggests that for merges, but read the live result with one caveat from Google's help page: the live test follows redirects without reporting that it did, or which final URL it tested. ^{[1]Google Search Console Help. URL Inspection Tool} The indexed result is the one to watch. Once Google has recrawled the old URL, the Page indexing report lists it as "Page with redirect", defined as "This is a non-canonical URL that redirects to another page." ^{[5]Google Search Console Help. Page indexing report} That status is the goal, not a problem.

Google recommends URL Inspection for testing individual redirected URLs and scripts for large numbers of them. ^{[6]Google Search Central. Site moves with URL changes} If you keep a sitemap of old URLs during a move, Search Console may warn that it contains redirecting URLs; Google says this is normal and you can ignore the warnings. ^{[6]Google Search Central. Site moves with URL changes}

Leave the redirect in place

Keep the redirect for at least a year so Google can move all signals to the new URL, and point it straight at the final destination rather than through a chain. ^{[6]Google Search Central. Site moves with URL changes} Removing the redirect early reopens the duplicate you just closed.

A worked example

The table below is constructed to illustrate the pattern; the figures are not from a real property.

Two articles on one SEO blog, /blog/fix-cannibalization and /blog/cannibalization-fixes, both showed for the query "how to fix keyword cannibalization" over 28 days. Before the merge, the Performance report split them: 1,900 and 1,400 impressions, 41 and 22 clicks, average position 7.8 and 11.2. The owner merged the second into the first and set a 301 redirect.

Three details carry the lesson. The surviving page got the request; the retired page was inspected and left to the redirect. Nothing was clicked twice. And success was read in the Performance report, where the two rows became one and CTR could be compared against the pre-merge baseline, not in the green tick of the inspection tool. The decision between merging and redirecting, and what to do with the content of the losing page, is covered in merge or redirect competing pages.

What to do in Search Console now

1. Inspect the URL before you request anything. If it is "on Google", the problem is ranking, not indexing.
2. For "URL is unknown to Google" or a page you just fixed, request indexing once and note the date.
3. For "Crawled - currently not indexed", change the page or its duplicates first. Requests re-run the same evaluation.
4. For more than a handful of URLs, update lastmod honestly, resubmit the sitemap, and add internal links.
5. After a merge, request on the surviving URL, inspect the retired one until it shows "Page with redirect", and judge the result in the Performance report four weeks later.

If a traffic drop is what sent you to the inspection tool, indexing is one of fourteen checks in the Search Console traffic drop checklist, and rarely the first.