Schema.org Markup That Earns AI Citations

Search engines and the new AI answer engines both read your pages, but they read them differently than a person does. A person infers that the phone number in your footer is how to reach you and that the five stars near a review mean a rating. A machine has to guess unless you tell it. Schema.org is the free, shared vocabulary that lets you stop making them guess. Add it correctly and you make your business a clear, named thing on the web, which is exactly what a rich result or an AI citation needs. Here is which markup a service business needs and how to add it without shipping code you cannot check.

Schema.org is not a Google product and it is not a paid tool. It is an open vocabulary founded by Google, Microsoft, Yahoo, and Yandex, and it defines the words the whole web agrees to use for things like a business, a service, a review, or an article. When you add it to a page, you are labeling the page's meaning in a language every major search engine and answer engine already understands. You can read the full vocabulary at schema.org. You do not need to read all of it. A service business needs a short list of types, and the rest is noise for your purposes.

This is one lever in the same public-data system we run before we build anything, the five-phase system that starts with the Census and ends with a site engineered to be found. Structured data is a small part of that last phase with an outsized payoff. It is free, it is standardized, and most competitors either skip it or add it wrong. Here is the method.

#Why explicit markup matters more now

For years, structured data mostly bought you a chance at a rich result in Google: a star rating under a listing, an FAQ that expands in the results, a business card with your hours. Those still matter. But a second reader arrived. AI answer engines and the generative results inside search now try to answer a question directly and cite the sources they pulled from. This shift has its own name in the trade, generative engine optimization or answer engine optimization, and structured data is one of the clearest signals you can give it.

The reason is simple. An answer engine has to decide which pages describe a real, trustworthy entity and what those pages actually claim. Prose can be ambiguous. A block of schema.org markup is not. It states, in a machine-readable form, that this is an accounting firm, in this city, offering these services, with this rating, and these are the questions it answers. That does not force a citation. But it removes the ambiguity that keeps a cautious engine from citing you at all. Reports from the SEO field describe explicit entity markup helping pages surface in AI answers, and the mechanism is exactly this: you made your meaning unambiguous, so a machine could use it without guessing.

#The types a service business actually needs

The schema.org vocabulary has hundreds of types. You need a handful. Each one below answers a specific question a machine would otherwise guess at. Match the type to the page it describes:

• Organization or LocalBusiness. The identity of the business itself, usually on the home page and the about page. LocalBusiness is the local subtype, and there are more specific ones under it, such as a professional service or a medical business. Core fields: legal name, url, logo, address, telephone, and the same-as links to your profiles.
• Service. One per service you offer, on that service's page. It names the service, ties it to the provider (your Organization), and can state the area served. This is how you tell an engine you do commercial roof repair in these counties, not just that the words appear on a page.
• FAQPage. The questions and answers a page genuinely publishes, marked so both Google and answer engines can lift a clean question-and-answer pair. Only use it for content the visitor can actually read on the page.
• Article. For a blog post or guide. It carries the headline, author, publish date, and publisher, which is what lets an engine attribute the piece to you and place it in time.
• BreadcrumbList. The trail that shows where a page sits in your site, such as Home, Services, then this service. It helps engines understand your structure and can show a cleaner path in results.
• Review and AggregateRating. A single review or a rollup of many, but only when the ratings are real, collected honestly, and visible on the page. This is the most abused type, so it is the one to treat most carefully.

That is the entire list for most service businesses. If you run one location, one Organization or LocalBusiness block plus a Service block per service plus an FAQPage where you publish real FAQs covers the ground. Add Article on your content and BreadcrumbList sitewide. Resist the urge to mark up everything. More types do not help; correct types on the right pages do.

#Add it as JSON-LD, in one clean block

There are three formats for schema.org markup, but you only need one. JSON-LD is the format Google recommends, and it is the easiest to live with. Instead of weaving labels through your visible HTML, you put a single script block on the page that holds a structured object describing the page. The full field-by-field reference lives in the Google Search Central structured-data docs, which list exactly which properties each type supports and which ones Google requires versus recommends. Work through it in this order:

1. Open the Google structured-data doc for the type you are adding. It lists the required fields and the recommended ones. Start with required, then add recommended where you have real data.
2. Write one JSON-LD object per meaningful thing on the page. A service page typically carries a Service block and a BreadcrumbList block; a home page carries the Organization or LocalBusiness block.
3. Fill every field from the visible page. The business name, address, phone, hours, and links must match what a visitor sees and what your Google Business Profile shows. Copy them, do not retype from memory.
4. Connect the entities. Give your Organization a stable identifier and reference it as the provider on each Service, so an engine reads one connected business rather than several loose fragments.
5. Place the block in the page head or body. In a modern site it is rendered server-side so it is present in the initial HTML, not injected later by a script an engine might not run.

If your site is a content platform or a custom build, this markup should be generated from the same data that renders the visible page, not hand-written per page. When the address is one value used in both the footer and the JSON-LD, the two can never drift. That is how we build it, and it is why a page's markup stays true to the page as the site changes. If your stack cannot do that yet, that is a web build problem worth fixing before you scale the markup.

#Validate every page before you trust it

Unvalidated structured data is a liability, not an asset. A typo in a field name or a missing required property means the markup silently does nothing, and you will not know unless you check. There are two free tools, and you should run both, because they answer different questions.

• The Rich Results Test answers the Google question: is this page eligible for a Google rich result, and which one? Paste the URL or the code, and it reports the rich-result types it detected, plus any errors or warnings Google specifically cares about. This is the tool that tells you whether your FAQ or your business card can actually appear.
• The Schema Markup Validator answers the vocabulary question: is this valid schema.org, regardless of what Google chooses to display? It catches structural mistakes and types the Rich Results Test ignores because Google does not render them. Since answer engines read the whole vocabulary, not just Google's rich-result subset, this check matters for AEO even when the Rich Results Test is quiet.

Run the page through both. Fix every error. Read the warnings and fix the ones that reflect missing real data. A warning that you have no rating is fine if you have no rating; a warning that a required field is missing is not. Then, once the page is live, watch the Enhancements and structured-data reports in Search Console over the following weeks, because that is where Google reports problems it finds on the live page at scale, not just on the one URL you tested. Pair this with the query work in mining Search Console so you are reading the same console for both jobs.

#What to prioritize by business type

The same short list applies to everyone, but the order of value shifts with what you do:

• Professional services. Lead with Organization or the professional-service LocalBusiness subtype, a Service block per practice area, and an FAQPage on the questions clients actually ask. Your buyers research before they call, so clear entity and service markup is what puts you in the consideration set.
• Healthcare and wellness. The medical-business subtypes carry fields for specialties and the conditions or services you address, and accuracy is not optional here. An address, hours, or a service that does not match reality is a trust problem before it is an SEO problem. Validate ruthlessly.
• Logistics and industrial services. Service blocks with a clearly stated area served do the heavy lifting, because your buyers are filtering on coverage and capability. Pair the markup with the coverage read in mapping competitor coverage so you mark up the services and areas where you can actually win.

Notice what is not on any list: marking up things you do not really offer, inventing reviews, or padding an FAQPage with questions no one asks. Those do not earn citations. They earn the spam flag in the callout above.

#Common mistakes to avoid

• Marking up content that is not visible on the page. If the rating, price, or answer is not there for a visitor to read, do not put it in the markup. This is the fastest way to lose eligibility.
• Letting the markup drift from the Google Business Profile. A mismatched address or phone across your site, your JSON-LD, and your profile tells every engine to trust none of them.
• Adding types you do not need. A pile of loosely connected schema blocks is harder for an engine to reason about than a few accurate, connected ones.
• Shipping without validating. Run both the Rich Results Test and the Schema Markup Validator on every template before it goes live, then watch Search Console for problems at scale.
• Hand-authoring markup per page. The moment a fact lives in two places you maintain by hand, one of them will go stale. Generate the JSON-LD from the same data that renders the page.

Structured data is one of the few free levers where the whole standard is public, the validation tools are free, and most competitors either skip it or get it wrong. Open the schema.org page for the type you need, add it as JSON-LD from your real page data, and validate with both tools before you trust it. Then keep it consistent with your profile forever. When you want the markup generated from your data and kept true to the page as the site grows, see how we handle SEO or run discovery and we will read your current markup for you.