Last updated
Why My Pages Are Not Indexed
A page stays unindexed when the crawler never allocates enough budget to reach it, or reaches it and the content does not clear Google's quality threshold. Discovered and Crawled are two different not-indexed states, and each points to a different fix.
A stuck page is different from a stuck domain
Not every unindexed page means your whole site has a problem. A domain can index most of its pages just fine while a specific product, article, or category page sits stuck in a queue or gets rejected on its own. That is a narrower situation than a domain where nothing indexes at all, which is a directive or hosting fault covered separately when Google refuses to index your entire site.
This page isolates what happens at the level of one URL: crawl budget allocation, the Discovered and Crawled not-indexed statuses, and the quality threshold that decides whether a crawled page actually earns a spot. Everything downstream depends on clearing this layer first, which is why indexing sits as an early checkpoint on the broader SEO failure umbrella before ranking or traffic questions matter at all.
Six reasons a specific page never enters the index
Six patterns explain most page-level indexing failures. Some act at the crawl stage, before Google ever fully evaluates the page, and some act at the quality stage, after a clean fetch already happened. Work through all six, since a single stalled page often has more than one of these stacked at once.
Crawl budget spends itself on parameter clutter before reaching the money page
Every domain gets a finite number of crawl visits in a given window, and Google decides how to spend that budget based on server response speed and perceived value across the URL set. Faceted navigation, sort parameters, session identifiers, and endless pagination can each generate URLs that look distinct to a crawler even though a human never treats them as separate pages. When that clutter outnumbers the pages you actually want indexed, the crawler spends its visits on combinations nobody will ever land on.
This shows up as a widening gap between how many URLs your site technically has and how many Google is willing to fetch in a normal cycle. The fix is not asking for more budget, since Google allocates it based on what it observes, not what you request. It is removing or consolidating the low-value variants so the ratio of worthwhile URLs to total URLs improves, which naturally redirects visits toward the pages that matter.
What this looks like: Server logs show Googlebot hitting hundreds of filtered, sorted, or paginated URL variants while the actual product or article page waits days between visits.
'Discovered - currently not indexed' means low crawl demand, not a block
This status means Google is aware the URL exists, usually because it appeared in your sitemap or an internal link, but has not yet decided the page is worth a crawl visit. It is a scheduling and demand problem, not a permission problem. Confusing the two wastes time chasing directive fixes on a page that was never blocked in the first place.
Crawl demand strengthens when a URL receives contextual internal links from pages Google visits often, when the server responds quickly and consistently, and when similar pages on the domain have a track record of being worth indexing. A brand-new page sitting only in an XML sitemap, with no links pointing to it from anywhere a person would actually browse, tells the crawler it can wait.
What this looks like: URL Inspection lists the page as Discovered, the Last crawl field stays empty for weeks, and nothing in robots.txt or the page's meta tags refuses entry.
'Crawled - currently not indexed' means the page failed a quality bar
Google fetched this page, parsed it, and then made a deliberate choice not to add it to the index. That decision usually comes down to how the page compares to what already exists, either elsewhere on your own site or across the wider web on the same topic. A technically clean page can still fail this bar if it adds little beyond a template and a few paragraphs of boilerplate.
Because access is not the issue here, robots.txt fixes, sitemap resubmissions, and canonical tweaks do nothing for this specific status. The page needs a real reason to exist that a near-duplicate does not already cover, whether that is original data, a distinct angle, or depth the competing pages skip. Treat this status as a content-quality verdict, not a technical error to patch.
What this looks like: Live Test in URL Inspection returns a clean 200 status and a render that matches the live page, yet the status still reads Crawled - currently not indexed.
Thin internal links leave a page with no crawl priority signal
Internal links do more than help visitors navigate. They tell a crawler which pages the rest of the site treats as important enough to reference, and they give the crawler an additional path to find and revisit a URL beyond the sitemap alone. A page that only exists in the sitemap and a distant archive page reads as low priority by default, regardless of how good the content actually is.
This failure is common on large catalogs, deep blog archives, and sites that publish faster than they update older content with fresh links. The sitemap alone rarely offsets it, because a sitemap tells Google a URL exists without telling it how much the rest of the site values that URL. Adding a handful of contextual links from pages Google already crawls often is usually enough to change the signal.
What this looks like: The URL only appears in the XML sitemap and a paginated archive several pages deep, with zero contextual links from any page a visitor would actually browse.
Near-duplicate pages get crawled then folded into someone else's canonical
When a page overlaps heavily with another URL, whether that is a printer-friendly version, a tag archive, a syndicated copy, or simply a page that covers the same narrow topic as an older post, Google can decide the set is really one page wearing different URLs. It then picks one representative URL to index and treats the rest as duplicates, even when you never set an explicit canonical tag pointing away.
This is different from a sitewide canonical bug, where every URL on the domain collapses toward one destination. Here the collapse is scoped to a specific cluster of similar pages, and the fix is differentiation rather than a template repair. Add distinct information, a different angle, or original data to the page you want indexed, or consolidate the cluster into one stronger URL instead of maintaining several weak ones.
What this looks like: Search Console's Duplicate, Google chose different canonical label points your own URL at a near-identical page instead of indexing it separately.
New pages publish faster than the site's crawl budget can absorb them
Publish velocity and crawl budget are two separate numbers, and when the first consistently outruns the second, new pages queue up faster than the crawler can process them. Each new URL competes for the same finite pool of visits as every existing page on the domain, so a large batch release can leave most of that batch sitting in a Discovered state for longer than a single new page would.
This is common right after a migration, a bulk import, or a content push meant to cover a topic quickly. Spacing out publication, prioritizing internal links to the newest URLs first, and confirming the server can handle a burst of crawl activity without slowing down all reduce the backlog. A steady publishing pace the domain’s measured crawl budget can actually absorb prevents the queue from building up again.
What this looks like: A weekly batch of new URLs ships every Monday, but crawl stats show the bot completing only a handful of fresh fetches before that week's budget resets.
How a page actually moves from crawl to a live result
Indexing is not a single yes-or-no gate a page passes once. A URL moves through a budget decision, then a quality decision, and only after both clear does ranking even become a question worth asking. Each stage can end the story on its own, long before content quality is ever the real issue.
Crawl-budget triage for stalled URLs sits with the rest of the crawl stack inside the AI SEO Agent, because indexing eligibility and citation eligibility both get evaluated against the same set of pages.
From crawl budget to a live SERP result
- 01Crawl budget decides whether the crawler visits and parses the page at all
- 02The fetched page enters the index only once it clears the quality threshold
- 03Ranking systems score the newly indexed page for relevance and authority
- 04Query-time systems select which SERP feature the page is eligible to fill
- 05The page either surfaces for a matching query or loses the slot to a stronger page already indexed
| Coverage status | What it actually means | Where the failure sits | What confirms it |
|---|---|---|---|
| Discovered - currently not indexed | Google found the URL but has not spent a crawl on it yet | Crawl budget and demand | URL Inspection shows no recorded last-crawl date |
| Crawled - currently not indexed | Google fetched the page and chose not to add it to the index | Quality threshold | Live Test returns 200 but the index request stays pending |
| Duplicate, Google chose different canonical | The URL was crawled but folded into another page's index entry | Near-duplicate content | Inspection names a different URL as the chosen canonical |
| Alternate page with proper canonical tag | The page correctly points to another URL and is not meant to index on its own | Intentional consolidation | Your own canonical tag names the other URL |
| Excluded by 'noindex' tag | A directive removed the page from consideration entirely | Explicit exclusion, not budget | The tag or header appears on a live fetch of the URL |
Signs the block sits in budget or quality, not a directive
Each sign below is something you can confirm directly in Search Console or a live fetch, not a guess about what might be happening behind the scenes.
SIGNS CHECKLIST
0 / 8 checked
How to fix page-level indexing, in the right order
Work through crawl budget first, then confirm the quality bar, then protect new pages from the same backlog. Skipping straight to a content rewrite before checking access wastes effort on a page nobody ever tried to fetch.
Redirect crawl budget toward pages that earn it
Audit server logs for where crawl budget actually goes
Result: You see the exact split between money-page fetches and low-value URL fetches over a real week of traffic.
- Pull at least seven days of raw server logs, not a sampled analytics view
- Filter requests down to verified Googlebot user agents only
- Bucket the crawled paths into money pages versus parameter, filter, and archive variants
- Note how many total fetches each bucket receives across the window
#!/usr/bin/env bash
LOG="access.log"
echo "Googlebot fetches by top-level path, last 7 days:"
grep "Googlebot" "$LOG" |
cut -d'"' -f2 |
cut -d' ' -f2 |
cut -d'?' -f1 |
cut -d'/' -f1-3 |
sort | uniq -c | sort -rn | head -20
Cut or consolidate the URL patterns draining the budget
Result: Parameter, filter, and pagination variants stop competing with money pages for the same limited crawl slots.
- Add a scoped robots.txt rule for the specific parameter patterns found in the log audit
- Set a self-referencing canonical on filtered and sorted views so they consolidate instead of multiplying
- Cap pagination depth or noindex the deepest archive pages that get zero real traffic
- Re-check the log split two to three weeks after the change ships
# Crawl-budget triage only. This touches faceted and
# parameter clutter, not the whole site or the money paths.
User-agent: *
Disallow: /*?sort=
Disallow: /*?filter=
Disallow: /*&page=
Allow: /blog/
Allow: /products/
Confirm the fetch clears the quality bar, not just the crawl
Run a live URL Inspection test on every stalled URL
Result: You know whether Google is fetching the page at all, or fetching it and rejecting what it finds once it arrives.
- Open URL Inspection and request a Live Test on each affected URL
- Compare the rendered HTML to what a real visitor sees in a browser
- Record whether the status reads Discovered or Crawled, since each points to a different fix
- Log the test date so you can measure change after the next round of fixes
Rebuild thin or near-duplicate pages so they clear the quality bar
Result: Pages that were crawled and rejected now carry a real reason to exist that a near-duplicate does not already cover.
- List every URL sharing the topic or template with the stalled page
- Add information, data, or an angle none of the similar pages already provide
- Merge pages that cannot be meaningfully differentiated into one stronger URL
- Set canonical tags deliberately once the cluster is consolidated, rather than leaving them to default
Keep new pages from stalling behind budget limits
Notify search engines directly after each publish batch
Result: Newly published URLs get a nudge toward a crawl visit instead of waiting purely on sitemap discovery.
- Ping the sitemap endpoint after every batch of new or updated URLs
- Submit priority URLs through IndexNow if your CMS or host supports it
- Add internal links to new pages from high-traffic existing pages within the same publish cycle
- Watch Crawl Stats in Search Console for a change in request volume over the following days
#!/usr/bin/env bash
SITEMAP="https://www.example.com/sitemap.xml"
curl -s "https://www.google.com/ping?sitemap=$SITEMAP" -o /dev/null -w "Sitemap ping: %{http_code}"
curl -s -X POST "https://api.indexnow.org/indexnow" -H "Content-Type: application/json" -d '{"host":"www.example.com","key":"YOUR-INDEXNOW-KEY","urlList":["https://www.example.com/new-page/"]}'
Match publish velocity to the crawl budget the domain has actually earned
Result: New batches stop outrunning the crawler, so a smaller share of each release sits stuck in a Discovered state.
- Compare average weekly Googlebot requests from Crawl Stats to the number of new URLs published weekly
- Space out large batch releases so the newest pages are not competing with each other for budget
- Prioritize which URLs in a batch get internal links first if the whole set cannot launch with equal support
- Revisit the pace quarterly as crawl budget shifts with site authority and technical health
What an AI visibility score assumes about indexing
VISIBILITY INSIGHT
An indexing gap shows up as a visibility gap before anyone notices
An AI visibility score weighs mention frequency, citation share, factual accuracy, entity strength, and competitive share of voice across engines like ChatGPT, Perplexity, and Gemini. Most sites score low on the indexing dimension specifically because a page stuck in a not-indexed state cannot accumulate any of those signals, no matter how strong its content reads to a human. SearchDock checks whether your key URLs are actually indexed alongside their mention and citation performance across engines, so a crawl or quality gap surfaces as the root cause instead of getting misread as a content problem. It also tracks competitor share of voice on the same queries, showing whether an indexed competitor page is winning a slot your unindexed page could otherwise contest.
Score this URL's AEO readinessAn indexing fix is measurable well before any AI engine reflects it, so track Search Console status alongside AI mention data from the AI Visibility Checker rather than waiting on one signal alone.
Related indexing and SEO diagnostics
These sit alongside this diagnostic in the same cluster, plus the bridge and learning resources referenced above.
Fix the layer that is actually blocking the page
Page-level indexing failures come down to three questions: does the crawler visit the page, does the page clear the quality bar once it does, and does the site’s crawl budget keep up with what gets published. Answer those in order instead of guessing at content rewrites first. Once a page clears all three, whether it actually ranks for a query is a separate diagnostic, covered when content clears the index but still does not rank. Indexing is the floor everything else stands on, not the finish line.
See which of your pages SearchDock flags as stuck before Google doesFrequently asked questions
Why does Search Console say my page is Discovered but not indexed?
That status means Google found the URL, usually through your sitemap or an internal link, but has not yet spent a crawl visit on it. Low crawl demand, not a block, causes the delay. Strengthening internal links to the page and confirming the server responds quickly both help the URL earn a visit sooner.
What does Crawled - currently not indexed actually mean?
It means Googlebot fetched the page successfully but decided not to add it to the index. The block is a quality-threshold decision, not an access problem, so the page usually looks thin, duplicate, or low-value compared to similar URLs already indexed. Rebuilding the page to clear that bar is the fix, not resubmitting the sitemap again.
How do I know if crawl budget is the reason my pages are not indexed?
Check server logs for how often Googlebot actually visits the stalled URL compared to how often it visits your highest-priority pages. A wide gap, combined with a Discovered but never crawled status in Search Console, points to budget rather than a quality rejection. Pages that get crawled and still stay out point to quality instead.
Can duplicate content stop one page from getting indexed on its own?
Yes. When a page overlaps heavily with another URL on your site or a competitor's, Google can crawl it and then fold it into a different page's index entry instead of indexing it separately. Search Console labels this Duplicate, Google chose different canonical, and the fix is differentiation, not resubmission.
Does resubmitting the sitemap fix pages stuck at not indexed?
Rarely by itself. Resubmitting a sitemap only re-announces a URL Google likely already knows about, so it does not change crawl demand or fix a quality rejection. It can help after you have added real internal links or rebuilt thin content, as a way to nudge a fresh crawl once the underlying problem is solved.
How long does it take for a stuck page to move to indexed?
There is no fixed timeline, and Google does not guarantee indexing ever happens. Pages that clear a genuine crawl-budget or quality problem often get revisited within a few weeks, but domains with limited crawl budget can take longer. Track the specific URL in Search Console weekly instead of judging progress from one check.
Does an unindexed page also hurt my visibility in AI answers?
It usually does, because most AI engines lean on a page being findable through conventional search infrastructure before they treat it as a citable source. A page stuck outside Google's index rarely earns a mention or citation in ChatGPT, Perplexity, or similar tools until the underlying crawl or quality problem is fixed.