How AI Uses Schema Markup

Updated May 2026 • 8 min read

A Columbia family with two young kids, a golden retriever who came in muddy from the back yard, and a recurring "smells like dog" carpet problem opens ChatGPT and asks, "We need a carpet cleaning service in Columbia SC that's good with pet odors on wool berber, family-friendly chemistry (kids on the floor), can do an upholstery clean on a sectional, and has weekend availability. Who's good?" Two services appear in the answer. Both have implemented schema markup that the AI used to match the query attributes specifically. The other carpet cleaners in the area are not mentioned — partly because the AI couldn't confirm specific attributes from their schema-less content.

This article explains the specific ways AI assistants parse and use schema markup — turning the abstract concept into operational understanding.

Layer 1: Entity Identification

The first thing AI assistants extract from schema is "what entity is this?" The @type field in JSON-LD declares the entity type:

For our Columbia carpet cleaner, the homepage schema might declare @type: "CarpetCleaningService" or, more specifically, @type: "HouseCleaningService" with categoryServices noting carpet specialization. The AI extracts this identification and slots the business into its internal taxonomy.

Why this matters: when a query specifies "carpet cleaning service in Columbia," the AI uses the entity type as the primary category filter. Services that declare the right entity type get into the candidate pool; services that don't declare an entity type or declare a wrong/generic one (just "LocalBusiness") face uphill matching.

Layer 2: Attribute Matching

The second layer is matching the query's specific attributes against the business's declared attributes. For the Columbia carpet-cleaning query, the AI looks for:

• Service area: Columbia, surrounding neighborhoods. Declared in areaServed.
• Specialty: pet odor on wool. Declared in Service entities or category descriptions.
• Chemistry: family-safe. Often inferred from service descriptions or product mentions; can be declared via knowsAbout on related Service entities.
• Service type: upholstery. Separate Service entity for upholstery cleaning.
• Availability: weekend. Declared via openingHoursSpecification with day-specific entries.
• Pricing tier. Declared via priceRange.

Each attribute match adds confidence to the AI's recommendation decision. Schema-rich businesses produce strong attribute matching; schema-poor businesses produce inference-based hedging.

Layer 3: Relationship Parsing

The third layer is parsing relationships between entities. Schema explicitly declares:

• Employee relationships: Carpet-cleaning business → list of named technicians (Person entities) with credentials.
• Service-provider relationships: Service entity → provided by → Carpet-cleaning business.
• Author relationships: BlogPosting → author → Named individual.
• Affiliation relationships: Business → memberOf → Trade associations (IICRC certification, CRI member, etc.).
• Location relationships: Business → location → PostalAddress → containedIn → City.

The AI uses relationships to build the entity graph. Rich relationships make the business node more connected to other recognized entities — and connected entities get cited more confidently than isolated ones.

Layer 4: Content Extraction

The fourth layer is direct content extraction from schema for quotation. Most-quoted schema content:

• FAQPage Q&A pairs: Extracted directly and surfaced in AI answers verbatim.
• Service descriptions: Used as one-line business descriptions in AI recommendations.
• Credentials and certifications: Cited as trust signals ("IICRC-certified," "EPA Safer Choice user").
• Pricing and offer information: Cited as concrete ranges in recommendations.
• Articles and blog posts (BlogPosting): Lifted with author attribution.

Pages with structured-quotable content (especially FAQ) get materially more direct quotations in AI answers, which compound visibility through repeated citation surface.

What Happens at Each Layer Without Schema

Layer 1 without schema

The AI infers entity type from page content. For a carpet cleaner with a header "Welcome to Reid's Cleaning" and prose describing services, the AI might correctly classify as carpet-cleaning service or might generically classify as "cleaning services" or even mistype based on dominant content. Inference produces probabilistic categorization rather than definite.

Layer 2 without schema

Attribute matching from prose is lossy. The page may discuss "pet odor specialization" but unless that's clearly anchored to a Service entity, the AI's confidence that the business specifically offers pet-odor specialty work is reduced. Multi-attribute queries (pet odor + wool + family-safe + upholstery) compound the uncertainty.

Layer 3 without schema

Relationships are inferred from text proximity and links — less reliable than explicit schema relationships. A named technician mentioned on a service page may or may not be parsed as "this technician performs this service at this business."

Layer 4 without schema

Without FAQPage schema, FAQ content gets parsed as general page content rather than extracted as quote-ready Q&A. The quote-citation rate drops significantly. The same content with FAQPage schema produces dramatically higher quote citation.

How the Layers Compound

For our Columbia carpet-cleaning service to win the query, the AI needs:

1. Layer 1: Confirm this is a carpet-cleaning service (entity type).
2. Layer 2: Match the specific attributes (Columbia, pet odor specialty, wool, family-safe chemistry, upholstery option, weekend availability).
3. Layer 3: Verify the relationship to named technicians, certifications (IICRC, CRI Seal of Approval), and reviewers.
4. Layer 4: Extract quotable content (specific pricing, specific process, specific guarantees).

The cited services pass all four layers cleanly. The uncited services typically fail at Layer 2 or 4 — they exist as entities but their attributes are inferred-rather-than-declared, and they have no quote-ready content for the AI to use.

What "Good" Schema Implementation Looks Like (For a Columbia Carpet Cleaner)

Layer 1: Identification

HouseCleaningService schema on homepage with all foundational fields. Specific subtype recognition.

Layer 2: Attribute matching

Service entities for:

• Carpet cleaning (with description detailing pet-odor handling, wool-safe protocols, family-friendly chemistry).
• Upholstery cleaning (separate entity with descriptions).
• Pet-odor specialty (called out as distinct service or attribute).
• Tile and grout cleaning (if offered).
• Each with areaServed naming Columbia and surrounding neighborhoods.

openingHoursSpecification declaring weekend availability explicitly.

priceRange declaration ($$).

Layer 3: Relationships

Employee array referencing named technicians with Person entities. Person entities with hasCredential for IICRC certifications, training credentials. memberOf references for trade-association membership (IICRC, CRI). aggregateRating where genuine review aggregates exist.

Layer 4: Content extraction

FAQPage schema on the FAQ page with 15-20 substantive Q&A pairs covering pricing, process, pet-odor handling, wool care, family-safe products, drying time, scheduling, guarantees. BlogPosting schema on educational content.

Total schema types: 6-7. Implementation: 15-25 hours for a moderately-sized site. Citation lift: typically 2-4x across category-relevant queries within 60-90 days.

Validation: What "Working" Schema Looks Like

Rich Results Test

Run every schema'd page through the Rich Results Test. Pass without errors. Warnings should be addressed when they affect substantive fields.

Content match check

Schema claims should match visible content. If schema says "open Saturdays" but the homepage footer says "closed weekends," fix the inconsistency.

Cross-reference check

If schema references an employee, the employee Person entity should exist. If schema references a service, the service should be findable on the site. Broken cross-references trigger warnings.

Recency check

dateModified should reflect actual content changes. Stale dateModified on regularly-updated content reduces freshness signal.

Common Schema Implementation Failures

Failure 1: Schema generated but never validated

Many CMS plugins auto-generate schema. Often the auto-generated output has errors or warnings that prevent the schema from being usefully parsed. Always validate.

Failure 2: Generic schema where specific is available

Using "LocalBusiness" when "HouseCleaningService" or "CarpetCleaning" subtype exists. The generic type produces weaker categorization signal.

Failure 3: Schema-content inconsistency

Schema declares 7-day operation; site footer says closed Sundays. Schema claims "since 2008"; about page says "since 2010." Inconsistencies degrade trust.

Failure 4: Schema duplicated across pages without purpose

Putting full LocalBusiness schema on every page rather than on the homepage with breadcrumb-and-context schema on inner pages.

Failure 5: Empty or thin schema fields

Schema with name and address only, missing services, employees, attributes, FAQ. Technically valid but doesn't populate the AI's entity graph meaningfully.

The Bottom Line

AI assistants use schema markup across four distinct layers — entity identification, attribute matching, relationship parsing, and content extraction. The Columbia carpet-cleaning service with comprehensive schema implementation across all four layers gets named when the family with the pet-odor problem asks ChatGPT. The service with the same actual capability but only Layer 1 schema (or no schema at all) does not — and the multi-layer parsing reality is what most schema implementations miss when they treat schema as a checkbox exercise.