Google fetched 5 of our 32 pages in 42 days. Bingbot fetched 27 of them in two.

The setup

WashDash is a booking marketplace for mobile pet grooming and car detailing in the Greater Toronto Area. The domain went live on 2026-07-16 with no prior history: no redirected legacy site, no expired-domain purchase, no existing brand searches.

By the end of the window the sitemap carried 32 URLs. Every one of them returns 200, is allowed by robots.txt, is self-canonical, and is indexable. Nineteen of them are prose pages with a median of 901 words; none falls under our 400-word thin threshold, and all 19 carry Article or FAQPage structured data. The property is verified in Search Console as a domain property, the sitemap was submitted on day one, and an IndexNow key has been live and posting since launch.

In other words: the ordinary checklist was done, and done early. What follows is what happened anyway.

Google's side: a 100% index rate on a 16% fetch rate

We ran the Search Console URL Inspection API against all 32 sitemap URLs. The result is not the shape people usually expect from a struggling new site. Google did not crawl our pages and reject them. Google did not crawl our pages.

Of the 6 URLs Google has ever fetched (the 5 in the sitemap plus one off-sitemap page), 6 are indexed. The pages Google reads, Google keeps. The other 27 sitemap URLs have never been fetched a single time, and 17 of them are not in Google's URL list at all — the inspection API's answer for those is that the URL is unknown to Google.

The fetches that did happen are clustered, not spread. Across 42 days, the last-crawl dates of every URL Google has ever fetched fall on just four calendar days — 16 and 17 July, 2 August, 10 August — and the newest fetch of any page was 17.5 days before this study was published. That is not a slow crawl rate. That is a handful of visits and then near-silence.

Google downloads the sitemap. It just doesn't act on it.

The obvious first theory is that Google never got the list. It got the list, repeatedly. We logged 15 distinct downloads of sitemap.xml by Google during the window, 13 of which came more than six hours after any resubmission of ours — that is, on Google's own schedule, unprompted.

So on days when Googlebot fetched no page at all, it was still downloading a file listing 32 URLs, zero errors, zero warnings. The submitted-URL count in Search Console has read 32 the whole time. Google is not missing the URLs. It is holding them and declining to spend crawl budget on them.

The practical consequence, which cost us several weeks to accept: resubmitting a sitemap is not a lever. We tried it. The crawl pattern did not change, and the download that followed our last submission was one Google was going to make anyway.

Bing's side: the same 32 URLs, most of them read, in about two days

Because Search Console only tells you what Google did, we built a second reading from the other end: our own CDN request log, sampled continuously and classified by user agent. It sees every crawler that touches the origin, not just Google's.

In roughly 49 hours of observation at 64% time coverage, Bingbot fetched 27 of our 32 sitemap URLs, plus three paths that are not in the sitemap at all. Most of the 27 are URLs Googlebot has never fetched once in six weeks. We also logged YandexBot and DuckDuckBot at the origin. Because our coverage is partial, 27 is a floor, not a total.

The mechanism is not mysterious and it is not about content quality. IndexNow — the push protocol Bing and Yandex both consume — accepts a POST of every URL we publish, and we have been posting. Google has never joined IndexNow, and its only per-URL equivalent is the manual Request Indexing button in Search Console, which has no API. We can push to one index and not the other, and the crawl logs show exactly that split.

What we ruled out, and how

Every standard explanation for a new site not being indexed was tested against a reading rather than a hunch, and every one of them came back clean.

Robots and directives: 0 of 32 URLs blocked, 0 with a noindex we did not intend. Canonicals: 0 mismatches between our declared canonical and Google's chosen one. Rendering and status: all 32 return 200 to a live fetch, and Google's own fetch state on every URL it tried is SUCCESSFUL — no soft 404s, no fetch failures. Thin content: 19 prose pages, median 901 words, none below our 400-word floor, structured data on all of them.

The strongest evidence against a quality explanation is the index rate itself. If Google were reading these pages and judging them poorly, we would see fetched-and-not-indexed. We see the opposite: 100% of what it read, it kept. The pages are unread, not rejected.

What is left is the thing we never did. After 42 days we have not recorded a single inbound link: no directory listing has gone live, no partnership link has landed, and we have never placed one. A brand-new domain with no inbound links generates almost no crawl demand, and crawl demand is what everything above is really measuring. We would rather name that as the likeliest explanation than dress it up as a proven cause — it is the one input we have not tested, because it is the one we have not yet supplied.

What we'd tell someone launching a new domain tomorrow

Instrument the crawl before you write the content. We spent weeks improving pages that no crawler had fetched, because Search Console's coverage report tells you a URL is 'Discovered — currently not indexed' without telling you the far more useful fact that it has never been fetched at all. The URL Inspection API does tell you that, per URL, and it changes what you do next.

Read your own origin log, not only Search Console. Half the findings on this page do not exist in Google's tooling, because they are about crawlers that are not Google.

Do not spend a second week on sitemap resubmission. If the sitemap has been downloaded and shows zero errors, the list has been delivered and the decision not to crawl is being made downstream of it.

And treat links as the crawl-budget input they are, not as a ranking nice-to-have you get to later. We had good pages and no links, and the crawl log is what that combination looks like from the inside.

How this was measured

1. Google-side figures come from the Search Console URL Inspection API run against every URL in the live sitemap, using a service account on the sc-domain:washdash.ca property. Each URL is read individually; the run on 2026-08-26 read 32 of 32 with zero inspection failures.
2. Sitemap download counts come from the Search Console Sitemaps API, recorded once per day. We count a download as unprompted only when it happened more than six hours after any resubmission of our own; downloads inside that window are attributed to us and excluded from the unprompted figure.
3. Crawler figures come from our own Vercel request log, read continuously and grouped into observation windows. Each window records how much wall-clock time it actually covered, so every crawler figure carries a coverage percentage. The log has a one-hour retention, which is why coverage is partial rather than complete.
4. The inbound-link figure is our own accounting, not a crawl of the web: it is the count of links we have placed, been granted, or seen go live in our own backlink ledger. We do not license a third-party backlink index, so read it as 'zero recorded', not 'zero in existence'.
5. Content figures (word counts, structured-data presence) come from fetching each live URL and parsing the rendered main element.

What this does not show

• n = 1. This is one domain, one country, two service categories, 42 days. It is a case study, not a survey, and none of it should be read as a general law about how Google treats new sites.
• User agents in our origin log are self-reported and we do not reverse-DNS verify them. A request claiming to be Bingbot is recorded as Bingbot. Treat the crawler figures as claims about what identified itself, not about what was cryptographically proven.
• Origin-log coverage is partial — about 65% of the observed window — because the log we read retains one hour at a time. Every crawler count here is therefore a floor. The true number can only be higher.
• Absence of a crawler in our log is not proof it never came; it is proof we did not see it in the time we covered. In particular we have observed no AI-assistant crawler at our origin at all, and we are not claiming that means none has ever visited.
• The inbound-link count is our own ledger, not a third-party backlink index. It is a reliable 'we have never placed or received one' and not a crawl of every site on the web.
• The 42-day window ends 2026-08-27. Search Console data can be restated after the fact; figures were read on the dates given in the methodology and are not retroactively adjusted here.

Common questions

Where this data comes from

• How WashDash works for groomers and detailersThe business this data comes from: a zero-commission GTA marketplace for mobile pet grooming and car detailing.
• The WashDash care guidesThe 22 content pages whose crawl history this study is about.