Structured Data That Earns Its Keep

Structured data is machine-readable metadata — JSON-LD in a <script> tag — that tells search engines and AI systems precisely what a page is about: this is a business, here is its address, these are its hours, this is a review and here is its rating. Google maintains an explicit, documented list of the types it actually uses. Everything on that list is worth implementing well. Almost everything off it is decoration.

What structured data does — and doesn't do

Google's own documentation is unambiguous: structured data is not a ranking factor. What it does is make pages eligible for rich results — star ratings, FAQ dropdowns, breadcrumb trails, business knowledge panels — and remove ambiguity about entities. A rich result typically improves click-through rate even at the same position, which is the honest commercial case for doing this work. The dishonest case — "schema juice" — does not exist.

The types we implement on every local business site

LocalBusiness (or its subtype)

The workhorse. Always the most specific subtype that fits — Restaurant, AutoRepair, HairSalon, HomeAndConstructionBusiness — with name, address, geo, telephone, openingHoursSpecification, url, image, and sameAs links to the business's real profiles. The critical discipline: every value must match what a human sees on the page and what Google Business Profile says. Inconsistent NAP (name, address, phone) data across surfaces is the classic local-search self-injury.

Organization

Sitewide, on the home page, with logo, contact information, and sameAs. This is the entity anchor that knowledge panels and AI assistants resolve against. We give it a stable @id so every other schema block on the site can reference the same entity instead of redefining it.

BreadcrumbList

Cheap to implement, visibly used: Google frequently replaces the raw URL in results with the breadcrumb trail. It must mirror the visible breadcrumb navigation — structured data that describes invisible content violates Google's guidelines.

FAQPage — with a caveat

Since Google's August 2023 change, FAQ rich results display almost exclusively for well-known, authoritative government and health sites. We still implement FAQPage where a page genuinely answers common questions — the markup remains valid, costs nothing, and the question-answer structure is precisely the format AI assistants quote — but we no longer promise the dropdown treatment in search results, because for most businesses it will not appear.

Review and AggregateRating

Powerful and tightly policed. Google's guidelines prohibit self-serving reviews — a business marking up ratings about itself that it collected itself is exactly the pattern that earns a manual action. We only mark up reviews where the rating is displayed on the page and sourced legitimately.

Types that are usually wasted effort

• WebPage / WebSite beyond the basics — harmless, but Google infers nearly all of it.
• Exhaustive Service catalogs with no corresponding visible content.
• speakable — still limited to news content in Google's docs, years on.
• Any markup describing content that isn't visibly on the page. This isn't just wasted — it's a guideline violation.

Implementation rules we hold ourselves to

• JSON-LD only. It's Google's stated preference, and it keeps metadata out of the markup where it can't break rendering.
• One entity, one @id. Blocks reference each other; nothing is defined twice.
• Parity with the visible page. If it's in the schema, a human can see it on the page.
• Validate on every deploy — Google's Rich Results Test for eligibility, Schema.org's validator for syntax.
• Monitor Search Console's enhancement reports, which surface per-type errors as Google recrawls.

This site practices what it preaches: view source on any page here and you'll find the same Organization, BreadcrumbList, and TechArticle patterns described above, live and validating.

← All research