Bing Crawled It and Stored Nothing

01Allowed to crawl, not allowed to index

A few hours after three new guides went up on the agency site, I opened Bing's inspection tool on one of them. It said the page had been discovered that day, crawled, fetched successfully, and that indexing was not allowed. The index step was a red cross and the canonical address was blank. Across the top, in red: this address cannot appear on Bing. A message like that makes you assume you broke something. A successful crawl is not an indexed page. It is a visit.

Nothing on the page said no

So I checked the page the way the crawler saw it. The server log shows Bing's crawler fetching it at 21:26 UTC with a normal 200 response, the full page, the same bytes a person gets. The page declares index and follow, points its canonical at itself, and carries no noindex in its markup or its response headers. Nothing on our side told Bing to stay away. The blank canonical is a consequence, not a cause: Bing only fills it in after it has indexed a page, and it had not.

02Eighty three stored, seventeen empty

Asking Bing what it actually keeps

One page is an anecdote, so I asked Bing's webmaster API about every address in the sitemap. For each page it reports when it was discovered, when it was last crawled and how large the stored document is. A hundred pages answered before the API started throttling. Eighty three had a stored copy; an older guide that ranks well sits there at 193,459 bytes. Seventeen had a size of zero, and the zeros were not random. They were the newest articles: one from late August, four from September, the three from early October, the three published that day. Two had never been discovered at all, weeks after going live, although every deploy announces new addresses through IndexNow and the sitemap lists them all. Being announced is not the same as being wanted.

Not a ban, a queue

This is not the domain level suppression I fought on another site in the spring, where pages stayed indexed and simply stopped being shown. Here the old pages are stored and the domain is served. Two September articles had made it in. Bing crawls new pages quickly and decides about them slowly, and the decision is the part nobody shows you. The gap between being read and being kept is the same gap I measured from the other side in indexed, not quoted.

03Where ChatGPT looks first

Bing is the door to the answers

This would be a footnote if Bing were only Bing. It is not. ChatGPT's search leans on Bing's index, and Copilot is built on it, so a page Bing has crawled but not stored is a page those assistants are unlikely to find when they search on someone's behalf. The October guides were written for exactly those readers. For assistant visibility, the index that matters is the one the assistant searches, and on many of them that is Bing. The pattern behind it, an index deciding which pages count, is also why seventy five impressions said to measure the first gate before anything else.

What I am doing, and not doing

Not editing the pages. Changing a page Bing has not judged yet only resets the clock. Requesting indexing through the inspection tool for the newest and the never discovered ones, which is harmless and has a daily quota. Recording the stored size of every page now, so I can see when each one flips from zero. And setting a date to check again, about a week out, with a support ticket ready if the September articles are still empty by then. Write down what the index holds today, or you will never know how long it took to change. The habit of recording the before is the one I neglected in the cache that hid my crawlers.

Tomorrow: the week ChatGPT traffic vanished from my analytics, and why it was never really gone.