TrafficTriageGoogle Stopped Indexing My New Pages: What Actually Fixed It
By Ugur Saritepe · October 28, 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.
Update, 7 October 2026. The prediction at the end of this post came due on 4 October, and the same cliff has opened on the site you are reading. Both readouts are in the two sections before the FAQ; nothing above them has been changed.
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.
Graded on 7 October: seven of the nine moved
The prediction above said the vampire list would earn two clicks by 4 October with no request and no content change. On 7 October I read the whole table of nine against Search Console, which held data through 4 October. Seven of the nine are earning. The vampire list earned 19 clicks, not 2.
list state on 3 Sep first impression 1 Sep to 4 Oct best-dinosaur Discovered 2 Sep 1,403 impr 9 clicks best-skateboarding Discovered 5 Sep 1,111 impr 20 clicks best-parkour Discovered 5 Sep 1,340 impr 20 clicks best-cyberpunk Discovered 5 Sep 190 impr 6 clicks best-platformer Discovered 6 Sep 232 impr 2 clicks
best-vampire Discovered 15 Sep 965 impr 19 clicks (the prediction) best-ninja Discovered 21 Sep 246 impr 4 clicks best-hack-and-slash not indexed none Crawled, not indexed; last fetch 18 Aug best-heist not indexed none Crawled, not indexed; last fetch 12 Aug
Is the vampire list indexed now, and when was it crawled?
url https://game-scout.app/best/best-vampire-games
coverageState Submitted and indexed verdict PASS lastCrawlTime 2026-10-05T14:49:37Z referringUrlCount 1 richResultTypes Breadcrumbs, Review snippets, Videos
Discovered since 28 July. In-cluster links on 2 September, first impression 15 September, 19 clicks by 4 October against an expected 2. No Request Indexing, no content change.
The lag from the links to the first impression ran from zero days to nineteen, wider than the seven to seventeen I reported from the first cohort. Five of the seven moved within five days of the 1 and 2 September migration that gave them their sibling links; vampire took thirteen days and ninja took nineteen. That is the only dated change on record for these pages, so the attribution is by date, the same way it was above. I checked content edits only on the vampire list; the other six I did not check, and I say so rather than claim it.
Two did not move, and they are a different case. hack-and-slash and heist were both fetched in August, on the 18th and the 12th, and Google has not been back. Their state is "Crawled - currently not indexed": fetched and declined. Links from sibling pages did not earn either one a second visit in seven weeks. The dinosaur list is the one honesty note in the table: it had three impressions on 2 September, the day before I called it not indexed from that day's coverage report, so the two sources disagreed for a day, the way they did in the false-verdict incident.
The same cliff, on this site
On 6 October I inspected every post this site had published since 3 September, 27 of them, most of them case studies like this one. On 7 October I inspected them again. One has been crawled. The post you are reading is "URL is unknown to Google" on the day of this update.
27 posts published 3 Sep to 5 Oct, inspected 6 Oct and again 7 Oct
6 Oct 7 Oct
Submitted and indexed 1 1 (crawled 25 Sep)
Discovered - currently not indexed 18 17
URL is unknown to Google 8 9
never crawled, by either label 26 26label changed overnight, no crawl recorded on any 9 of 27 unknown on 6 Oct, Discovered on 7 Oct 4 Discovered on 6 Oct, unknown on 7 Oct 5 (this post among them) referring page reported 1 of 27
Nine labels changed in 24 hours and not one crawl happened. Google's URL Inspection help says the result "is not a live test" and comes from the most recently indexed version of the page; for a page with no indexed version, Discovered and unknown are two labels on the same fact. I had been reading the split between them as a signal in the 6 October count. It is not one. The number to read is the last crawl date, and 26 of 27 have none.
Then I did for this site what the control page did for the other one: I looked at which pages Google actually fetches here, and whether they link to the 27.
page on traffictriage.com last crawl links to the 27 posts /blog (lists every post) 1 Oct all 27 / (home) 18 Sep none; one link, to the Vercel guide /blog/ai-assistant-seo (hub) 22 Jul all 24 case studies the Vercel guide, most fetched 30 Sep none
The blog index is the one page Google fetches that links to all of them, and Google read it on 1 October with every one of the 27 on it. Six days later none of them had been crawled. On the other site the lag from a fetched link to the first impression ran up to nineteen days, so six days does not falsify the rule above. It sets a date for it. If none of the 27 has a crawl date by 18 October, seventeen days after that fetch, the rule is wrong on this site, and this post will say so in its next update. I have not logged this one in the product; the date is in the text instead.
We have not added a link to any of the 27 from the three guides Google fetches on this site, and we have not requested indexing for any of them; the fix this post recommends is unapplied on the site that published it, and the check date above is the honest consequence. The impressions this site lost in the same weeks are a separate event with its own write-up in impressions dropped, position improved; none of the 27 ever had an impression to lose. If your own pages read "URL is unknown to Google" while sitting in a sitemap Google downloaded, the guide to that state covers the causes this cohort does not.
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.
Why does URL Inspection say Discovered one day and URL is unknown to Google the next?
Because the tool reads Google's last index snapshot, not the live crawl queue, and for a page Google has never fetched the two labels are the same fact: no crawl. On this site I inspected 27 never-crawled posts on 6 October 2026 and again on 7 October; nine of them changed label overnight, four from unknown to Discovered and five the other way, with no crawl recorded on any. Read the last crawl date and count the pages that have none. The label is noise.
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.