What is structured data? Real examples from our own website

Every page on this website carries structured data. Rather than explain it in the abstract, here is ours, piece by piece, with what each line tells a machine. The snippets below are trimmed from the live code on hunleymedia.com.

What structured data is, in plain English

Think of the label on a moving box. Anyone can open the box and look inside, but the label tells you what is in it without opening it. Structured data is that label for a web page. Visitors never see it. Search engines and other software read it to know what the page is about without guessing.

The labels come from Schema.org, a shared vocabulary backed by Google, Microsoft, Yahoo and Yandex. The usual format is JSON-LD, a small block of code in the page that lists facts as name and value pairs. Google recommends JSON-LD, and it is what this site uses. You will also hear it called schema or schema markup. Same thing.

Example 1: telling Google who we are

This block sits on every page of the site. It describes the company once, in one place.

{
  "@type": "Organization",
  "@id": "https://hunleymedia.com/#organization",
  "name": "Hunley Media Group",
  "location": { "@type": "City", "name": "Louisville" },
  "founder": { "@id": "https://seanstafford.com/#person" },
  "knowsAbout": [
    "Growth engineering",
    "Search engine optimization",
    "AI search visibility",
    "Conversion rate optimization",
    "Website design and development",
    "Structured data",
    "Sales process design",
    "Referral programs",
    "Business turnaround"
  ]
}

• @type says this is an organization, not a person, a product or a place.
• @id is a permanent name tag. Our service pages and blog posts point back to it, so a machine knows they all belong to the same company.
• location says Louisville, Kentucky (trimmed above to save space). There is also a Louisville in Colorado, and the markup removes the doubt.
• founder does not repeat Sean’s details. It points to his own record, which lives on his own site.

What knowsAbout does

knowsAbout lists the subjects a business or person works in. Ours names nine. It is a plain statement, in a form a machine can read, of what we want to be known for.

Two cautions. Google does not document knowsAbout as a property it uses for search features, so treat it as a clarity signal, not a ranking lever. And it only means something if the site backs it up. Every topic on our list has a page or post behind it, like growth engineering, SEO audits and referral programs. A list of topics with nothing behind it is just a claim.

Example 2: a service with a price

Our SEO and Conversion Path Audit page carries this block.

{
  "@type": "Service",
  "name": "SEO and Conversion Path Audit",
  "serviceType": "SEO audit",
  "provider": { "@id": "https://hunleymedia.com/#organization" },
  "offers": {
    "@type": "Offer",
    "price": "1500",
    "priceCurrency": "USD"
  }
}

A visitor sees “$1,500” on the page. The markup states it as a number, in US dollars, attached to a named service from a named company. There is no room to read it as a monthly fee or a starting price. Pricing is one of the most common things people ask search engines and AI assistants, and a vague price page gives them nothing firm to repeat.

Example 3: questions and answers

Each FAQ on this site is marked up as a clean question and answer pair.

{
  "@type": "Question",
  "name": "How much does an SEO audit cost from Hunley Media Group?",
  "acceptedAnswer": {
    "@type": "Answer",
    "text": "The Hunley Media SEO and conversion path audit costs $1,500, fixed, with no monthly contract."
  }
}

An honest note: Google no longer shows FAQ rich results, the expandable questions that used to appear under some search listings. We keep the markup anyway. It is still valid Schema.org, it costs nothing, and it puts our answers in the same question and answer shape people type into search. Whether AI assistants give it extra weight is not proven, so we do not count on it.

Example 4: connecting the author

{
  "@type": "Person",
  "@id": "https://seanstafford.com/#person",
  "name": "Sean Stafford",
  "jobTitle": "Founder",
  "worksFor": { "@id": "https://hunleymedia.com/#organization" },
  "sameAs": [
    "https://seanstafford.com/",
    "https://www.linkedin.com/in/seanstaffordlouisville/"
  ]
}

sameAs links Sean’s record to his own website and his LinkedIn profile. That tells search engines the person who writes these posts is the same person on those other pages, one identity instead of three similar names. Every blog post on this site names him as the author through that same @id.

What structured data will not do

• It will not rescue a weak page. It describes the page. The page still has to be worth ranking.
• It does not guarantee anything. Google says correct markup makes a page eligible for rich results, not that they will appear.
• It has to match what visitors see. Marking up a price, review or claim that is not on the page breaks Google’s guidelines and can cost the page its rich results.
• Its effect is hard to isolate. Schema usually ships alongside other changes. Be wary of anyone who credits a ranking jump to schema alone.

On the Louisville Historic Tours rebuild, schema on every page was one of five changes, alongside one page per tour, original stories, a working booking path and the same facts everywhere. Here is how those five changes worked together.

Check your own site in five minutes

1. Paste a page into Google’s Rich Results Test. It shows which markup Google can read and flags errors.
2. Run the same page through the Schema Markup Validator, which checks all Schema.org markup, not just the types Google uses.
3. Open the page, view the source and search for application/ld+json. No results usually means no JSON-LD.
4. Compare the name, address, phone and hours in the markup with your Google Business Profile. They should match exactly.
5. Look for leftovers from old plugins or themes. Two Organization blocks with different details is a common mess.