# Google supplier unit: 418 of 1,419 sites gave a crawler no words to read > Google documents three Search features for the European Economic Area, and they are opened by three different things: an approved data feed, an interest form, and nothing but an ordinary crawl. Lantad measured the one site-side condition the Google supplier unit names across all 1,419 hostnames in this repository's two committed corpus seed files on 16 October 2026. 347 delivered no HTML at all and 71 of the 1,072 that did delivered zero words, so 418 gave a plainly identified crawler nothing to read. - Canonical page: https://lantad.co/blog/google-supplier-unit-418-of-1419-gave-a-crawler-no-words - This file: https://lantad.co/blog/google-supplier-unit-418-of-1419-gave-a-crawler-no-words.md - Last substantive update: 2026-10-16 ## Key facts - **Published:** 2026-10-16 - **Category:** Findings - **Author:** Lantad - **Length:** 3893 words - **Takeaway 1:** Google's supplier unit documentation, carrying a last updated stamp of 2026-09-18 UTC and read at source on 16 October 2026, states that a direct provider does not need to provide additional data beyond what is accessible through web crawling, which makes being crawlable the only condition it names that sits on the site itself. - **Takeaway 2:** The aggregator unit documentation carries the same 2026-09-18 UTC stamp and names a different route entirely: approval as a Vertical Search Service, an interest form for the relevant query type, and a direct data feed integration or real-time API. Nothing a provider publishes on its own pages enters that unit. - **Takeaway 3:** The ecosystem carousel documentation, last updated 2026-09-08 UTC, states in its own note that no new structured data markup or special feeds are required for the feature, and then adds an interest form and an authoritativeness requirement that no markup can satisfy. - **Takeaway 4:** Lantad measured the one site-side condition the Google supplier unit names on 16 October 2026 across 1,419 corpus hostnames as LantadBot/1.0: 347 delivered no HTML, led by 227 HTTP 403 responses, and 71 of the 1,072 that did answer with HTML delivered zero extracted words. 418 of 1,419 therefore gave the crawler no words at all. - **Takeaway 5:** The strata closest to the supplier unit's stated audience of brick-and-mortar direct providers were the most readable in the corpus: of 160 local media, Wix, Squarespace, Framer and Webflow hostnames, 157 served a readable home page and 7 gave a crawler no words, against 64 of 130 travel hostnames. ## Summary Most of what gets written about appearing in a search feature is advice about your pages. Add the markup, write the heading, fill in the fields. That advice assumes the feature reads your pages, and it is worth checking the assumption before acting on it, because Google now documents three Search experiences for the European Economic Area and they do not all read your pages at all. One of them is populated from a data feed you have to be approved to submit. One requires an interest form and a judgement about whether you are an authoritative source. And one, the [supplier unit](https://developers.google.com/search/docs/appearance/supplier-unit), says in a single sentence that it needs nothing beyond what an ordinary crawl can already reach. That sentence is the only site-side requirement in the set, and it happens to be the exact thing this scanner measures. So this post does two things: it reads all three documentation pages at source and sets out what actually opens each one, then it measures that one condition across the 1,419 hostnames in this repository's committed corpus. If you want the single page version of the same question, [what GPTBot sees](https://lantad.co/tools/what-gptbot-sees) renders the text a crawler gets from one URL. ## What is the Google supplier unit, and what does it ask of your site? The supplier unit is described on its own documentation page as a dedicated feature for direct providers, and the page gives examples: individual hotels or airlines, brick-and-mortar business owners, and providers of services such as plumbing. It appears alongside the aggregator unit, and the page is explicit that it only appears if the aggregator unit appears. Availability is stated as the European Economic Area, for queries related to hotels, flights, long distance trains or buses, products, and local businesses. Then comes the sentence that makes this feature different from almost everything else in Google's appearance documentation. Under the participation requirements, a note states that you do not need to provide additional data beyond what is accessible through web crawling to appear in this feature, and adds that supplier results can be enhanced with data feeds if available. Read carefully, that is a statement about a channel rather than about quality. The feature is fed by the crawl. The feed is an optional enhancement on top. The rest of the requirements are facts about your business rather than facts about your site: your website must serve users in the European Economic Area, and your business must be a direct provider that could appear for one of those query types. Neither of those is something a scanner can check, and neither is something you can change by editing a template. So the requirement list reduces to one checkable item. Everything else is either a property of your company or an optional extra. That is unusual enough to be worth stating plainly, because it inverts the normal shape of advice about search features. There is no markup to add here. There is no property to fill in. There is a condition that most site owners assume is already met, and the rest of this post is about how often that assumption is wrong. The vocabulary for the parts of this that a scanner can see is on the [AI crawler](https://lantad.co/glossary/ai-crawler) and [AI visibility](https://lantad.co/glossary/ai-visibility) glossary pages. ## Three EEA features, and only one of them is opened by your own pages Reading the three pages together is the fastest way to see how little of this is an on-page problem. All three were opened at source on 16 October 2026 and all three were reached from Google's own [documentation updates feed](https://developers.google.com/search/updates), whose 18 September 2026 entry records local business query support being added to both units and whose 8 September 2026 entry records the regional differences documentation being added. The [aggregator unit](https://developers.google.com/search/docs/appearance/aggregator-unit) is the one with the longest requirement list and the least to do with your markup. Businesses are eligible when they are approved as a Vertical Search Service, provide the necessary data, and meet quality standards. The data arrives through direct data feed integrations or real-time APIs, and the page routes you to separate feed documentation depending on whether the query is about lodging, ground transportation, flights, products or local businesses. Two interest forms cover the set: one for ground transportation, flight, hotel and local business queries, and the comparison shopping services contact form for product queries. A site that publishes immaculate markup and submits no feed is not in this unit, and no amount of on-page work changes that. The [ecosystem carousel](https://developers.google.com/search/docs/appearance/ecosystem-carousel) is the most direct about it. Its requirements are that your website serves users in the European Economic Area, that it publishes relevant finance, weather or sports information or provides translation, and that it is an authoritative source or specialized provider in its domain. Then a note states that no new structured data markup or special feeds are required for this specific feature. That is a vendor telling you, in its own documentation, that the thing many readers would reach for first is not the lever. It is the same shape as the finding in [the five GEO tactics Google says you can ignore](https://lantad.co/blog/google-names-five-geo-tactics-to-ignore), and it is worth taking at face value rather than hedging against. Set beside those two, the supplier unit is the only one of the three whose stated input is the crawl. That makes it the only one of the three where a scanner can tell you anything useful at all, and it is also the one aimed at the smallest businesses in the set. The asymmetry is the finding: the feature for large aggregators is gated behind a commercial integration, and the feature for the individual hotel and the plumber is gated behind nothing but being readable. ## How the one condition was measured, and what the measurement cannot settle The capture ran on 16 October 2026 over the 1,419 hostnames in this repository's two committed corpus seed files, 392 sampled by the platform a site is built on and 1,027 by industry, with no overlap between the two files. Every hostname was asked for /robots.txt first, as LantadBot/1.0, and each file was parsed with this scanner's own parseRobotsTxt with the root verdict computed by its evaluateRobots. 1,390 of the 1,419 returned some status for the file and 1,017 served a file that parsed into at least one group. 12 of those files disallowed LantadBot at the root, and those 12 home pages were not requested. Every other home page was fetched once, redirects followed, no JavaScript executed and no browser involved, and the body was read with the extractor in this repository's core library. The full procedure is on the [methodology](https://lantad.co/methodology) page and the user agent is documented on [LantadBot's own page](https://lantad.co/bot). Three things this measurement does not establish, and they matter more than the figures. It does not establish that any of these hostnames serves users in the European Economic Area, which is a requirement on all three features and is not visible in a home page. It does not establish that any of them is a direct provider rather than an aggregator, which is the other requirement, and the corpus was never sampled for that distinction. And it does not observe any search result: no claim here is about what Google did or did not show anyone. What it measures is the single condition the supplier unit documentation names about the site, applied to a large set of real sites, which is a different and narrower thing than eligibility. It is also worth being exact about which crawler this is. LantadBot is not Googlebot, and a site that refuses one may well serve the other. The reading that survives that objection is the weaker and more useful one: these are sites whose servers refuse a plainly identified, documented, well behaved crawler that obeys their robots.txt, and that is a property of the server's configuration rather than of Google. Where the two diverge we have measured it before, in [the 103 sites that served an unknown bot and refused GPTBot](https://lantad.co/blog/cdn-blocking-ai-crawlers-103-of-1089). The [robots.txt tester](https://lantad.co/tools/robots-txt-tester) runs the file half of this check against a single host. ## 347 of 1,419 sites delivered no HTML to a crawler at all The largest single failure of the crawlability condition is not subtle and needs no interpretation: the server refused. 227 of the 1,419 hostnames answered the home page request with HTTP 403. In all 227 cases this scanner's robots evaluation left LantadBot allowed at the root, so nothing in the file explained the refusal. 56 of the 227 had served a robots.txt that parsed into at least one group, which means they went to the trouble of publishing crawl rules and then overrode them at the edge; the remaining 171 served no usable file at all, which is its own kind of silence. We have measured that same gap from the other direction in [the 79 of 115 sites that refused a crawler their robots.txt allows](https://lantad.co/blog/is-my-site-blocking-ai-crawlers-79-of-115). Sixty seven of the 227 were re-requested the same day, up to eight from each of the ten strata where a 403 occurred, and 63 returned 403 again. Three answered 200 on the second attempt, those being getdianahr.com, aucegypt.edu and canadiantire.ca, and one, banorte.com, answered 503. So about one refusal in seventeen was transient rather than settled, which is the point of re-reading them: a 403 that flips is rate limiting wearing the wrong status code, and a 403 that holds is a policy. On that sample the stable share of the 227 is roughly 94 percent, and the 227 itself is a single-pass count. Below the 403s the tail is varied and mostly unhelpful to a crawler in the same way. 51 hostnames answered 503 on the home page, the status a server uses to say it is temporarily unavailable. On robots.txt specifically a 503 is read as blocking every crawler, which we have written about as [the opposite of a 404](https://lantad.co/blog/robots-txt-404-and-503-are-opposites), but these 503s were on the page rather than the file. 29 produced no response at all: a DNS failure, a TLS failure or a timeout before any status arrived. 12 disallowed the crawler in robots.txt, which is the only one of these outcomes that is a deliberate, documented choice made in the right place. Then 9 answered 202, 7 answered 429, 5 answered 404, and single figures spread across 406, 401, 400, 498 and 500. The distribution across the corpus strata is where this stops being a general observation about the web and starts bearing on the features above. News is the extreme case: 60 of 128 news hostnames answered 403, and news sits in the ecosystem carousel's territory rather than the supplier unit's. Travel, which is the aggregator unit's heartland, refused 32 of 130. Ecommerce refused 48 of 130. Against those, the strata built on site builders and no-code platforms refused almost nobody, which is the inverse of what a reader who equates small sites with technical neglect would expect. Earlier corpus work is collected on the [research](https://lantad.co/research) page. ## 71 readable home pages carried no words at all A 200 and an HTML content type is not the condition. The condition is that the content is accessible, and content that arrives as an empty shell is not. 71 of the 1,072 pages that answered HTTP 200 with HTML yielded zero words from this repository's extractor. 87 yielded ten words or fewer, 119 yielded fifty or fewer, and 167 yielded a hundred or fewer, against a median across the whole readable set of 563 words. Twenty five of the zero-word pages were re-fetched the same day and all 25 came back at zero, so this is the steady state of those pages rather than a bad moment. What the zero-word pages have in common is the rendering model, not the industry. Ten of the 71 are in the no-code stratum and five more in the single-page-application stratum, where the words exist in a browser and are assembled by JavaScript the crawler never runs. That failure has its own measurements here already, in [the 10 of 42 no-code home pages that served a crawler zero words](https://lantad.co/blog/no-code-seo-10-of-42-served-zero-words) and in [the 11 of 271 pages where JavaScript supplied all of the prose](https://lantad.co/blog/client-side-rendering-11-of-271-returned-no-words), and the vocabulary for it is on the [prose parity](https://lantad.co/glossary/prose-parity) page. The remaining 56 are spread across eleven further strata, led by travel with 11, ecommerce with 10, education and healthcare with 8 each, finance with 7 and government with 5. Put the two halves together and the arithmetic is simple. 347 delivered no HTML and 71 delivered HTML with nothing in it, so 418 of 1,419 hostnames gave a plainly identified crawler no words. That is the one site-side condition the supplier unit documentation names, failed by 29.5 percent of this corpus, on a measurement taken from outside with no privileged access to anything. The more interesting number is the one that runs the other way. Group the strata by the business kinds the units name and the supplier unit's own stated audience comes out best. Across 160 hostnames in the local media, Wix and Squarespace, Framer and Webflow strata, which is where the corpus's brick-and-mortar and small service businesses sit, 157 served a readable home page and only 7 gave a crawler no words. The travel stratum, by contrast, gave no words on 64 of 130, and the combined finance and news strata on 110 of 255. The feature designed for the plumber is the one whose audience is already passing its only test, and the stack-specific guidance for two of those platforms is on [the Framer guide](https://lantad.co/fix/framer) and [the Shopify guide](https://lantad.co/fix/shopify). ## The attributes Google asks aggregators for do not live in your markup The aggregator unit page closes with best practices, and reading them next to a corpus of real markup is instructive. It encourages rich entity details where available: images of the entity, detailed descriptions and specifications, verified user ratings and review counts, specific categories such as boutique hotel rather than a generic hotel, and key amenities, features and operating hours. It asks for factual titles in title case and warns against all caps, excessive punctuation, emoji and promotional text such as best deals. It asks that prices and availability in feeds match the landing page. Every one of those attributes has a schema.org counterpart that a site can publish on its own pages, which makes the comparison tempting and makes it important to say what it does and does not show. For the aggregator unit the markup is not the channel: the data arrives by feed, so a page that declares an [opening hours specification](https://schema.org/OpeningHoursSpecification) is not thereby closer to that unit. What the corpus does show is how thinly those attributes exist on pages at all, which bears on every other surface that does read pages, including the supplier unit and the [Google AI Overviews](https://lantad.co/how-to-get-cited/google-ai-overviews) path. Across the 1,072 readable home pages, 254 declared an ImageObject node, 61 declared a node typed LocalBusiness itself, 33 declared an AggregateRating and 28 declared an OpeningHoursSpecification. The sparse end of that list is the end Google's best practices lean on hardest. We have measured each of these separately and found the same pattern each time: [685 of 943 ImageObject nodes carried nothing but a URL and a size](https://lantad.co/blog/imageobject-schema-685-of-943-nodes-url-and-size), and [2 of 172 home pages carried opening hours a machine could read](https://lantad.co/blog/localbusiness-schema-two-of-172-carried-hours). Google's own [local business structured data documentation](https://developers.google.com/search/docs/appearance/structured-data/local-business), last updated 2026-09-08 UTC, requires only a name and an address, and lists the rest as recommended, so the thinness is not non-compliance. It is just absence. Which leaves the practical reading of the whole set, and it is not the reading an [AI visibility](https://lantad.co/glossary/ai-visibility) vendor would choose. For two of these three features there is nothing to build. For the third, the work is not adding [structured data](https://lantad.co/glossary/structured-data); it is making sure a crawler receives the page at all, which 418 of 1,419 real sites currently do not manage. That is a dull conclusion and it is also the one the documentation supports. This scanner can tell you whether your site clears that bar, and it cannot tell you whether you serve the European Economic Area, whether Google considers you a direct provider or an aggregator, or whether a feed you submit is any good. For the first two features on that list, a scanner is the wrong tool and a conversation with Google is the right one. ## Questions and answers **What is the Google supplier unit?** The supplier unit is a Google Search feature for direct providers such as individual hotels, airlines, brick-and-mortar businesses and service providers like plumbers. Its documentation, last updated 2026-09-18 UTC, says it appears to users in the European Economic Area for queries about hotels, flights, long distance trains or buses, products and local businesses, and that it appears only when the aggregator unit also appears. **Do I need structured data to appear in the supplier unit?** Google's supplier unit page does not require it. It states that you do not need to provide additional data beyond what is accessible through web crawling, and that supplier results can be enhanced with data feeds if available. The ecosystem carousel page goes further and states that no new structured data markup or special feeds are required for that feature. **How is the aggregator unit different from the supplier unit?** The aggregator unit is for Vertical Search Services such as online travel agencies, comparison shopping services, metasearch engines and directories, and its documentation requires approval as a Vertical Search Service, an interest form and a direct data feed integration or real-time API. Nothing published on a provider's own pages enters it. The supplier unit is for direct providers and is fed by the ordinary crawl. **How many sites actually fail the crawlability condition?** In Lantad's measurement of 1,419 corpus hostnames on 16 October 2026, 418 gave a plainly identified crawler no words at all: 347 delivered no HTML, of which 227 answered HTTP 403, and 71 of the 1,072 that did answer with HTML delivered zero extracted words. That is 29.5 percent of the corpus failing the only site-side condition the supplier unit names. --- Lantad measures whether AI crawlers can actually read a page: it fetches as a non-rendering crawler, renders as a browser, and reports the gap. Free scan, one URL, no signup. Method and weights: https://lantad.co/methodology | All pages as markdown: https://lantad.co/md | Crawler policy: https://lantad.co/bot