Creator economy · Search
Why are creator pages ‘discovered but not indexed’?
We expected this bucket to be our biggest problem. Two samples on our own property said otherwise, and no creator page was in it at all.
Some links here are affiliate links — if you buy, the retailer may pay us a commission at no extra cost to you. We have earned $0 from them so far. Here’s how it works.
Part of: For creators
The biggest bucket of unindexed pages on our site is not “discovered and declined”. It is “never discovered at all”. Across two Search Console samples run on 3 September 2026 — 45 URLs spread across the sitemap and 40 spread across publish dates — 27 pages were unknown to Google and 18 were discovered but not indexed.
That inverts the usual advice, which treats the discovered bucket as the problem to solve and assumes a page Google knows about is a page Google has considered. It has not considered it. It has not read it.
What the label actually means
Google’s own wording for this state is that the URL was found but not crawled, often because crawling it was expected to overload the site or because it was scheduled and not yet reached. Two words in that do the work.
Not crawled. The page has never been fetched. There is no last-crawl date, and in our sample there was not one exception — every page in this state had no crawl date, and every indexed page had one.
Not judged. Nothing about the page’s content has been assessed, because the content has not been read. Reading the label as “Google saw it and thought it was thin” is the single most common mistake made about it, and it sends people to rewrite pages that were never opened.
What our own two samples showed
We ran two differently-designed samples on the same afternoon, which is worth doing because the design changes the answer.
| Sample | URLs | Indexed | Discovered, not indexed | Unknown to Google |
|---|---|---|---|---|
| A — spread evenly across the whole sitemap | 45 | 18 (40%) | 12 (27%) | 15 (33%) |
| B — spread across publish dates, creator/shopper balanced | 40 | 22 (55%) | 6 (15%) | 12 (30%) |
| Both together | 85 | 40 (47%) | 18 (21%) | 27 (32%) |
Sample A is the one to quote for the site as a whole, because it was drawn across the sitemap rather than weighted toward recent pages. Sample B is not a corpus estimate and we are saying so rather than quoting its friendlier 55%.
On either reading the ordering is the same, and it is the finding: more of our pages are unknown to Google than are discovered and waiting. A month ago the same site measured 20% indexed, 37% discovered and 43% unknown. Indexation has roughly doubled and the discovered bucket has shrunk.
One more result belongs here because it contradicts the row we set out to write. We expected creator-economy pages to be over-represented in the discovered bucket, since they are the newest part of the site. Not one creator page was in it. All 18 creator pages in sample B were either indexed or completely unknown. Whatever puts a page in the discovered bucket, on our site it is not being a creator page.
Keep reading
The causes we can and cannot tell apart
Honest ranking, with what we can support next to each.
| Cause | Can we tell? | What we can say |
|---|---|---|
| Crawl budget — the site is not worth much fetching yet | Partly | Consistent with a domain that has no earned links and a crawl history measured in the low hundreds of requests. |
| The page is genuinely thin or duplicated | No | Google has not read it, so this cannot be the reason it was skipped. It can still be a reason it fails later. |
| Discovered too recently to be reached | Partly | Some of the bucket is simply a queue, and it clears without anyone doing anything. |
| Internal linking too weak to signal importance | No, on our site | We measured zero orphan guides and a median of five inbound editorial links, so this is not our bottleneck. |
| Technical blocking — robots, noindex, canonical | Yes | Ruled out: no page in either sample reported a robots or indexing restriction. |
The two rows marked “No” are the ones worth dwelling on, because they are the two that most advice tells you to fix.
The advice that does not follow
- “Rewrite the page to improve quality.” It has not been read. This is the clearest case of effort aimed at the wrong stage.
- “Resubmit the sitemap.” The URL is already discovered. That is what the label means. Resubmitting announces something already known.
- “Publish more so the site looks active.” More URLs on a fixed crawl budget makes each one less likely to be fetched, not more. We have run this experiment on ourselves and would not recommend it.
- “Delete the page.” Possibly right for a genuinely thin page, but you are deleting on a verdict that was never issued.
What actually moves a page out of the bucket
- Link to it from a page that is already indexed. Those are the pages a crawler demonstrably visits. This is the only lever most creators hold outright, and it costs nothing.
- Give the crawler less to choose from. Fewer, better pages beats more pages when the constraint is fetch budget rather than quality.
- Earn a link from somewhere already crawled often. Slow, unglamorous, and the only thing that changes the budget itself. It has to be earned — bought and exchanged links are against Google’s policies and we do not use them.
- Wait, and re-measure rather than re-guess. Part of this bucket is a queue. Our own numbers moved from 20% to 40% indexed without any intervention aimed at it.
Frequently asked
What does ‘Discovered — currently not indexed’ mean?
Google knows the URL and has not fetched it. In our own 85-URL inspection on 3 September 2026, no page in this state carried a last-crawl date, and every indexed page did.
Is it a quality penalty?
It cannot be a judgement of the content, because the content has not been read. It is a fetching decision.
Is discovered-not-indexed the biggest bucket?
Not on our site. Across 85 inspected URLs, 27 were unknown to Google entirely and 18 were discovered but not indexed. The larger problem was discovery, not selection.
Will publishing more pages help?
On a fixed crawl budget it works against you. More candidate URLs means a smaller share of them gets fetched.
How do I check which state my pages are in?
The URL Inspection tool in Search Console, one URL at a time, free. The field that matters most is whether a last-crawl date exists at all.
Method and sample
- Sample A: 45 URLs drawn spread across our 360-URL sitemap, inspected 3 September 2026.
- Sample B: 40 guides drawn with a fixed seed, balanced across publish dates and between creator and shopper pages. Deliberately not a corpus estimate.
- Both used the Search Console URL Inspection API on our own verified property. Coverage states are Google’s.
- The earlier 20/37/43 figures are our own prior measurement on the same property, quoted for the trend and not re-verified in this run.
- Not measured: why any individual page was skipped. Search Console reports the state, never the reason.
- We have earned $0 in affiliate commission, and we publish our own indexation numbers whichever way they move.
Keep reading
Last verified 3 September 2026 against 85 URL Inspection results across two samples on our own Search Console property
How this guide was made. We research and draft these guides with AI, then a person checks every price, link and factual claim against the source before it publishes. We work this way because it lets us re-verify prices across hundreds of guides in a day, which is what keeps the numbers here current; it does not decide what we recommend. Anything we could not verify is labelled as unverified rather than filled in.