Structured data for insurance websites: what's allowed, and what trips compliance

I have spent fifteen years building and running the consumer web for a Fortune 1000 property and casualty insurer, and for most of that time teams treated schema markup as a developer detail. It isn't. Once a sentence sits in JSON-LD, a search engine can show it in a result, and an AI assistant can quote it without the page around it. On an insurance site, that changes who needs to see it before it ships.

What does structured data do for an insurance website?

Structured data helps search engines and AI systems identify who you are, what each page is about and how pages relate to one another. It does not make a page rank on its own, and for most insurance pages it no longer produces any special visual treatment in Google results.

Two changes made that clear. In August 2023 Google limited FAQ rich results to well-known government and health websites and stopped showing HowTo rich results. In May 2026 it stopped showing FAQ rich results altogether and began removing the related Search Console reports. Google's documentation for AI Overviews and AI Mode says the same thing from another direction: no special markup is required to appear in those features. A page has to be indexed and eligible to show a snippet.

So the case for schema on an insurance site is not "get stars and drop-downs." It is entity clarity. Machines should read the carrier, its agencies, its agents and its content the same way a customer would. That benefit is real, and it is exactly why the markup needs the same care as the copy.

Which schema types fit an insurance website?

Most insurance sites need six types: Organization for the carrier, InsuranceAgency for each agency or office, WebSite, BreadcrumbList, Article or BlogPosting for educational content, and Person for agents and authors. Risk begins when markup starts carrying claims such as ratings, prices or coverage answers.

schema.org defines InsuranceAgency as a subtype of both LocalBusiness and FinancialService, which makes InsuranceAgency schema the natural choice for an agency with a physical office. For a carrier's corporate site, Organization is usually the clearer choice because the entity is the company, not a storefront.

The rule that matters most: markup must match the page

Google's structured data guidelines require markup to describe content that users can see on the same page. Don't mark up hidden content, and don't add facts that exist only in the JSON-LD.

For regulated copy this rule does double duty. Compliance teams review what customers see. If a developer writes a description by hand inside a script tag, that sentence never passes through review, yet it can appear in a search result, and an assistant can quote it. The fix is structural rather than procedural: generate structured data from the same approved CMS fields that render on the page. Then there is only one sentence to review, and it is the one the customer reads.

Where does insurance schema markup trip compliance?

Five patterns cause most of the trouble: review stars on your own site, FAQ answers written as promises, prices on quote-based products, stale agent and location data, and markup that nobody reviewed. Each one looks harmless in a pull request and reads very differently to a regulator or a customer.

1. Review stars on your own pages

Since September 2019 Google has treated reviews that a business controls about itself as self-serving reviews. It does not show star snippets for them on LocalBusiness and Organization pages, and that includes reviews displayed through an embedded third-party widget. Adding AggregateRating to a homepage or agency page will not produce stars.

The compliance side is stricter than the search side. The FTC rule on consumer reviews and testimonials, in effect since October 21, 2024, prohibits fake or purchased reviews, undisclosed reviews from insiders, company-controlled "independent" review sites and certain review-suppression tactics, with civil penalties of up to $51,744 per violation. State insurance advertising rules add their own layer. The NAIC model regulation for accident and sickness insurance advertising, for example, expects testimonials to be genuine, current and accurately reproduced, and expects any financial interest of the person giving one to be disclosed.

The practical rule: collect reviews where a third party hosts them, such as your Google Business Profiles, link to them, and keep them out of the schema on your own pages.

2. FAQ answers that read as coverage promises

FAQPage schema is still valid schema.org vocabulary, and Google has said sites can leave the markup in place even though it no longer produces a rich result. The risk sits elsewhere. Question-and-answer text is exactly the format that AI systems extract and repeat. "Yes, flood damage is covered" loses the qualifier that sat in a tooltip, a footnote or the next paragraph.

Write the qualifier into the answer sentence itself: "Flood damage is usually excluded from a standard homeowners policy and is covered through a separate flood policy." If a qualifier cannot fit inside the answer, the question probably does not belong in a public FAQ.

3. Prices on quote-dependent products

An Offer with a price makes sense for a product with a fixed price. Most insurance premiums depend on rating factors, underwriting and the state. Marking up "from $29 a month" turns a marketing estimate into a structured fact that can be displayed without its conditions. Unless compliance has approved a specific advertised price, with its conditions visible on the same page, leave price out of the markup.

4. Stale agent and location data

Structured data goes stale quietly. An agent leaves, an office changes its hours, a license lapses in one state. Nobody looks at the JSON-LD, so nobody reports the error. Generate Person and InsuranceAgency markup from the system of record, such as the agent directory or location database, instead of from templates someone edits by hand.

5. Markup that nobody reviewed

Insurance advertising rules generally expect a company to keep a record of its advertisements, and the NAIC model regulation asks insurers to maintain a complete advertising file. If JSON-LD is generated at build time from version-controlled code and content, you already have a dated history of exactly what machines were told and when. If it is injected by a tag manager container or a plugin, you probably don't. That is a good reason to keep schema in the codebase rather than in a tag manager.

How do you run schema through legal review without slowing SEO?

Split the work by risk. Structural markup such as Organization, WebSite and BreadcrumbList repeats facts that legal has already approved and can ship as an engineering change. Anything that carries a claim, including descriptions, FAQ answers, ratings and prices, should come only from approved copy fields and never from hand-written JSON.

1. Inventory. List every schema type on the site, the templates that emit it and where each value comes from.
2. Classify each property. Structural (name, URL, logo, breadcrumbs), factual (address, hours, license) or claim (description, answer, rating, price).
3. Source claims from reviewed fields. A claim property may only read from a CMS field that goes through compliance review.
4. Validate in the build. Parse every JSON-LD block during the build and fail if it is invalid or a required field is empty. The Rich Results Test is useful, but it is manual.
5. Keep the history. Version control plus build artifacts give you the record the advertising file expects.
6. Re-review on change. Trigger review when a product, form or filing changes, not on a calendar.

On the enterprise SEO program I run, and on sites I have built such as East Street Insurance, this split is what lets engineering move quickly on structure while compliance keeps authority over every claim.

Structured data for insurance websites: a pre-publish checklist

• Organization or InsuranceAgency markup uses the licensed legal name, and sameAs links point only to profiles you control.
• Every description, answer and headline in JSON-LD is rendered visibly on the same page.
• No AggregateRating or Review markup about your own company or agencies.
• No Offer or price on products whose premium depends on underwriting.
• Agent and location markup is generated from the system of record.
• Article markup names a real author with a profile page, and dateModified reflects real edits.
• FAQ answers carry their qualifiers inside the answer text.
• JSON-LD is validated in the build and kept in version control.

This article describes search and compliance practice. It is not legal advice; confirm requirements for your states and lines of business with your compliance team.