The Short Answer
A new page that is not indexed is usually in one of four states: Google has never heard of it, Google knows about it but has not crawled it, Google crawled it and decided not to index it, or Bing crawled it and stored nothing. Each state has different causes. The most common cause we found this autumn was not a technical block but a missing signal: new pages linked only from a blog index, in sitemaps that told search engines every page had changed on every deploy. Give a new page at least one link from a page search engines already visit often, keep sitemap dates honest, make sure your submissions read the real sitemap, request indexing, and then leave the page alone while the engines decide.
The one sentence version
Check the exact status in each engine, give the page a real link and an honest date, submit it once, and stop editing it while you wait.
First, Find the Exact Status
Not indexed is not one problem. Google's URL Inspection tool and its API report a coverage state for every address, and Bing's webmaster tools report discovery and crawl dates and whether a document is stored. Read both before changing anything.
| Status | Engine | What it means | First thing to check |
|---|---|---|---|
| URL is unknown to Google | Google has no record of the address | Internal links and the sitemap Google last read | |
| Discovered, currently not indexed | Known but not yet crawled | Crawl demand and links | |
| Crawled, currently not indexed | Read and judged not worth indexing yet | Content, duplication, page type | |
| URL cannot appear on Bing, nothing stored | Bing | Fetched, held back from the index | Live page for noindex, then time |
| Never discovered | Bing | No record of the address | Links, sitemap and IndexNow |
Our guide to reading search data through the API shows how to query these states for every page at once instead of one at a time in the browser.
What We Found on Our Own Sites
On 10 November we asked Google about every guide we published on this site since September. Three guides published on 2, 4 and 6 October were still unknown to Google five weeks later. Three published on 21 October were indexed within days. Two September guides were indexed too. All of them sit in the same sitemap and are linked from the same blog index, and we cannot point to a single difference that explains the split. That is itself useful: the engines do not treat new pages equally, and waiting for them is not a plan.
| Guide published | Google, 10 November | Bing, stored copy |
|---|---|---|
| 10 and 12 September | Indexed | Yes by 10 November, empty on 22 October |
| 2 October | Unknown to Google | No, crawled 4 November |
| 4 October | Unknown to Google | No |
| 6 October | Unknown to Google | No, first discovered 4 November |
| 21 October, three guides | Indexed | No |
One of those unknown guides is our own guide to reading Search Console data through the API, which is a fair reminder that publishing good advice does not exempt a page from the queue. Bing told a slower story: on 22 October it had stored nothing for most of our new articles; by 10 November the two September guides finally had stored copies, about 170,000 bytes each, while every October guide was still empty.
Cause 1: The Page Has Only One Way In
On a voice product we run, three articles were unknown to Google on 10 November, one of them live since late September. They answered normally, carried a self canonical, and sat in a sitemap Google had read the day before with no errors. Their only internal link was the blog index. Pages published on the same days that also had links from the site footer or other pages were indexed. A single link from an index page that changes daily is a weak invitation.
Add a link from a page that is crawled often
The homepage, a footer section or a popular related article. One strong link beats several weak ones.
Link from related articles
Two or three contextual links from pages on the same topic tell search engines where the page belongs.
Keep it in the sitemap
The sitemap supports discovery; it rarely replaces links.
Cause 2: Sitemap Dates That Say Everything Changed
A sitemap's last modified date is a hint about which addresses are new or updated. On two of our products the sitemap stamped every address with the time of the latest deploy, so every page claimed to have changed every time anything shipped. A CV product's sitemap had done this for all 1,237 addresses since August. When every page is new, no page is new, and the genuinely new article has nothing that sets it apart.
| Sitemap habit | What it tells search engines | Better |
|---|---|---|
| Every lastmod set to the deploy time | Everything changed, constantly | Real date per page, changed only when content changes |
| No lastmod at all | Nothing about recency | Real dates where you have them |
| Real dates per page | Exactly which pages are new | Keep it this way |
Cause 3: Your Submission Read an Old Sitemap
IndexNow lets you tell Bing and other engines about changed addresses immediately, and many sites submit their whole sitemap after each deploy. On 10 November one of our deploys submitted the sitemap it read through the content delivery network, which was still serving the previous copy: 1,237 addresses where the real file had 1,238. The new page, the one that mattered, was the one left out. The same CV product had also been submitting all 1,237 addresses on every deploy, which tells the engines nothing about which one is new.
Read the sitemap from the origin
Have the submission script read the freshly built file, not the public copy behind a cache.
Submit only what changed
Send new and updated addresses, not the whole site every time.
Check the log
After each deploy, confirm the new address appears in the submission log, and submit it by hand if it does not.
Our IndexNow setup guide covers the protocol itself.
Cause 4: The Engine Has Judged the Page Type
Sometimes the page is known, crawled and simply not wanted. On a small tool site we inspected every sitemap address on 29 October: 42 were crawled and not indexed, 20 were unknown and 11 discovered but not crawled. Most of the crawled but refused pages were near copies of each other, templated variants published in one day months earlier. When most pages of one type are refused, the type is the problem, and the honest fixes are to make those pages genuinely different or to stop asking for them, with a noindex and removal from the sitemap.
Look for a pattern by page type
Group refused pages by template. One type refused across the board points at duplication or thin content.
Do not keep asking for refused pages
A sitemap is a list of pages you want judged. Leave out the ones you would not defend.
Give judged pages time
Crawled but not indexed can change after the rest of the site improves. Re-check monthly, not daily.
Bing Has Its Own Queue
Bing deserves separate attention, because ChatGPT search leans on its index and Copilot is built on it. Its inspection tool can say a page cannot appear on Bing, with indexing not allowed and an empty canonical, even when the page carries no noindex anywhere. In our case that meant Bing had fetched the page and not yet decided to keep it. The September guides took between six and nine weeks to be stored. Check the live page for any noindex first, then request indexing in Bing Webmaster Tools, which has a daily quota, and record the stored document size so you can see the moment it changes. If whole groups of pages stay empty for months, our guide to Bing pages that are indexed but not served covers the support route.
How Long Is Normal?
There is no published waiting time, so the honest answer comes from your own data. On our sites this autumn, Google indexed some new guides within days and left others unknown for more than five weeks, on the same site, in the same sitemap. A small blog of ours had two of twelve new entries shown in Google within about two weeks. Bing was slower across the board: guides published in September were stored between six and nine weeks later, and nothing published in October had been stored by 10 November.
| Engine | Fast case we saw | Slow case we saw |
|---|---|---|
| Indexed within days | Unknown after five weeks | |
| Bing | Stored after about six weeks | Not stored after five weeks and counting |
Plan for weeks, not days, on a small site, and measure your own medians so you know when a page is genuinely stuck rather than merely waiting.
Requesting Indexing: What It Does and Does Not Do
The request indexing button in Google's URL Inspection tool asks Google to crawl the address soon. It has a daily quota, it does not promise indexing, and pressing it repeatedly for the same unchanged page adds nothing. Use it once for each new page that is still unknown after a few days, and again only after a real change. Google's separate Indexing API is documented for job posting and livestream pages, not general articles, so it is not a shortcut for blog posts. Bing Webmaster Tools has its own request button with its own quota, and IndexNow notifies Bing and other participating engines directly.
Internal Links That Actually Count
Not every link is an equal invitation. A link from the homepage or a site wide footer is seen on every crawl. A link from a popular article that search engines revisit often is seen within days. A link from a paginated blog index is seen until the page scrolls off the first screen of the index, and then much less. When a new page matters, give it at least one link of the first two kinds.
What Not to Do While You Wait
Rewriting the page repeatedly
Each edit gives the engine a new version to judge and resets nothing in your favour.
Changing the address
A new address starts the queue again and leaves a redirect behind.
Resubmitting every day
Repeated requests for the same unchanged page add nothing.
Assuming a penalty
Most unindexed new pages are waiting, not punished. Check the old pages are still indexed before concluding anything.
A Two Week Checklist for Every New Page
| When | Check | Action if it fails |
|---|---|---|
| Launch day | Page answers 200, self canonical, no noindex, in the built sitemap | Fix before announcing |
| Launch day | New address appears in the submission log | Submit it by hand |
| Launch day | At least one link from a frequently crawled page | Add one |
| Day 3 | Google status: unknown, discovered or indexed | Request indexing if unknown |
| Day 7 | Bing: discovered date and stored size | Request indexing in Bing |
| Day 14 | Both engines again | Strengthen links; do not rewrite |
The technical SEO checklist has the launch day checks in more detail.
The Bottom Line
New pages wait in queues you cannot see, and the engines do not treat every page in a sitemap the same. Find the exact status in each engine, give the page a real way in from a page that is crawled often, keep sitemap dates honest, make sure your submissions read the file you actually built, and then stop touching the page. On our own sites the pages that waited longest were not the weakest ones. They were the ones with only one link, in sitemaps that claimed everything was new.