Structured data is your facts, stated so they cannot be misread
Lesson 3 was about writing facts a human can read and an assistant can lift. This lesson is about stating the same facts a second time, in a format built for machines.
Schema.org is a shared vocabulary for describing things on the web. JSON-LD is the format used to write that vocabulary into a page: a small script block that says, in effect, this page is about a business, here is its name, here is its address, here are its hours. Engines read it directly rather than inferring it from your layout.
The honest framing: for a business whose facts are already clean and unambiguous, schema is a marginal gain. For a business that is hard to pin down, a service-area operator with no public address, a name shared with another business in the region, a recent move, it can be the thing that lets an engine resolve you as one entity at all. The guide on whether you need schema for AI Overviews gives the direct answer on where your site sits.
The fields that earn their place
Dozens of properties exist. These are the ones that consistently matter.
- name and url, your trading name and canonical site URL.
- telephone, matching your profile exactly, including format.
- address as a PostalAddress, or areaServed if you hide your address.
- openingHoursSpecification, matching the profile again.
- geo as GeoCoordinates, useful for proximity understanding.
- sameAs, an array of the external profiles you own.
- image and logo, so the entity has a visual reference.
- priceRange, a rough band rather than a precise figure.
- hasOfferCatalog, optional, useful when you offer several distinct services.
The guide on which LocalBusiness fields matter covers the ones people add that change nothing, which is a longer list than you would hope.
A starting block you can adapt
Replace the values, delete what does not apply, and validate before you ship it.
{
"@context": "https://schema.org",
"@type": "HVACBusiness",
"@id": "https://example.com/#organization",
"name": "Example Refrigeration Services",
"url": "https://example.com/",
"telephone": "+61 3 9000 0000",
"email": "hello@example.com",
"image": "https://example.com/images/premises.jpg",
"priceRange": "$$",
"address": {
"@type": "PostalAddress",
"streetAddress": "14 Hammond Road",
"addressLocality": "Dandenong",
"addressRegion": "VIC",
"postalCode": "3175",
"addressCountry": "AU"
},
"geo": {
"@type": "GeoCoordinates",
"latitude": -37.9884,
"longitude": 145.2148
},
"areaServed": [
{ "@type": "City", "name": "Dandenong" },
{ "@type": "City", "name": "Springvale" },
{ "@type": "City", "name": "Noble Park" }
],
"openingHoursSpecification": [
{
"@type": "OpeningHoursSpecification",
"dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday"],
"opens": "07:30",
"closes": "17:00"
}
],
"sameAs": [
"https://www.google.com/maps/place/?q=place_id:EXAMPLE",
"https://www.facebook.com/examplerefrigeration",
"https://www.linkedin.com/company/examplerefrigeration"
]
}
Two rules that matter more than the syntax. Everything in that block must match your visible page, and everything must match your Google Business Profile. Markup that disagrees with the page it sits on is worse than no markup, because it creates exactly the contradiction Lesson 2 told you to eliminate.
Installing it
Wrap the JSON in a script tag with type="application/ld+json" and put it in the page. Head or body both work,
despite the confident advice you will read elsewhere. What matters is that it renders in the served HTML and that
the page it sits on is the page it describes.
On WordPress, a schema plugin or a snippet in the theme header both work, though a plugin that also generates its own competing block is a common source of duplication. On a hosted builder, look for a custom code or head-injection setting. On a hand-coded or static site, add it to the layout template. The guide on adding JSON-LD to a local business site walks each path and lists the mistakes that silently invalidate a block.
Validate, then check it is actually live
Two checks, both free, both quick.
Google Rich Results Test. Paste the live URL. It tells you whether Google can parse the markup and whether the page is eligible for any rich result.
A schema validator. The Schema.org validator reports structural problems that the Google tool skips, because it checks the vocabulary rather than one search product’s requirements.
Then view the rendered page source and confirm the block is present on every page it should be. Markup that only exists in a plugin preview helps nobody. Re-run both checks any time you change a fact.
sameAs, entity resolution and Wikidata
The sameAs array is how you tell an engine that the business on your site, the one on your Google profile, the one
on Facebook and the one on a trade directory are all the same organisation. That is knowledge graph entity
resolution in practice, and for a local business it is the highest-value part of the whole block after the basics.
List only profiles you genuinely own and maintain, typically three to eight. Dead or abandoned profiles are weak signals worth cleaning up. Almost no local business needs a Wikidata item, despite what you may have been told. The guide on using sameAs explains when it is worth the effort and when it is not.
What schema will not do
It will not make a thin page quotable. It will not rescue a business whose listings contradict each other. It is not a declared ranking factor for AI Overviews, and no amount of correct markup will get you named if your pages say nothing specific. It also cannot invent authority: marking up a rating you collected on someone else’s platform is against the guidelines and risks losing rich result eligibility entirely.
| Problem | Does schema fix it? | What actually fixes it |
|---|---|---|
| Facts are correct but ambiguous to a machine | Yes, this is its job | A validated LocalBusiness block |
| Listings contradict each other | No | The NAP audit in Lesson 2 |
| Pages contain nothing specific to quote | No | Rewriting passages, per Lesson 3 |
Treat it as what it is: the cheapest way to remove ambiguity about facts you have already made true elsewhere.
What to do next
Add the block, validate it, and confirm it renders on the live page. Then move to Lesson 5, which covers the technical floor that lets a crawler reach these pages at all. Markup nobody can fetch is markup that does nothing.