Schema markup is the layer of code that tells search engines and AI systems what your content actually means rather than making them infer it from the words on the page. As answer engines increasingly decide what to cite rather than what to rank, structured data has moved from a technical nicety to the practical difference between being quoted in an AI answer and being invisible to it. This guide covers which schema types matter, how to implement them, and how to check the result.
Key Takeaways
- Schema markup does not directly improve rankings. It improves machine understanding, which is what determines whether a page can be cited in an AI answer or shown as a rich result.
- Five types cover most business websites: Organization, LocalBusiness, Service, FAQPage and Article. Most sites are missing at least three.
- Use JSON-LD, not microdata. It is what Google recommends, it sits separately from your content, and it does not break when the page design changes.
- Every entity needs an @id. Without it, five pages describing your business look like five different businesses to a machine.
- Schema must match visible page content. Marking up FAQs that do not appear on the page is a guidelines violation, not a shortcut.
- Validate everything with the Rich Results Test and the Schema.org validator. Broken JSON fails silently, with no warning.
What Schema Markup Actually Does
A search engine reading your page sees text. It can infer a great deal from that text, but inference is guesswork. Schema markup removes the guesswork by stating facts in a format machines read directly: this is a business, this is its phone number, these are the areas it serves, this block is a question and this is its answer.
A useful way to think about it: your page content is written for people, and your schema is the same information written for machines. When both agree, a search engine can act on the information with confidence. When schema is missing, everything has to be inferred, and inference loses to certainty when a system is deciding which of ten pages to cite.
This is why schema matters more in an AI-search environment than it did in a purely blue-link one. Ranking tenth still put you on page one. Not being cited in an AI answer puts you nowhere.
The Five Types Most Businesses Need
1. Organization
Establishes who the business is: name, logo, URL, and social profiles via the sameAs property. This is the entity anchor. Everything else references it.
2. LocalBusiness
For any business serving a physical area. Covers address or service area, phone, opening hours, price range and payment methods. For service-area businesses that do not want a public address, this is where areaServed replaces a street address.
3. Service
Describes each individual service: what it is, who provides it, where it is offered. This is the type most commonly missing entirely. A site with ten service pages and no Service schema is asking search engines to work out what each page offers from the prose.
4. FAQPage
Marks up question-and-answer pairs. Directly useful for AI answers, because a question with a clean answer attached is exactly the shape an answer engine is looking for. The questions must be genuinely visible on the page.
5. Article
For blog posts and guides. Covers headline, author, publication and modified dates. The author field matters more than it used to, since named authors with real credentials feed the experience and expertise signals search engines weigh.
JSON-LD, and Why the Alternatives Are Worse
There are three ways to write schema. Only one is worth using.
JSON-LD sits in a script block, usually in the head or footer, entirely separate from your visible HTML. It is what Google recommends. Because it is separate, a design change cannot break it, and it can be read and edited as a single coherent block.
Microdata and RDFa both weave attributes through your HTML tags. They work, but they are fragile: any change to the page markup risks breaking the structured data invisibly, and nobody notices until a rich result quietly disappears.
If you inherit a site using microdata, it is not urgent to migrate. If you are adding schema now, use JSON-LD.
The @id Property: The Part Most Implementations Get Wrong
This is the single most common mistake, and it undoes much of the benefit.
If your homepage declares an Organization, your contact page declares a LocalBusiness, and each service page declares a provider, a machine reading them has no way to know these describe the same company unless you say so explicitly.
The @id property solves this. Give the business one canonical identifier, such as https://example.com/#organization, declare the full entity once, and then reference that same @id everywhere else instead of describing the business again. Every mention then resolves to one entity rather than creating a new one.
The practical symptom of getting this wrong: a site with schema on every page that still fails to build a coherent entity, because it has been describing a slightly different business twenty times over.
Not sure what schema your site is actually outputting?
Most sites have less than they think, and what is there is often duplicated or disconnected. Checking takes minutes and the findings are usually surprising.
Rules Worth Knowing Before You Start
- Schema must match visible content. Marking up FAQs that do not appear on the page, or reviews that are not shown, is a guidelines violation and can cost you rich results entirely.
- Do not mark up your own reviews on your own site. Self-serving review markup for a business on its own pages is specifically disallowed. Reviews belong in your content and on third-party platforms.
- One FAQPage per URL. Two FAQ blocks on the same page, which commonly happens when a plugin and a manual snippet both add one, is duplicate schema and can result in both being ignored.
- Do not claim events you do not host. Event markup is for the organiser or an authorised ticket seller. Marking up someone else’s event on your page reads as claiming you run it.
- Keep it accurate. Hours, phone numbers and addresses in schema that disagree with the page or with your Google Business Profile actively weaken the signal rather than strengthening it.
How to Implement It
Through your SEO plugin
Yoast and Rank Math both generate Organization, WebSite, WebPage and Breadcrumb schema automatically once configured. This handles the foundation. Where they tend to fall short is Service schema and page-specific FAQ markup, which usually need to be added separately.
Through a code snippet
For anything the plugin does not cover, a snippet that outputs JSON-LD on specific pages gives full control. This is the usual approach for Service schema across a set of service pages, since it lets one definition of the business be reused everywhere via @id.
Through the page builder
Some builders, including Elementor’s accordion widget, can output FAQPage schema from the content already on the page with a single toggle. Where that exists, use it rather than hand-writing a second copy, and make sure you are not doing both.
Validating: Two Tools, Both Free
Broken JSON-LD fails silently. A missing comma means the entire block is ignored, with no error shown anywhere. Always validate.
- Google Rich Results Test. Shows what Google can detect and which rich results a page qualifies for.
- Schema.org Validator. Stricter, and catches structural problems the Google tool tolerates.
Use both. A page can pass the Rich Results Test while still containing errors that matter to other systems reading your markup.
What This Has to Do With AI Search
Traditional search ranked pages. Answer engines synthesise a response and cite sources. That changes what a website is optimising for: the goal is now to be the source a system trusts enough to quote.
Structured data helps in three specific ways. It states facts unambiguously, so a system does not have to infer them. It connects entities via @id, so the business is understood as one thing across many pages. And it presents question-and-answer pairs in exactly the shape an answer engine wants when it is looking for something to quote.
None of that replaces good content. A well-marked-up page with nothing to say will not be cited. But between two pages with equally good content, the one a machine can parse with certainty is the one that gets used. Our AI engine optimization checklist covers the strategy side, and AEO vs SEO for Wisconsin businesses explains how the two disciplines differ.
A Worked Example: Service Schema Done Properly
Abstract advice about schema is less useful than seeing the shape of it. Here is what Service schema looks like on a single service page, referencing the business rather than describing it again:
The Service block names the service, states what type of service it is, describes it in a sentence, gives the page URL, and then points at the business using provider with an @id rather than repeating the company name, address and phone. The business itself is declared once, on the homepage, with that same @id.
That structure is what makes ten service pages describe one company offering ten services, rather than ten companies each offering one. It is a small implementation detail with a large effect on how the site is understood as an entity.
Where sites commonly get this wrong is repeating the full business details inside every Service block. It is not fatal, but it produces a graph full of near-identical entities that a machine has to reconcile, which is exactly the guesswork schema exists to remove.
The Errors That Come Up Most Often
- A trailing comma. Valid in JavaScript, invalid in JSON. Breaks the entire block silently.
- Unescaped quotation marks inside a text value. Same effect. This is the most common cause of an FAQ block that validates locally and fails live.
- Schema describing content that is not on the page. FAQs in the markup that a visitor cannot see is a guidelines violation.
- Two plugins both adding schema. A page ends up with two Organization blocks or two FAQPage blocks, and both may be disregarded.
- Details that contradict the page. Opening hours in schema that disagree with the hours in the footer, or a phone number that differs from the one in the header.
- Copying an example without changing the URLs. More common than it should be. Always check that
@idvalues point at your own domain.
All of these are caught in seconds by validation, which is the argument for validating every page you touch rather than assuming the first implementation was right.
Frequently Asked Questions
Does schema markup improve search rankings?
Not directly. Schema is not a ranking factor in the way content quality and links are. What it does is make your content machine-readable, which determines eligibility for rich results and materially affects whether an AI answer engine can confidently cite your page. The effect is real, but it operates through understanding rather than through ranking.
Which schema types does a typical business website need?
Five cover most cases: Organization for the business entity, LocalBusiness for location and service-area details, Service for each individual service offered, FAQPage for question-and-answer content, and Article for blog posts. Most sites already have Organization from their SEO plugin and are missing Service and FAQPage entirely.
What is the difference between JSON-LD and microdata?
JSON-LD sits in a separate script block, independent of your visible HTML, and is the format Google recommends. Microdata weaves attributes through the HTML itself, which makes it fragile: a design change can break the structured data without any visible sign. Use JSON-LD for anything new.
Can I have too much schema on a page?
Yes, in two ways. Duplicate schema, such as two FAQPage blocks on the same URL, can cause both to be ignored. And schema describing content that is not visible on the page violates guidelines. More is not better. Accurate and non-duplicated is better.
How do I check whether my schema is working?
Run the page through Google’s Rich Results Test and the Schema.org Validator. The first shows which rich results the page qualifies for. The second is stricter and catches structural errors. Broken JSON-LD fails silently, so validation is not optional.
Do I need schema if I already use an SEO plugin?
Probably. Plugins reliably handle the foundation: Organization, WebSite, WebPage, Breadcrumb. What they generally do not add is Service schema for each service page, or FAQ markup for specific content. Check what your site is actually outputting rather than assuming the plugin covers everything.
Where to Start
If you are adding structured data to an existing site, the order that produces results fastest: confirm Organization and LocalBusiness are correct and use a consistent @id, add Service schema to every service page, add FAQPage where genuine FAQs already exist on the page, then validate the lot.
That sequence builds the entity first and the detail second, which is the order machines read it in. If you want a view of what your site is currently emitting before deciding what to add, that is a straightforward audit rather than a project.