Why Google isn't indexing your pages, and what to fix before you request indexing

Search Console keeps them in its Page indexing report, under Indexing, then Pages: a table headed Why pages aren't indexed, with a row for each reason and the number of pages it covers. For one address, paste it into the search bar at the top of Search Console, and URL Inspection gives that page's reason.

The groups are what matter. On its own, a request only asks Google to fetch the page again, so it helps only where Google hasn't read the page. A page that is blocked, broken or turned down will be blocked, broken or turned down again until something changes; once it has, one request gets the change seen sooner.

Two more reasons can turn up for pages Google did index. “Indexed, though blocked by robots.txt”: Google found the address in links and indexed it without reading it. “Page indexed without content”: Google couldn't read what was on it. When every page under a reason is fixed, Validate fix asks Google to check them all; it takes about two weeks, and Google rechecks the pages either way.

Our own site shows what the two look like. On 19 October 2026 we read every page in passcite.com's sitemap with URL Inspection:

Nothing was blocked, broken or a duplicate. Of the 230 pages Google didn't have, it hadn't read 225, and 193 of those were our agency directory, most of it two days old. Google had found most of it through the sitemap and not fetched it yet. A few things move a page up the queue:

• Links from pages Google already has. Links are how Google finds most pages, and a page linked from your home page or a section page is one Google meets every time it reads them.
• A sitemap that lists the address you want indexed, and only addresses you want indexed: not ones that redirect, or that say noindex.
• A request, for the few that matter most. You get only a few a day, so they go to the pages worth them.

Then time. Google says crawling can take from a few days to a few weeks.

This is the reason that stings, because Google has read the page and passed on it. It is not a penalty: those are manual actions, reported on a page of their own. Google may still take the page later, but asking again while the page is unchanged is unlikely to move it.

On our site, the five pages here were the only ones Google had read and turned down, and all five were built from templates: one page for each industry or platform, its own data inside a frame the others shared. A template alone didn't decide it. Of our 13 platform pages, Google kept six, left out two and hadn't read the other five.

What we could measure was how much of each page was its own. We split every page into sentences, masked the name and numbers that made it that page, and counted the words in sentences no sibling had. On the two platform pages Google left out, Wix and BigCommerce, that was 32% of the page, about 330 words. We rebuilt all 13 around what is particular to each platform (its robots.txt as it ships, what we read on real sites built with it, where each setting lives), which took those two to over 700 words of their own, 57% and 59% of the page.

What helps a page Google read and left out:

• Something no other page has: your own numbers, the specifics of this place or product, and an answer to the question its title asks, in its first lines.
• One page for one question. Near-copies, like the same service page for twenty towns, are better merged, or pointed at one canonical, than pushed into Google one by one.
• Links from the pages Google keeps.
• Then one request, after the change.

Search Console caps how many pages you can ask for in a day, and does not publish the number. On our own site it took 11 requests in about 16 hours and refused the twelfth. So a request is something to spend: on a page Google hasn't read that matters, like a new page you want AI answers to pick up, and on a page you have just fixed. The sitemap is how Google hears about the rest.

Google's Indexing API is no way round the cap: it is only for pages with job postings or livestreams, and Google can withdraw access when it is used for anything else.

Passcite's Google index checker plans the day's requests for you: up to ten pages Google hasn't read, the ones that matter first (articles you have just published, then what your sitemap ranks highest), each with a button that opens the page's inspection in Search Console, where you click Request indexing.

Google's documentation on its AI features is plain about it: to be shown as a supporting link in AI Overviews or AI Mode, a page has to be indexed and eligible to appear in Search with a snippet. There is no separate door. A page Google hasn't indexed cannot be cited in its AI answers however well it answers the question, and noindex or nosnippet keeps it out as surely.

That puts indexing first for anyone writing pages to be cited: the comparison, the pricing page, the answer to the question a client's buyers ask. Until Google has indexed the page, it cannot move Google's AI answers, so there is nothing yet to measure. When Passcite's Proof asks the questions a page was written for again, a week after it goes live, it also notes whether Google had the page that day.

URL Inspection answers for one address at a time. The report gives counts, with lists of up to 1,000 example addresses, which Google says may not show every page under a reason. For a site of a few hundred pages, or a client list's worth of sites, that is an afternoon of pasting. The same answers come through Search Console's URL Inspection API, 2,000 addresses a day for each site.

Passcite's index checker reads your sitemap that way: up to 500 pages, and the articles you publish from Passcite, each at most once a day, when you open it. Each page shows Google's reason in plain words, the pages are grouped by section of the site, the ones Google hasn't read go into the day's requests, and each kind of problem becomes one task that says what to change. It is free on every plan, and it reads Search Console without changing anything in it.