The fastest disambiguation comes from cross-referencing Search Console’s Page Indexing report status with actual crawl frequency in your server logs for the affected URLs. If pages are being crawled regularly (Googlebot is visiting them, sometimes repeatedly) but still show as “Crawled – currently not indexed,” that pattern points to a content-quality judgment: Google saw the page and chose not to index it. If pages are barely being crawled at all, infrequent visits or none in recent log windows, that points toward a crawl budget or prioritization issue: Google isn’t investing crawl resources in the page in the first place, so a quality judgment hasn’t even been reached yet. These are functionally different problems with different fixes, and conflating them is the most common diagnostic mistake with large programmatic sites.
Why these two failure modes look similar but aren’t
Programmatic pages generated from a template plus a data source (location pages, product variant pages, comparison pages, tag/category aggregations) are structurally vulnerable to both problems at once, which is exactly why they get confused.
The crawl budget exhaustion story: if a site publishes a very large number of URLs relative to what Google is willing to crawl for that host, some pages simply don’t get visited often, or at all, in a given window. This is a resourcing/prioritization issue on Google’s side, driven by factors like the site’s overall crawl demand (perceived value and change frequency) and crawl capacity limits. In this scenario, the pages themselves might be perfectly fine, they just haven’t been seen recently enough for Google to index or re-evaluate them.
The thin content story: if Googlebot does crawl a page and evaluates its content but judges it not worth adding to the index, that’s a quality decision independent of how much crawling happened. This is common with programmatic pages that share a heavy template shell (same header, same boilerplate, same layout) around a small amount of unique, per-URL substance, a pattern Google has consistently described as a risk factor for pages being excluded even when crawled without issue.
The reason these get confused is that both failure modes produce the same visible symptom: the page isn’t indexed. Without checking the specific exclusion reason and crawl frequency, “not indexed” alone tells you nothing about which mechanism is responsible.
Practical diagnostic steps
1. Start with the exact exclusion reason in the Page Indexing report. Search Console’s Page Indexing (formerly Coverage) report gives specific status labels, and the distinction between two of them is the whole diagnosis:
- “Crawled – currently not indexed” means Google fetched the page and made a decision not to index it right now. This is the status that should make you suspect a content-quality issue, since the crawl already happened; Google had the chance to evaluate the page and passed.
- “Discovered – currently not indexed” means Google knows the URL exists (found via sitemap, internal links, or otherwise) but hasn’t crawled it yet. This status leans toward a crawl prioritization/budget explanation, the page hasn’t even been fetched yet, so no quality judgment has been made.
Pull a sample of your affected programmatic URLs and check which of these two statuses applies. If it’s overwhelmingly “Crawled – currently not indexed,” treat thin content as the leading hypothesis. If it’s overwhelmingly “Discovered – currently not indexed,” treat crawl budget/prioritization as the leading hypothesis.
2. Cross-check against server/CDN log data for actual crawl frequency. Search Console’s own crawl stats report (and, if available, raw log analysis) tells you how often Googlebot is actually requesting these URLs. Pages that are crawled frequently, weekly or more, but never indexed strongly support the thin-content explanation, Google keeps checking in, which suggests interest or at least routine coverage, but repeatedly decides the content isn’t worth indexing. Pages that show few or zero recent Googlebot hits in the logs support the crawl budget explanation, there simply hasn’t been an evaluation.
3. Test the thin-content hypothesis directly by checking template-level uniqueness. For a sample of affected URLs, strip away the shared template elements (navigation, footer, boilerplate intro/outro copy, repeated schema) and look at what’s actually unique to that specific URL. If the unique content is minimal, a single data point swapped into an otherwise identical template, a short auto-generated sentence, a list with no original commentary, that’s a strong practical confirmation. There’s no published or reliable word-count threshold for “thin,” Google has never given one, and framing this in terms of a specific number would be fabricating a standard that doesn’t exist. The right frame is qualitative: does this page offer something a user (or Google) would consider distinctly valuable versus the next fifty pages built from the same template, independent of how long it is.
4. Look for a template-wide pattern rather than isolated cases. If the non-indexed pages cluster tightly around a specific template or content type (all pages from one generator, all below a certain data-completeness threshold, all missing a specific field that other indexed pages have), that clustering itself is evidence supporting the thin-content explanation, since crawl budget issues tend to be more evenly distributed by crawl-path depth or site architecture rather than by content template specifically.
5. Check internal linking depth and sitemap presence as a control. Since crawl budget problems are also strongly influenced by how easy a page is to discover (orphaned pages, pages buried deep in pagination, pages missing from the sitemap), rule this out separately. If affected pages are well-linked, present in an accurate sitemap, and still under-crawled, that strengthens the case for a genuine prioritization/demand issue rather than a discoverability failure that’s incorrectly being read as “crawl budget.”
6. Use a controlled comparison set. If you have a subset of programmatic pages that are indexed successfully and a subset that aren’t, compare them directly: crawl frequency, exclusion status, and unique-content density. Differences that track with content depth point to thin content; differences that track with site depth, internal link count, or publish recency point to crawl/discovery issues.
Once you’ve localized the cause, the fixes diverge substantially: crawl budget issues are addressed through improving internal linking, sitemap accuracy, site architecture, and server performance so Google can afford to crawl more of the site; thin content issues are addressed by consolidating near-duplicate template output, adding genuinely differentiating content per URL, or pruning/noindexing low-value pages that shouldn’t have been generated as standalone URLs in the first place. Applying the wrong fix (say, trying to solve a thin-content judgment by improving crawl budget) won’t move the needle, because Google was never short on opportunities to evaluate those pages, it evaluated them and decided against indexing.
Hypothetically, imagine a site with 20,000 programmatic city-level service pages, call it “Example Services,” where roughly 15,000 of those pages aren’t indexed. If a sample check of the Page Indexing report shows those 15,000 are overwhelmingly labeled “Crawled – currently not indexed,” and server logs confirm Googlebot has visited most of them multiple times in the past month, that pattern, in this hypothetical, would point squarely at thin content rather than crawl budget. Let’s say the team’s first instinct was to add more internal links and resubmit the sitemap, hoping to fix a “crawl budget problem.” In this hypothetical scenario, that effort wouldn’t move the needle, because Google had already been crawling and evaluating those pages all along; the fix that would actually matter is differentiating the templated content itself.
