Schema markup for AI search. Which types matter, how to layer them, and the validation step that catches the bugs.

What schema does for AI search

Schema markup is structured metadata embedded in a web page that tells consuming systems what the page is about, who wrote it, and how its various pieces relate to each other. The dominant format on the modern web is JSON-LD, a JSON-encoded variant of the schema.org vocabulary, dropped into the page inside a <script type="application/ld+json"> block.

For traditional Google SEO, schema's main job has been to trigger rich results: the star ratings, FAQ accordions, product prices and recipe panels that appear in the SERP. Pages without schema can still rank; they just do not get the rich-result rendering.

For AI search, schema does a second job that has become equally important. AI systems use the structured data as a confidence signal during their answer generation. The schema confirms what the page is about, which entity owns the content, who wrote it, and how the page relates to other pages. That confidence layer affects which pages get cited and which get summarised but not attributed. See entity SEO for the entity-side treatment and E-E-A-T explained for the expertise side.

The shift from rich results to confidence signal

Worth saying clearly because clients still ask. Three years ago, schema was a SERP feature: add it, get rich results, win extra clicks. The math was straightforward. Today, schema does that plus a second job that is harder to measure: it tells AI systems how to read the site.

The visible signs of the shift across client sites in 2025 and 2026:

• AI Overview citation pickup correlates with schema completeness. Pages with valid Organization, Person and Article schema get cited more often than equivalent pages without it. See the AI Overviews chapter.
• Entity disambiguation is harder without schema. AI clients struggle to identify which "Smith Plumbing" they are reading when there is no Organization schema with sameAs links to disambiguate.
• FAQ blocks without FAQPage schema get extracted less reliably. The schema does not change what the FAQ says; it makes the structure parseable to the AI extractor.

The implication for an Australian business. Schema is no longer optional even if you do not care about rich results. It is now the cheapest reliable signal you can send to AI clients about who you are and what your pages are.

The five types that matter most

Schema.org defines hundreds of types. Most sites do not need most of them. Five types cover roughly 80 percent of the AI-search benefit for a typical Perth small business.

1. Organization

The single most important type. Defines the business entity that owns the site. Include name, url, logo, telephone, address, and sameAs (an array of links to the brand's profile pages: Facebook, LinkedIn, Instagram, GMB, Wikipedia if applicable). Place in the global JSON-LD that appears on every page. Reference by @id from every other schema block.

2. Person

Defines named individuals associated with the site. The most common use is for content authors: every article should have a Person in its schema, linked via author. Include name, jobTitle, worksFor (linked by @id to the Organization), and a url pointing to the author's bio page. On YMYL topics this is moving from helpful to required.

3. LocalBusiness

For any business with a physical presence. Subtypes (ProfessionalService, HomeAndConstructionBusiness, MedicalBusiness, etc.) further refine the business category. Include name, address, telephone, geo coordinates, openingHoursSpecification, and links to the Organization. Critical for local search visibility and for local-intent answers across all AI clients.

4. Article

For content pages: pillars, clusters, blog posts. Include headline, description, datePublished, dateModified, inLanguage, author (linked by @id to a Person), publisher (linked to Organization), and isPartOf if the article belongs to a wider Course or Series.

5. FAQPage and HowTo

Use FAQPage for pages with genuine FAQ blocks. Each Question has a name (the question) and an acceptedAnswer with Answer.text. Use HowTo for genuinely step-by-step content (recipes, tutorials, how-to guides). Each HowToStep has a name and a text. The "genuine" qualifier matters: padding FAQ schema onto pages without real FAQs is a known violation pattern that Google has tightened on.

Other types worth knowing

Product and Offer for e-commerce. Service for service businesses. BreadcrumbList for the breadcrumb trail. Course for educational content (the Learn Hub pillars use this). Review and AggregateRating where the site has legitimate first-party reviews. Use what matches the content; do not pad.

The @graph and @id pattern

Most published schema examples on the web show inline schema: one entity per JSON-LD block, repeated wherever it is referenced. That works for tiny sites and becomes unmaintainable at scale.

The better pattern uses @graph and @id:

• @graph is a top-level array that contains multiple entity definitions in one block. Instead of separate Organization, Person, Article blocks, you have one @graph containing all three.
• @id is the unique identifier for each entity. By giving every entity a stable @id (typically the page URL plus a fragment, like https://example.com/#business), you can reference it from anywhere else without repeating its full definition.

The benefit. The Organization entity is defined once in the site's global JSON-LD. Every Article, Person and LocalBusiness on the site references the Organization by @id. When the business name changes (rare) or the phone number updates (more common), you change it in one place. The same applies to the named author who appears on every page.

This pillar guide and every cluster in the Learn Hub use the @graph pattern. View any cluster page's JSON-LD to see the pattern in practice.

Layering schema across page types

Different page types want different schema stacks. The mapping that works for most small business sites.

Homepage

Organization (or LocalBusiness as a subtype) plus WebSite. The homepage establishes the canonical entity for the site; the rest of the site references it.

About page

Organization reference plus Person schema for any named team members on the page. AboutPage as the page type.

Service pages

Service with provider linked to Organization, plus BreadcrumbList. For Australian businesses, include areaServed with the geographic scope.

Location pages (Perth, Fremantle, Joondalup, etc.)

LocalBusiness with the relevant areaServed and address data, plus BreadcrumbList. Each location page can have its own LocalBusiness entity if the business has multiple physical locations; if not, link back to the main one.

Pillar and cluster pages

Article referencing Person and Organization, plus BreadcrumbList, plus FAQPage if there is a genuine FAQ section, plus HowTo if the content is step-by-step. The pillar can additionally include Course with hasPart referencing the cluster URLs, as the Learn Hub pillars do.

Product pages (e-commerce)

Product with offers (Offer), brand and aggregateRating if you have legitimate first-party reviews. Be careful with Review schema; misuse here is a known penalty trigger.

Validation, the step everyone skips

The single most common preventable schema failure we see in client audits is invalid JSON-LD that nobody validated. The page looks fine to humans; the schema parses badly to machines; the AI clients get noise instead of signal.

The two free tools to use

• Google's Rich Results Test. Catches errors that would affect rich-result rendering on Google. Specifically useful because it tells you whether Google can read the schema cleanly.
• Schema.org's official validator. Broader check against the wider schema.org vocabulary. Catches issues the Google tool misses, particularly for types that do not have rich-result rendering.

The validation rhythm

1. Validate every template before pushing to production. One page per template type is enough for the initial validation.
2. Re-validate after any template change. Even small changes can break the JSON-LD.
3. Quarterly spot-check. Pick five to ten pages at random and validate. Catches drift from CMS field changes.
4. Validate after any major migration. Site moves, platform changes, theme updates all break schema reliably.

The validation step takes 60 seconds per page. Skipping it costs months of AI-search invisibility because the schema looks present but parses broken.

Common mistakes

Perth and WA context

Two patterns from running schema audits across Perth and WA client sites in 2026.

Trade and services businesses get the most out of LocalBusiness schema. A Perth plumbing or electrical business with valid LocalBusiness schema, accurate geo coordinates, complete openingHoursSpecification and consistent NAP across the site picks up more local-pack visibility and more local-intent AI answers. See trades SEO and the Google Business Profile chapter for the matching off-site work.

Multi-location businesses need the @id pattern most. A Perth professional services firm with offices in West Leederville and Fremantle needs separate LocalBusiness entities per location plus a parent Organization with branchOf or similar linkages. The @id pattern is the only sane way to manage this at scale. See SEO Fremantle and services Perth for the location structure pattern.

YMYL businesses cannot skip the Person schema layer. A Perth law firm, healthcare practice or financial services business needs valid Person schema for every named author or expert quoted on the site, with credentials in the hasCredential field where applicable. AI clients are visibly more conservative about citing unattributed YMYL content. See legal SEO and healthcare SEO.

For the wider context, the AI Search pillar covers the full visibility stack, the canonical tags chapter covers the URL-identity work that pairs with entity identity, and the entity SEO chapter covers the on-page side. For an entry-level diagnostic of your existing schema coverage, the free SEO audit includes the structured-data checks, and the full website audit service includes per-template validation across the site.