Discovered - currently not indexed means Google never fetched it
Summary
Pages sitting in Google's "Discovered - currently not indexed" status have never been fetched, so nothing about their content has been judged and rewriting them changes nothing.
Date every affected URL first and set aside anything younger than a few weeks, the window Google says a new page can take to be crawled.
A thread on r/TechSEO builds a triage order for “Discovered - currently not indexed” on one line from Google’s Page indexing report help page: the page was found but not crawled yet, typically because fetching it was expected to overload the site. The order is to date every affected URL, read template groups instead of individual URLs, then separate a server problem from a demand problem.
The status carries no last crawl date, and that absence decides everything that follows. Google has not seen the page’s content, so there is no quality judgement to appeal and no copy to fix. The same fact rules out noindex as a cleanup tool on these URLs, because a robots meta tag is read at crawl time and these pages have not been crawled.
The poster sells a paid pack of Claude skills and discloses it in the thread; every step below is manual work in Search Console.
Most “Discovered” rows on a young site are not a finding at all. Google’s help page says it can take a week or so before a new page or site starts being crawled, and up to a few weeks after a URL becomes known before Google crawls some or all of a site. Anything inside that window gets set aside before the real triage starts. Google also says a site with fewer than 500 pages probably does not need the Page indexing report, and that checking key pages directly is enough.
Counting individual URLs tells you little anyway, since the export caps at 1,000 example rows and on a large site that list is a sample. The thread’s advice is to group by folder, language prefix, parameter and pagination, then compare each group against the size of the template behind it. Its own example makes the answer obvious once grouped:
| Template | Indexed |
|---|---|
| Articles | 40 of 45 |
| Tag pages | 10 of 310 |
That is a tag-page question, not a site question. A large share under the “Unsubmitted pages only” filter points the other way, at URLs Google found and nobody listed, such as sort parameters and old paths.
The cause then splits into a server problem and a demand problem. The server side shows up in the Crawl Stats report’s host status section, which covers robots.txt availability, DNS and connectivity. On the demand side, Google’s crawl budget guide lists perceived inventory, popularity and staleness, so publishing more pages on a young site raises what Google knows about without raising how popular any of it is. Page count is not a crawl-demand factor in that guide, and the thread says so: adding pages is not a fix.
One claim in the thread is marked as the poster’s own inference rather than anything Google states: uncrawled pages have not been judged, but when their crawled siblings are sitting in “Crawled - currently not indexed”, the uncrawled ones will probably keep waiting. That is also where the two statuses need different work, since the crawled-not-indexed state is rarely a crawl budget problem and needs a rendering check rather than a scheduling one.
The worked example is the poster’s own site, macplus.pro, about 260 pages across four languages, whose early pages went uncrawled. Checking it, the poster found the site answers 200 on /index.html, on /fr/index.html and on a trailing-slash variant of a clean URL. Canonicals point at the clean URLs, so the direct risk is small, but anything linking to those variants hands Google more inventory to crawl before it reaches the pages that matter. The fix given is a 308 redirect to the clean URL. An unindexed language version is also not automatically lost traffic, since Google can serve hreflang alternates it never indexed on their own.
What to do
Work the list in this order, and stop as soon as a step explains the groups you are looking at.
- Put a date against every affected URL and discard anything younger than Google’s week-to-a-few-weeks window. What is left is the actual finding.
- Group the export by folder, language prefix, parameter and pagination, and compare each group’s indexed share against its template size.
- Check Crawl Stats host status before concluding anything about demand. A robots.txt or DNS failure makes the rest of the analysis noise.
- Split sitemaps one per template, listing only canonical URLs that answer 200, with an honest lastmod. Google ignores priority and changefreq, and per-template sitemaps let the report’s sitemap filter show each template’s indexation separately.
- Add plain
<a href>links in body copy from pages Google already crawls. - Use “Request indexing” last. There is a quota, repeat requests do not speed anything up, and Google does not promise the URL gets crawled at all.