IndexaWhy isn't Google indexing my pages?
Google indexes a page only after three separate things happen: it discovers the URL, it decides to spend a crawl on it, and it judges the fetched page worth storing. When pages do not get indexed, exactly one of those three stages failed — and the fix is completely different for each. Search Console’s Page indexing report tells you which stage you are stuck at, and that is the only sensible place to start.
Last updated 2026-07-28
How do I find out why a specific page is not indexed?
Use the URL Inspection tool in Google Search Console on the exact URL. It reports the page’s current state in Google’s systems — whether the URL is known, when it was last crawled, which canonical Google selected, and the reason it is excluded. The aggregate version of the same data is the Page indexing report, grouped by reason.
The reason string it gives you is the whole diagnosis. These are the ones that account for most real cases, and they are not interchangeable:
| Status in Search Console | What actually happened | Where the problem is |
|---|---|---|
| Discovered — currently not indexed | Google knows the URL exists but has not fetched it | Crawl scheduling / predicted value |
| Crawled — currently not indexed | Google fetched the page and chose not to index it | Page quality, duplication |
| Duplicate, Google chose different canonical | Indexed, but under another URL | Canonicalisation, near-identical pages |
| Excluded by ‘noindex’ tag | You told Google not to index it | A meta robots tag or X-Robots-Tag header |
| Blocked by robots.txt | Google may index the URL but cannot fetch it | robots.txt rules |
| Soft 404 | Page returned 200 but looks empty or like an error | Thin or empty template output |
| Page with redirect / Not found (404) | The URL is not a servable page | Your sitemap is listing URLs it should not |
What does "Discovered — currently not indexed" actually mean?
It means Google has the URL on its list — almost always from your sitemap or an internal link — but has repeatedly decided not to spend a crawl on it yet. Google is predicting, before fetching, that the page is unlikely to be worth the request. That prediction is based mostly on the rest of your site, not on the page itself, because Google has not seen the page itself.
This is the status that confuses people most, because nothing is technically broken. The sitemap is valid, the URL returns 200, robots.txt allows it, there is no noindex. Google simply is not interested enough to look.
Three things drive that prediction:
- Predicted page value, extrapolated from siblings. Google generalises. If the pages it has crawled on your domain turned out to be thin or templated, it discounts the ones it has not crawled that look structurally similar — same URL pattern, same section, same sitemap.
- Crawl demand. Google crawls in proportion to how much it thinks a site matters and how often it genuinely changes. A new or low-authority domain gets very little crawl demand, regardless of how many URLs you submit.
- Crawl capacity. If your server is slow or returns 5xx under load, Googlebot backs off deliberately to avoid hurting the site. This one is measurable: check the Crawl stats report for average response time and any spike in server errors.
That example is the single most useful thing to internalise about this status: “Discovered — currently not indexed” at scale is a content verdict wearing a technical costume. A handful of URLs in this state on a healthy site is normal churn. Most of your sitemap sitting in it is Google telling you the pages are interchangeable.
How is "Crawled — currently not indexed" different, and is it worse?
It is a stronger signal, and usually a more useful one. Google spent a crawl, fetched the page, evaluated it, and decided not to index it. You are no longer guessing what Google thinks of your content — it has told you.
The common causes, roughly in order of how often they turn out to be the real one:
- The page duplicates something else, on your site or elsewhere. Programmatic pages built from the same template with a swapped variable are the classic case.
- The page is thin relative to intent — it exists to target a query rather than to answer it.
- Google picked a different canonical, so the content is indexed, just not at this URL. Check the “Google-selected canonical” line in URL Inspection before doing anything else.
- The content is rendered only by JavaScript and the render was deferred or failed. Use the “View crawled page” HTML in URL Inspection — if your body copy is not in it, that is the problem.
- The page is new and the domain has little history. Sometimes this status resolves on its own within a few weeks with no changes at all.
Unlike “Discovered”, this status responds to editing. Make the page materially better or merge it into a stronger page, then request a re-crawl — that combination genuinely works, and it works because you changed the input, not because you pressed submit.
Which technical problems actually block indexing?
A short list of hard blockers accounts for nearly every case where a page cannot be indexed no matter what you do. Work through them before touching content, because they are cheap to check and absolute in effect.
- 1A
noindexdirective. Check both the<meta name="robots">tag and theX-Robots-TagHTTP response header. The header is the one people forget, because it is invisible in the page source. - 2A robots.txt
Disallow. This blocks crawling, not indexing — which produces the worst outcome of all: a URL that can appear in results with no description, and anoindexon the page that Google can never read. - 3A canonical pointing somewhere else. A site-wide canonical tag hardcoded to the homepage is a genuinely common template bug.
- 4Non-200 status codes. Verify what Googlebot receives, not what your browser receives — geo-routing, bot protection and CDN rules can differ.
- 5An authentication or consent wall. If content sits behind a login, a paywall interstitial or a blocking cookie banner, Googlebot sees the wall.
- 6The URL is not in any sitemap and nothing links to it. Orphan pages are the one case where discovery really is the bottleneck.
Will submitting URLs fix "Discovered — currently not indexed"?
Usually not, and it is important to be straight about that. Submission solves discovery. If Search Console already says “Discovered”, discovery has already succeeded — Google has the URL and is choosing not to crawl it. Re-submitting the same unchanged URL is asking the same question again and expecting a different answer.
Where submission genuinely does move things:
- Genuinely new URLs. Cutting the gap between publishing and Google knowing the URL exists from days to minutes is real, and it is entirely within your control.
- Pages you actually changed. After you have rewritten a thin page or fixed a technical blocker, a submission is how you tell Google to look again rather than waiting for its own schedule.
- Engines that are not Google. Bing, Yandex, Seznam, Naver and Yep accept push notifications through IndexNow, with far more generous volumes and no ownership dance beyond hosting one text file.
- Large or frequently-changing sites, where the sheer lag of waiting for a sitemap re-read is the binding constraint.
And where it does not: no submission channel — not the Indexing API, not IndexNow, not Search Console’s Request Indexing button — obligates any engine to index anything. Google says so explicitly about its own tools. Any product that promises guaranteed indexing is either misunderstanding the mechanism or misrepresenting it.
What actually gets these pages indexed?
Change Google’s prediction rather than repeating the request. In practice that means making fewer, better pages; linking them from pages Google already crawls often; and giving the domain a reason to be crawled more.
- 1Consolidate. Ten interchangeable pages that each answer a fragment of a question routinely lose to one page that answers it completely. Merging is the highest-leverage move available and the least popular one.
- 2Add something that only you have. Original data, a real worked example, screenshots, numbers from your own logs. This is what separates a page from its template.
- 3Link them properly. Internal links from pages Google crawls frequently are the strongest discovery and priority signal you control. A page reachable only from a sitemap is a page you have implicitly declared unimportant.
- 4Prune the dead weight. Removing or noindexing genuinely worthless pages raises the average quality Google extrapolates from — this is the direct lever on the “Discovered” prediction.
- 5Fix crawl capacity. If Crawl stats shows slow responses or 5xx spikes, that is a real ceiling and no amount of submitting will lift it.
- 6Then re-submit, so the re-crawl happens on your schedule rather than Google’s.
Order matters. Steps one to five change the answer; step six changes the timing. Doing step six alone is the mistake that keeps whole categories of indexing tools in business.
How long should I wait before assuming something is wrong?
For an established site, a genuinely new page that is internally linked and in your sitemap is typically crawled within days. On a new domain with no external links, several weeks with little indexing is normal and not evidence of a fault.
Google does not publish a service-level target for indexing, and any specific figure you see quoted is someone’s observation rather than a commitment. Useful checkpoints:
- Nothing at all indexed after 30 days on a new site: check for a hard blocker first (see above), then whether the site has a single external link pointing at it.
- Homepage indexed, deeper pages not: normal early on. Strengthen internal linking; do not add more pages.
- Was indexed, now dropped: a different problem — look for canonical changes, redirects, or a quality-driven de-indexing after a core update.
- Most of the sitemap in “Discovered”: treat it as a content verdict and read the section above again.
The one thing worth automating in all of this is the part you actually control: making sure every engine learns about every new and changed URL the day it happens, so the only remaining variable is whether the page deserves indexing. That is what Indexa does — it reads your sitemaps daily and submits what changed, from your own machine. It cannot make Google index a thin page, and it does not claim to.
Frequently asked questions
Does resubmitting the same URL repeatedly help?
No. Repeated submission of an unchanged URL does not increase the chance of indexing, and the Search Console Request Indexing quota exists partly to discourage it. Change the page, then submit once.
Can a sitemap be "submitted successfully" while pages stay unindexed?
Yes, and this is the most common misreading of Search Console. A green sitemap status means Google fetched and parsed the file. It says nothing about whether the URLs inside it will be crawled or indexed.
Is crawl budget the reason my small site is not indexed?
Almost certainly not. Google has said crawl budget is not a limiting factor for the vast majority of sites, particularly those under a few thousand URLs. On small sites the constraint is nearly always predicted page value, not crawl capacity.
Does the Google Indexing API fix "Discovered — currently not indexed"?
No, and it is officially restricted to JobPosting and BroadcastEvent pages besides. It notifies Google about a URL; it does not change Google’s assessment of the page. See what the Indexing API actually covers.
Stop hand-submitting URLs
Indexa reads your sitemaps every day and submits what changed — to Google’s Indexing API with your own Google Cloud project, and to Bing, Yandex, Seznam, Naver and Yep over IndexNow. It runs on your own computer; your credentials never leave it.
Submitting a URL is not a guarantee that it will be indexed — that decision always rests with each search engine. What a submission tool controls is the notification half: making sure every engine knows about every page the day it is published or changed.