“Discovered, Currently Not Indexed” for Three Months: How a URL Move Fixed Eight Pages on My New Site

If your new site’s pages are not showing up on Google and every fix has failed, this case is for you. It is from my own website. The pages were fine, the server was fine, and the standard fixes changed nothing. Moving the pages to new URLs indexed all eight, most within minutes.

In brief

My practice’s new site went live in mid-June 2026 with 18 pages. Within weeks, Google had indexed the homepage and the informational pages. Eight pages were never indexed: the AI Visibility services hub, the five service pages beneath it, the methodology page, and a guide of about 5,700 words. For about three months they sat at “Discovered, currently not indexed” or “URL is unknown to Google” while I applied every standard fix: weekly indexing requests, a sitemap cleanup, a page-weight overhaul, about 90 internal links, and a server migration. None of it moved them. On September 24 to 26, I moved the eight pages to new top-level URLs with 301 redirects from the old ones. All eight were indexed, most within minutes of a single indexing request. The diagnosis took an afternoon. The problem had cost well over 100 hours over three months.

Site	Period	Pages affected	Time to resolve	Outcome
A 21-page WordPress consulting site on a managed host	Mid-June to September 26, 2026	8 of 21, all in one section	About 36 hours from diagnosis to the last page indexed	All 8 indexed at new URLs; the old URLs redirect

The situation

The site is telstarconsultinginc.com, my own practice’s site. The site is new; I am not. I have built websites for years, spent more than a decade on SEO, and now practice AI visibility for manufacturers and B2B firms, and this site replaced an earlier one when I restructured the practice. I know how indexing works, and I still had a problem on my own site that came close to beating me. I did everything described here myself with an AI agent. That matters for two reasons. I had full access to every tool, so nothing in this story was hidden from me. And I made several of the early mistakes myself, which are recorded below because the fix only makes sense against them.

The eight pages are the commercial center of the site: the services hub and the five engagement pages under it, the methodology page, and the long-form guide to online visibility. Each is between roughly 1,850 and 5,700 words, with structured data, internal links, and self-referencing canonicals. Every page passed Google’s live URL test whenever I ran it. For three months, a prospect searching for what I do could not find the pages that describe it. A page that is not indexed does not exist as far as Google Search is concerned: it cannot rank for anything, it cannot appear in an AI Overview, and AI Mode cannot cite it, however good it is. For a practice whose new business starts with a search, the pages that sell the services were invisible for a quarter of a year.

What we saw

Google Search Console showed two statuses on the eight pages, and it never showed anything else:

• “Discovered, currently not indexed.” Google knew the URL existed but had not crawled it.
• “URL is unknown to Google.” Google had no record of the URL, even though the sitemap listed it and Google was reading the sitemap.

On July 20, five weeks after launch, 11 of 18 pages were indexed, and the live test on every stuck page returned “URL is available to Google,” which means Google could fetch and read the page when asked to. The Audit page showed “URL is unknown to Google” with no referring sitemap and no referring page, while the sitemap, read successfully by Google on June 23, listed it. Two service pages published on August 2, six weeks after launch, went straight into the same state, so being on the site from day one was not what kept pages out.

Everything else on the site behaved normally. Google fetched nine pages between July 1 and 3 and indexed all of them. It recrawled the homepage regularly. On September 21, I published a service-style post of more than 4,000 words; Google crawled it the next morning and indexed it within hours of an indexing request.

What we ruled out

Every hypothesis below was tested with the evidence beside it. The first six were my own theories or the agent’s, and each fix was a real improvement to the site. None of them reached the cause.

The last row deserves its own explanation, because it is the one that rules out the site itself. A second search engine, crawling the same pages on the same server during the same weeks, fetched every one and judged every one worth indexing. Bing was ahead of Google by 41 to 81 days on seven of the eight pages, and by at least 10 days on the eighth.

Bing also responded to submissions where Google did not. The Audit page had been submitted through IndexNow about 15 times with no Google crawl; Bing crawled it three days after a URL submission on August 1.

What changed the diagnosis

Two readings broke the pattern, and both came from Search Console data I had been looking at for weeks without asking the right question.

The control page. The September 21 post went from published to indexed within hours on the same site, the same template, and the same server. So, Google was crawling and indexing new URLs on this site quickly. The problem could not be the site.

Crawl Stats by Googlebot type. In 90 days of crawl data, Google’s indexing crawler never fetched one of the eight pages. Every fetch of a stuck page was tagged “Other agent type,” which is the crawler Google uses for a live test or an indexing request. The scheduled crawler, the one that decides what enters the index, had not come back to these URLs once. Improving content, speed, or links only matters when Google returns to read the page, and it never did.

Those two facts pointed at the URLs themselves. On September 24, I ran a test: move three pages to new top-level URLs, add 301 redirects from the old addresses, replace the internal links, and request indexing once.

The fix and the result

Date and time (ET)	What happened
September 24, about 10:11 to 10:13 PM	Intelligence, Content Strategy, and Content Development, moved that evening, were crawled by Google’s smartphone crawler and indexed. Google accepted each page’s own canonical.
September 25, late evening	Methodology, Audit, and the guide were moved, and indexing was requested.
September 26, morning	Methodology and Audit were indexed. The guide, at its new address, showed “URL is unknown to Google.”
September 26, morning	Snapshot, then the hub, were moved, child page first so the child did not move twice. Both were indexed within minutes of the request. The two moves took about an hour.
September 26, 8:37 AM	A live test on the guide’s new address passed. The page itself was fine.
September 26, 8:56 AM	Control test: indexing was requested again on the guide’s new address, with nothing else changed.
September 26, 9:57 AM	The control test result: still “URL is unknown to Google,” never crawled. A fresh request alone did not move this URL.
September 26, about 10:10 AM	The guide was moved a second time, to a clearly different address, with one redirect covering both old URLs. Indexing was requested.
September 26, 10:13 AM	Google crawled the guide’s second address, the first crawl of this page’s content in three months.
September 26, about 10:30 AM	Indexed. All eight pages were on Google.

Seven of the eight pages were indexed on their first move, most within minutes of one indexing request at a new URL, after about 12 weeks of the old URLs never moving. The eighth, the guide, is the most useful result in the whole case, and the next section is about it.

Each move followed the same procedure: a backup, the page’s parent set to none and its slug changed, a 301 from the old URL, a dry run of the internal-link replacement, the live replacement, a second dry run to confirm zero matches remained, a cache purge, a sitemap refresh, and a logged-out check of every page on the site. The order mattered where pages were nested: the child page moved before its parent, and the child’s links were replaced before the parent’s, because the parent’s path was contained in every child link.

What remains uncertain

Google does not publish how it stores or resets crawl priority for a URL, so the mechanism here is inference from the evidence, and I am labeling it as such.

What the evidence supports. Google’s own definition of “Discovered, currently not indexed” says Google wanted to crawl the URL but expected the crawl to overload the site and rescheduled it (1). Google’s crawling documentation says its crawlers treat a 429 status as a server-overload signal and slow down in response (2). During its first two weeks, this site served exactly those signals: a store plugin’s coming-soon page to every logged-out visitor, a 10-second crawl delay in robots.txt, and bot management at the host’s edge security layer that challenged and rate-limited crawlers, including a 429 I reproduced myself on June 26. It is reasonable to think the eight URLs were assigned a low priority then and never re-evaluated, while URLs Google first met after those barriers came down, by July 1, got a clean start. The evidence fits this. Nothing proves it.

What does not fit neatly. The guide’s first new address was a brand-new URL, and Google treated it like the stuck one: two indexing requests, including a clean control test, and no crawl. Its second new address was crawled in three minutes. Two explanations fit. Google may have associated the first new URL with the old one, through the shared word stem, the 301 pointing at it, and a sitewide footer link on a client’s site that was still sending Google to the old address. That fits what Google’s Gary Illyes has described about Google judging URL patterns rather than single URLs (3). The counterevidence is that the services hub also kept a shared stem and a 301, and it was indexed in minutes. The sitewide external link to the old URL is the one factor unique to the guide, and I removed it about an hour before the second move, so the two changes cannot be separated. With one site and one failed case, this cannot be settled.

How common is this fix. Not common, as far as I can find. I read six current guides to this status from authors and firms that specialize in indexing. Five of them, from Onely, Ahrefs, Search Engine Land, Stan Ventures, and Indexing Insight, do not mention moving a page to a new URL; their advice is the standard set of content quality, internal links, crawl efficiency, server performance, and indexing requests (4)(6)(10)(11)(12). One, from Motava, lists republishing the content at a new slug as a workaround it tried first, and says it did not fix that site’s case (7). I have not found a reputable author who recommends the move, and I am not recommending it as a first step either. It is the test to run when the standard advice has been applied, measured, and has changed nothing.

Why the move is a low-risk test on a page like these. A page that was never indexed has nothing to lose. It holds no ranking, no index entry, and no search traffic, so a new URL cannot cost it any of those. What it does hold is worth protecting, and two steps protect it. The 301 redirect keeps every existing path to the page open: visitors’ bookmarks, links shared in email or on LinkedIn, the client’s footer link in this case, and Bing’s index entry, which follows the redirect to the new address in time. Replacing the internal links and refreshing the sitemap means the site’s own navigation, the sitemap, and the crawlers that read them point at the new URL from the first minute, so there is no window in which the page is unreachable. The rest of the site is untouched; nothing changes for the pages that were indexed. The costs are housekeeping: a backup, a dry run of the link replacement, the live replacement, a cache purge, and a sitemap check, which took about an hour per batch here. The same move is a different decision on a page that is, or was, indexed and ranking, because there the URL has standing to lose, and a redirect passes most of it but not all. Pages do slide backward: Indexing Insight’s study of 1.4 million pages across 18 sites found that once Google stops recrawling a page, most move from indexed to “Crawled, currently not indexed” and, after about 190 days without a crawl, on to “Discovered” or “URL is unknown to Google” (13). A page that arrived at “Discovered” that way once had rankings and inbound links, and the first question is why Google stopped coming back, not where to move it. This test is for pages Google has never taken.

What this case does not show. This is one site. The pattern should be tested on other sites before anyone, me included, presents it as a rule. The standard advice for this status is to improve content, add links, speed up the server, and request indexing (4)(5), and on most sites that advice is probably right; indexing studies attribute most not-indexed pages to quality (6). This case is about the sites where all of that has been done, measured, and has changed nothing.

How it was done

I did this with a Claude in Chrome agent working inside my own Chrome browser, plus separate Claude chats for analysis and documents. The setup and the boundaries are part of the method, so here they are.

Access. I signed in to Search Console, the host’s portal, and WordPress myself. The agent worked inside those sessions and never held passwords or standing admin access. It asked before changing a setting, requesting indexing, or editing anyone else’s site. I took every backup, and I ran every irreversible database change myself, after the agent had run and checked the dry run.

Who did what. The agent read the evidence directly, in URL Inspection, in Crawl Stats by Googlebot type, and in the plugin and host settings, and it checked every page the way a logged-out visitor sees it, uncached, after every change. That is how it caught a stale sitemap and stale cached copies that would have misled us. It moved the pages, added the redirects, tested every old URL with and without a trailing slash, ran the dry runs, set the move order for nested pages, and designed the control test for the guide with one variable changed. It also found the client footer link and verified all 60 pages on the client’s site afterward; I decided to run the URL-move test and to extend it to all eight pages once the first batch was indexed, owned the client relationship, set the standards the site had to meet, and supplied the facts the record was missing.

What the AI agent got wrong. From June through August, successive sessions proposed reasonable explanations that did not hold, such as normal delay for a new site, a sitemap exclusion, an edge-firewall rule, crawl budget, page weight, and missing links. Each was measured carefully, and each fix was a real improvement, but none reached the cause. In the final session, the agent misreported two pages as indexed “within hours” when it was minutes, misspelled a client’s surname in a draft, and recommended waiting until Monday on the guide page. I corrected the first two and pushed back on the third, because every other page had indexed within minutes, and that pushback led straight to the control test and the second move.

Why the combination worked. The August 1 session used the same tools, measured carefully, and still did not find the cause. What changed the outcome was a better question: why does a new page on this site index in hours while these eight do not? The agent brought reach across every tool at once, patience for repetitive checking, and a record of every step. I brought the judgment that the answers were not adding up, from early July onward, the willingness to try an unconventional fix, control over anything irreversible, and knowledge of the business. I would not have solved it alone, and without my knowledge of websites and visibility, even with the AI agent, I would have probably failed.

What you can take from this

If your new site has pages stuck in “Discovered” or “URL is unknown” while other pages index normally, run these three checks before you rewrite anything.

1. Compare against a control page. Publish or find a recent page on the same site and see how quickly Google indexes it after an indexing request. If it indexes in hours, the site is not the problem.
2. Check Crawl Stats by Googlebot type. In Search Console, open Crawl Stats and look at the fetches of your stuck URLs. If every fetch is “Other agent type” and the indexing crawler never appears, the URL itself is being held back, and nothing you change on the page will be read. URL Inspection shows the date and time of Google’s last crawl of each page, which is how you know whether the indexing crawler has ever come back.
3. Once the pages pass every quality and technical check, test a controlled URL move. One page, a new top-level URL with a clearly different stem, a 301 from the old address, internal links replaced, and one indexing request. A page that was never indexed has no rankings or traffic to lose, and the redirect and the link replacement keep every existing path to it open, so the test costs an hour of housekeeping and risks nothing else. Here it worked in minutes. If the first new address is also ignored, move again to a more different one, and remove any external links still pointing at the old URL first.

Two more things this case taught me:

• Check the other search engine. Bing’s URL Inspection showed me in one afternoon that every stuck page had been crawled and indexed weeks earlier. That evidence was sitting there the whole time, and I discounted it because Bing sends less traffic. It was the cleanest proof that the site was fine.
• Remove every crawler barrier before you submit a sitemap. The expensive part of this story happened in the first ten days: a coming-soon mode, a crawl delay, edge bot management, a day of sitemap 404s, and three hours of accidental noindex. Google’s first impression of a URL can last for months, or so it would seem. A new site should be free of all of it before Google’s first look.

Questions site owners ask

About the practice and the next step

Telstar Consulting Inc is an AI Search and Visibility practice in Connecticut. Every engagement starts with a diagnostic, because the fix in this case study came from reading the data, and reading the data is what a diagnostic is.

If your pages are stuck, run the three checks above first. If they pass and you want a second set of eyes on the crawl data before you change anything, I’d start with the AI Visibility Audit; it covers crawl access, sitemaps, structured data, and technical blockers in one pass. The free AI Visibility Snapshot is the lighter first step if you want to see how the AI engines describe your business today.

References

1. Google Search Central. Page indexing report. Google Search Console Help. https://support.google.com/webmasters/answer/7440203
2. Google Search Central. How HTTP status codes, and network and DNS errors affect Google Search. Updated February 4, 2026. https://developers.google.com/crawling/docs/troubleshooting/http-status-codes
3. Schwartz, B. (2022, September). Google can crawl sections of your site more frequently and determine quality differently also. Search Engine Roundtable. https://www.seroundtable.com/google-section-indexing-quality-34023.html
4. Taylor, D. (2025, May 22). Understanding and resolving “Discovered, currently not indexed.” Search Engine Land. https://searchengineland.com/understanding-resolving-discovered-currently-not-indexed-392659
5. Schwartz, B. (2024, August 21). Google on Discovered, currently not indexed. Search Engine Roundtable. https://www.seroundtable.com/google-on-discovered-currently-not-indexed-37931.html
6. Gent, A. Why pages are not indexed in Google [study]. Indexing Insight. https://indexinginsight.com/blog/why-pages-are-not-indexed-in-google
7. Bilandzic, V. (2024, July 16). 9 non-obvious fixes for “Crawled / Discovered, currently not indexed.” Motava. https://www.motava.com/blog/fixes-discovered-currently-not-indexed-urls/
8. IndexNow. IndexNow: instantly index your web content in search engines. https://www.indexnow.org/
9. Google Search Central. Ask Google to recrawl your URLs. Updated December 10, 2025. https://developers.google.com/search/docs/crawling-indexing/ask-google-to-recrawl
10. Góralewicz, B. (2026, March 13). How to fix “Discovered, currently not indexed” in Google Search Console. Onely. https://www.onely.com/blog/how-to-fix-discovered-currently-not-indexed-in-google-search-console/
11. Kukic, D. (2022, September 20; updated 2026, August 12). How to fix “Discovered, currently not indexed” in Google Search Console. Ahrefs. https://ahrefs.com/blog/discovered-currently-not-indexed/
12. Thekkethil, D. (2023, September 21). Discovered, currently not indexed status: how you can fix it. Stan Ventures. https://www.stanventures.com/blog/how-to-fix-discovered-currently-not-indexed-in-google-search-console/
13. Indexing Insight. (2025, June). New study: after 190 days since last crawl, Googlebot forgets. https://indexinginsight.substack.com/p/new-study-after-190-days-since-last