Chapter 18: Structured Data and Schema Markup — Helping Google Understand What Your Content IS

"A human reads your page and infers that you are a plumber in Cedar Hills, open until nine, with a wall of good reviews. A machine reads the same page and sees words near other words. Structured data is you writing down, in a language the machine can't misread, the thing a person would have inferred anyway." — constructed, in the voice of this book

Overview

Here is the search question that opens this chapter, and it is a strangely specific one: your page plainly says you are an HVAC company in Cedar Hills, open until 9 p.m., with a 4.8-star reputation — but does Google actually know that, or is it only guessing from the arrangement of your words? And a companion question that every business owner has asked while staring at a results page: why does that competitor's listing show gold review stars, a price, and an "open now," while mine is a plain blue link?

The answer to both is structured data — a way of labeling the things on your page so a machine doesn't have to infer them. Left to itself, Google reads your page the way it reads the whole web: as text, from which it estimates meaning using the entity and semantic systems you met in Chapter 4. It is astonishingly good at that estimation, and getting better. But estimation is not certainty, and certain kinds of facts — this is a product with this price and this rating; this is a business at this address with these hours; this is a recipe that takes this long — are facts you can simply tell Google outright, in a standardized vocabulary, instead of hoping it reads them correctly off the page. When you do, you become eligible for the enhanced listings Google calls rich results: the stars, the breadcrumbs, the FAQ drop-downs, the images and prices that make a listing bigger, clearer, and more clickable.

That word eligible is the hinge of the whole chapter, and we will lean on it constantly. Marking up a page does not earn you a rich result the way a good title earns a click; it makes you qualified to be considered for one, and Google decides, per query, whether to show it. Structured data is not a magic lever, it is not a ranking hack, and — a caution this chapter takes seriously — it is a place where a surprising number of people either waste effort marking up things Google ignores, or get themselves penalized marking up things that aren't true. This is technical SEO in its purest form (theme 4): plumbing that helps a machine understand a page it cannot see the way you do. And it is the anti-trick discipline (theme 1) stated almost literally: the entire job is to tell Google the truth about your page in a language it can parse, and the fastest way to ruin it is to lie.

In this chapter, you will learn to:

• Explain the two distinct jobs structured data does — adding meaning, and unlocking rich-result eligibility.
• Recognize JSON-LD when you see it, and know why Google recommends it over the older formats.
• Match the rich results that lift click-through to the schema types that enable them — and know which ones Google has quietly taken away.
• Plan LocalBusiness, Organization, and Service markup for a multi-location business, and connect it to the entity work of Chapter 4 and the local-pack work of Chapter 25.
• Test and monitor your markup with three free tools, and read the Search Console reports that tell you it's working.
• Refuse the myths: that schema ranks you, that more markup is always better, and that you can invent ratings you don't have.

Learning Paths

🏪 Local Business: §18.4 is your chapter — LocalBusiness, Organization, and the honest line between schema and the Google Business Profile — plus the Strategy File. 📝 Content Creator: weight §18.3 (rich results) and the FAQ/HowTo rollback; it changes what markup is worth your time. 🛒 E-Commerce: §18.3 (Product, review, and the self-serving-review rule) and §18.5 (markup at scale) matter most; Chapter 31 goes deeper. 🔧 Developer: §18.2 (JSON-LD and where it lives) and §18.6 (testing) are your core; you will be the one briefed to implement. 📊 Strategist: internalize §18.1 and §18.7 — what structured data can and cannot buy — so you can set honest expectations before a single line is written.

18.1 What structured data actually does

Let's define the thing precisely, because half the confusion in this topic comes from a fuzzy definition.

Structured data is standardized, machine-readable labeling added to a web page that states explicitly what the page's content means — that this string of characters is a price, that one is a phone number, this block is a review, that heading names a product. It doesn't change what a human sees on the page; it runs alongside the visible content as a kind of caption written for machines. The visible page says "Furnace Repair — Rivertown Home Services, (555) 019-2210, open Mon–Sat 7am–9pm." Structured data says the same thing in a form with no ambiguity: telephone: "+1-555-019-2210", openingHours: "Mo-Sa 07:00-21:00", @type: "HVACBusiness". One is for the reader; the other is for the reader's software.

Structured data does exactly two jobs. Keep them separate in your head, because they have very different levels of payoff and very different evidence behind them.

Job one: it makes meaning explicit. Instead of Google inferring what your content is from context, you state it. This helps Google understand the page and connect it to the right entities and topics — the "things, not strings" shift that is the whole argument of Chapter 4. This job is quiet and rarely produces a visible change, but it is the more durable of the two, and it is becoming more important, not less, as search moves toward entity understanding and AI-generated answers.

Job two: it makes the page eligible for rich results. A rich result (Google's current term; you'll also hear the older "rich snippet") is a search listing enhanced beyond the plain title-URL-description with extra visual elements drawn from your structured data: star ratings, an image thumbnail, a price, a breadcrumb trail, an expandable set of questions. Rich results are bigger, more eye-catching, and often more clickable than a plain listing — which is the CTR (click-through rate) story we develop in §18.3.

WHAT STRUCTURED DATA ADDS TO THE PIPELINE                    [schematic — not to scale]

  YOUR PAGE ──crawled──▶ Google reads the HTML
                              │
              ┌───────────────┴───────────────┐
              ▼                                ▼
      VISIBLE CONTENT                   STRUCTURED DATA (JSON-LD)
      (what humans read;                (a caption for machines:
       Google infers meaning)            meaning stated outright)
              │                                │
              └───────────────┬───────────────┘
                              ▼
                 Google UNDERSTANDS the page better
                              │
                 ┌────────────┴────────────┐
                 ▼                         ▼
        better ENTITY match          ELIGIBILITY for a rich
        (meaning; Ch 4)              result (Google decides
                                     per query — not guaranteed)

Read that diagram against the pipeline from Chapter 1. Structured data doesn't create a new stage; it feeds the indexing and serving stages better information. Nothing about it helps a page get discovered, crawled, or rendered — if Google can't reach or read your page, no amount of markup rescues it, which is why this chapter has Chapter 14 as a prerequisite. Structured data is a refinement you add on top of a page that already works, not a fix for one that doesn't.

🔎 How Search Sees It When Googlebot processes your page, a parser looks for structured data in the code, extracts it, validates it against the Schema.org vocabulary, and stores those explicit facts alongside its own inferences about the page. Two things follow. First, the markup must describe content that is actually on the page and visible to users — Google's guidelines are blunt about this, and §18.7 shows what happens when you break the rule. Second, being parsed is not the same as being displayed. Google reads far more structured data than it ever surfaces as a rich result; the data still does job one (meaning) even when it never does job two (a visible enhancement). So "my markup is valid but I don't see a rich result" is not a failure — it is the normal, common case, and §18.6 explains how to tell the difference between "broken" and "just not shown."

The single most important sentence in this section is the one about eligibility, so let's make it a rule you carry: structured data buys eligibility, not outcomes. Google's own documentation says, in plain words, that adding structured data does not guarantee a rich result — Google shows one only when it judges it useful for the query, and it can stop showing it at any time. This is the same honesty as Chapter 1's pipeline docs: the company that owns the feature refuses to promise it. Anyone who tells you "add this schema and you'll get stars" is selling the outcome Google explicitly won't guarantee.

18.2 Schema.org and JSON-LD: the vocabulary and the recommended format

Two things have to exist for structured data to work: a shared vocabulary (what words like "Product" and "openingHours" mean) and a syntax (how you physically write those words into a page). Schema.org is the vocabulary; JSON-LD is the syntax you should use.

Schema.org is a shared, collaborative vocabulary of types and properties for describing things on the web. It was launched in 2011 by Google, Microsoft (Bing), Yahoo, and later Yandex — the major search engines agreeing, unusually, on one dictionary so that a publisher marks a page up once and every engine understands it. Schema.org defines a sprawling hierarchy of types (Thing at the top, branching down through Organization, LocalBusiness, Product, Recipe, Event, Person, and thousands more) and the properties each type can carry (name, address, price, aggregateRating, openingHours). It is the reason "structured data" and "schema markup" are used almost interchangeably: in practice, marking up a page means describing it with Schema.org types.

JSON-LD — JavaScript Object Notation for Linked Data — is a syntax for writing that vocabulary into a page. It is a small block of code, wrapped in a <script type="application/ld+json"> tag, that sits in the page's HTML (HyperText Markup Language) but stands apart from the visible content. Here is what a minimal block looks like, describing one of Rivertown's service pages:

{
  "@context": "https://schema.org",
  "@type": "HVACBusiness",
  "name": "Rivertown Home Services — Cedar Hills",
  "url": "https://rivertownhome.example/locations/cedar-hills",
  "telephone": "+1-555-019-2210",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "128 Maple Avenue",
    "addressLocality": "Cedar Hills",
    "addressRegion": "RV",
    "postalCode": "00142",
    "addressCountry": "US"
  },
  "openingHours": "Mo-Sa 07:00-21:00",
  "priceRange": "$$"
}

Read it as English and it is almost self-explanatory, which is the point. @context tells the parser the words come from the Schema.org dictionary. @type says what this thing is — here HVACBusiness, a real Schema.org subtype of LocalBusiness, more specific and therefore more useful than the generic label. The rest are the properties: name, URL, phone, a structured postal address, hours in Schema.org's compact notation, and a rough price range. (All values are a constructed teaching example; the Rivertown metro is fictional.) A developer or a plugin drops this into the page's code; the visitor never sees it; Google reads it and now knows, rather than guesses, these facts.

You will still meet two older syntaxes, and you should recognize them without needing to write them. Microdata and RDFa (Resource Description Framework in Attributes) both weave the labels into the visible HTML using extra attributes on your existing tags (itemprop="telephone" sprinkled through the markup). They work — Google supports all three — but they are fiddlier, harder to change, and tangled up with your page's design, so an edit to the layout can silently break the markup.

⚖️ Evidence Check Claim: "JSON-LD is the format you should use." Where does this sit on the honesty scale? — Confirmed by Google: Google Search Central explicitly recommends JSON-LD for structured data, and says so in its documentation. This is not a correlation or a folk preference; it is the search engine's stated recommendation. — The practitioner's reasons, layered on top: because JSON-LD is a separate block, it is decoupled from your visible HTML — easy to add, easy to update, easy to generate from a template or inject with a tag manager, and easy to read and validate on its own. Microdata and RDFa remain valid, so a site already using them isn't broken and doesn't need an emergency migration. But for anything new, JSON-LD is the default, and the rest of this chapter shows it exclusively.

There is one discipline that JSON-LD's convenience makes easier to neglect, and it matters enough to flag now. Because the JSON-LD block is separate from the visible page, it is perfectly possible to write markup that says one thing while the page shows another — to claim hours, a price, or a rating in the code that no human can see on the page. That decoupling is JSON-LD's great strength and its one trap. Hold that thought; it becomes the manual-action discussion in §18.7.

18.3 Rich results that move click-through — and the ones Google took back

This is the section people come for, because rich results are the visible payoff. Let's catalog the ones that matter, then tell the honest, recent, and slightly deflating story about two of them — because a chapter that sold you FAQ markup without the 2023 news would be exactly the outdated folklore this book exists to replace.

First, see what a rich result even is, rendered against a plain one.

📄 Read the SERP

text FIGURE 18.1 — "Two listings for the same kind of page" [constructed teaching example] THE QUERY / PAGE "best cordless drill for home use" — two organic results, side by side. WHAT'S THERE Result A (plain): a blue title, a green URL, two lines of description. Result B (rich): the same, PLUS ★★★★☆ 4.6 (218), a product image thumbnail, a price "$89.00," and an "In stock" line — all drawn from Product structured data. WHAT IT SHOWS Result B occupies far more vertical space and carries trust-at-a-glance (the stars) and commercial signal (price, availability). On a crowded mobile screen it dominates. WHAT IT DOESN'T It does NOT prove B ranks above A — rich results and ranking are separate. And a rich result can *cost* clicks if it answers the question so completely the user doesn't click (the FAQ problem, below). Bigger is not always better for YOU. THE MOVE Where your page genuinely has the underlying facts (real products, real prices, real third-party reviews), mark them up so you're eligible for the enhanced listing. THE LESSON Rich results compete for the eye, not the rank. They change the *click*, not the *position* — and only when the facts are really there to display.

The stars, price, and image in Result B come from a small Product block. This is what enables the review-snippet and product rich results, and it's the pattern e-commerce lives on (Chapter 31 goes deep):

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Aspen 20V Cordless Drill",
  "image": "https://example-store.example/img/drill.jpg",
  "offers": {
    "@type": "Offer",
    "price": "89.00",
    "priceCurrency": "USD",
    "availability": "https://schema.org/InStock"
  },
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.6",
    "reviewCount": "218"
  }
}

Every element of Result B traces to a field here: the stars to aggregateRating, the "\$89.00" to offers.price, the "In stock" to availability, the thumbnail to image. Note what makes this legitimate — the store actually has this product, at this price, with 218 real customer reviews. The markup reports facts that exist on the page; it does not invent them. Hold that standard; §18.7 shows what happens when markup asserts facts a page doesn't have.

Now the working catalog. These are the rich-result types most sites can realistically pursue, each tied to the Schema.org type that enables it:

Two rows in that table carry a "★"-worthy lesson, and it is the most important structured-data news of the last few years. For a long time, FAQPage (marking up a list of questions and answers) and HowTo (marking up the steps of a task) were the darlings of the SEO world, because they produced big, real-estate-grabbing rich results and were easy to add. Then, in 2023, Google sharply cut both back. FAQ rich results were restricted to a narrow set of "well-known, authoritative government and health websites"; for an ordinary business — a plumber, a shop, a blog — they simply stopped appearing. HowTo rich results were first limited to desktop and then deprecated entirely, removed for everyone, and Google even retired the corresponding report in Search Console.

🚫 SEO Myth: "Add FAQ schema to your pages and you'll get those expandable questions in Google." Not anymore, and this is the cleanest example in the whole book of why you must date your SEO knowledge. For years this advice was correct and everywhere. In 2023 Google restricted FAQ rich results to authoritative government and health sites and removed HowTo rich results outright. If you run a home-services company, a store, or a personal blog, adding FAQPage markup today will not produce the FAQ rich result — that door is closed to you. The markup is not forbidden and can still help Google understand your Q&A content (job one, meaning), but expecting the SERP feature is chasing a snippet that no longer exists for your site. Every "add FAQ schema for more visibility" tutorial written before 2023 and never updated is now teaching a ghost. Check the date on any structured-data advice, and confirm the feature against Google's current documentation before you invest in it.

That story is not a downer; it is the chapter's spine made concrete. Google gives SERP features and Google takes them away, on its own schedule, for its own reasons (often: the feature was being abused, or it cluttered results, or it answered questions so well that users stopped clicking — a genuine problem for Google's own publishers). If your strategy depended on the FAQ rich result, an announcement erased it overnight. This is why we never build a plan on a single SERP feature, and why the durable value of structured data is job one (meaning), which no announcement can revoke.

For the record, here is what FAQPage markup looks like — still valid, still readable by Google for meaning, just no longer producing the expandable SERP box for an ordinary business:

{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [{
    "@type": "Question",
    "name": "Do you offer 24/7 emergency HVAC service?",
    "acceptedAnswer": {
      "@type": "Answer",
      "text": "Yes. All five Rivertown Home Services locations dispatch emergency technicians around the clock."
    }
  }]
}

The block is honest and correct; what changed is not your markup but Google's willingness to display it. That is the whole lesson of dating your SEO knowledge, sitting in one snippet.

Now the review-stars caveat, which trips up more small businesses than any other single thing in this topic.

🔎 How Search Sees It You cannot get gold review stars in Google by marking up the testimonials on your own business page. Since 2019, Google has not shown review rich results for "self-serving" reviews — reviews an organization or local business publishes about itself, via AggregateRating on LocalBusiness or Organization. The reasoning is obvious once stated: a business rating itself five stars is not trustworthy signal. Review stars appear for reviews on specific supported types — a Product, a Recipe, a Course, an Event — or they come from independent aggregators (the review platforms Google itself trusts). So the star ratings you see next to a local competitor almost always come from Google's own ecosystem — the Google Business Profile and its reviews, which is Chapter 25's territory — not from schema the business wrote about itself. Marking up your own "★★★★★ — our customers love us!" and expecting stars is one of the most common wasted afternoons in local SEO.

So which rich results should most sites actually pursue? The honest, unglamorous answer: breadcrumbs (near-universal, trivial, low-risk), Product (if you sell things — Chapter 31), Recipe/Event/Video (if you genuinely publish those), and, quietly and without expecting a visible reward, the meaning markup of §18.4. Everything else is situational, and two former favorites are simply gone for you.

The breadcrumb is the cleanest first win, so here is that one in full — it usually comes straight from your navigation hierarchy (the site architecture of Chapter 15):

{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    { "@type": "ListItem", "position": 1, "name": "Home", "item": "https://rivertownhome.example/" },
    { "@type": "ListItem", "position": 2, "name": "Services", "item": "https://rivertownhome.example/services/" },
    { "@type": "ListItem", "position": 3, "name": "Furnace Repair", "item": "https://rivertownhome.example/services/furnace-repair/" }
  ]
}

It replaces the raw URL in your listing with a readable trail — rivertownhome.example › Services › Furnace Repair — which is clearer for the searcher and reinforces your site structure for Google. Low effort, low risk, and a sensible place to start a markup project.

🔄 Check Your Understanding A local bakery adds FAQPage markup ("Do you make gluten-free cakes?" etc.) hoping for the expandable FAQ rich result, and adds AggregateRating to its LocalBusiness markup hoping for star ratings. Predict what each will actually produce in the SERP, and why.

Answer

Neither produces the hoped-for feature. The FAQ rich result was restricted in 2023 to authoritative government and health sites, so a bakery won't get the expandable questions (the markup may still help Google understand the content — meaning, not display). The self-serving AggregateRating on a LocalBusiness won't produce star ratings either, because Google stopped showing rich results for self-serving business reviews in 2019. The bakery's real path to stars is earning Google reviews on its Business Profile (Chapter 25), not writing markup about itself.

18.4 LocalBusiness, Organization, and sameAs: the entity and local layer

This is the section that matters most for Rivertown and for any business with an address, and it is where structured data connects back to the entity work of Chapter 4. Here the payoff is mostly meaning (job one), and the honesty required is mostly about what schema doesn't do for local ranking.

LocalBusiness is the Schema.org type for a business with a physical location and, usually, a service area: a restaurant, a dentist, a plumber, a store. It carries exactly the properties you'd expect a directory to want — name, address, telephone, openingHours, geo coordinates, priceRange, areaServed — and it has more specific subtypes worth using when they fit: HVACBusiness, Plumber, Electrician, Restaurant, Dentist, and many more. Using the most specific accurate type is a small act of clarity: HVACBusiness tells Google more than the generic LocalBusiness, which tells it more than nothing.

Organization is the broader type for the entity behind the business — the brand itself, whether or not it has a walk-in location. For a single-location shop, LocalBusiness often carries everything. For a multi-location company like Rivertown, the clean model is a parent Organization for the brand and a LocalBusiness (or a specific subtype) for each branch. Here is the brand-level block:

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "Rivertown Home Services",
  "url": "https://rivertownhome.example/",
  "logo": "https://rivertownhome.example/img/logo.png",
  "founder": "Ray Delgado",
  "foundingDate": "1984",
  "sameAs": [
    "https://www.facebook.com/rivertownhome",
    "https://www.linkedin.com/company/rivertown-home-services",
    "https://www.yelp.com/biz/rivertown-home-services"
  ]
}

The property doing the quiet, important work there is sameAs. You met sameAs in Chapter 4 as an entity-disambiguation tool, so we won't redefine it — but here is where it earns its keep. sameAs is a list of authoritative URLs that refer to the same entity: the brand's own social profiles, its Wikipedia or Wikidata page if it has one, its established listings. It is you telling Google, "the Rivertown Home Services on Facebook, on LinkedIn, and on Yelp is the same Rivertown Home Services as this website." That helps Google consolidate a scattered set of mentions into one confident entity — the raw material of a Knowledge Graph understanding and, eventually, a knowledge panel.

🔗 Connection This section sits on top of Chapter 4 (Entities, the Knowledge Graph, and Semantic Search) — sameAs, disambiguation, and topical authority all come from there; structured data is one of the mechanisms Chapter 4 named for connecting your content to entities. It also hands off forward to Chapter 25 (Local SEO), where the Google Business Profile, NAP (name, address, phone) consistency, citations, and the local pack get their full treatment. Structured data is one leg of local visibility; the Business Profile is the bigger one. This chapter builds the schema leg and is honest that it is not the whole animal.

That honesty deserves its own callout, because the single most common overclaim in local SEO is that LocalBusiness schema "gets you into the map pack."

⚖️ Evidence Check Claim: "Adding LocalBusiness schema will get my business into the local pack (the map with three businesses)." Sort it out: — What's true: LocalBusiness markup helps Google understand your business as an entity and reinforces that your NAP details are what you say they are — a genuine, if modest, contribution to how confidently Google associates your site with your real-world business. — What's overstated: the local pack is driven overwhelmingly by your Google Business Profile — its categories, reviews, proximity to the searcher, and prominence (Chapter 25) — not by site schema. Google has said as much: your Business Profile, not LocalBusiness markup, is the lever for the map pack. — The honest posture: add the markup (it helps meaning and NAP consistency, and it's cheap), but do not expect it to move you into the local pack on its own. If someone sells "we'll get you in the map pack with schema," they are selling the overstatement. The Business Profile does that work.

For the service pages themselves, a light Service type describes what Rivertown does and where:

{
  "@context": "https://schema.org",
  "@type": "Service",
  "serviceType": "Furnace repair",
  "provider": {
    "@type": "HVACBusiness",
    "name": "Rivertown Home Services"
  },
  "areaServed": ["Rivertown", "Cedar Hills", "Northgate", "Westbrook", "Millhaven"]
}

Be honest about this one, too: there is no "Service" rich result in Google. Marking up a service does not produce a visible SERP enhancement. Its entire value is job one — helping Google understand what this page is about and which service, in which areas, it represents. That is a perfectly good reason to add it (meaning compounds, especially as search leans on entities and AI systems that read structured data). It is not a reason to expect anything to appear. If you add Service schema and see no change in your listings, the markup is working exactly as designed.

Notice the pattern across this whole section: the local and entity markup is the most durable structured data you can add and the least visible. It pays off in understanding, not in stars. That is precisely backwards from where beginners spend their enthusiasm, and getting it right is a mark of a strategist rather than a snippet-chaser.

18.5 Implementation: hand-coded versus plugins

You now know what to say and in what language. The practical question is how it gets onto the page, and for most readers of this book — who are marketers and owners, not necessarily developers — the honest answer is "probably a plugin, and that's fine." Let's map the options and their trade-offs.

HOW STRUCTURED DATA GETS ONTO A PAGE                         [decision sketch]

  Do you run a mainstream CMS (WordPress, Shopify, etc.)?
        │
        ├─ YES ─▶ Use its built-in schema or a reputable plugin/app.
        │          + fast, templated across many pages, no code
        │          − can output bloated or generic markup; verify it
        │
        └─ NO / custom site ─▶ Hand-code JSON-LD, or generate it from
                   your templates / inject via a tag manager.
                     + full control, exactly the fields you want
                     − needs a developer; you own the maintenance

The plugin / built-in path. Rivertown's site runs on WordPress, so this is its road. Modern SEO plugins, and many themes and page builders, generate structured data automatically — an Organization block from your site settings, BreadcrumbList from your navigation, Article from your posts, LocalBusiness from a local-SEO plugin's location fields. E-commerce platforms like Shopify and WooCommerce output Product markup from your catalog data. The appeal is enormous: you fill in fields in an admin screen, and correct JSON-LD appears across hundreds of pages, updating itself when your data changes. For the vast majority of sites this is the right choice, and hand-coding would be a waste of money.

The catch is that plugins vary in quality, sometimes fight each other (two plugins each emitting an Organization block, or conflicting LocalBusiness data), and often emit generic markup where a specific type would serve better. So the plugin path does not remove your job; it changes it from authoring to auditing. You still open the Rich Results Test (§18.6) and confirm the output is correct, specific, and matches the page.

The hand-coded path. On a custom-built site, a developer places JSON-LD blocks in the template so that, say, every product page renders a Product block populated from the product's data, and every location page renders its LocalBusiness block. This is more work and needs engineering, but it gives exact control — the precise type, only the fields you want, no bloat. A middle road, popular on larger sites, is to generate the JSON-LD from page data and inject it with a tag manager, keeping markup out of the core codebase.

That last option carries a quiet catch worth flagging. Structured data injected by a tag manager exists only after JavaScript runs — which means Google must render the page to see it, and rendering is the delayed, sometimes-imperfect step from Chapter 1 that gets its own treatment in Chapter 19. Markup that ships in the raw HTML the server sends is the safest; markup that appears only after client-side script is markup you're betting Google will render. For most sites this works, but it is one more reason to test the rendered page, not just the source, and one more thread pulling toward the rendering problem of the next chapter.

🛠️ Try It on Your Site Find out what structured data your site already emits — most sites emit some without the owner knowing. Open Google's free Rich Results Test (search.google.com/test/rich-results), paste in your homepage URL, and run it. Then try a product, service, or location page. You'll likely see an Organization, BreadcrumbList, or WebSite block your CMS added automatically. Are the details right? Is the type as specific as it could be (a Plumber, not a bare LocalBusiness)? Are there errors or warnings? You have just audited your markup before writing a single line — and you may find you already have more, or messier, structured data than you thought.

One decision cuts across both paths and is worth stating as a rule: mark up what's on the page, and let the page's real data drive the markup. Whether a plugin generates it or a developer writes it, the JSON-LD should be populated from the same source of truth as the visible content — the product's real price, the location's real hours — so the two can never drift apart. Markup that is generated from the page's data stays honest automatically. Markup that is hand-typed as a separate copy is the kind that quietly goes stale, or worse, gets faked. Which brings us to testing, and then to the myths.

18.6 Testing and monitoring: three free tools and a report

Structured data has an unusually clean feedback loop, and you should use it every time you add or change markup. Three free tools, each answering a different question.

1. The Rich Results Test (search.google.com/test/rich-results) answers: "Is this page eligible for a Google rich result, and does Google see valid markup?" It is Google's own tool, it tests a live URL or a snippet of code, it renders the page the way Google does, and it reports which rich-result types the page qualifies for, plus errors (which block eligibility) and warnings (which don't block it but represent missing recommended fields). This is your first stop, because it tells you specifically about the features Google actually supports — including telling you, helpfully, when a type is not eligible for any rich result.

2. The Schema Markup Validator (validator.schema.org) answers a broader question: "Is my markup valid Schema.org, regardless of whether Google shows a rich result?" Run by the Schema.org community — it succeeded the old Structured Data Testing Tool that Google retired — it validates any Schema.org markup, not just the subset Google turns into rich results. Use it when you're marking up something for meaning (a Service, a detailed Organization) that the Rich Results Test will shrug at because there's no Google feature for it.

3. Google Search Console answers the only question that ultimately matters: "Is this working on my real pages, at scale, over time?" The two testing tools check one page in a lab; Search Console reports on your whole site as Google actually processes it.

📄 Read the Report

text FIGURE 18.2 — "The Enhancements section of Search Console" [constructed teaching example] THE SOURCE Search Console → "Enhancements," for Rivertown after adding schema sitewide. WHAT'S THERE "Breadcrumbs": 62 valid items, 0 errors, 3 warnings. "Merchant listings / Product": 14 valid, 2 invalid (missing 'price'). "Sitewide Organization": detected. No FAQ report present. WHAT IT SHOWS Google is reading Rivertown's breadcrumb and product markup across many pages, and has flagged 2 product pages whose markup is broken (no price) — a specific, fixable bug. The absence of an FAQ report is expected: that feature isn't available to this site. WHAT IT DOESN'T It does NOT report how many rich results were *shown*, or how they affected clicks — that lives in the Performance report, filtered by "Search Appearance," and even there the attribution is coarse. Valid markup ≠ displayed feature ≠ measured click lift. THE MOVE Fix the 2 invalid product pages (add 'price'), clear the warnings if cheap, and check the Performance report's Search Appearance filter to see whether any rich results ran. THE LESSON Testing tools prove eligibility on one page; Search Console proves Google is reading your markup across the whole site — and surfaces the broken items you'd never find by hand.

The monitoring habit is the part people skip and the part that separates working markup from decorative markup. Structured data breaks silently: a site redesign changes a template and drops a required field; a plugin update alters its output; a price format changes and now validates as text instead of a number. None of that announces itself. Search Console's Enhancements reports are where you catch it, and glancing at them belongs in the same weekly review ritual we build around Search Console in Chapter 27.

🔗 Connection The tools here are lab checks; the ongoing measurement lives in Chapter 27 (Google Search Console), where the Performance report and its "Search Appearance" filter let you see whether a rich result actually ran for your pages, and the Enhancements reports become part of the weekly review. Add the markup here; watch it there.

The two testing tools have a habit of seeming to disagree, and learning to read that disagreement correctly is worth one quick check before we turn to the limits.

🔄 Check Your Understanding You add Service markup to Rivertown's furnace-repair page. The Schema Markup Validator says it's valid, but the Rich Results Test reports "no rich results detected." Is your markup broken? What should you conclude?

Answer

It is not broken. The Schema Markup Validator confirms the markup is valid Schema.org. The Rich Results Test reports "no rich results" because there is no Google rich result for the Service type — nothing is supposed to appear. This is the normal, expected outcome for meaning-only markup (§18.4). The two tools disagreeing this way is exactly how you tell "valid but not a Google feature" from "actually broken": if the validator passes and only the Rich Results Test is silent, your markup is fine; it's just doing job one.

18.7 The limits and the myths: what schema is not

We close with the guardrails, because structured data attracts two opposite errors — treating it as a ranking lever it isn't, and treating it as a place to invent facts, which gets sites penalized. Both are worth disarming explicitly.

Start with the biggest myth in the topic.

🚫 SEO Myth: "Structured data is a ranking factor — mark up your pages and you'll rank higher." No. Google representatives have said repeatedly and consistently that structured data is not a direct ranking factor. Adding schema does not, by itself, push your page up the results. What it can do is make you eligible for a rich result, and a rich result can lift your CTR (click-through rate) by making your listing more prominent — and there is a plausible, indirect, second-order argument that better understanding and better engagement don't hurt. But that is a world away from "schema ranks you." The honest chain is: markup → eligibility → maybe a rich result → maybe more clicks — with Google making the decision at the "maybe" steps. Treat anyone who calls schema a ranking factor the way you'd treat anyone who calls the meta description one (Chapter 9): they've confused "affects the listing" with "affects the rank."

The myth has a grain of truth buried in it — that a rich result can lift clicks — and that grain gets oversold almost as hard as the myth itself, so it earns its own honest sorting.

⚖️ Evidence Check Claim: "Rich results increase click-through rate." This one deserves careful sorting, because it's mostly true and often oversold. — Direction, well-supported: a more prominent, information-rich listing tends to attract more attention and clicks than a plain one — this is intuitive and backed by Google's own published customer case studies reporting CTR increases after adding structured data. — The caveats that get dropped: those are vendor/self-published case studies (Tier 2 to Tier 1-ish), the exact percentages are situational and not a law you can quote, results vary by query and by how crowded the SERP is, and — crucially — a rich result can reduce your clicks when it answers the question in place (a fully expanded FAQ, a featured answer), the very zero-click dynamic that led Google to pull FAQ results back. So: rich results can lift CTR, sometimes substantially, and occasionally lower it. Pursue them where the facts are real and the enhancement helps the click — not as a guaranteed multiplier.

Now the serious limit — the one with consequences. Because JSON-LD is decoupled from the visible page (§18.2), it is technically trivial to mark up things that aren't true or aren't there: to claim a 4.9 rating you don't have, to mark up prices or products that don't appear on the page, to add hidden FAQ content, to label a page as something it isn't. Google's structured-data guidelines forbid exactly this, and enforcement is real.

🔎 How Search Sees It Google issues a specific manual action — a human-reviewed penalty, which you met in the Chapter 1 case study as the kind of judgment Search Console reports — for "spammy structured markup." Its documented triggers are precisely the temptations JSON-LD's decoupling creates: markup that describes content invisible to users, markup that is irrelevant or misleading about the page, and fake or self-serving reviews. When it fires, Google removes your rich results and can suppress the page, and you must fix the markup and file a reconsideration request (Chapter 26's territory) to recover. This is theme 1 in its sharpest form: structured data works because it's supposed to be true. The moment you use it to assert something false, you've stopped helping Google understand your page and started trying to deceive it — and this is one of the more reliably detected and penalized deceptions in SEO, because the mismatch between markup and page is mechanically checkable.

The practical rules that keep you safely on the right side of all this are simple, and they are the whole ethic of the chapter compressed:

• Only mark up what's on the page and visible to users. If a human can't see it, don't claim it in schema.
• Only mark up what's true. Real prices, real hours, real third-party ratings. Never invent a number.
• Match the markup to the page's actual content and type. Don't label a category page as a Product, or a thin page as something it isn't.
• Use the most specific accurate type, and don't pile on types you don't need — more markup is not better markup; correct markup is.
• Expect eligibility, not outcomes. Add it, test it, monitor it, and let Google decide what to show.

There is also a plain opportunity-cost limit worth naming for the strategist. Structured data is real work, and for many sites it is not the highest-leverage work available. A business whose pages are thin, whose titles don't match intent, or that isn't in the local pack will get far more from Chapters 9, 15, and 25 than from a schema project. Markup refines a listing; it does not create the underlying quality, relevance, or authority that earns the ranking in the first place. Do the foundational work, then add the markup that makes a already-deserving page's listing clearer and more clickable. In that order, structured data is a genuine edge. In the wrong order, it's a distraction with a technical sheen.

📈 The Strategy File

Rivertown's site is missing structured data almost entirely — one of the plain problems in its frozen profile. Now that the architecture (Chapter 15) and mobile (Chapter 17) work is scoped, we add the schema layer: a plan Marisa and Tony Delgado can hand to whoever maintains the WordPress site. This is a plan, not a fix — and, in the spirit of the chapter, it is explicit about what each piece will and won't do.

FIGURE 18.3 — "Rivertown's structured-data plan"                     [the Strategy File]
  MARKUP                     WHERE                         WHAT IT DOES        HONEST LIMIT
  Organization (+ sameAs)    Site-wide (one block; from    Consolidates the    Won't produce a
    founder: Ray Delgado,      brand settings). sameAs →     brand entity;       visible result;
    foundingDate: 1984         Facebook, LinkedIn, the       feeds Knowledge     entity payoff is
                               five Business Profiles.       Graph (Ch 4).       slow + invisible.
  LocalBusiness / HVACBusiness Each of the 5 location       States NAP, hours,  Does NOT get them
    / Plumber / Electrician     pages (Rivertown HQ, Cedar    area outright;      into the local
    (most specific type)        Hills, Northgate,             reinforces NAP      pack — that's the
                                Westbrook, Millhaven).        consistency.        GBP (Ch 25).
  Service                      Each service page (furnace    Clarifies what the  NO Service rich
                                repair, AC, drain, panel,     page is + where     result exists;
                                EV charger…), areaServed.     it's offered.       meaning only.
  BreadcrumbList               Every page, from the nav      Eligible for the    Low-risk, low-
                                hierarchy (Ch 15).            breadcrumb rich     reward; a clean
                                                              result.             first win.
  FAQPage                      The service-page FAQs         Helps Google        WON'T show the FAQ
                                (draft + technician review,   understand the      rich result — that
                                Ch 13's workflow).            Q&A content.        closed in 2023.

Three honesty notes make this a strategist's plan rather than a snippet-chaser's wish list:

• The most valuable markup here is the least visible. The Organization + sameAs + LocalBusiness layer pays off in entity understanding and NAP consistency, not in stars. Nothing "appears," and that's fine — this is job one (meaning), the durable job.
• We add FAQPage markup knowing it won't earn the FAQ rich result (Rivertown is not a government/health site). We add it only for machine-understanding of the Q&A, and we do not promise the Delgados the expandable questions. Promising them would be repeating the pre-2023 myth.
• This plan does not touch the local pack. The map-pack work — Google Business Profiles for all five locations, review generation, citation and NAP cleanup — is Chapter 25, and it is the bigger local lever. Schema reinforces it; it does not replace it. When we assemble the full strategy in Chapter 40, this schema layer sits underneath the local-SEO playbook, not instead of it.

Your Strategy-File task (on your own site, using Appendix C's worksheet): run the Rich Results Test on your homepage and one key page to see what markup you already emit; note the type and whether it's as specific as it could be; then write a two-column list — "markup to add" and, honestly, "what I expect it to do (eligibility, not outcome)." If any line says "get me ranked" or "get me in the map pack," rewrite it. You now know why.

Conclusion

We answered the chapter's opening question: no, Google does not automatically know your page is a plumber in Cedar Hills open until nine — it estimates, and structured data is how you replace the estimate with a statement it can't misread. We separated the two jobs that statement does: making meaning explicit (job one, durable and mostly invisible) and unlocking eligibility for rich results (job two, visible but never guaranteed). We chose JSON-LD, the format Google recommends, and learned to recognize it. We cataloged the rich results that lift click-through — and told the honest, dating-sensitive story of how Google restricted FAQ and removed HowTo in 2023, and why you can't get stars by rating yourself. We built the local and entity layer, and drew the bright line between site schema and the Google Business Profile that really drives the local pack. And we closed on the guardrails: schema is not a ranking factor, more is not better, and faked or mismatched markup earns a manual action — because the whole discipline works only when it tells the truth.

What remains genuinely uncertain is how much more structured data will come to matter as search shifts toward entities and AI-generated answers that read markup directly. The durable bet is job one: explicit, truthful meaning is unlikely ever to hurt you, and may quietly matter more each year. What is not uncertain is the ethic — mark up what's real and visible, expect eligibility rather than outcomes, and do the foundational content, architecture, and local work first.

There is a deeper thread running from this chapter into the next. We have spent Chapter 18 helping Google understand a page. Chapter 19 confronts the prior problem of helping Google see it at all: what happens when a site is built so heavily on JavaScript that its content — sometimes including the structured data itself — doesn't exist until code runs, and Google's renderer may run it late, partially, or not at all. Meaning is worthless if the machine never reached the words. That is the rendering problem, and it's next.

→ Continue to Chapter 19: JavaScript SEO.

Key Terms

• Structured data — standardized, machine-readable labeling added to a page that states explicitly what its content means, running alongside the visible content for machines to read.
• Schema.org — the shared vocabulary of types and properties for structured data, launched in 2011 by the major search engines; in practice, "schema markup" means describing a page with Schema.org types.
• JSON-LD (JavaScript Object Notation for Linked Data) — Google's recommended structured-data syntax: a self-contained code block, separate from the visible HTML, that carries the Schema.org labels.
• Rich result — a search listing enhanced beyond the plain title-URL-description with elements drawn from structured data (stars, images, prices, breadcrumbs, expandable questions); formerly "rich snippet."
• LocalBusiness — the Schema.org type for a business with a physical location or service area, with subtypes like HVACBusiness, Plumber, and Electrician; use the most specific accurate one.
• FAQPage — the Schema.org type for a page's list of questions and answers; since 2023 its rich result appears only for authoritative government and health sites.
• HowTo — the Schema.org type for the steps of a task; its rich result was deprecated (removed) by Google in 2023.
• Product schema — the Product type (with Offer and AggregateRating), central to e-commerce rich results showing price, availability, and review stars.
• Breadcrumb schema — the BreadcrumbList type, which enables the breadcrumb-trail rich result; near-universal, low-effort, low-risk.
• Rich Results Test — Google's free tool for checking whether a page is eligible for a Google rich result and whether its markup is valid.

Spaced Review

Retrieval practice mixing this chapter with Chapters 4 and 14. Try each before revealing the answer.

1. Structured data does two distinct jobs. Name both, and say which one is more durable and why.
2. A business owner adds FAQPage and self-serving AggregateRating markup and sees no FAQ box and no star ratings. Give the specific reason each feature failed to appear.
3. Why is LocalBusiness schema not the lever that gets a business into the local pack — and what is?
4. (Ch 4) What does the sameAs property do, and how does it relate to entities and the Knowledge Graph?
5. (Ch 14) Structured data helps the indexing and serving stages, but it can't rescue a page that fails an earlier stage. Name one earlier-stage failure (from Chapter 14's territory) that would make markup pointless, and why.