LocalBusiness schema: 2 of 172 home pages carried opening hours a machine could read

What we asked, and what answered

The sample is the industry sampling frame committed to this repository at worker/seeds/corpus-seeds-industry.json, generated on 3 August 2026. Two of its eight sectors were used: healthcare at 123 hostnames and travel at 130, which is 253 in total. The frame is weighted toward large organisations rather than being a random sample of the web, so every figure below describes those 253 and nothing wider. It holds national health services and hospital groups on one side and airlines, hotel chains, booking platforms and restaurant groups on the other.

Each hostname was asked once for https://host/ as LantadBot/1.0, the user agent documented on our bot page, with redirects followed, a 25 second timeout and no JavaScript executed. That last condition is the point rather than a shortcut: it is what a crawler that does not run a browser sees, and the gap between that and the rendered page is what prose parity exists to measure.

172 of the 253 answered with a 2xx status and an HTML content type, 95 of them healthcare and 77 travel. Everything else was a refusal or a failure: 47 responses of 403, 19 of 503, eight requests that failed at the transport layer, and one each of 400, 401, 404, 405, 406, 429 and 500. The refusals fell more heavily on travel, which returned 29 of the 403s against healthcare's 18. This is the same wall we walked into when we found that 79 of 115 sites refused a crawler their own robots.txt allows, and it is a standing limit on any measurement taken from outside: a third of this sample never showed us anything.

Two more honesty notes belong here rather than in a footnote. One of the 172 was booking.com, which answered HTTP 202 with a 3,962 byte interstitial rather than a home page. Six more returned bodies under 1,000 bytes, the smallest being irishrail.ie at 92 bytes, which cannot contain a page either. All seven are counted in the 172 denominator and none of them carried any of the fields below, so they make every positive figure in this post slightly conservative rather than inflating one.

What LocalBusiness schema has to carry

Two documents define the target, and they are worth separating because they ask for different amounts.

The first is the vocabulary itself. The schema.org definition of LocalBusiness is a type for a particular physical business or branch of an organisation, and it sits under both Organization and Place. Reading schema.org's current vocabulary file on 14 September 2026 gives 131 types in that branch, counting LocalBusiness itself and the 130 more specific types beneath it: Hospital, Hotel, Restaurant, TravelAgency, Dentist, DaySpa, Store and its own subtree of shop types, and so on down. The branch is deep because the vocabulary expects a business to name what kind of business it is.

The second is what one consumer of that vocabulary actually asks for. Google's local business structured data documentation, carrying a last updated stamp of 8 September 2026, requires exactly two properties: name and address, where address must be a PostalAddress. Everything else is recommended, and the recommended list includes geo, openingHoursSpecification, telephone, priceRange, url, aggregateRating and review. The same page states, in its own words, "Use the most specific LocalBusiness sub-type possible; for example, Restaurant, DaySpa, HealthClub, and so on." It also says the markup can go on any page of a site, though it may make more sense on a page that carries information about the business.

Note what that documentation is for. It describes eligibility for a Google rich result, not for an AI answer, and no AI crawler operator publishes an equivalent list of required properties for its own answers. So the honest frame for the rest of this post is that Google's list is the only published specification of what a complete place record looks like, and we are using it as a yardstick rather than as a promise. Nothing here establishes that filling it in gets a business recommended by anything.

What it does establish is a floor. A page that carries none of these fields has not made the claim at all, in any form, to any consumer. That is a fact about the page rather than a prediction about an engine, and it is the only kind of fact a scan from outside can produce.

What 172 home pages actually carried

82 of the 172 pages carried at least one JSON-LD script, and between them those 82 shipped 144 blocks. Four of the 144 did not parse as JSON and were discarded, which is the same small persistent failure rate we found when eight of 442 blocks would not parse on a wider corpus, and it matters more than its size suggests: a block that does not parse is not partially read, it is skipped whole.

Counting by how many pages carry each type, the shape of what does get published is clear. WebSite appears on 46 pages and Organization on 44, which between them are the two types that describe a brand rather than a place. PostalAddress appears on 27, ImageObject on 25, SearchAction on 23, WebPage and ContactPoint on 21 each. MedicalOrganization appears on eight and Hospital on four. Everything in the LocalBusiness branch, across all 131 types, appears on ten pages in total.

The field level counts are the finding. 25 of the 172 carry a non-empty streetAddress somewhere inside their JSON-LD. 31 carry a telephone, and ten of those 31 carry a phone number with no address attached to it. Two carry geographic coordinates. Two carry opening hours. Not a single page in the sample used microdata for any of this: no itemprop naming streetAddress, no itemtype naming LocalBusiness, Hotel, Restaurant, Hospital, Dentist, Physician or Store. The whole of the machine readable place data in this sample lives in JSON-LD or nowhere.

For contrast with what the same pages do publish, 48 of the 172 carry an href beginning tel:. That is a phone number the site has gone to the trouble of making clickable for a human on a phone, on a page that never states in a typed field who or what that number belongs to. The gap between 48 and 31 is not laziness. It is a site optimising for the reader it can see.

One page in the whole sample carried the full record: dishoom.com, a restaurant group, publishes a Restaurant node with a street address, a telephone, an openingHoursSpecification and GeoCoordinates together. Being the only one is the result. This is the same pattern we recorded in the audit of 70 of 146 structured data values that pointed off the page: markup is present in the market, and it describes the organisation rather than the thing a reader wants.

The address that is there is usually attached to something that is not a place

25 pages carry a street address, which on its own reads like the least bad number in this post. It survives one further question badly.

We went back to those 25 the same day and recorded which node the address hangs off, since an address is a property and a property belongs to something. On six of the 25 it belongs to a type inside the LocalBusiness branch: Hospital on helios-gesundheit.de, GovernmentOffice on inserm.fr, Restaurant on dishoom.com, TravelAgency on edreams.com, Hotel on meininger-hotels.com and a bare LocalBusiness on wagamama.com. On the other 19 the owner is Organization, NGO, Corporation, MedicalOrganization, Place, Airline or AdministrativeArea.

None of those 19 is wrong in vocabulary terms. Organization genuinely has an address property, and a corporate headquarters genuinely has an address, so a validator would pass every one of them. What they are not is the claim Google's documentation describes, which asks for the most specific LocalBusiness subtype available. The difference between "this company's registered office is at this address" and "this is a place you can go to, and here is when it is open" is the entire difference between a company record and a place record, and the vocabulary marks it with the type rather than with the fields.

MedicalOrganization is the sharpest case, because it looks like the right answer and is not. It sits under Organization in the schema.org hierarchy and not under LocalBusiness, while Hospital, which sits beneath MedicalOrganization, is also a CivicStructure and does reach the LocalBusiness branch. Two hospital groups in this sample publish a MedicalOrganization with an address, which is a reasonable reading of the vocabulary and lands one level short of the type a local result asks for. That is a documentation problem rather than a negligence problem, and it is the same class of near miss as an author node that names a person the page never shows.

So the count that matters is not 25 of 172. It is six of 172 pages that make a place claim in the form the only published specification asks for. The other 19 have published something true about a company, and the difference is invisible to anybody who checks whether markup is present rather than whether its syntax and typing carry the meaning.

One click further, and the contact page added nothing

There is an obvious objection to everything above, and it is a fair one. A hotel chain's home page is not a hotel. A hospital group's home page is not a hospital. The place record, if it exists, would sensibly live on a locations page or a contact page, and Google's documentation explicitly allows the markup to sit on whichever page carries the business information.

So we followed the link. For each of the 172, we parsed the home page for internal links whose path or anchor text named contact, locations, a store locator or their German and Spanish equivalents, ranked them so that a path ending in /contact or /locations beat a partial match and a careers or press page was pushed to the back, and fetched the single highest ranked candidate. 57 of the 172 had no such link at all in the raw bytes. Of the rest, one answered with a PDF, one answered 403 and two answered 404. 111 returned an HTML page.

37 of those 111 carried JSON-LD. Three carried a street address, and all three, icmr.gov.in, rivm.nl and rki.de, had already published the same address on their home page. One carried a type from the LocalBusiness branch. None carried opening hours. None carried geographic coordinates. Not one of the 111 contact or locations pages added a single place field that its own home page was missing.

The honest limit on that second pass is that we followed one link per site, chosen by pattern rather than by judgement, so a site whose place records live three clicks deep behind a search form was not reached and is not described by this figure. That is a real constraint and it points at a real property of the pages: a place record behind a form is a place record a crawler that does not fill in forms will not retrieve, which is the same shape of problem as the home pages that arrive through a redirect before any content is sent. What we can say precisely is narrower and still worth saying: the obvious path a crawler would take, from the home page through the site's own contact link, reached no new machine readable place data on any of 111 sites.

If you want to see the same thing on one page of your own, the raw view of what a crawler receives shows the bytes before any script runs, which is where every count in this post was taken from.

What this does not measure

Every figure above describes markup on a page. None of it describes an answer, and the distance between the two is where most writing on this subject goes wrong.

We did not observe any AI crawler fetching any of these sites. No access log was read. Nothing here shows that a missing openingHoursSpecification cost a business a recommendation in ChatGPT or in Google's AI Overviews, and nothing shows that adding one would win a recommendation either. An answer engine asked where to eat tonight has licensed directories, map data and review corpora available to it, and a business's own markup is one input among several whose weights nobody outside those companies knows. The audit that put structured data third behind two other factors is the closest published evidence on that question and it is somebody else's study, not ours.

The sample is also narrow by construction. 253 hostnames from two sectors of one frame, weighted toward large organisations, asked once from one network on one day. A single home page says nothing about the rest of a site. A 403 is a bot defence answering rather than a statement about markup, and 47 of them means a quarter of the sample was never seen. Any of these sites could publish a complete place record on a location page we did not reach.

What the measurement does support is narrow and solid. Among organisations that occupy buildings, the fields that would let a machine state an address, a phone number and an opening time were absent from the great majority of home pages on 14 September 2026, absent from the contact pages those home pages linked to, and present in complete form on one site in 172. That is a statement about supply, and the useful thing about a supply measurement is that it is actionable without any claim about demand: whatever weight an engine puts on a place record, a business that has not published one is not in the running to have it weighted.

If you want to check your own site against this rather than against an average, what we count and how we count it is written down, and the wider set of measurements behind these posts is published alongside it. The work of adding an address, a telephone and an opening hours specification to one page is an afternoon. Two sites in 172 had done the last of those.