TrafficTriageGoogle Stopped Indexing My New Pages: What Actually Fixed It
By Ugur Saritepe · September 3, 2026
Between 27 July and 15 August I published 18 new list pages on my games site. On 16 August, 17 of them had zero impressions in Search Console and URL Inspection said "Discovered - currently not indexed". Submitting them, requesting indexing, and linking them from my homepage did nothing I could measure. What moved them was in-context links from pages Google already crawled every few days. Nine of the 18 are still not indexed today, and this post says so.
Publishing into a void
From 18 July I had an assistant building one curated list a day. The site's clicks were growing, so for three weeks I assumed the new pages were part of that. They were not. On 16 August I asked for the grade on the previous cycle and got this back, verbatim from the log it keeps:
17 of the 18 lists shipped since 7/27 have ZERO Google impressions (Discovered - currently not indexed, confirmed via URL Inspection on best-ninja-games / best-anime-games). Selection retune worked; the pipeline's output is now gated on indexing, not on niche choice.
All of the growth had come from older pages maturing. The daily engine, in the log's words, "is publishing into a void". Every one of the 18 was in the sitemap, and the hub page that lists every registered list linked to all of them. URL Inspection on two samples showed the tell: never crawled, and the only referring URL was the sitemap.
That is what Discovered - currently not indexed means in practice. Google knows the URL exists. It has decided not to spend a crawl on it yet. The general guide to that state covers the causes; this post is about the six weeks it took me to find out which one was mine.
Four fixes, in the order I tried them
Each row is a dated change from git, and what Search Console showed afterwards. Read the last column before the middle one.
date change effect on the stalled lists
18 Jul IndexNow submissions (Bing, Yandex) Bing indexed them; Google ignores IndexNow
4 Aug link 6 stalled lists from high-traffic pages 0 of 6 crawled by 28 Aug
12 Aug link 9 more orphan lists + 10 articles 2 of 9 moved
mid-Aug Request Indexing in the Search Console UI coverage state unchanged ("did not stick")
18 Aug cluster registry: every list gets 4 in-context first impressions on 7 of the 18,
links from sibling lists, by rule all dated 19 Aug or laterThe first three rows are the standard advice, and I did them in the standard order. The links on 4 and 12 August were real links from real pages, hand-placed in related-lists blocks. Two of fifteen pages moved. On 16 August my assistant concluded, reasonably, that discovery was not the problem and authority was: Google could see the pages and was choosing not to crawl a low-authority domain's new URLs. I had already done the things it was about to recommend, and I said so:
Check my last updates on GitHub, there are changes for backlinks, and check if pages started to get indexed and impressions.
The authority diagnosis was not wrong. It was just not the whole answer, and the fourth row is why.
The control page that changed my mind
On 18 August I shipped a cluster registry: instead of hand-placing links, every list in a topic cluster automatically receives four in-context links from its sibling lists, plus a breadcrumb to a hub page. Because the previous fixes had taught me not to trust a before/after on the whole site, three new lists were deliberately left out as a control: no registry links, no hub, no request indexing. What they did get, the same day, was what every new list got: a slot in the home page's newest-lists strip, which the home page has carried since 18 August.
Two of the three controls flipped. The city-building list, published 16 August, was crawled and indexed on 23 August with one referring URL and no request from me; the cozy list, published 13 August, followed on 28 August. The third, a wrestling list, is still unknown to Google. Same links, same week, two out of three. That is weaker than a clean result and stronger than anything the first three fixes produced.
Is the control page still indexed, and when was it crawled?
url https://game-scout.app/best/best-city-building-games
coverageState Submitted and indexed verdict PASS lastCrawlTime 2026-08-23T01:25:58Z referringUrlCount 1 richResultTypes Breadcrumbs, Review snippets, Videos
Published 16 August, crawled 23 August, first impression 24 August. No Request Indexing on record. Eight days, and the only link it had was from a page Google fetches often.
The same mechanism explained a difference I had not understood the week before. Two hub pages went live a day apart. The sci-fi hub was crawled and indexed two and a half hours after deploy, and in the same crawl second the mech-games list flipped from Discovered to indexed and the anime-games list earned its first three impressions. The vehicle-sims hub was still "URL is unknown to Google" four days later. The difference was not the hubs. The sci-fi hub's donor page had been crawled 18 hours before the merge; the vehicle hub's donors had not been fetched since 14 August, so nothing Google read yet contained the new link.
So the rule I now believe, stated narrowly: a page moves out of Discovered when a page Google crawls often starts linking to it, and Google gets around to re-fetching that page. Sitemap entries and Request Indexing put the URL in the queue; links from freshly crawled pages move it up. The dates line up with that and with nothing else I tried.
When each page was first seen
The seven lists from the cohort that have earned impressions, with the day Search Console first recorded one. Every date is on or after 19 August, the day after the registry shipped:
list published first impression days impressions to 2 Sep best-anime-games 12 Aug 19 Aug 7 137 best-beat-em-up 15 Aug 22 Aug 7 88 best-lego-games 8 Aug 19 Aug 11 543 (18 clicks) best-looter-shooter 14 Aug 26 Aug 12 138 best-mech-games 9 Aug 26 Aug 17 52 best-western-games 27 Jul 13 Aug 17 212 best-city-building 16 Aug 24 Aug 8 112 (control)
Two honesty notes on that table. The It Takes Two guide I published on 12 August pulled 3,515 impressions in its first two weeks, and a flight-games list started climbing on 15 August, so any site-wide number for this period is contaminated; that is why the table is per page. And 19 August is also the day the sci-fi hub deployed, so for the lego and anime lists the registry and the hub crawl are the same event.
Nine of eighteen are still not indexed
On 3 September, vampire, skateboarding, dinosaur, platformer, ninja, parkour, cyberpunk, hack-and-slash and heist are still not in the index. Two are "Crawled - currently not indexed", which is a different problem: Google fetched them and declined. The other seven are still Discovered, five and six weeks after publishing.
Inspect the two oldest stalled ones.
url https://game-scout.app/best/best-vampire-games url https://game-scout.app/best/best-ninja-games
best-vampire-games Discovered - currently not indexed lastCrawl null referring 1 (37 days) best-ninja-games Discovered - currently not indexed lastCrawl null referring 1 (32 days)
Both got their in-cluster links only on 1 and 2 September, when their clusters were migrated. The registry did not reach every cluster at once.
My own theory about the fix was also wrong in a way worth recording. By the end of August I was sure the answer was more hub pages:
I am trying to create hubs that are not touched or crawled, so my plan is to increase reach with hubs. What I see: ninja, parkour, skateboarding, platformer never checked and they are idle.
The audit I asked for said no. The hub pages themselves earned almost nothing in their first month: the sci-fi hub 9 impressions and 1 click, the vehicle-sims hub 0. Across 81 list pages, clusters with a hub were between 57% and 83% indexed, and the four clusters with no hub at all were 100% indexed. What did correlate was inbound links: lists with three or fewer were 62% indexed, lists with nine or more were 17 of 17. That correlation is confounded by age, older pages have both, and I would rather say so than pretend it is clean. But it pointed at links, not hubs, and it changed what I built next.
The prediction, logged where it can fail
The vampire list is the cleanest remaining test. It has sat at Discovered since 28 July, it got a hub and four in-cluster links on 1 and 2 September, and I have not requested indexing and will not.
Log it: structure only, no requests. First clicks by October?
url /best/best-vampire-games action hub 1 Sep + derived in-cluster links 2 Sep; no Request Indexing, no content change metric clicks baseline 0 expected 2 check 2026-10-04
{ "id": 15 }Graded on 4 October against fresh data. If it stays at Discovered, the mechanism above is wrong or incomplete, and the follow-up post says that.
This is the second prediction in this series. The orphan-pages post logged one on 3 September for a page that went from zero to four inbound links; it is graded on the same day.
Read your own coverage states in one session
The Search Console UI shows Discovered - currently not indexed as a count and a list. What it does not show is the thing that diagnosed mine: which of the pages linking to each stalled URL Google has actually crawled recently. With Search Console connected to an assistant, that is three asks.
1."Inspect every URL I published in the last 30 days and group them by coverage state." Discovered means never fetched; Crawled means fetched and declined; treat them separately. 2.For each Discovered URL: "Which pages on my site link to this, and when was each of those last crawled?" If the answer is "the sitemap and a page crawled in June", you have found it. 3. Add one in-context link from the two or three pages Google fetches most often, record the date, and check the coverage state again in two weeks rather than requesting indexing every morning. The page-level dates in this post come from exactly that loop, run inside the assistant-connected workflow I already use for everything else.
Google's own Page indexing report documentation describes the Discovered state as Google having found the URL but not yet crawled it, often to avoid overloading the site. On a low-authority site that reads as crawl priority: give the queue a reason to move your page up. track_page then dates every change on the page next to its Search Console line, so the next time a coverage state flips, you know what you did the week before.
FAQ
How long should a new page sit at Discovered - currently not indexed before I worry?
On my site, pages that Google was going to index were crawled within 7 to 17 days of getting a real internal link from an already-crawled page. Pages that only had a sitemap entry sat at Discovered for five weeks and counting. Two weeks with no crawl is normal; two weeks with no crawl and no internal links is a link problem, not a waiting problem.
Does Request Indexing in Search Console fix Discovered - currently not indexed?
Not reliably. I requested indexing on most of my stalled URLs in mid-August and the coverage state did not change. The page that flipped without any request was the one that received links from pages Google already crawls often. Request Indexing is a nudge to the crawl queue, not an override of it.
Do hub or category pages get new pages indexed?
Not on their own. My hub pages earned close to zero impressions in their first month, and an audit of 81 list pages found no correlation between having a hub and being indexed. What correlated was inbound links from pages that already rank: lists with three or fewer inbound links were 62% indexed, lists with nine or more were 100% indexed. The hubs mattered only as a mechanism for adding those links by rule.
Check your stalled pages the same way. Create a free account, connect Search Console, and your assistant can inspect coverage states in bulk, watch the pages you change, and grade the predictions you log. Every tool is read-only against Google. The MCP server works with Claude, Cursor, or anything else that speaks the protocol.
In your AI assistant
Ask your AI about your own site
TrafficTriage plugs into Claude, Cursor, and ChatGPT. Your assistant runs the 8 checks, reads your Search Console data, and can even check your site every morning. Free account, no API key, nothing to install.