Google found my pages but will not index them

By Idea to Traffic Editorial Team · Published September 27, 2026 · Last updated September 27, 2026

This site, discovered and not indexed

The Cloudflare Pages project for ideatotraffic.com was created on 2026-08-31. The site was verified in Google Search Console and its sitemap submitted on 2026-09-07. Within days, the URL Inspection tool returned the same verdict on page after page: Discovered, currently not indexed. There was no crawl error, no robots block and no canonical conflict. Google knew the URLs existed and had not come to fetch them.

That is not one site's problem. We run seven live sites on Cloudflare Pages. All seven are verified in Search Console with sitemaps submitted. Across all seven, over a 28 day window, Google produced one click. Not one click each. One click in total.

The traffic that does arrive comes from somewhere else. Measured on 2026-09-07, about 92 percent of the network's organic traffic came from the Bing family, meaning Bing plus DuckDuckGo and Yahoo, which both draw on Bing's index. Roughly 6 percent came from Google. ideatotraffic.com on its own recorded 4 pageviews from 5 sessions in the seven days to 2026-09-27.

One site in the network shows zero Google impressions at all, despite being live with content and having a submitted sitemap. We have not worked out why, and we are not going to invent a reason. Some Google behaviour on a new domain does not resolve into a cause you can act on, and saying so beats a theory.

Google has the URL and has not spent a crawl on it

The status has a precise meaning that its wording hides. Google holds the URL in its list of known addresses and has not crawled it. Indexing has not been refused, because the crawl that would precede indexing has not happened. The status is a queue position, not an error, and there is no button anywhere in Search Console that changes a queue position.

On a brand new domain the constraint is almost always the same: nothing links to you. Crawl priority is allocated partly on external evidence that a page is worth fetching, and a domain registered weeks ago with no inbound links supplies none. A sitemap is a claim you make about yourself. A link is a claim somebody else makes about you, and only the second kind carries weight in a crawl decision.

Bing behaves differently, and the difference is mechanical. Bing accepts a push protocol, IndexNow, which lets a site announce that a URL changed instead of waiting to be found. A key file at the site root plus a POST to api.indexnow.org is enough to get Bing crawling a brand new domain within days. That is the largest reason the network's traffic is 92 percent Bing family: one engine can be told, and the other cannot.

Telling a waiting page from a rejected one

Two separate questions hide inside one symptom. Can Google fetch the page, and does Google want to. Confirm the first before spending effort on the second, because a genuine fetch defect looks identical in the Search Console summary.

Check that the URL answers with a 200 and not a redirect or a soft error:

curl -sI https://ideatotraffic.com/guides/ | head -1
curl -s https://ideatotraffic.com/robots.txt
curl -s https://ideatotraffic.com/guides/ | grep -i 'rel="canonical"'

You want a 200 status, a robots.txt that does not disallow the path, and a canonical that points at the URL itself rather than at another page. If the canonical points somewhere else, you have a different problem and this guide is not it.

Then run the live test in URL Inspection rather than reading the cached verdict. The stored verdict describes the last crawl, which never happened here, so it tells you nothing. If the live test reports the URL is available to Google, fetchability is confirmed and the remaining issue is priority.

A better confirmation is to check the same URL in Bing Webmaster Tools. If Bing has crawled and indexed it, the page is reachable, renderable and parseable by a real crawler, so the Google status is about queue position rather than any defect of yours.

Measure whether Googlebot has touched the origin at all rather than inferring it. Counting requests by user agent over a fixed window turns an argument into a number: .

Three things reliably do not work, and we tried all three before accepting it:

• Resubmitting the sitemap. The submission is recorded once, and repeating it adds nothing.
• Requesting indexing on the same URL over and over. The request is not a vote, and volume does not raise its weight.
• Adding more thin pages. More URLs in the discovered state is a larger version of the same problem.

Confirm the basics once, then stop resubmitting

1. Confirm the technical basics once with the three commands above and write down the result. If the page returns 200, is allowed by robots.txt and self-canonicals, close the technical question.
2. Submit the sitemap exactly once per site and note the date. That date starts the clock, it is not a lever to pull again.
3. Wire IndexNow into the deploy so Bing hears about every change without anyone remembering. Place the key file at the site root and POST the changed URL list to api.indexnow.org as the last build step. This produced the 92 percent share, and it costs nothing per deploy.
4. Verify in Bing Webmaster Tools within a few days that the pushed URLs were crawled. If Bing has them and Google does not, the problem is isolated to Google's queue.
5. Get one real inbound link from a site that already gets crawled. It is the only input that comes from outside your own property, which is why it outweighs every Search Console action combined.
6. Consolidate rather than expand. Fold thin pages into fewer, deeper pages so the URLs Google eventually crawls are worth the crawl.
7. Track impressions and clicks per engine rather than aggregate organic totals, so a Bing improvement cannot disguise a flat Google line.

Launch with fewer, stronger pages

Launch with fewer pages than you want and more words on each. A new domain gets a small crawl allocation, and spending it on short pages wastes the only attention you are given.

Have at least one inbound link in place before you submit anything. A link from an already crawled page is a discovery path that does not depend on a queue.

Automate the IndexNow push at build time, and label it as a Bing mechanism in whatever checklist you keep. A step that works for one engine, filed under a heading implying both, misleads whoever reads that checklist next.

Set the expectation before launch rather than after. On a new domain the realistic near term picture is Bing traffic first and Google traffic later, which is what our numbers say: one Google click in 28 days across seven sites.

No way to put Google on your schedule

None of this makes Google index a page on a schedule you control. There is no mechanism that does.

IndexNow does nothing for Google. That bears repeating, because the temptation to file it as a general indexing fix is strong when it works so visibly on the other side.

It also does not explain the site in our network with zero Google impressions. The steps here did not change it, and we would rather record that as unexplained than present a guess as a diagnosis.

Last, none of this fixes a page nobody was looking for. Crawling and indexing are necessary and not sufficient. If a page is indexed and still gets no clicks, the problem moved from the queue to the content.

Questions about Discovered, currently not indexed