Address schema markup: 203 of 1,102 home pages declared one, and 19 LocalBusiness nodes omitted the property Google requires

What does address schema markup have to carry?

Two primary documents set the bar and they set it in different places. Google's local business documentation, carrying Last updated 2026-09-08 UTC, lists exactly two required properties for a LocalBusiness, which are address and name, and lists no others as required. Its description of the address property is one sentence: the physical location of the business, include as many properties as possible. Everything else on that page sits under Recommended, including geo with its latitude and longitude, telephone, url, openingHoursSpecification, priceRange, review and aggregateRating. So for the whole LocalBusiness family the address is not a nicety that improves a result. It is one of the two things the page says the markup must have, and a node without one is incomplete by the vendor's own definition rather than by ours.

Schema.org's PostalAddress type, at version 30.1 dated 2026-09-16, defines what the address can be taken apart into. Seven properties belong to the type itself: addressCountry, addressLocality, addressRegion, extendedAddress, postOfficeBoxNumber, postalCode and streetAddress. None of the seven is mandatory, because schema.org marks nothing mandatory, which is why the Google page matters for the question of what is required and the schema.org page matters for the question of what is readable. On addressCountry it is specific about the form it wants, saying the value is recommended to be in 2-letter ISO 3166-1 alpha-2 format, for example US, while also allowing three letter codes and full country names for backward compatibility. That last clause is doing real work later in this post, because it means a full country name is permitted rather than wrong.

A third document governs the relationship between the markup and the page. Google's structured data policies, carrying Last updated 2026-07-10 UTC, state under their quality guidelines that you should not mark up content that is not visible to readers of the page, and give the example that if the JSON-LD describes a performer then the HTML body must describe that same performer. Under relevance the same page states that your structured data must be a true representation of the page content, and in its introduction it lists content referred to by the structured data being hidden from the user as a reason Google may not show the structured data at all. That rule is the one most likely to be broken without anyone noticing, because an address injected by a plugin into the head of every page is invisible to the person maintaining the footer. None of these three documents is an AI crawler vendor's document, and that gap is addressed in the last section.

How many home pages declared an address at all?

203 of the 1,102 home pages declared at least one PostalAddress node. That figure is thin on its own, so the useful denominator is not every site but the sites that bothered to name themselves at all. 514 of the 1,102 declared a node in the Organization or Place family, counting Organization and Corporation along with the LocalBusiness subtypes, the medical, government and news organisation types, and Place itself. On 283 of those 514 there was no address anywhere in the parsed graph: not as an address property on the identity node, not as a free standing PostalAddress elsewhere in the file. Those 283 are sites that told a parser who they are and not where they are, and it includes software companies whose home page names a company with no premises on it, among them crayo.ai, quartr.com, amplemarket.com and groundcover.com, though this measurement did not classify all 283 by what they sell. For a company that sells only online that is a defensible choice, which is why the LocalBusiness subset in the next section is the sharper test.

Of the 1,198 Organization and Place family nodes those 514 sites declared, 823 carried no address property, 310 carried a PostalAddress node, 57 carried a bare string and 8 carried an array. The split between a node and a string matters more than it looks. A string address is permitted, since the schema.org address property accepts text as well as a PostalAddress, but a string cannot be taken apart: badwavebrows.com publishes its address as a single value holding a street, a city, a state, a postcode and a country separated by newlines, which a parser can store and cannot query. Ten of the 57 strings were worse than that, being an empty string, published by barbaratatumlaw.com, bohobodysugaring.ca and seven others, which is a declared address property carrying no address. This is the same class of defect this blog found when it measured that 117 of 612 home pages with JSON-LD carried a defect.

The 438 nodes are also concentrated, and quoting the node count without saying so would overstate how widespread the practice is. The median site declaring an address declared exactly one, 161 of the 203 declared exactly one, and the top five sites hold 175 of the 438 between them: helios-gesundheit.de with 83, meininger-hotels.com with 41, stripe.com with 24, fibilaw.com with 14 and dishoom.com with 13. Those are hospital groups, hotel chains, a payments company listing its offices and a restaurant group listing its sites, so the long tail is a handful of multi location businesses doing the job thoroughly while most of the corpus does it once or not at all. The same shape showed up in the count of which types reach a home page at all, where 88 of the 939 types schema.org defines reached 626 home pages, and in the finding that 277 of 448 identity nodes declared no category. A site that is invisible to this check is not necessarily invisible to a search engine, which may read a Google Business Profile the site never published, but it is invisible to anything reading only the page, which is what AI visibility measures.

The 19 LocalBusiness nodes that omitted a required property

The LocalBusiness family is where the Google page stops being advice. 99 of the 1,102 sites declared at least one node in that family, 173 nodes in total, counting LocalBusiness itself along with the subtypes present in the corpus: MedicalOrganization, Restaurant, Store, FinancialService, BankOrCreditUnion, InsuranceAgency, LegalService, ProfessionalService, TravelAgency, Hotel and the rest. 19 of those 173 nodes, on 18 sites, carried no address property of any kind. Under the documented requirement that is a node missing one of its two required properties, and the list is not made up of small sites that never got round to it. It includes wellsfargo.com and dcu.org declaring BankOrCreditUnion, blackrock.com and emiratesnbd.com declaring FinancialService, newyorklife.com declaring InsuranceAgency, clevelandclinic.org, plannedparenthood.org, mediclinic.co.za, acibadem.com.tr and acog.org declaring MedicalOrganization, wagamama.com declaring Restaurant and trip.com declaring TravelAgency.

The distinction that matters for the site rather than for the node is whether an address appears anywhere else in the same page's graph. On 7 of the 18 it does, so blackrock.com, wagamama.com, dcu.org, emiratesnbd.com, acibadem.com.tr, fibilaw.com and chiro.london each publish a usable address on some other node and have only put it where the LocalBusiness node does not claim it. wagamama.com is the clearest case of that kind, declaring a Restaurant node with no address and a second LocalBusiness node carrying a complete one, both in the same file. On the other 11 there is no address on the home page at all, and that list is wellsfargo.com, clevelandclinic.org, newyorklife.com, trip.com, plannedparenthood.org, mediclinic.co.za, acog.org, kbc.com, weareelectrical.co.uk, growbatheaston.co.uk and spoondrift.studio.

Two readings of that are available and only one of them holds. The generous reading is that a national bank or a restaurant group has no single address, so leaving the property off the home page node is honest. The problem is that the type carries the obligation whichever way the business is shaped: a company with many branches and no head office address on its home page can declare an Organization instead, which requires no address, or declare the branches as separate nodes the way helios-gesundheit.de and meininger-hotels.com do. Choosing the LocalBusiness subtype is a claim to be a place, and 19 nodes made the claim without supplying the one property that locates it. The remaining 154 nodes in the family did carry an address, and 132 of the 310 nodes carrying a PostalAddress also named a telephone, which is the other half of a listing and the subject of the finding that 119 of the 191 home pages with a clickable phone number named no telephone in their markup.

The pattern of a type declared without the property that gives it meaning is the most common defect this corpus produces, whatever the type. It appeared when 2 of 172 home pages carried opening hours a machine could read on the same LocalBusiness nodes, and in the extreme when 1 of 1,093 home pages declared a Hotel and none of the 111 Hotel nodes named a check in time. What is different about the address is that Google says in one line, on a page dated six weeks before this measurement, that it is required, so there is no interpretive gap to argue about.

How complete were the addresses that existed?

Google asks for as many properties as possible and schema.org names seven. Taking the five that locate a building, which are streetAddress, addressLocality, addressRegion, postalCode and addressCountry, 200 of the 438 nodes declared all five, 174 declared four, 45 declared three, 6 declared two, 11 declared one and 2 declared none of them. The two with none are a PostalAddress node with every field either absent or empty, published by reliancedigital.in and austria.info, which is the address equivalent of the empty string described earlier: the type is present, the parser finds the node, and there is nothing in it. Read per site rather than per node the picture is better, because a site with one good address and several thin ones still answers the question: 137 of the 203 sites declared at least one complete five part address and 176 declared at least one with four parts.

Which part goes missing is consistent. addressLocality, the city, is present on 430 of the 438 nodes. addressCountry is on 416, streetAddress on 396 and postalCode on 389. addressRegion, the state or province, is present on only 223, just over half. For a European address that is often correct, since many countries have no administrative level that belongs there, so the gap is not a defect by itself. It becomes one in the United States, where the state is part of the address and where the corpus shows the field instead being folded into another: fullsteamcrossfit.com declares addressLocality as the single string Chattanooga, Tennessee, United States, putting three levels of the hierarchy into the field schema.org defines as the city or town. aiven.io does the same thing six times over, declaring six offices as nothing but an addressLocality reading Helsinki, Finland, then Berlin, Germany, then Paris, France, then Boston, MA, then Sydney, Australia, then Toronto, Canada.

Those are the cases a validator would not flag, because every value is a string and every string is populated. They matter anyway, and the reason is specific rather than general: a field that holds a city is queryable, and a field that holds a city and a country in one string has to be parsed again by whatever reads it, which is the work the markup existed to remove. A reader who wants to see what a crawler takes from their own page without guessing can use what GPTBot sees, and the per part breakdown below is the same shape of evidence this blog published when it found that 685 of 943 ImageObject nodes carried nothing but a URL and a size. The seven properties schema.org defines on the type include two more, extendedAddress and postOfficeBoxNumber, which this measurement did not count.

The 57 addressCountry values that were not the recommended code

416 of the 438 nodes declared an addressCountry, across 58 distinct values. 359 of the 416 wrote the two letter form schema.org recommends. 57 wrote something else, and because the same page allows three letter codes and full country names for backward compatibility, 42 of those 57 are permitted rather than broken: 13 are three letter ISO codes, being USA eleven times and TUR twice, and 29 are a country's full listed name, most often United States at ten, with Australia, Spain, France, Germany, Canada, Italy, Mexico, India, Switzerland, United Kingdom and United Arab Emirates making up the rest. Permitted is not the same as consistent, and the consistency is where the cost sits, because a consumer joining these values has to normalise three spellings of the United States before any of them compares.

Fifteen of the 57 resolve against no country list at all. dishoom.com declares England as the addressCountry on twelve of its thirteen nodes and United Kingdom on the thirteenth, and England is not an entry in ISO 3166-1, so the field holds a constituent country for twelve of its restaurants and a sovereign state for the last one, in the same file, from the same publishing system. stripe.com writes UAE on one node, which is an abbreviation rather than either of the two codes or the listed name United Arab Emirates it uses elsewhere. bdmasonry.net declares the addressCountry as the literal string US +1 on both of its nodes, which is a country code with a telephone dialling prefix appended, almost certainly a form field that collected both and wrote both. None of those values is visible to anybody who checks only that the property is present.

This is the detail that decides whether markup is an asset or a liability, and it generalises past the address. A value that is present and wrong is harder to find than a value that is absent, because every presence check passes. This blog has measured the same failure in the fields that name who a site is, finding that 107 of 163 schema topic statements named the site itself and that 85 of 317 organizations named a reference entry while the rest pointed only at social profiles. The address property accepts whatever string it is given, so nothing in the pipeline between a contact form and a rendered page objects to US +1, and nothing will until somebody reads the output.

Declared in the markup and absent from the page

On 102 of the 203 sites declaring an address, none of the declared street, locality or postcode appeared anywhere in the page's own visible text. The test is deliberately crude and worth stating exactly, because the number depends on it: the HTML was stripped of script, style, template and comment content, the remaining text and each declared value were lowercased and reduced to letters and digits only, and the value counted as present if it appeared as a substring. So 2054 Vista Parkway, Suite 400 counts as present against a page rendering 2054 Vista Parkway Suite 400 and absent against one rendering 2054 Vista Pkwy, which means the count includes addresses a human would call shown. Two were checked by hand against the live page on 23 October 2026: anvilogic.com declares 644 Emerson St, Palo Alto, CA 94301 and shows none of it, and uxcel.com declares 2054 Vista Parkway, Suite 400, West Palm Beach, FL 33411 and shows none of it either. Per node the gap is wider still, with 323 of the 396 declared street lines and 299 of the 389 declared postcodes absent from the text, while on 55 sites a declared street line did appear verbatim.

Set against the policy quoted earlier this is the inconvenient half of the finding, because it cuts the other way from everything above. The sites in this group did the work: they published a complete, parseable address when 283 comparable sites published none. What they also did is put it only in the head of the document, where the policy says content a reader cannot see should not be marked up. Our own view is narrower than the policy's. A crawler extracting the graph gets a usable address either way, so the markup is not useless; what it is, is unverifiable against the page, and an answer engine with any check on agreement between markup and prose has nothing to agree with. That is the same mechanism behind the finding that 412 of 1,080 home pages named their site in neither source Google reads first.

What this measurement does not show is worth as much as what it does. No crawler was observed doing anything, because there are no server logs here, so nothing in this post states that GPTBot, ClaudeBot or PerplexityBot reads an address, weights one, or answers a location question differently when one is present. The published crawler documentation for those tokens, listed on the AI crawlers page, does not discuss address markup at all, and the three documents this post relies on are Google's and schema.org's. One URL was requested per hostname at the apex, so a business whose address sits on a contact page it links to is counted here as declaring nothing, and that is the single largest reason these figures understate the web: the home page is the wrong page for this markup on many sites and the right one on local businesses. The 1,419 hostnames are two sampling frames built for the crawlability study rather than a sample of the web, and they are weighted toward English language sites, so none of these proportions generalises beyond them. The fetcher that took the measurement is documented on the bot page, and how much weight a missing entity signal carries in a grade is set out under entity confidence.