Google Discovered But Not Indexed: the AI Search source page playbook

Step-by-step checklist

Step-by-step checklist

1. Confirm the page returns 200.
2. Confirm the canonical points to the final URL.
3. Confirm there is no noindex in HTML or headers.
4. Confirm the URL appears in sitemap.xml, feed, and llms.txt.
5. Link to the page from indexed pages in the same cluster.
6. Put the direct answer near the top.
7. Add a table, FAQ, and visible sources.
8. Submit the sitemap if discovery surfaces changed.
9. Recheck Search Console after the crawl window.
10. Monitor AI answers for citation, not just brand mention.

What does "Discovered - currently not indexed" actuall

What does "Discovered - currently not indexed" actually mean?

Discovered - currently not indexed means Google knows the URL exists, but the URL has not become an indexed page. It is not automatically a penalty, and it is not proof that the content is bad. It is a queue and priority signal: Google has found the address, but the page has not yet passed through crawl and indexing in a way that makes it eligible to appear in Search.

Google's own Search documentation is clear that indexing is not guaranteed. Not every page Google processes will be indexed, and indexing depends on the canonical page, its content, and its metadata. Google also says every important page should be linked from at least one other page on the same site so people and Google can find it. ¹² For a strategic source page, "at least one" is a floor, not the operating standard.

That distinction matters for AI Search. A page that is not indexed by Google may still be accessible to some crawlers, but it has a weaker chance of being selected as a durable source in grounded AI answers. The page is not just trying to rank. It is trying to become a reusable answer surface.

What does "URL is unknown to Google" mean for a new so

What does "URL is unknown to Google" mean for a new source page?

URL is unknown to Google is a stronger discovery warning than Discovered - currently not indexed. In Search Console's URL Inspection help, this status means Google has not seen the URL before in the inspected index. ⁵ In practice, that can happen even when a page is live and present in a sitemap, especially when the page is new, weakly linked, or not yet reached through the crawl paths Google is prioritizing.

For the main AI services pillar, this means the fix should emphasize discovery and importance:

1. Make the page reachable from already indexed pages.
2. Link to it with descriptive anchor text from the related cluster.
3. Keep it in sitemap, feed, and llms.txt.
4. Make the first screen answer the primary prompt directly.
5. Add source-backed snippets and FAQ that can be extracted.
6. Recheck URL Inspection after crawl windows, not every hour.

The wrong fix is panic-churn: changing slugs, changing canonical tags that are already correct, or publishing a near-duplicate page with a different title. Those moves create more ambiguity.

Why should AI Search source pages be handled differently from or

Why should AI Search source pages be handled differently from ordinary blog posts?

An ordinary blog post can afford to be loose. A source page cannot. A source page is meant to be cited, summarized, and used as a stable reference by search engines, AI systems, and humans.

That changes the page requirements. The page needs a short direct answer, visible evidence, clear authorship, stable entity language, related first-party links, and a post-publish monitoring loop. It should not merely contain keywords like "AEO", "GEO", or "AI visibility". It should answer a buyer or operator prompt so clearly that another system can quote the answer without guessing.

This is where the usual SEO checklist becomes insufficient. A sitemap can tell Google that a page exists. It cannot prove that the page is important. A self-canonical tag can identify the preferred URL. It cannot make the page useful. Schema can describe the page. It cannot replace visible evidence.

For a source page, indexability has three layers:

The first layer is technical. The second layer is site architecture. The third layer is editorial proof.

What should you do before requesting indexing again?

What should you do before requesting indexing again?

Before another request-indexing attempt, run a small proof loop. The point is not to guarantee indexing. No tool can do that. The point is to remove ambiguity from the signals you control.

Use this sequence:

1. Confirm the page returns 200.
2. Confirm the canonical URL is the same URL you want indexed.
3. Confirm there is no noindex in HTML or headers.
4. Confirm the URL is in sitemap and llms.txt.
5. Add contextual internal links from indexed, related pages.
6. Add or improve the short answer at the top of the page.
7. Add at least one table, checklist, or FAQ section that makes the answer extractable.
8. Add visible source links if the page makes factual claims.
9. Submit the sitemap if the sitemap changed.
10. Recheck URL Inspection after a reasonable crawl window.

For the current gregshevchenko.com case, the obvious next fix is not technical. The two unindexed AI services pages should be linked more strongly from indexed pages such as /research/ai-services-vs-saas/, /research/outcome-based-pricing-ai-services/, /research/what-marketing-engineers-do-ai-search-era/, /research/content-refresh-for-ai-search/, /start/, and the research hub.

That is the most honest action because the indexed pages already prove Google can crawl and index the cluster. The issue is not global indexability. It is cluster priority and source-page strength.

Why not use Google's Indexing API for ordinary articles?

Why not use Google's Indexing API for ordinary articles?

Do not use the Google Indexing API as a shortcut for ordinary research articles. Google documents the Indexing API for pages with JobPosting or livestream BroadcastEvent markup. ⁴ A founder research page, AI Search methodology article, service page, or blog post does not fit that use case.

For articles, the valid path is still the boring path. Make the page crawlable, include it in the sitemap, link to it internally, publish a distinct answer, distribute the canonical URL, and monitor Search Console plus AI answer visibility.

Indexing myths are attractive because they promise a button. Source pages usually need a system.

How do you turn indexability into an AI visibility loop?

How do you turn indexability into an AI visibility loop?

Publish-ready is not loop-closed. A page can pass local QA and still fail to become a useful AI Search source. The operating loop should continue after deployment.

Use four checkpoints:

The measurement should separate mentions from citations. A brand mention without a cited URL is useful, but it is not the same as source selection. For AI Search visibility, the stronger signal is a prompt where the answer cites your canonical URL or uses it as a named source.

How should this apply to the AI services cluster?

How should this apply to the AI services cluster?

The AI services cluster already has a useful shape:

• The AI services page is the pillar.
• /research/ai-services-vs-saas/ compares the company form.
• /research/outcome-based-pricing-ai-services/ explains pricing.
• The market-selection page handles where to begin.
• /research/what-marketing-engineers-do-ai-search-era/ connects the role and operating model.

Because 2 support pages are indexed and 2 strategic pages are not, the cluster is not invisible; it is uneven. The practical repair is to make the pillar and market-selection page feel unavoidable inside the cluster.

Add these internal links:

• From AI Services vs SaaS to the pillar with anchor text like "AI services company form".
• From Outcome-Based Pricing for AI Services to the pillar with anchor text like "the AI services operating model".
• From What Marketing Engineers Actually Do in the AI Search Era to How to Choose a Market for an AI Services Company.
• From /start/ to the AI services pillar if the cluster is now strategically important.
• From the research hub to the pillar and at least two supporting pages.

Then refresh the pillar page itself. The opening should answer the primary prompt in the first 50 words. The page should include a comparison table, FAQ, source links, and a "how this connects to Humanswith.ai" route without turning into a sales page.

Where companies go wrong

Where companies go wrong

Teams often treat indexability as a button problem. The useful repair is different: prove the crawl path, strengthen internal links, make the answer extractable, then measure whether the page becomes a source.

FAQ

Questions this page answers

Source trail

Sources

Related

Related research