Module 10: Structured Data, Schema, and Machine-Readable Meaning

MODULE 10

Structured Data, Schema, and Machine-Readable Meaning

Make important page meaning explicit for machines—without pretending schema is a secret AI ranking switch.

Before Class 1: Audit Your Structured Data   •   Before Class 2: Implement and Validate Meaningful Schema

The core idea

Visible content tells people what a page means. Structured data can make parts of that meaning more explicit for machines.

Schema.org provides a shared vocabulary of types and properties for describing entities, relationships, and actions. Google also uses supported structured data to better understand page content and to determine eligibility for certain rich search appearances.

For GEO, the useful question is not “How much schema can I add?” It is:

What important meaning is already visible to a human that I can represent accurately and explicitly for a machine?

Learning Outcomes

  • Explain the difference between visible content, metadata, and structured data.
  • Recognize common Schema.org types and properties that fit a page’s actual purpose.
  • Inspect the structured data already present on a real page.
  • Distinguish valid Schema.org markup from Google rich-result eligibility.
  • Identify gaps or mismatches between visible content and machine-readable meaning.
  • Implement one useful structured-data improvement and validate it.
  • Avoid overclaiming that schema directly causes AI citations, rankings, or recommendations.

1. Structured Data Is Explicit Meaning

A normal web page contains clues that humans interpret easily: a name, a job title, a product price, an author, an event date, a business location, or a review rating. Machines can often infer these things from text and layout, but structured data gives them a more explicit description.

Schema.org organizes that description around two building blocks:

  • Type: What kind of thing is this? Examples: Person, Organization, LocalBusiness, Product, Article, Event, Course.
  • Property: What do we know about that thing? Examples: name, url, author, datePublished, address, offers, brand, sameAs.

A type gives the entity a category. Properties give it attributes and relationships.

Connection to Module 6

In Module 6, you learned to think in terms of entities, attributes, and relationships. Schema is one way to express some of those relationships explicitly in machine-readable form.

Entity thinking comes first. Markup comes second. Choosing a schema type does not create a clear entity if the visible page itself is confused.

2. JSON-LD: A Common Way to Express Schema

Structured data can be embedded in several formats. JSON-LD is widely used because it keeps the machine-readable description separate from the visible HTML.

{
  "@context": "https://schema.org",
  "@type": "Person",
  "name": "Jordan Lee",
  "url": "https://example.com/about-jordan/",
  "jobTitle": "Marketing Consultant",
  "worksFor": {
    "@type": "Organization",
    "name": "Example Marketing"
  }
}

This example says that the page is describing a Person, gives that person a name and role, and connects the person to an Organization.

The value of the markup comes from accurately representing real information—not from adding as many properties as possible.

3. Choose Schema From the Page Purpose

Start with the question you used in earlier modules: What job is this page doing? Then choose structured data that matches the page’s real content.

Page purposePossible typeMeaning you may clarify
About a personPersonName, role, affiliation, sameAs profiles
About a companyOrganization / LocalBusinessName, URL, logo, location, contact information
Sell or describe a productProductBrand, model, offers, availability, identifiers
Publish an articleArticleHeadline, author, dates, image, publisher
Promote an eventEventName, dates, place, organizer, offers
Describe a courseCourseName, provider, description

Not every valid Schema.org type produces a Google rich result. Schema.org is a broad vocabulary; Google supports a smaller set of structured-data features for search appearances. Do not confuse valid schema with rich-result eligibility.

Before Class 1: Audit Your Structured Data

Choose one important page from your website. Your goal is to determine what the page currently tells machines about what it is, who or what it is about, and the information it contains.

Step 1 — Choose the page

Select a homepage, About page, product page, service page, article, FAQ/resource page, or another important page.

Step 2 — Describe the page in plain English

In one or two sentences, state what the page is primarily about and identify its main entity or subject.

Step 3 — Inspect the markup

Use the Google Rich Results Test and/or the Schema.org Validator. Record the schema types detected. If none are found, that is a valid audit result.

Step 4 — Compare visible meaning with machine-readable meaning

Choose three important facts that a visitor can clearly see. Determine whether each fact is also represented in the structured data.

Step 5 — Find one gap or mismatch

Identify one important fact that is missing, incomplete, confusing, or represented with the wrong type/property.

Step 6 — Separate observation from inference

Observation: “The structured data on this page contains ______.”

Inference: “This may help a machine understand ______.”

Come to class ready to answer: What does your page tell a human that it does not clearly tell a machine?

4. What Schema Can—and Cannot—Tell Us About GEO

Schema is attractive in GEO because it looks like a direct channel to machines. That makes it easy to overstate.

We can responsibly sayWe should not automatically claim
Structured data explicitly describes selected entities and properties.Schema makes an AI system trust a page.
Google documents that supported structured data can help it understand content and enable eligible rich results.Adding schema directly increases AI citations.
Schema can reduce ambiguity when the markup accurately matches visible content.More schema is always better.
We can test whether visibility changes after a schema intervention.A visibility change proves schema caused it.

This course-wide rule still applies: observe first; infer carefully.

5. Common Structured-Data Mistakes

  • Marking up content that is not actually on the page. Structured data should describe the real visible content.
  • Choosing a type because it sounds impressive. Use the most accurate type, not the most specific-looking type.
  • Confusing Schema.org validity with Google support. A valid Schema.org type may not produce a Google rich result.
  • Adding duplicate or conflicting markup. WordPress themes, SEO plugins, commerce plugins, and custom code can all generate schema.
  • Leaving outdated facts in markup. Price, availability, dates, addresses, names, and other properties should remain accurate.
  • Treating validation as proof of performance. “Valid” means the syntax/structure passes the test—not that Google or an AI system will use it.

6. A Practical Schema Workflow

Use this sequence whenever you consider adding or changing structured data:

  1. Clarify the page purpose.
  2. Identify the primary entity.
  3. Inspect existing markup before adding anything.
  4. Choose a type that accurately fits the visible page.
  5. Add only meaningful, truthful properties.
  6. Check for duplicate or conflicting schema.
  7. Validate the result.
  8. Recheck the live page after publishing.
  9. Measure outcomes separately from implementation.

Before Class 2: Implement and Validate Meaningful Schema

Return to the page you audited before Class 1. Make one structured-data improvement that accurately represents visible information on the page.

1. State the problem

What important meaning was missing, incomplete, or inaccurate?

2. Choose the appropriate type/property

Use Schema.org to verify what the type or property actually means. If Google rich-result eligibility matters for the page, also check Google’s supported structured-data documentation.

3. Implement one improvement

You may use an SEO/schema plugin, your CMS, a commerce plugin, or carefully added JSON-LD. Do not add markup that contradicts or invents visible content.

4. Validate it

Run the live page through the Schema.org Validator and, where relevant, Google’s Rich Results Test. Save the result or take a screenshot for your notes.

5. Explain the improvement

Complete: “Before, the page left ______ implicit. Now the structured data explicitly says ______.”

6. Keep the claim modest

Do not claim that the change will cause rankings, citations, or recommendations. If you later measure a visibility change, treat that as a result to investigate—not automatic proof of causation.

7. Tools and References

Portfolio Challenge: Make Meaning Explicit

Choose one page that matters to your audience and document a before-and-after structured-data improvement.

  • Page URL and page purpose
  • Primary entity
  • Schema types found before the change
  • One meaningful gap or mismatch
  • The type/property you changed or added
  • Validation result
  • A short explanation of what is now more explicit for machines
  • One sentence separating the observed implementation from any future performance inference

Module 10 Summary

Structured data is not a substitute for clear content, strong entities, useful answers, credible evidence, or sound technical SEO. It is a way to make selected meaning more explicit.

Page purpose → Primary entity → Appropriate type → Accurate properties → Validation → Measurement

The best schema is not the most complicated schema. It is the markup that accurately describes what the page really is and what the page actually says.

Previous: Module 9 — Trust, Evidence, and Source Credibility

Next: Module 11 — Technical GEO.

Scroll to Top