What is schema markup? It is structured code you add to a web page that tells search engines and AI assistants exactly what the page is about. Instead of letting a crawler guess that "Aurora" is a place, a name, or a product, schema labels it. Written in JSON-LD using the shared schema.org vocabulary, it powers rich results in Google and helps AI engines pull clean, citable facts from your site.
What is schema markup, in plain English?
Search engines read your page as text. They are good at it, but reading is not understanding. A page can say "4.8 stars, $129, in stock, open until 9pm" and a crawler still has to infer which number is the price, which is the rating, and whether you are even a business that sells things.
Schema markup removes the guessing. It is a separate layer of code that names the parts of your page in a machine-readable way: this is a Product, this is its price, this is its aggregateRating, this is the FAQPage and here are the questions and answers. You are not changing what visitors see. You are handing the machines a labeled map of what is already there.
That vocabulary, the actual list of types and properties you are allowed to use, comes from schema.org, a standard backed by Google, Microsoft, Yahoo, and Yandex. So "schema markup" and "schema.org markup" are the same thing. You are speaking a language all the major engines agreed to read.
Schema markup vs structured data (people mix these up)
People use the terms interchangeably, and that is mostly fine, but there is a real distinction worth knowing.
- Structured data is the broad concept: any data organized in a predictable, machine-readable format. Schema is one flavor of it.
- Schema markup is structured data that specifically uses the schema.org vocabulary to describe page content for search engines and AI.
If structured data is the category, schema markup is the dialect everyone uses on the web. We split these into two glossary terms on purpose, because conflating them is how people end up implementing the wrong thing.
How schema markup works
Schema lives in your page's code, not on the visible page. There are three accepted formats, and the choice matters less than people think.
| Format | What it is | Where it goes |
|---|---|---|
| JSON-LD | A self-contained script block of labeled data | In the <head> or <body>, separate from your content |
| Microdata | Attributes (itemprop, itemtype) sprinkled inside your existing HTML tags | Tangled into the visible markup |
| RDFa | HTML5 attribute extension, similar to microdata | Tangled into the visible markup |
Google supports all three equally, as long as the markup is valid and properly implemented. But Google explicitly recommends JSON-LD, and so do we, because it is decoupled from your HTML. It sits in its own script tag, independent of how the page renders, which makes it dramatically easier to add, audit, and maintain at scale without breaking your layout.
A minimal JSON-LD block looks like this:
{
"@context": "https://schema.org",
"@type": "LocalBusiness",
"name": "Your Business Name",
"telephone": "+1-910-556-9420",
"address": {
"@type": "PostalAddress",
"streetAddress": "34 Main St, Unit 1C-B, Toms River, NJ 08753"
}
}@context points to schema.org so engines know which dictionary you are using. @type declares what the thing is. Everything after that is a property describing it. Notice that address is not just a string: it is its own typed object, a PostalAddress, nested inside the business. That nesting is the part most DIY attempts botch. Real schema is rarely one flat block. A Product holds an Offer, which holds a price and a priceCurrency; an Article holds an author that is itself a Person or Organization. The engines read those relationships, not just the labels, so a price floating loose with no Offer around it often gets ignored. Once an engine parses a well-formed block, it has facts it can trust instead of inferences it has to make.
The bigger payoff comes when those typed objects start agreeing with each other across your site. When your Organization block, your LocalBusiness block, and your author bios all point at the same name, URL, and identifiers, the engines stop treating your business as a string of text and start treating it as a known entity. That consistency is the bridge between schema and entity SEO, and it is what eventually earns a spot in the knowledge graph.
The schema types that earn their keep
There are hundreds of schema types. You do not need most of them. The rule from Google is simple: use the most specific applicable type. These are the ones that pull real weight:
- Organization / LocalBusiness - who you are, where you are, how to reach you. The entity backbone of your whole site.
- FAQPage - your questions and answers, eligible to surface directly in results and easy for AI to lift.
- Article / BlogPosting - author, publish date, and headline, which feed E-E-A-T and freshness signals.
- Product - price, availability, and reviews, the schema behind those rich shopping results.
- Review / AggregateRating - the star ratings that make a listing impossible to scroll past.
- BreadcrumbList - your site hierarchy, which cleans up how your URL displays in results.
- HowTo and Event - step-by-step and date-based content, when it fits.
One caution worth more than the list itself: pick the most specific type that genuinely fits, not the grandest one. A dental practice is a Dentist, not just a LocalBusiness. A recipe blog is a Recipe, not an Article. Specificity gives the engine more confidence and unlocks the features tied to that type. Reaching for a type that does not match your content is the fast way to get nothing.
Why schema markup matters (for SEO and for AI)
Two reasons, and the second one is the one most agencies are still asleep on.
For classic Google: rich results. Schema is what makes your listing eligible for the enhanced treatment, stars, FAQs, prices, breadcrumbs, instead of a plain blue link. Pages that show as rich results tend to earn meaningfully higher click-through rates, because they take up more space and answer more before the click. Worth saying plainly: Google does not guarantee a rich result even when your markup is flawless. Schema makes you eligible. It does not buy the placement.
For AI answer engines: clean, citable facts. This is the lever. When ChatGPT, Perplexity, or Google's AI Overviews build an answer, they favor sources where the facts are unambiguous. Schema hands them exactly that: labeled entities, structured Q&A, confirmed relationships. An AI engine assembling a quick answer would rather lift a clean FAQPage question-and-answer pair, or an Offer with a stated price, than reverse-engineer the same facts out of a paragraph and risk getting them wrong. It does not magically force a citation, but it removes the friction that makes an engine skip you for a source that is easier to parse. In a world where buyers ask an assistant before they ever open a tab, being the easy-to-quote source is not a nice-to-have. We dig into the evidence and the limits of this in our breakdown of whether schema markup helps AI visibility.
Schema is genuinely table-stakes here. It will not, by itself, vault you into AI answers. But missing it is a self-inflicted handicap, like submitting a resume with no formatting and hoping the reader squints hard enough to find the good parts. It is part of the foundation. The content, the entity signals, and the authority are what win the citation. Schema is what makes you eligible to be read correctly in the first place. We cover the full picture in answer engine optimization.
How to add and test schema markup
You generate the JSON-LD, drop it into the page, and validate it. The validation step is non-negotiable. Broken schema is worse than no schema, because it can disqualify you from features and, in egregious cases, draw a manual penalty.
- Write it by hand, with a generator, or via a CMS plugin (WordPress sites have several solid options). Hand-written gives you the most control; plugins scale better across hundreds of pages. Either way, the markup has to render in the page source, not get injected so late that crawlers miss it.
- Match the type to the content. FAQ schema on a page with no FAQs is the kind of mismatch Google acts on.
- Test it in two places, because they answer different questions. Google's Rich Results Test tells you whether you qualify for a specific Google feature. The Schema.org Validator checks whether your markup is structurally valid against the vocabulary. Passing one does not guarantee the other.
- Keep it honest. Schema must describe content that is visible on the page. No marking up reviews you do not display, no prices you do not list.
- Then watch it. Schema is not set-and-forget. Google Search Console flags structured-data errors after the fact, and a template change or plugin update can quietly break markup that validated fine on launch day. This is where schema overlaps with technical SEO: it has to survive every redesign, migration, and CMS update, not just the first deploy.
The bottom line
Schema markup is the labeled map you hand the machines. It does not win on its own, but skipping it means showing up to the field without cleats. It is the kind of foundational, unglamorous work that quietly decides whether Google and the AI assistants understand you or guess at you.
If your site is running on guesswork, that is fixable, and it is exactly the kind of foundation we build into every answer engine optimization engagement. No jargon, no gatekeeping, we will show you what is implemented and why. Email us at admin@moonsauceagency.com and we will tell you straight where your schema stands and whether it is worth fixing.
Keep reading: What is structured data? · What is a featured snippet? · What is a knowledge graph? · Back to the glossary
Sources: Google Search Central, Intro to How Structured Data Markup Works · Google Search Central, General Structured Data Guidelines
