Schema markup for AI search: a working implementation guide

Most schema guides describe what LocalBusiness schema is. Fewer show the actual JSON-LD, unedited, that you can paste into a page and adapt. That's the gap this piece fills. Schema markup for AI search works differently from schema written for blue links: an answer engine reads your structured data to decide whether it can state a fact about your business confidently enough to cite you. What follows is localbusiness schema, multi-location variants, FAQPage, HowTo, and a healthcare version, each with real properties checked against the schema.org vocabulary rather than invented ones. If you manage Google Business Profiles for Indian local businesses, or you're the person an agency hands the "add schema" task to without a developer on staff, this is written for you. For the platform-level version of this — write-back that actually reaches Google's live listing, not just a suggested edit — see how Angryturtle's Edit to Google works.

One thing to settle before any code: schema markup does not cause a page to rank higher, and it does not guarantee a citation inside an AI answer. It disambiguates what's already on the page so a machine — Google's indexing systems, an AI Overview, a retrieval layer feeding ChatGPT or Perplexity — can parse "this is a business, this is its name, this is its phone number" instead of guessing from unstructured text. That disambiguation makes a page eligible for certain rich results and easier to cite accurately. It doesn't make the underlying content better, and it can't compensate for a business with no reviews, an unclaimed GBP, or wrong hours. Keep that distinction in mind through the rest of this piece, because a lot of schema advice online implies the opposite.

1. What schema markup actually does for AI search
2. Structured data vs schema markup: what's the real difference
3. LocalBusiness schema: the base implementation
4. Adding schema without a developer
5. Multi-location schema: does every location need its own markup
6. HowTo schema: when to use it, and when not to
7. Healthcare schema for AEO
8. Validating schema before you publish
9. FAQ

Schema markup for AI search: what structured data actually does

Google's own documentation on AI features is direct about this: there's no special schema markup that makes a page qualify for AI Overviews specifically, and the guidance on AI features and your website says as much. AI Overviews and AI Mode draw from the same crawled, indexed content that ranks in ordinary search, plus the same signals — E-E-A-T, page quality, relevance. Schema doesn't sit outside that pipeline as some separate AI-only lever.

What schema does is remove ambiguity from the content that pipeline already has to parse. A restaurant's address might appear on the page as "12, MG Road, opposite the old cinema hall, Bengaluru" — perfectly readable to a human, mildly ambiguous to a machine trying to extract a structured street address, locality, and postal code. LocalBusiness schema states those fields explicitly. An AI system building an answer from multiple sources doesn't have to infer which string on the page is the address; it's told. That's the mechanism, and it's the whole mechanism — not a ranking boost, not a citation guarantee, just less inference required.

Angryturtle's own site runs FAQPage and Service schema sitewide, plus server-rendered heading anchors on long-form pages, which is one reason this piece links to specific anchors rather than whole pages throughout. It's a practice, not a claim about what it's earned us — we're not going to dress up an internal habit as a case study with numbers attached to it. The rest of this guide covers the specific types worth implementing and the code for each, starting with the one most local businesses skip entirely: structured data on the site itself, separate from whatever's already inside your Google Business Profile.

Structured data vs schema markup: what's the real difference

People use these two terms interchangeably, and mostly that's fine, but there's a real distinction worth having straight before writing any code. Structured data is the broader concept: any information organized in a predictable, machine-readable format — a spreadsheet is structured data, a database table is structured data, XML is structured data. Schema markup is one specific implementation of structured data, built on the vocabulary maintained at schema.org and expressed in a page using one of three syntaxes: JSON-LD, Microdata, or RDFa.

JSON-LD has effectively won that syntax competition for web content. It's a block of JSON dropped into a <script type="application/ld+json"> tag, separate from the visible HTML, which is precisely why it's the format every example in this piece uses — it's the one Google recommends and the one that's easiest to add without touching the rest of a page's markup.

So: all schema markup is structured data, but not all structured data is schema markup. When someone says "add structured data to your site" in a local SEO context, they almost always mean "add schema.org JSON-LD," and that's what the rest of this guide is about. The underlying vocabulary itself — what a "PostalAddress" is, what properties a "LocalBusiness" can carry — comes from the schema.org specification, not from Google, and it's maintained collaboratively across search engines, not owned by any one of them. Full terminology is in the structured data glossary entry and the schema.org glossary entry if you want the short-form definitions side by side.

LocalBusiness schema: the base implementation

Every other section in this guide assumes you have this one in place first. LocalBusiness is the schema.org type for a business with a physical location or a defined service area, and it's the foundation Google's own local business structured data documentation is built around.

Here's a working example for a single-location business:

{
 "@context": "https://schema.org",
 "@type": "LocalBusiness",
 "name": "Anand Family Dental Clinic",
 "image": "https://example.com/images/clinic-front.jpg",
 "url": "https://example.com",
 "telephone": "+91-80-1234-5678",
 "priceRange": "₹₹",
 "address": {
 "@type": "PostalAddress",
 "streetAddress": "12 MG Road",
 "addressLocality": "Bengaluru",
 "addressRegion": "Karnataka",
 "postalCode": "560001",
 "addressCountry": "IN"
 },
 "geo": {
 "@type": "GeoCoordinates",
 "latitude": 12.9758,
 "longitude": 77.6045
 },
 "openingHoursSpecification": [
 {
 "@type": "OpeningHoursSpecification",
 "dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday"],
 "opens": "09:00",
 "closes": "18:00"
 },
 {
 "@type": "OpeningHoursSpecification",
 "dayOfWeek": ["Saturday"],
 "opens": "09:00",
 "closes": "14:00"
 }
 ],
 "sameAs": [
 "https://www.facebook.com/anandfamilydental",
 "https://www.instagram.com/anandfamilydental"
 ]
}

Every property in that block exists in the schema.org LocalBusiness vocabulary or one of its referenced types (PostalAddress, GeoCoordinates, OpeningHoursSpecification). Nothing there is invented. The sameAs property is worth calling out specifically — it's what ties this schema to the business's other verified profiles across the web, and it's a real contributor to the entity confidence an AI system assigns before it decides whether to cite a source at all, covered in more depth in the entity authority glossary entry.

A word on placement: this JSON-LD goes in the <head> of the page it describes — usually the homepage or a dedicated location page — not floating loose in a template that gets duplicated across pages with the wrong address attached. That specific mistake, one clinic's address showing up in another clinic's schema because a template got copy-pasted, is common enough to name directly, and it's exactly the kind of NAP mismatch covered in the NAP consistency glossary entry.

Adding schema without a developer

You don't need a developer to get a correct LocalBusiness block onto a page, and the barrier here is smaller than most guides make it sound. Three realistic paths exist, and which one fits depends on what platform the site already runs on.

If the site runs on WordPress, a plugin like Yoast SEO or Rank Math generates LocalBusiness schema from fields you fill in through a normal admin form — business name, address, hours — no code touches the page directly. The plugin handles the JSON-LD output. If the site is on a platform without a schema plugin, a free generator (search "JSON-LD LocalBusiness generator") produces the block from a form, and pasting that block into the page's <head> — most CMS platforms have a "custom HTML" or "header scripts" field for exactly this — takes a few minutes once you know where that field lives in your specific CMS.

The third path is the one this guide has been building toward the whole time: copy one of the code blocks above or below, replace the placeholder values with your actual business details, and drop it in. The syntax doesn't change between businesses. Only the values inside the quotes do. That's true whether you're adding LocalBusiness, FAQPage, or HowTo — the structure is fixed, the content is yours.

Where this gets genuinely harder is at scale — fifty locations each needing their own correct block, kept in sync as addresses and hours change. That's a platform problem, not a "hire a developer for one page" problem, and it's the specific gap Angryturtle's self-serve platform and Rank OS both close, whether a business's own team runs the corrections or Angryturtle's team does. More on the multi-location version of that problem in the next section.

Multi-location schema: does every location need its own markup

Yes, each physical location needs its own LocalBusiness block with its own address, phone number, and hours. A single generic block describing "the company" in the abstract, reused across every location page, is the most common multi-location schema mistake — it tells an AI system nothing about which specific branch a searcher is asking about, and worse, if the address in that shared block matches only one location, every other location's page is now carrying incorrect structured data about itself.

The cleaner pattern links each location's LocalBusiness entry back to a parent Organization using the branchOf property:

{
 "@context": "https://schema.org",
 "@type": "LocalBusiness",
 "name": "Anand Family Dental — Indiranagar",
 "branchOf": {
 "@type": "Organization",
 "name": "Anand Family Dental",
 "url": "https://example.com"
 },
 "address": {
 "@type": "PostalAddress",
 "streetAddress": "45 100 Feet Road",
 "addressLocality": "Bengaluru",
 "addressRegion": "Karnataka",
 "postalCode": "560038",
 "addressCountry": "IN"
 },
 "telephone": "+91-80-9876-5432",
 "openingHoursSpecification": {
 "@type": "OpeningHoursSpecification",
 "dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday", "Saturday"],
 "opens": "09:00",
 "closes": "19:00"
 }
}

branchOf is a genuine LocalBusiness property, and it does real work here: it tells a machine that this specific branch belongs to a larger organization without merging the two into one confusing block. Each location page carries its own full LocalBusiness entry with this property pointing back to the same Organization name and URL every time — consistency in that shared value matters as much as the location-specific fields do.

A retail chain running eight branches across Mumbai and Pune, each with a page carrying this pattern correctly, is in a materially different position from the same chain running one generic "About Us" schema block site-wide. An AI system fielding "dentist near Indiranagar" has a specific, correctly-addressed entity to retrieve for that branch rather than an ambiguous corporate description that could apply to any of the eight. The operational side of keeping this correct as locations get added or addresses change is covered in multi-location local SEO services and the multi-location SEO glossary entry.

HowTo schema: when to use it, and when not to

HowTo schema exists for genuine step-by-step instructions — content that walks a reader through a process with a defined sequence, not every blog post that happens to contain a list. That distinction matters because Google has narrowed how and where HowTo results display over time, and marking up content that isn't actually instructional just to get the schema on the page produces no benefit and a technically inaccurate markup.

Where it's genuinely useful: "how to claim your Google Business Profile," "how to respond to a negative review," "how to fix NAP inconsistency across directories" — content with real, ordered steps a reader follows to complete a task. Here's the structure:

{
 "@context": "https://schema.org",
 "@type": "HowTo",
 "name": "How to claim your Google Business Profile",
 "step": [
 {
 "@type": "HowToStep",
 "name": "Search for your business",
 "text": "Go to Google Maps and search for your business name and city to see if a listing already exists."
 },
 {
 "@type": "HowToStep",
 "name": "Request ownership",
 "text": "If a listing exists but you don't manage it, click 'Claim this business' and follow the ownership request flow."
 },
 {
 "@type": "HowToStep",
 "name": "Verify",
 "text": "Google will offer a verification method — phone, email, or postcard depending on the business — and the listing becomes editable once verification completes."
 }
 ]
}

Notice the steps in that block are named and ordered through the step array itself, not narrated in prose as "first... second... third." That's not a stylistic preference here, it's how the schema actually works: position is carried by array order and the optional position property, not by ordinal language in the text. Write the surrounding page copy the same way — plain connectors like "next" or "once that's done," or a real numbered list, never a first/second/third crutch in the prose.

If your content doesn't have genuine sequential steps — an explainer, an FAQ, a comparison — HowTo is the wrong type regardless of how the page is formatted. Use FAQPage schema for question-and-answer content instead, which is exactly the pattern this piece's own FAQ section below uses, described more fully in the QAPage schema glossary entry for the related question-answer variant. More on the type itself is in the HowTo schema glossary entry.

Healthcare schema for AEO

Healthcare listings answer to a stricter accuracy bar than most local categories, and that's true for AI-generated answers specifically — a wrong plumber recommendation is an inconvenience, a wrong medical specialty match carries a different kind of consequence, which is part of why review-verification and listing-accuracy standards run tighter here across every platform, not just Google's own. The schema type that carries that specificity is MedicalBusiness, a LocalBusiness subtype with fields the generic version doesn't need.

{
 "@context": "https://schema.org",
 "@type": "MedicalBusiness",
 "name": "Kolkata Multispecialty Clinic",
 "medicalSpecialty": "Cardiovascular",
 "address": {
 "@type": "PostalAddress",
 "streetAddress": "22 Park Street",
 "addressLocality": "Kolkata",
 "addressRegion": "West Bengal",
 "postalCode": "700016",
 "addressCountry": "IN"
 },
 "telephone": "+91-33-2345-6789",
 "openingHoursSpecification": {
 "@type": "OpeningHoursSpecification",
 "dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday", "Saturday"],
 "opens": "10:00",
 "closes": "20:00"
 }
}

A clinic offering multiple specialties needs a separate MedicalBusiness entry per specialty, or a separate department entry under a parent Organization for each — the same underlying problem as the multi-location case above, just with specialties standing in for branches. A general physician's listing that lumps cardiology, dermatology, and orthopedics under one undifferentiated block gives a retrieval system nothing to match against a specific query like "cardiologist near Park Street," even if the clinic genuinely offers that specialty.

This is also where a directory like Practo carries weight that the schema alone doesn't replace — Practo's structured specialty and consultation data sits on top of, not instead of, correct on-site markup and a well-maintained GBP. Deeper coverage of how that interacts with AI-driven healthcare discovery is in healthcare AI search, the broader healthcare local SEO treatment, and the underlying review signals glossary entry, since patient review data feeds citation confidence in ways that are specific to this vertical.

Validating schema before you publish

Publish schema with a syntax error or a mismatched value and the practical result is usually nothing — no error message on the page, no obvious sign anything's wrong, until you check months later and find the block was silently ignored the entire time. Validation before publishing isn't optional diligence here, it's the only way to know the markup actually did anything.

Two tools cover this. Google's Rich Results Test checks whether a specific page's markup is eligible for the rich results Google's own systems recognize, and it will flag missing required properties for the type you're using. The Schema Markup Validator, run by schema.org itself, checks the markup against the underlying vocabulary more broadly — whether a property genuinely exists on the type you've assigned it to, independent of what Google specifically does with it. Running both catches different failure modes: a technically valid schema.org block that still doesn't qualify for a Google rich result, and a block that would qualify for a rich result but contains a property that doesn't actually exist in the schema.org spec (a mistake this piece has been careful to avoid in every example above — every property, checked against schema.org directly rather than assumed). Paste the JSON-LD in, fix whatever's flagged, and only then does it go live. It's a five-minute step that a rewritten template or a copy-pasted block from another location page skips constantly, which is exactly how the wrong-address-in-the-wrong-branch mistake from the multi-location section above actually happens in practice. Businesses managing this across many locations at once tend to fold validation into whatever process already governs GBP write-back, rather than treating it as a separate one-off task.

FAQ

Does each location need its own schema markup, or can one block cover a chain? Each physical location needs its own LocalBusiness block with its own address, phone number, and hours, linked back to a shared parent Organization through the branchOf property. One generic block reused across every location page tells an AI system nothing useful about which specific branch a searcher means, and risks attaching the wrong address to the wrong page entirely.

How do I actually implement LocalBusiness schema for AI search visibility? Build a JSON-LD block using the schema.org LocalBusiness vocabulary — name, address, telephone, openingHoursSpecification, geo, and sameAs at minimum — and place it in the page's <head>. It doesn't create AI visibility on its own; it removes ambiguity from information the page already contains, which makes accurate citation more likely without guaranteeing it.

Can I add schema without hiring a developer? Yes. A WordPress SEO plugin like Yoast or Rank Math generates it from form fields, a free JSON-LD generator produces a block you paste into a CMS's header field, or you copy a working example like the ones in this piece and swap in your own business details. The syntax stays fixed; only the values change.

When should I use HowTo schema, and when should I skip it? Use it for genuine sequential instructions — a process with real, ordered steps a reader follows to complete a task. Skip it for explainers, comparisons, or FAQ-style content that doesn't have an actual step sequence; marking up non-instructional content as HowTo doesn't earn any benefit and misrepresents the content.

Does schema markup help a business appear in Google's AI Mode or AI Overviews? It helps indirectly, by making the page's information easier for those systems to parse accurately — Google's own documentation is explicit that there's no dedicated schema requirement for AI feature eligibility. Schema doesn't cause inclusion in an AI Overview; the same relevance and quality signals that govern ordinary ranking still govern that too.

What's different about schema for healthcare AEO? Healthcare listings use MedicalBusiness, a LocalBusiness subtype that carries a medicalSpecialty property generic schema doesn't have. Clinics with multiple specialties need separate entries per specialty rather than one undifferentiated block, because a query like "cardiologist near Park Street" needs a specific specialty match to retrieve correctly.

How do I validate schema before publishing it? Run the markup through Google's Rich Results Test and the Schema Markup Validator run by schema.org. The first checks eligibility for Google's specific rich results; the second checks the markup against the underlying schema.org vocabulary itself, catching properties that don't actually exist on the type you've assigned them to.

What's the actual difference between structured data and schema markup? Structured data is the broad category — any machine-readable, predictably organized information. Schema markup is one specific implementation of it, built on the schema.org vocabulary and expressed in JSON-LD, Microdata, or RDFa. In practice, when someone in local SEO says "add structured data," they almost always mean "add schema.org JSON-LD," which is what this entire guide covers.

This piece includes working JSON-LD examples checked against the schema.org vocabulary at the time of publication. Schema.org's spec and Google's rich-result eligibility requirements both change over time — verify current property support before shipping any of these blocks to production, and if something here looks outdated, let us know and we'll correct it.