Structured Data Beyond LocalBusiness: FAQPage, HowTo, Service, and Speakable

Service schema exists to describe one specific thing you do, separate from the LocalBusiness entity that describes who you are. On a page about gutter installation, the Service block should include serviceType stated plainly, a provider field pointing back to your LocalBusiness entity by @id rather than repeating its details, and areaServed listing the specific cities or region that service covers.

Add an offers block where you can state pricing honestly, even as a range — an aggregate offer with a priceRange or a low/high price is more useful to both search engines and AI systems than omitting price entirely. Leaving offers out because pricing varies is a missed opportunity; a stated range is still a citable fact, while an absent field is not.

Use one Service block per distinct offering rather than one giant Service trying to describe everything you do. A roofing company should have separate Service entities for repair, full replacement, and inspection, each with its own areaServed and offers if they genuinely differ.

FAQPage schema requires that every question and answer pair marked up also be visibly present on the rendered page in essentially the same wording — this is not optional, and mismatched or hidden FAQ content is one of the most common reasons markup gets ignored or, in worse cases, treated as a spam signal. Keep each answer genuinely self-contained, in roughly 40 to 80 words, so it can stand alone if pulled into a rich result or a generative answer.

FAQPage has a second life beyond the search results page: it is one of the clearest structural signals an AI answer engine uses when deciding what to cite, because it hands over an explicit question paired with a bounded, unambiguous answer. This overlaps directly with the answer-first content pattern described in our guide on getting cited by AI answers — the schema and the visible content should reinforce each other, not exist independently.

Do not mark up a page as FAQPage if the underlying content is a product listing or a service description with two questions tacked onto the bottom. Reserve it for pages where question-and-answer genuinely is the content structure.

HowTo schema fits genuine step-by-step processes — what happens during a home inspection, how to shut off water before a plumber arrives, how an insurance claim proceeds from filing to payout. Each step should be named plainly and appear in the same order as the visible content; do not reorder or compress steps in the markup relative to what a reader actually sees.

Its rich-result visibility in traditional search has narrowed over time, so treat it primarily as a clarity aid for AI extraction rather than a guaranteed source of a visual rich result. It is worth adding to process pages, but it should not be forced onto content that is not actually sequential — a services overview is not a HowTo just because it has a list.

Speakable schema marks specific CSS-selector-defined sections of a page as suitable for voice assistants to read aloud, most relevant to short, well-formed answer paragraphs rather than full articles. Its practical footprint is currently limited to specific voice assistant integrations, so treat it as a low-cost addition on your strongest answer-first paragraphs rather than a priority investment.

BreadcrumbList schema should mirror your visible breadcrumb navigation exactly, mapping each level from homepage down to the current page with position and name. It is inexpensive to implement, reduces ambiguity about site hierarchy, and commonly improves how your URL displays in results.

Article or BlogPosting schema belongs on every blog post, with headline, description, datePublished, dateModified, author, publisher, and image populated. dateModified deserves particular attention: it should update whenever you make a substantive content revision, not on every trivial edit, because it functions as a freshness signal for time-sensitive topics like pricing and regulation.

Review and AggregateRating schema are the most heavily policed types on this list, and misuse here can trigger a manual action rather than a soft ranking effect. The core rule is that you cannot mark up self-serving reviews about your own business on your own site's LocalBusiness or Organization entity when those reviews were not independently collected and verified by a third party in a way that meets the platform's requirements.

In practice, this means most local service businesses should not attempt to hand-write Review markup for testimonials on their own homepage. The safer, compliant path is to source AggregateRating data from your actual Google Business Profile or a legitimate third-party review platform's API and represent that accurately, or to omit review markup entirely and let the review platforms' own structured data carry that weight in the results.

A common error we see is Review markup applied to the wrong entity — attached to a Product or Service instead of the actual reviewed entity, or attached to an Organization when the reviews are genuinely about a specific individual location. Reviewed entity and schema entity need to match precisely.

Person schema for named staff — the owner, a licensed technician, a loan officer — adds credibility signals like name, jobTitle, and worksFor pointing back to your Organization or LocalBusiness. This matters more for regulated or credential-sensitive fields such as mortgage lending, where a named, credentialed individual carries trust weight that an anonymous business entity does not.

WebSite schema with a SearchAction (potentialAction) tells Google your site has an internal search function it can surface directly in results as a sitelinks search box. It is a small, low-effort addition on the homepage only, and it is unrelated to the LocalBusiness entity itself — it describes the site as a software property, not the business.

The technically correct approach is a single JSON-LD script per page containing one @graph array, where each entity — LocalBusiness, WebSite, the page's Service or Article, its FAQPage, its BreadcrumbList — is a member of that array and references other members by @id rather than repeating their fields. Your LocalBusiness entity gets one stable @id, typically your homepage URL plus a fragment, and every other entity that needs to reference "the business" points to that same @id instead of duplicating name, address, and phone.

This matters for two reasons. It prevents duplicate or conflicting entity data when multiple script blocks each describe your business slightly differently, which parsers can interpret as separate, competing entities. And it is simply easier to maintain — one @graph per page, one place to update the address if you move, referenced everywhere else by @id.

A practical pattern: keep your LocalBusiness and WebSite entities defined once, likely generated from a shared template or CMS field, and reference them by @id from every page-specific block — the Service entity's provider field, the Article's publisher field, the FAQPage's isPartOf field — rather than hardcoding your business details into each one separately.

Missing required properties is the most frequent failure — FAQPage without a mainEntity array, Service without a provider, Article without a headline. Validators generally flag these clearly, so the fix is usually just reading the error message and filling the gap.

Marked-up content that is not visible on the rendered page is the second most common issue and the one most likely to have policy consequences rather than just a warning. If your FAQPage schema includes a question your page copy does not actually ask and answer, remove it from the markup or add it to the visible content — do not leave the mismatch in place.

Duplicate entities from multiple, uncoordinated script blocks describing the same business with slightly different details is a structural error that a single @graph with @id references solves directly. Using the wrong @type — LocalBusiness where a more specific subtype like RoofingContractor exists, or Article where BlogPosting is more precise — narrows eligibility for some rich results without breaking validation outright, so it is worth auditing even when a page technically passes. And Review or AggregateRating markup attached to the wrong entity, as covered above, is a policy risk rather than just a technical one.

Run every page template through Google's Rich Results Test first, since it reflects what Google's own systems will actually parse and shows which rich result types the page is eligible for. Follow that with the Schema.org-affiliated Schema Markup Validator, which checks broader structural correctness beyond just Google's supported rich result types — useful because AI systems and other search engines may read fields Google does not currently surface.

Once markup is live, monitor Search Console's enhancement reports for FAQ, breadcrumb, and any other type you have implemented. These reports surface errors and warnings across your whole site over time, including issues that only appear on specific templates or after a content update broke a required field, which a one-time manual test will not catch.

Re-validate after any template change, not just after initial implementation. A redesign that alters how FAQ content is rendered, or a CMS update that changes how dates are formatted, can silently break markup that previously validated cleanly.

Homepage: LocalBusiness (or specific subtype) as the anchor entity, WebSite with SearchAction, and BreadcrumbList if applicable. Service page: Service referencing the LocalBusiness provider by @id, FAQPage if the page includes a genuine question-and-answer section, and BreadcrumbList.

City or location page: the same Service pattern with areaServed narrowed to that specific city, plus BreadcrumbList reflecting the location hierarchy. Blog post: Article or BlogPosting with complete author and publisher fields, FAQPage if the post ends with a genuine FAQ section, and BreadcrumbList. Contact page: LocalBusiness fields reinforced (often just referencing the same @id rather than a fresh entity) and, where applicable, Person entities for named staff. Booking or scheduling page: LocalBusiness reference plus a Service or Reservation-adjacent entity if your booking flow is structured enough to warrant it — for most local service businesses a simple reference back to the core LocalBusiness and relevant Service entities is sufficient, paired with a clear call to action like our own booking page.

This is a starting framework, not a rigid rulebook — add Speakable to any page with a particularly strong answer-first paragraph, and add Person schema wherever a named, credentialed individual is central to the page's trust signal, such as a loan officer on a mortgage lead page or a licensed technician bio on an HVAC service page.

Structured data is not a one-time project. Every time a service area expands, a price range changes, a staff member leaves, or a page's visible content is substantially rewritten, the corresponding schema needs to be updated in the same edit — not queued for a later cleanup pass that may never happen.

The most reliable way to enforce this in practice is to generate shared entities like LocalBusiness and WebSite from a single template or CMS field rather than hand-editing JSON-LD on individual pages, so a single update propagates everywhere that entity is referenced. For page-specific entities like Service and FAQPage, treat schema updates as a required step in your content review checklist alongside proofreading and internal linking, not as a separate technical task that gets deprioritized.

Businesses evaluating whether this level of structured data discipline is worth the investment relative to other channels can review our breakdown of local SEO versus AI search optimization, or explore our SEO and AI optimization services and lead pricing for a sense of how this fits into a broader lead generation program.