You open the Page Indexing report in Search Console expecting a clean bill of health, and instead two rows sit near the top: “Discovered – currently not indexed” and “Crawled – currently not indexed.” Between them they hold a few hundred URLs. The pages load fine in a browser. They are in your sitemap. Nothing looks broken. And yet Google has quietly decided that, for now, these pages do not belong in the index. That silence is the frustrating part, because Search Console hands you the status and almost never the reason.
The two statuses look like one problem and get treated as one problem. They are not. They sit on opposite sides of the crawl-to-index pipeline, and telling them apart is the entire diagnosis. Fix the wrong side and the URLs stay exactly where they were.
Two statuses, two different stages #
The wording is close, so the difference is easy to miss. It comes down to whether Google has actually fetched the page.
- Discovered – currently not indexed: Google has found the URL, usually from a sitemap or an internal link, but has not crawled it yet. The page was never fetched, so its content is not the question. Something upstream is holding the crawl back.
- Crawled – currently not indexed: Google fetched the page, looked at it, and then chose not to add it to the index. Here the page itself is part of the story.
A short mental model helps: Discovered is a crawl-side signal, Crawled is an index-side judgment. A change that rescues one status frequently does nothing for the other, which is why so much “fix your indexing” advice lands at random. Sort the URLs by status first, and the work stops being guesswork.
Why pages sit in “Discovered – currently not indexed” #
Google knows the URL exists and keeps postponing the crawl. A handful of patterns tend to explain it.
Crawl capacity. On large or slow sites, Googlebot deliberately limits how hard it fetches so it does not strain the server. Requests queue, and the lowest-priority URLs wait longest. A site that responds slowly under load teaches Googlebot to crawl it more cautiously, which pushes marginal pages further down the line. On a small site this is rarely the bottleneck; there the Discovered pages usually reflect low perceived priority rather than a strained crawl budget, which points the diagnosis toward the next two causes.
Perceived low priority. Google generally triages what to crawl by how valuable a URL looks from the outside before fetching it: how many internal links point to it, where it sits in the site structure, whether nearby pages have earned attention. A page buried ten clicks deep with a single internal link reads as low priority, and low priority means “later,” sometimes indefinitely.
A sitemap entry with nothing behind it. A URL that appears only in the XML sitemap, with no internal links carrying weight to it, gives Google a location but no reason to hurry. Sitemaps suggest; internal links vouch.
A recent publish or a sudden batch. When a large set of new URLs goes live at once, some can sit as Discovered for a while as the queue works through them. This cause often resolves on its own once crawl attention catches up, so it is worth ruling out before you assume something is wrong.
The reliable tell for this whole category: server logs show no Googlebot fetch of the URL at all. If Google never touched the page, the content cannot be why it is missing.
Why pages sit in “Crawled – currently not indexed” #
Here Google did the work of fetching the page and then declined to index it. This is a judgment about whether the page earns a place, and the usual causes cluster together.
Thin or templated content. Pages that repeat a pattern with little unique substance tend to get crawled and skipped: near-empty category pages, auto-generated tag archives, location pages that swap a city name into the same boilerplate. Google fetched them, saw little worth storing, and moved on.
Duplication and near-duplication. If a page substantially overlaps another URL on the site, Google may fold it into that other version rather than index both, even when no canonical tag tells it to. Two pages competing to answer the same query often leave one crawled and quietly set aside.
Weak differentiation from what already ranks. A page that repeats what a dozen indexed pages already say, in the same shape, gives Google no reason to add a new URL for it. Indexing is not automatic; a fetched page still has to justify the slot.
Section-level quality. Indexing is partly a site-level and section-level judgment. A folder full of thin, similar pages can lower how Google treats a genuinely useful page sitting inside it, so a good page sometimes gets skipped for the company it keeps.
The tell here is the mirror image of the first category: logs show Googlebot fetched the URL, sometimes more than once, and the page still never entered the index.
A diagnosis path before you change anything #
The temptation is to start editing pages and requesting indexing. Resist it until you have separated the two problems, because the fixes do not transfer. Work through a few questions for a representative URL.
| Question | What the answer points to |
|---|---|
| Have server logs recorded any Googlebot fetch of this URL? | No fetch means a crawl-side (Discovered) problem. A recorded fetch means an index-side (Crawled) problem. |
| Is the page reachable through internal links, or only through the sitemap? | Sitemap-only, deep, or orphaned points to a crawl-priority problem. |
| Does the page duplicate or closely resemble another URL? | Heavy overlap points to a duplication or value problem on the index side. |
| Does the page add anything the pages already ranking do not? | Nothing new points to a differentiation problem. |
| Is the whole section thin, or is this one weak page inside a strong section? | Section-wide thinness points to a site-level quality problem, not a single-page fix. |
Run the URL Inspection tool on one affected page to confirm the last crawl date and the canonical Google actually chose. When the reported canonical points to a different URL, Google is telling you plainly that it sees the page as a duplicate, which settles the diagnosis before you touch the content.
What actually moves pages into the index #
The fixes follow the split. Crawl-side problems and index-side problems need different work, and applying the wrong one is how weeks get wasted.
For pages stuck in Discovered, the goal is to raise crawl priority. Adding internal links from pages that already get crawled often is generally the most reliable lever, because it signals that the URL matters within the site. Flattening deep paths so important pages sit fewer clicks from the home page helps for the same reason. So does keeping the sitemap honest: pull out URLs you do not want indexed at all, so crawl attention concentrates on the ones you do.
For pages stuck in Crawled, the goal is to give the page a reason to exist. That means adding real substance the ranking pages lack, whether a framework, a worked example, a data point, or a genuinely different angle. It often means consolidating near-duplicates: merging overlapping pages into one stronger URL and redirecting the rest beats asking Google to index several thin versions. And it sometimes means the opposite of rescue, pruning or applying noindex to pages that will never carry unique value so they stop dragging on the section around them.
Requesting indexing through URL Inspection can nudge a single page up the queue, and it is a fair way to confirm a fix. It does not repair the underlying reason, though, and it does not scale to hundreds of URLs. Treat it as a check on your diagnosis, not the diagnosis itself.
When these statuses are not a problem #
Not every unindexed page is a failure waiting to be fixed. Faceted and filtered URL variants, thin tag archives, deep paginated pages, and internal search result pages are often better left out of the index. Finding them under “Crawled – currently not indexed” can mean Google is doing exactly what a careful site owner would want.
The useful question is not “is everything indexed” but “is everything I need indexed actually indexed.” A site that forces every URL into the index tends to end up with index bloat, which carries its own ranking drag and spreads crawl attention thinner across pages that matter. Before you spend a week rescuing a batch of URLs, confirm they were pages you wanted found in the first place. Sometimes the report is showing you a decision Google got right.
Frequently asked questions #
How long can a page stay “Discovered – currently not indexed”? There is no fixed window. Some pages resolve within days once crawl priority rises, while others sit for weeks or longer when nothing on the site changes to raise their standing.
Does requesting indexing guarantee the page gets indexed? No. Requesting indexing moves the URL up the crawl queue, but Google still applies the same value judgment when it fetches the page. A thin or duplicate page requested a dozen times stays out.
Will more backlinks fix “Crawled – currently not indexed”? Links can raise crawl priority and overall authority, but when a page was skipped for thin or duplicate content, links alone rarely change the outcome. The content problem comes first, and the link is wasted until it is solved.
The Page Indexing report names the symptom and hides the cause, which is why these two statuses get misread so often. Sort them by side first, crawl or index, confirm the split with server logs and the URL Inspection tool, then fix the matching problem. And leave room for the answer that some of those URLs were never meant to be indexed at all.