Local businessschema:what validatorsmiss.

01 / Original observation

Twenty homepages. Twenty-five parseable blocks. Further questions remained.

On October 22, 2026, MooseRank collected public server-response HTML from five Long Island handyman providers, five Long Island HVAC providers, five Austin plumbing providers, and five Denver-area electrical providers. Fifteen linked contact pages supplied additional context. MooseRank itself was reviewed separately.

The domains were a convenience sample discovered through public searches, excluding directories and marketing publishers. They were not randomly selected or treated as the top Google results. One plumbing-domain connection failed and was replaced; the downloadable record preserves that attempt. Provider affiliations were not assessed. Collection and source-text comparisons were AI-assisted; aggregation and source hashes were checked programmatically. The sampled business owners did not verify the findings.

Direct business-node properties appeared on nine homepages for telephone, nine for hours, nine for areaServed, and seven for a street-address property. Own-business aggregate-rating markup appeared on two. These are presence counts, not requirements, quality scores, or findings of policy violations.

One homepage had microdata indicators and none had detected Schema.org RDFa indicators. These other formats were not fully parsed. A homepage without observed JSON-LD might still supply other markup or add it through JavaScript. The study did not inspect Google's rendered version, test rich-result eligibility, or measure rankings.

02 / What required judgment

An hours field needs a meaning, not just a time range.

In record S09, the emitted all-day schedule sat beside public text that distinguished routine weekday hours from emergency availability. That is an unresolved scope question: which kind of availability does the schedule describe? It is not proof that the business is closed when its markup says it is open.

Record S10 contained two different same-brand business schedules in the collected homepage markup. The public live-answering statement did not establish which opening schedule was intended. The internal difference was observable; the correct real-world schedule was not established.

Record S05 illustrates a different limit. Its response included parseable business markup, while the body was essentially a JavaScript application shell. Comparing that server text with the markup could not settle what users would see after rendering. We kept that comparison unresolved.

These observations explain why we did not publish an error percentage. An absent optional property, a reference to another node, a dispatch schedule, and an actual contradiction need different treatment. The useful next action is to inspect the intended meaning with the business owner and page evidence.

03 / Controlled teaching example

Both documents parse. Their claims differ.

{
  "@context": "https://schema.org",
  "@type": "LocalBusiness",
  "@id": "https://example.com/#business",
  "name": "Example Home Services",
  "url": "https://example.com/",
  "openingHours": "Mo-Su 00:00-23:59",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "123 Example Street",
    "addressLocality": "Example City"
  },
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": 5,
    "reviewCount": 200
  }
}

{
  "@context": "https://schema.org",
  "@type": "LocalBusiness",
  "@id": "https://example.com/#business",
  "name": "Example Home Services",
  "url": "https://example.com/",
  "areaServed": "Example County",
  "openingHours": "Mo-Fr 09:00-17:00"
}

Our strict JSON parser successfully reads both examples. That is the test performed here. We do not present either as a result from Google's Rich Results Test or the Schema.org validator.

Own-business ratings also have a separate feature restriction: Google does not make self-serving LocalBusiness or Organization review markup eligible for review stars, including reviews embedded through a third-party widget. A syntactically readable rating is not a shortcut around that rule.

04 / Our documented implementation

We removed two availability assertions from MooseRank's graph.

Before this review, MooseRank's public business node included an all-week openingHoursSpecification of 00:00–23:59 and the same all-week schedule under contactPoint.hoursAvailable. The captured homepage and contact text did not state that round-the-clock opening or contact promise.

We could establish what the markup asserted and what the reviewed text did not substantiate. We could not establish actual staff availability from those pages. Our implementation choice was to omit the two assertions pending supported public details, rather than invent a replacement schedule.

1. RemovedThe two undocumented availability properties.
2. RetainedThe existing LocalBusiness type, business @id, public contact details, profile references, locality description, and service coverage.
3. Kept separateGoogle Business Profile settings, which were not changed; real-world availability and Google feature eligibility, which were not independently verified.

The preserved locality-only address is not presented as evidence of a complete physical-address submission for Google's LocalBusiness feature. We did not add a street address, claim a new office, or change the identity just to obtain a cleaner feature test.

The before record includes the source URL, collection time, and source-response hash. The after record contains the implemented business node. A comparison check confirms that only those two availability properties changed. This is a factual cleanup, with no measured ranking or conversion outcome attributed to it.

05 / Choose the statement first

Identity, location, and service are related, but they are different statements.

Organization

Describes an organization. It can be a sensible starting identity when a more specific local branch or business description is not supported.

LocalBusiness

Describes a particular real local business or branch. Use a genuine suitable subtype where available; keep legitimate parent and branch relationships clear.

Service

Describes the offer and links it to its provider. A service-area label describes coverage; it does not establish a physical branch at every place named.

A service-area business does not become an online-only organization merely because it withholds a private street address. Schema.org vocabulary and Google's feature requirements are separate. Google's LocalBusiness guidance requires a physical address for that feature; areaServed describes coverage and does not substitute for it.

Choose the actual business model before considering a search feature. For the separate question of which geographic website pages to build, use our local-page comparison in the next-reading section.

Reusing one stable business @id across pages can connect statements about the same entity. When a website already has markup from a theme, plugin, or custom layout, inspect and reconcile it before adding another business description. Multiple IDs can represent legitimate entities; check meaning and agreement before calling them a conflict.

06 / Interactive walkthrough

Build a small draft and read the reasons.

Use public facts you can support, or load the clearly fictional example. The walkthrough keeps optional claims out until you choose them, preserves an existing identity when supplied, and explains what still needs checking. It does not decide Google eligibility for you.

07 / Validation in layers

Use each check for the question it can answer.

1. ReadabilityParse the JSON and inspect the delivered page. This catches formatting failures, not business truth.
2. Vocabulary and relationshipsUse the Schema.org validator to review supported types and properties, then inspect provider, page, and identity connections.
3. Business evidenceCompare each substantive claim with current public page content and owner-confirmed operations. Resolve office, answering, appointment, and emergency scope explicitly.
4. Google feature requirementsUse the Rich Results Test for supported features, then Google's URL Inspection when access is available. Passing a tool does not guarantee appearance.

Feature lists also change. Google's May 8, 2026 update states that FAQ rich results stopped appearing starting May 7. Service remains useful Schema.org vocabulary, while Google's current search gallery does not list a standalone Service rich-result feature. Useful visible FAQs and accurate service relationships can remain without a promise of extra search decoration.

Review the graph when hours, services, locations, phone routing, software, or page ownership changes. Record the source of each important claim and give one person responsibility for checking it. The goal is an accurate description that stays connected to the business.

Connect strategy to execution

A priority is only useful when the campaign can act on it.

MooseRank's technical SEO and site foundation connects accurate structured data with crawl access, useful pages, consistent identities, and a working customer path.

As a Long Island SEO company, MooseRank keeps research tied to the services, markets, and customer decisions the business actually wants to win.