Schema Markup for Personal Injury Law Firms: The Complete JSON-LD Implementation Guide for 2026

Why Schema Markup Matters More for Personal Injury Firms in 2026 Than It Did Three Years Ago

Schema markup matters more in 2026 because AI search interfaces now sit between your site and your next client, and structured data is one of the few machine-readable signals you fully control. The AI Overview, ChatGPT search, and Perplexity primarily read your rendered content; Schema.org annotation is the layer that helps every machine reader resolve who the firm is, who the attorneys are, and which questions your pages answer, without guessing. Three years ago, the payoff for schema was mostly rich results in the Google SERP. Today, the payoff is entity clarity across a fragmenting set of surfaces where visibility depends on machine reading.

For personal injury specifically, three factors compound the effect. First, PI queries carry heavy near-me intent; that visibility runs through your Google Business Profile, and LocalBusiness + LegalService schema keep your site’s entity data consistent with it. Second, PI attorneys carry high-value credentials (board certifications, bar admissions in multiple states, published verdicts) that only become machine-readable authority signals when a Person block encodes them properly. Third, PI queries are informational-heavy (“what to do after a crash,” “how long does a settlement take”), and clearly structured question-and-answer content is the easiest format for AI systems to extract and attribute.

The machinery behind this is documented in Google’s own research and filings, not just SEO folklore. The 2014 Google research paper Knowledge Vault: A Web-Scale Approach to Probabilistic Knowledge Fusion describes four extractor lanes feeding the knowledge graph: plain text, tables, page structure, and publisher-declared structured data, with the declared lane the cleanest of the four. Google’s knowledge panel patent, Providing Knowledge Panels with Search Results, US Patent 9,268,820 B2, defines person-entity and place-entity panel templates populated with an image, a description, and facts about the entity; Person schema and LegalService schema supply exactly those placeholders. One guardrail before the patent citations in the rest of this guide: patents and research papers describe the machinery the vendors have filed and published, not confirmed live ranking behavior. I cite them because they show what schema-shaped data these systems are built to consume, which is the strongest available evidence for where the effort pays.

Here is the knowledge panel patent itself, pulled from the public USPTO record on Google Patents, with the sentence that defines what a knowledge panel presents highlighted. The frame shows the patent number and the current assignee, Google LLC, so you can confirm the attribution rather than take my word for it.

The visual below shows the nine canonical Schema.org types every PI firm implementation touches, arranged around a central LegalService entity. Hover on any node to pause the rotation.

The Traditional SEO Payoff: Rich Results, Local Pack, and Knowledge Panel

The traditional SEO payoff from schema markup is threefold: rich results in the SERP, local pack visibility in Google Maps, and a populated Knowledge Panel on branded searches. Rich results include the breadcrumb path under your title tag, the star ratings on third-party review platforms’ pages, and the article data that improves how your posts display across Google’s article surfaces. Local pack visibility is driven by your Google Business Profile (Google’s documented local factors are relevance, distance, and prominence); your LocalBusiness or LegalService schema supports it by keeping the site’s entity data consistent with that profile. The Knowledge Panel is what Google builds when your Organization schema plus sameAs links to authoritative external profiles give it enough entity signal to trust.

Not all of these render in every SERP. Some are query-dependent (Knowledge Panels appear on branded queries only), and some depend on the SERP layout Google chooses for that specific search session. But every one of them requires schema to be eligible in the first place.

The AI Payoff: Citation Eligibility in AI Overviews, ChatGPT, and Perplexity

The AI payoff is citation eligibility in AI Overviews, ChatGPT search (which crawls the web with OpenAI’s own OAI-SearchBot crawler), and Perplexity (which runs PerplexityBot). None of these vendors documents how much weight structured data carries in citation selection; what they all demonstrably need is unambiguous entities, and correctly implemented LegalService, Person, and FAQPage schema is the most direct control a firm has over that clarity. My working position after two published audits: schema does not guarantee AI citation, but ambiguous entities reliably lose it. On the Google side, the picture has a filed anchor: the stateful-chat application Search with Stateful Chat, US-2024289407-A1, describes the generative companion drawing contextual information from prior search results pages and query-responsive documents (Claims 3 and 4), which is precisely the surface schema-marked pages feed.

The mapping below covers the same surfaces from two kinds of evidence. The SERP rich result column reflects documented Google behavior. The three AI columns are my practitioner assessment from audit work, not vendor documentation, because no AI vendor publishes per-type citation criteria; read those columns as “where this type plausibly helps extraction and attribution.”

Why Personal Injury Firms Feel the Difference More Than Other Verticals

Personal injury firms feel the schema difference more than other verticals because PI search behavior compounds three signals schema controls. Near-me queries need LocalBusiness data. Named-attorney queries need Person data with credentials. Informational queries (“statute of limitations Texas car accident”) reach for FAQPage-annotated content the AI Overview can extract.

In PI SEO, schema is where entity signal starts, not where it ends.

I tell every firm on our first strategy call.

Firms that ship correct schema and then wire it to a real content and internal linking program consistently outrank firms with better copy and worse structural signals. Firms that ship broken schema and blame their content team for underperformance are looking at the wrong layer.

Most PI firms I audit get this wrong because their marketing agency treats schema as a one-time WordPress plugin install. They ship LocalBusiness (not LegalService), skip Person entirely, and leave the deprecated Attorney type running on every attorney bio. Six months later, the firm’s attorneys are invisible as machine-readable entities, the AI Overview cites competitor pages, and nobody can explain why. In the 1,005-firm audit, only 1.3% of PI firms on Google Page 1 reached Level 4 Semantic Authority, the maturity level above Entity Network where schema functions as a complete, validated authority layer. Zero reached Level 5. The market is uniformly under-implemented, which means the firms that ship correct schema quickly compound an advantage competitors will not close for years.

The Schema.org Deprecation Every Personal Injury Law Firm Still Gets Wrong

The Schema.org Attorney type is deprecated, and the deprecation is not news: the notice has been public for roughly a decade, dating to Schema.org’s mid-2010s professional-services vocabulary cleanup. Attorney still validates as vocabulary, but it adds nothing LegalService does not already provide, and shipping it in 2026 signals that your implementation has never been reviewed against the current vocabulary. The correct pattern is LegalService for the firm and Person for each attorney, linked via the worksFor property. If you have Attorney anywhere in your current schema, you are running markup the vocabulary itself told you to stop using years ago.

The timeline below walks the Attorney type’s real lifecycle. The scandal is not that the type was deprecated; it is how long the deprecation has been public while PI vendors kept shipping it.

I flag this deprecation on almost every PI firm audit I run. The most common pattern is a WordPress plugin whose schema template predates anyone on the current marketing team, plus a website vendor who never audited the plugin output against the live vocabulary. The firm shipped Attorney in good faith, then let it run for years while the deprecation notice sat public the entire time and better-run competitor sites migrated to LegalService + Person. In my 500-firm SSRN study, Schema Markup Adoption in Personal Injury Law Firm Websites (DOI 10.2139/ssrn.6551638), 41.2% of firms carry a Person or Attorney block; the published figure merges the two types, and in my client audits a meaningful share of that markup is still the deprecated Attorney type. If your schema has never been audited against the current Schema.org vocabulary, assume you are one of them until proven otherwise.

What the Attorney Type Was and Why Schema.org Deprecated It

The Attorney type was a Schema.org subtype under LegalService, itself under LocalBusiness. Its full inheritance chain was Thing > Organization > LocalBusiness > LegalService > Attorney and Thing > Place > LocalBusiness > LegalService > Attorney. It carried the same properties as LegalService with no additions unique to individual attorneys.

Schema.org’s own deprecation notice for the Attorney type reads: This type is deprecated - LegalService is more inclusive and less ambiguous. The notice traces to the mid-2010s professional-services vocabulary cleanup, and independent developer documentation was reproducing it verbatim by May 2019, which makes any vendor claim that the deprecation is recent easy to disprove. The reasoning is that Attorney as a business-entity type overlaps with LegalService without adding a property axis, and Attorney as an individual attorney conflates the person with the business. The clean split is LegalService for the firm and Person for each attorney, with worksFor establishing the entity relationship.

What Google Actually Wants Now: Person Plus LegalService Plus worksFor

Google wants Person for each individual attorney and LegalService for the firm, connected by worksFor. This is the pattern that gives Google a machine-readable attorney-to-firm relationship for entity reconciliation in its knowledge graph, that gives AI systems named attorneys with stated credentials to work with, and that survives future Schema.org changes.

{
  "@context": "https://schema.org",
  "@type": "Person",
  "@id": "https://firmdomain.com/attorneys/jane-doe#person",
  "name": "Jane Doe",
  "jobTitle": "Personal Injury Attorney",
  "worksFor": {
    "@type": "LegalService",
    "@id": "https://firmdomain.com/#legalservice"
  }
}

The @id in worksFor points back to the LegalService entity defined on the homepage or in the sitewide Organization block. This is how Google connects the attorney to the firm across pages.

How to Audit Your Current Schema for the Deprecated Attorney Type

To audit your current schema for the deprecated Attorney type, run three checks in sequence.

Step one, pull any attorney bio page from your live site and open the page source. Search for "@type": "Attorney" and "@type":"Attorney" (with and without the space). If either appears, you have deprecated markup.

Step two, run the same page through Google’s Rich Results Test at search.google.com/test/rich-results. The tool will validate the schema without flagging Attorney as deprecated (Google’s tool is permissive), but you will see whether Person is present. If Person is missing and Attorney is present, the fix is clear.

Step three, check your homepage and practice-area pages for any Organization or LocalBusiness block that references Attorney as a subtype. Some plugin templates include Attorney inside a hasMember array. That reference needs to become Person.

The Nine Schema Types Personal Injury Law Firms Actually Need

Personal injury law firms need nine Schema.org types to cover the entity, attorney, location, service, content, navigation, and reputation layers of a modern PI site. The nine are LegalService, Person, LocalBusiness, Organization, Service, FAQPage, Article, BreadcrumbList, and Review with AggregateRating. Every serious implementation ships all nine, distributed across the appropriate page templates.

Below, each of the nine gets its own definition, a placement note, and a production-ready JSON-LD block. The code you see in each block is directly copyable, with the caveat that you replace the placeholder values (firm name, domain, addresses, attorney names) with your actual data.

LegalService: The Firm Entity Type

LegalService is the Schema.org type that classifies your firm as a legal-service provider. It inherits from LocalBusiness, which itself inherits from Organization and Place, so LegalService carries every LocalBusiness property (address, telephone, geo, openingHours, priceRange, areaServed) plus every Organization property (name, url, logo, sameAs, contactPoint). Its full hierarchy is Thing > Organization > LocalBusiness > LegalService and Thing > Place > LocalBusiness > LegalService.

LegalService is the correct firm-entity type for every PI law firm homepage and every practice-area page. LocalBusiness on its own is too generic (it fires the same signal as a restaurant or retailer). LegalService tells Google specifically that this business provides legal representation. In my 1,005-firm audit, only 35.3% of Page-1 PI firms use LegalService, and the tier data shows correlation with ranking: 40% of firms in Positions 1 to 3 use LegalService versus 30% in Positions 7 to 10. Correlation is not causation, but the tier gap is consistent with LegalService’s role as an entity-clarity signal.

The 35.3% comes straight from the abstract of my 1,005-firm study, shown below with the finding highlighted. The paper title, my name, and the ORCID are in the same frame, so this is a source you can locate and check, not a number I am asking you to trust.

{
  "@context": "https://schema.org",
  "@type": "LegalService",
  "@id": "https://firmdomain.com/#legalservice",
  "name": "Doe Law Firm",
  "url": "https://firmdomain.com/",
  "logo": "https://firmdomain.com/logo.png",
  "image": "https://firmdomain.com/office.jpg",
  "telephone": "+1-713-555-0100",
  "priceRange": "$$",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "1400 Smith Street, Suite 300",
    "addressLocality": "Houston",
    "addressRegion": "TX",
    "postalCode": "77002",
    "addressCountry": "US"
  },
  "geo": {
    "@type": "GeoCoordinates",
    "latitude": 29.75589,
    "longitude": -95.36327
  },
  "areaServed": [
    { "@type": "City", "name": "Houston" },
    { "@type": "AdministrativeArea", "name": "Harris County" }
  ],
  "openingHoursSpecification": [
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday"],
      "opens": "08:00",
      "closes": "18:00"
    }
  ],
  "sameAs": [
    "https://www.linkedin.com/company/doe-law-firm",
    "https://www.avvo.com/attorneys/houston-tx-doe-law-firm.html"
  ]
}

The @id is critical. It gives your LegalService entity a canonical URL-based identifier that other schema blocks (Person, Service, BreadcrumbList) can reference across pages without creating duplicate entities in Google’s knowledge graph.

Person: The Attorney Profile Type (Not Attorney)

Person is the Schema.org type for individual attorneys. It replaces the deprecated Attorney type. Its properties support everything a PI attorney bio should surface: name, jobTitle, worksFor, alumniOf, memberOf (state bar), hasCredential (board certifications), sameAs (bar directory profiles, LinkedIn, Avvo), and image (headshot).

{
  "@context": "https://schema.org",
  "@type": "Person",
  "@id": "https://firmdomain.com/attorneys/jane-doe#person",
  "name": "Jane Doe",
  "honorificSuffix": "JD",
  "jobTitle": "Personal Injury Attorney",
  "image": "https://firmdomain.com/attorneys/jane-doe.jpg",
  "url": "https://firmdomain.com/attorneys/jane-doe/",
  "worksFor": {
    "@type": "LegalService",
    "@id": "https://firmdomain.com/#legalservice"
  },
  "identifier": {
    "@type": "PropertyValue",
    "propertyID": "State Bar Number",
    "value": "24012345"
  },
  "hasOccupation": {
    "@type": "Occupation",
    "name": "Personal Injury Attorney",
    "occupationalCategory": "23-1011.00 Lawyers",
    "experienceRequirements": {
      "@type": "OccupationalExperienceRequirements",
      "monthsOfExperience": 156
    }
  },
  "alumniOf": {
    "@type": "EducationalOrganization",
    "name": "University of Houston Law Center"
  },
  "memberOf": [
    { "@type": "Organization", "name": "State Bar of Texas" },
    { "@type": "Organization", "name": "American Association for Justice" }
  ],
  "hasCredential": [
    {
      "@type": "EducationalOccupationalCredential",
      "credentialCategory": "license",
      "name": "State Bar of Texas Admission",
      "recognizedBy": {
        "@type": "Organization",
        "name": "State Bar of Texas",
        "url": "https://www.texasbar.com/"
      },
      "dateCreated": "2013-05-15",
      "validIn": { "@type": "State", "name": "Texas" }
    },
    {
      "@type": "EducationalOccupationalCredential",
      "credentialCategory": "certification",
      "name": "Board Certified in Personal Injury Trial Law",
      "recognizedBy": {
        "@type": "Organization",
        "name": "Texas Board of Legal Specialization"
      }
    },
    {
      "@type": "EducationalOccupationalCredential",
      "credentialCategory": "degree",
      "educationalLevel": "JD",
      "recognizedBy": {
        "@type": "CollegeOrUniversity",
        "name": "University of Houston Law Center"
      }
    }
  ],
  "knowsLanguage": ["English", "Spanish"],
  "sameAs": [
    "https://www.linkedin.com/in/janedoe",
    "https://www.avvo.com/attorneys/houston-tx-jane-doe.html"
  ]
}

Three details in that block separate a machine-verifiable attorney profile from the flat name-and-title markup most bios ship. First, every credential is a structured EducationalOccupationalCredential with a credentialCategory (“license” for the bar admission, “certification” for board certification, “degree” for the JD), a recognizedBy pointing at the issuing body, and for the bar license a validIn jurisdiction. Second, the bar number rides in identifier as a PropertyValue, which gives Google and the state bar’s own directory a shared key for the same human. Third, hasOccupation carries the US Standard Occupational Classification code for lawyers (23-1011.00) plus months of experience, turning “20 years of experience” from marketing copy into a machine-readable attribute. Google’s entity-attribute patent, Identifying Entity Attribute Relations, US Patent 11,263,400 B2, describes the extraction pipeline these properties feed directly instead of leaving Google to infer them from prose. The book-keeping rule still applies: every credential and award you mark up must be visible in the bio’s body copy.

The patent record below shows the exact language: its purpose is identifying entity-attribute relationships in text corpora, which is what the structured credential, identifier, and occupation properties on a Person block supply pre-resolved. Assignee Google LLC is visible in the frame.

Person schema is where E-E-A-T stops being an abstract Google acronym and starts being a machine-readable record.

I tell every firm on our first strategy call.

Google cannot verify a lawyer’s board certification from body copy that says “board certified.” It can verify from a Person block with hasCredential pointing to the certifying body plus a sameAs to the certifying body’s own directory. The attorney bio page optimization piece covers the surrounding page structure that carries this Person block. Schema is one layer; the page structure and internal linking around it matter equally.

LocalBusiness: The Physical Office Anchor

LocalBusiness is the schema type Google uses for physical office data. For PI firms, LocalBusiness is functionally covered by LegalService (since LegalService inherits from LocalBusiness), but Google Search Central documents LocalBusiness as the type it looks for on physical-office data. A single-office firm ships LegalService on the homepage and treats it as the LocalBusiness block. A multi-office firm ships one LegalService per office, each acting as its own LocalBusiness anchor.

{
  "@context": "https://schema.org",
  "@type": "LegalService",
  "@id": "https://firmdomain.com/offices/houston/#localbusiness",
  "name": "Doe Law Firm, Houston Office",
  "parentOrganization": {
    "@type": "Organization",
    "@id": "https://firmdomain.com/#organization"
  },
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "1400 Smith Street, Suite 300",
    "addressLocality": "Houston",
    "addressRegion": "TX",
    "postalCode": "77002",
    "addressCountry": "US"
  },
  "telephone": "+1-713-555-0100"
}

Google’s own guidance on LocalBusiness lists name and address as the two required properties. Everything else is recommended, but telephone, url, openingHoursSpecification, geo, and priceRange should always be populated because they are the properties that keep your site’s entity data aligned with the Google Business Profile ecosystem that actually populates the Local Pack and Knowledge Panel.

Organization: The Firm Brand and Sitewide Signal

Organization is the parent-brand entity type, and the most common mistake with it is shipping it when you do not need it. LegalService inherits every Organization property (legalName, logo, sameAs, contactPoint, founder, foundingDate, knowsAbout and the rest), so a single-office firm publishes ONE LegalService node carrying all of them; publishing a parallel Organization node for the same firm splits the entity signal you are trying to concentrate. Ship a separate Organization node in exactly one situation: a multi-office firm that has no headquarters, where the parent brand carries no address and every office is its own LegalService child. A multi-office firm that does have a headquarters keeps the parent as a LegalService (the HQ), covered in the multi-office section.

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://firmdomain.com/#organization",
  "name": "Doe Law Firm",
  "url": "https://firmdomain.com/",
  "logo": {
    "@type": "ImageObject",
    "url": "https://firmdomain.com/logo.png",
    "width": 400,
    "height": 100
  },
  "contactPoint": {
    "@type": "ContactPoint",
    "telephone": "+1-713-555-0100",
    "contactType": "customer service",
    "areaServed": "US",
    "availableLanguage": ["English", "Spanish"]
  },
  "sameAs": [
    "https://www.linkedin.com/company/doe-law-firm",
    "https://www.facebook.com/doelawfirm"
  ]
}

For firms with more than one office, Organization is the parent and each office is a child LegalService (or LocalBusiness) linked via subOrganization, with each child pointing back via parentOrganization. The Organization does not carry a physical address; the child LegalServices do.

Service: The Practice-Area Sub-Block

Service is the schema type for each practice area your firm handles. Motorcycle accidents, truck accidents, wrongful death, TBI, medical malpractice, and every other practice area gets a Service block on its dedicated page, either as a standalone entity whose provider points at the firm’s LegalService or nested inside the firm’s LegalService via hasOfferCatalog. Its hierarchy is Thing > Intangible > Service, and its core properties are name, description, serviceType, provider, and areaServed.

{
  "@type": "Service",
  "@id": "https://firmdomain.com/practice-areas/motorcycle-accidents/#service",
  "name": "Motorcycle Accident Representation",
  "description": "Legal representation for injured motorcyclists in Harris County and surrounding Texas counties, including cases involving uninsured motorists, defective helmets, and roadway design defects.",
  "serviceType": "Personal Injury Representation",
  "provider": {
    "@type": "LegalService",
    "@id": "https://firmdomain.com/#legalservice"
  },
  "areaServed": {
    "@type": "AdministrativeArea",
    "name": "Harris County, Texas"
  }
}

Precise Service names beat vague ones. “Motorcycle Accident Representation” carries more entity signal than “Personal Injury Services.” AI Overviews match specific service names to specific queries; a firm whose Service block says “motorcycle accident representation for uninsured motorists” will earn citation eligibility for that exact query in ways a generic “personal injury services” block will not. My 1,005-firm audit found that 57.2% of PI sites with schema are missing the areaServed property entirely, and 71.3% were missing it in the earlier 500-firm SSRN study. That single missing property is one of the highest-leverage schema fixes a PI firm can make in an afternoon.

The practice area page structure for personal injury firms piece covers the surrounding page layout, copy structure, and conversion architecture around this Service block.

FAQPage: The AI Citation Extractor

FAQPage is the Schema.org type for pages built around a series of questions and their answers. Its hierarchy is Thing > CreativeWork > WebPage > FAQPage, and it uses the mainEntity property to nest Question objects, each with an acceptedAnswer.

Google restricted FAQ rich results to well-known, authoritative government and health websites in a change announced on the Google Search Central blog on August 8, 2023 and rolled out that same week. The eligibility language from Google Search Central reads: the feature is only shown for well-known, authoritative government and health websites. For personal injury law firms, this means FAQPage schema no longer produces the expandable FAQ dropdown that once appeared under your SERP snippet.

FAQPage still matters. AI Overviews, ChatGPT, and Perplexity all extract question-and-answer content from FAQPage-annotated blocks. A firm whose practice-area pages ship FAQPage schema is dramatically more likely to be cited when an AI system answers a user question about that practice area. In my 1,005-firm audit, only 18.5% of Page-1 PI firms ship FAQPage schema, so a firm that adds substantive FAQPage blocks on its top practice-area pages moves ahead of roughly 80% of the market on this layer.

{
  "@type": "FAQPage",
  "@id": "https://firmdomain.com/practice-areas/motorcycle-accidents/#faqpage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "How long do I have to file a motorcycle accident lawsuit in Texas?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Texas has a two-year statute of limitations for personal injury claims arising from motor vehicle accidents, including motorcycle accidents."
      }
    },
    {
      "@type": "Question",
      "name": "Does wearing a helmet affect a motorcycle injury claim in Texas?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Texas requires helmets only for riders under 21 or riders who lack minimum insurance coverage. For riders over 21 with qualifying insurance, choosing not to wear a helmet does not automatically bar recovery."
      }
    }
  ]
}

Article and BlogPosting: The Content Attribution Block

Article is the Schema.org type for long-form content, including blog posts, guides, and news pieces. BlogPosting is a more specific subtype for blog-format content. Both signal authorship, publication date, and publisher to Google and to AI systems that read your content.

Google Search Central lists no required properties for Article, but recommends author, dateModified, datePublished, headline, and image. Author should be a Person type with the attorney’s name and, ideally, a url or sameAs property that ties back to the attorney’s bio page and external profiles.

{
  "@type": "Article",
  "@id": "https://firmdomain.com/blog/what-to-do-after-a-motorcycle-accident/#article",
  "headline": "What to Do After a Motorcycle Accident in Texas",
  "author": {
    "@type": "Person",
    "@id": "https://firmdomain.com/attorneys/jane-doe#person",
    "name": "Jane Doe"
  },
  "publisher": {
    "@type": "LegalService",
    "@id": "https://firmdomain.com/#legalservice",
    "name": "Doe Law Firm"
  },
  "datePublished": "2026-05-15",
  "dateModified": "2026-07-20",
  "image": "https://firmdomain.com/blog/motorcycle-accident-hero.jpg",
  "about": { "@type": "Thing", "name": "Motorcycle Accident Aftermath" }
}

The about property is worth setting even though it is optional. It gives AI systems an explicit entity to associate the article with, which improves citation matching for queries about that entity.

BreadcrumbList: The Sitewide Navigation Signal

BreadcrumbList is the schema type for the navigation trail on any page below the homepage. Google renders it as the breadcrumb path under your SERP snippet on desktop, with a simplified domain-level display on mobile since 2024.

Google Search Central lists itemListElement (an array of ListItem objects with position, name, and item) as the required property. Every ListItem needs position, name, and (except for the final item) item. Minimum two ListItems per BreadcrumbList.

{
  "@type": "BreadcrumbList",
  "@id": "https://firmdomain.com/practice-areas/motorcycle-accidents/#breadcrumb",
  "itemListElement": [
    { "@type": "ListItem", "position": 1, "name": "Home", "item": "https://firmdomain.com/" },
    { "@type": "ListItem", "position": 2, "name": "Practice Areas", "item": "https://firmdomain.com/practice-areas/" },
    { "@type": "ListItem", "position": 3, "name": "Motorcycle Accidents" }
  ]
}

Ship BreadcrumbList on every page below the homepage. The rendering cost is zero and the entity-hierarchy signal it sends to Google is consistent across every crawl.

Review and AggregateRating: The Third-Party-Only Reputation Block

Review is the Schema.org type for individual client reviews and AggregateRating for the summary star rating. Google’s guidance here is the most misunderstood rule in the legal SEO stack, and it has been in force since September 16, 2019, when the Search Central update Making Review Rich Results More Helpful removed review stars for LocalBusiness and Organization entities (and every subtype, including LegalService) wherever the reviewed entity controls the reviews about itself. Google’s review snippet guidelines also require ratings to be sourced directly from users and prohibit aggregating reviews from other websites into your own markup.

Together those two rules close every path PI vendors keep selling. Testimonials on your own site wrapped in Review schema will validate, but will not render stars, because you control the placement. Copying your Avvo or Google reviews into your own markup will not render stars either, and additionally violates the sourcing guideline (and usually the review platform’s terms of service). Star ratings for law firms render where the reviews actually live: on the third-party platforms’ own pages, and through your Google Business Profile reviews in the local surfaces.

The block below is the pattern I remove most often during audits. It is shown here so you can recognize it, not ship it.

{
  "@type": "LegalService",
  "@id": "https://firmdomain.com/#legalservice",
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.9",
    "reviewCount": "127",
    "bestRating": "5",
    "worstRating": "1"
  },
  "review": [
    {
      "@type": "Review",
      "author": { "@type": "Person", "name": "Verified Client, Avvo" },
      "reviewRating": {
        "@type": "Rating",
        "ratingValue": "5",
        "bestRating": "5"
      },
      "reviewBody": "Jane and her team handled my motorcycle accident case with clarity and speed."
    }
  ]
}

The Complete JSON-LD Stack for a Single-Office Personal Injury Firm

The complete JSON-LD stack for a single-office PI firm is one @graph block per major page template: homepage, attorney bio, practice-area, blog post. Each @graph nests the entity types that page carries, using @id to link entities across pages so Google reads them as one entity graph rather than isolated blocks.

The decision tree below routes you to the right architecture based on how many offices your firm operates.

A single-office firm ships one LegalService entity anchored on the homepage, one Person entity per attorney anchored on each bio, and one Service block per practice area anchored on each practice-area page. Every entity gets an @id derived from its canonical URL. Every cross-reference uses that @id.

The @context and @graph Boilerplate

Every schema block starts with the same two-line boilerplate: an @context declaration pointing to Schema.org, and either a single @type or an @graph array holding multiple typed entities. For pages with more than one entity type (which is most pages), use @graph.

{
  "@context": "https://schema.org",
  "@graph": [
    { "@type": "LegalService", "@id": "https://firmdomain.com/#legalservice" },
    { "@type": "WebSite", "@id": "https://firmdomain.com/#website" }
  ]
}

The @graph array is the cleaner of the two accepted patterns for multiple entity types on one page; the alternative, separate script tags each carrying their own @context, is equally valid to Google. @graph keeps every entity in one block, which makes the @id cross-references easier to audit and harder to drift.

The Homepage @graph: One LegalService Node Plus WebSite

The homepage @graph carries two entities, not three. LegalService inherits every Organization property through the type hierarchy, so the single firm node carries the brand identity (legalName, alternateName, slogan, founder, foundingDate, knowsAbout) alongside the physical-office data. Do not publish a parallel Organization node for a single-office firm; one entity, fully populated, beats two entities splitting the signal. This is the Entity Home discipline: the full firm definition lives on one page (homepage or about page), and every other page references it by @id rather than repeating it.

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "LegalService",
      "@id": "https://firmdomain.com/#legalservice",
      "name": "Doe Law Firm",
      "alternateName": "Doe Injury Lawyers",
      "legalName": "Doe Law Firm, PLLC",
      "slogan": "No Fee Unless We Win",
      "url": "https://firmdomain.com/",
      "logo": {
        "@type": "ImageObject",
        "url": "https://firmdomain.com/logo.png",
        "width": 400, "height": 100
      },
      "foundingDate": "2008",
      "founder": { "@id": "https://firmdomain.com/attorneys/jane-doe#person" },
      "knowsAbout": [
        "Personal Injury Law",
        "Car Accidents",
        "Truck Accidents",
        "Motorcycle Accidents",
        "Wrongful Death"
      ],
      "telephone": "+1-713-555-0100",
      "priceRange": "$$",
      "address": {
        "@type": "PostalAddress",
        "streetAddress": "1400 Smith Street, Suite 300",
        "addressLocality": "Houston",
        "addressRegion": "TX",
        "postalCode": "77002",
        "addressCountry": "US"
      },
      "geo": {
        "@type": "GeoCoordinates",
        "latitude": 29.75589,
        "longitude": -95.36327
      },
      "hasMap": "https://www.google.com/maps?cid=1234567890123456789",
      "areaServed": [
        { "@type": "City", "name": "Houston" },
        { "@type": "AdministrativeArea", "name": "Harris County" }
      ],
      "openingHoursSpecification": [
        {
          "@type": "OpeningHoursSpecification",
          "dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday"],
          "opens": "08:00",
          "closes": "18:00"
        }
      ],
      "contactPoint": {
        "@type": "ContactPoint",
        "telephone": "+1-713-555-0100",
        "contactType": "customer service",
        "availableLanguage": ["English", "Spanish"]
      },
      "sameAs": [
        "https://www.linkedin.com/company/doe-law-firm",
        "https://www.facebook.com/doelawfirm",
        "https://www.avvo.com/attorneys/houston-tx-doe-law-firm.html"
      ]
    },
    {
      "@type": "WebSite",
      "@id": "https://firmdomain.com/#website",
      "url": "https://firmdomain.com/",
      "name": "Doe Law Firm",
      "publisher": { "@id": "https://firmdomain.com/#legalservice" }
    }
  ]
}

Two properties in that block are worth singling out because almost no PI firm ships them. The geo coordinates carry five decimal places; pull them from the Google Maps URL before zooming, because lower precision risks rejection. And hasMap points at the firm’s Google Business Profile CID URL (the ?cid= form, retrievable with any CID lookup tool), which explicitly tells Google that this entity and that Maps listing are the same business, the single cheapest entity-consolidation signal available to a local firm.

Every entity carries an @id anchored on the domain root. Every cross-reference uses the @id; Google’s entity-resolution patent, Additive Context Model for Entity Resolution, US Patent 9,697,475 B1, describes exactly the kind of cross-reference machinery that stable identifiers feed. One deliberate omission: no SearchAction. Google retired the sitelinks search box in November 2024, so the potentialAction markup older guides still recommend no longer produces anything; if your current schema carries it, removing it is harmless cleanup.

The Attorney Bio Page @graph: Person Plus ProfilePage Plus BreadcrumbList

The attorney bio page @graph carries three entities: Person (the attorney), ProfilePage (the bio page itself), and BreadcrumbList (the navigation trail). Use ProfilePage here, not the generic WebPage. ProfilePage is the WebPage subtype Google documents for pages whose whole purpose is one person or organization, and Google names employee pages on a company website as a supported case, which is precisely what an attorney bio is. The more specific type carries a stronger declaration: this page is about this attorney, full stop.

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Person",
      "@id": "https://firmdomain.com/attorneys/jane-doe#person",
      "name": "Jane Doe",
      "jobTitle": "Personal Injury Attorney",
      "image": "https://firmdomain.com/attorneys/jane-doe.jpg",
      "url": "https://firmdomain.com/attorneys/jane-doe/",
      "worksFor": {
        "@type": "LegalService",
        "@id": "https://firmdomain.com/#legalservice"
      },
      "alumniOf": { "@type": "EducationalOrganization", "name": "University of Houston Law Center" },
      "memberOf": [ { "@type": "Organization", "name": "State Bar of Texas" } ],
      "hasCredential": [
        {
          "@type": "EducationalOccupationalCredential",
          "credentialCategory": "certification",
          "name": "Board Certified in Personal Injury Trial Law, Texas Board of Legal Specialization"
        }
      ],
      "sameAs": [
        "https://www.linkedin.com/in/janedoe",
        "https://www.avvo.com/attorneys/houston-tx-jane-doe.html"
      ]
    },
    {
      "@type": "ProfilePage",
      "@id": "https://firmdomain.com/attorneys/jane-doe/#profilepage",
      "url": "https://firmdomain.com/attorneys/jane-doe/",
      "name": "Jane Doe, Personal Injury Attorney at Doe Law Firm",
      "isPartOf": { "@id": "https://firmdomain.com/#website" },
      "dateModified": "2026-07-20",
      "mainEntity": { "@id": "https://firmdomain.com/attorneys/jane-doe#person" },
      "breadcrumb": { "@id": "https://firmdomain.com/attorneys/jane-doe/#breadcrumb" }
    },
    {
      "@type": "BreadcrumbList",
      "@id": "https://firmdomain.com/attorneys/jane-doe/#breadcrumb",
      "itemListElement": [
        { "@type": "ListItem", "position": 1, "name": "Home", "item": "https://firmdomain.com/" },
        { "@type": "ListItem", "position": 2, "name": "Attorneys", "item": "https://firmdomain.com/attorneys/" },
        { "@type": "ListItem", "position": 3, "name": "Jane Doe" }
      ]
    }
  ]
}

Two type-specific choices matter here. The wrapper is ProfilePage, whose required property is mainEntity, and mainEntity points to the Person @id. That is a deliberately stronger statement than the about property a generic WebPage would use: about says the page mentions the attorney, mainEntity says the attorney is the whole point of the page. The Person block itself lives independently (Jane could appear on multiple pages: bio, blog author, practice-area team roster) and every reference uses the same canonical @id, so this ProfilePage is her Entity Home and every other page borrows it.

The Practice-Area Page @graph: Service Plus FAQPage Plus WebPage

The practice-area page @graph carries four entities: WebPage (the page itself), Service (the specific practice area, whose provider points at the firm’s one canonical LegalService @id), FAQPage (the Q&A block), and BreadcrumbList. Resist the temptation to mint a new LegalService entity on every practice page; that multiplies firm entities across templates and walks straight into the entity-duplication error covered later in this guide.

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "WebPage",
      "@id": "https://firmdomain.com/practice-areas/motorcycle-accidents/#webpage",
      "url": "https://firmdomain.com/practice-areas/motorcycle-accidents/",
      "name": "Motorcycle Accident Lawyer in Houston | Doe Law Firm",
      "isPartOf": { "@id": "https://firmdomain.com/#website" },
      "about": { "@id": "https://firmdomain.com/practice-areas/motorcycle-accidents/#service" },
      "breadcrumb": { "@id": "https://firmdomain.com/practice-areas/motorcycle-accidents/#breadcrumb" }
    },
    {
      "@type": "Service",
      "@id": "https://firmdomain.com/practice-areas/motorcycle-accidents/#service",
      "name": "Motorcycle Accident Representation",
      "description": "Contingency-fee representation for injured motorcyclists in Texas, including uninsured motorist claims, roadway design defect cases, and catastrophic injury claims.",
      "serviceType": "Personal Injury Representation",
      "provider": { "@id": "https://firmdomain.com/#legalservice" },
      "areaServed": { "@type": "AdministrativeArea", "name": "Harris County, Texas" }
    },
    {
      "@type": "FAQPage",
      "@id": "https://firmdomain.com/practice-areas/motorcycle-accidents/#faqpage",
      "mainEntity": [
        {
          "@type": "Question",
          "name": "How long do I have to file a motorcycle accident lawsuit in Texas?",
          "acceptedAnswer": {
            "@type": "Answer",
            "text": "Texas has a two-year statute of limitations for personal injury claims arising from motor vehicle accidents, including motorcycle accidents."
          }
        }
      ]
    },
    {
      "@type": "BreadcrumbList",
      "@id": "https://firmdomain.com/practice-areas/motorcycle-accidents/#breadcrumb",
      "itemListElement": [
        { "@type": "ListItem", "position": 1, "name": "Home", "item": "https://firmdomain.com/" },
        { "@type": "ListItem", "position": 2, "name": "Practice Areas", "item": "https://firmdomain.com/practice-areas/" },
        { "@type": "ListItem", "position": 3, "name": "Motorcycle Accidents" }
      ]
    }
  ]
}

The @graph Pattern for Multi-Office Personal Injury Firms

The @graph pattern for a multi-office PI firm uses one parent entity with a child LegalService per branch office. The parent’s type is decided by one question: does the firm have a headquarters with its own address? If yes, and most multi-office firms do, the parent is a LegalService (the HQ office, which doubles as the firm’s brand node), and the branches are its children. If the firm has no single HQ, the parent is an addressless Organization instead. Either way, each office LegalService carries its own @id, PostalAddress, telephone, geo, and areaServed, and attorneys tie to their specific office via worksFor.

The hub-and-spoke below shows the entity relationships for a three-office firm.

This pattern reflects how a multi-office firm actually operates: a main office that carries the brand, additional physical locations, attorneys assigned to specific offices, distinct service areas per office. The schema graph mirrors that reality so Google’s knowledge graph does not conflate the offices or duplicate the brand entity.

The Parent Entity: Your Headquarters LegalService (or an Addressless Organization)

The parent is a LegalService when the firm has a headquarters, because it is still a law firm and it has an address. It carries the brand identity (name, legalName, logo, url, sameAs) and the HQ office’s local properties (address, geo, telephone, areaServed) on the same node, then links to the branch offices via subOrganization. Each branch LegalService carries its own address and local operational properties and points back with parentOrganization. Only when the firm has no headquarters does the parent become an addressless Organization, per the exception below.

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "LegalService",
      "@id": "https://firmdomain.com/#legalservice",
      "name": "Doe Law Firm",
      "legalName": "Doe Law Firm, PLLC",
      "url": "https://firmdomain.com/",
      "logo": { "@type": "ImageObject", "url": "https://firmdomain.com/logo.png" },
      "telephone": "+1-713-555-0100",
      "address": {
        "@type": "PostalAddress",
        "streetAddress": "1400 Smith Street, Suite 300",
        "addressLocality": "Houston",
        "addressRegion": "TX",
        "postalCode": "77002",
        "addressCountry": "US"
      },
      "geo": { "@type": "GeoCoordinates", "latitude": 29.75589, "longitude": -95.36327 },
      "areaServed": { "@type": "City", "name": "Houston" },
      "subOrganization": [
        { "@id": "https://firmdomain.com/offices/dallas/#legalservice" },
        { "@id": "https://firmdomain.com/offices/san-antonio/#legalservice" }
      ]
    },
    {
      "@type": "LegalService",
      "@id": "https://firmdomain.com/offices/dallas/#legalservice",
      "name": "Doe Law Firm, Dallas Office",
      "url": "https://firmdomain.com/offices/dallas/",
      "parentOrganization": { "@id": "https://firmdomain.com/#legalservice" },
      "address": {
        "@type": "PostalAddress",
        "streetAddress": "500 Main Street, Suite 1200",
        "addressLocality": "Dallas",
        "addressRegion": "TX",
        "postalCode": "75201",
        "addressCountry": "US"
      },
      "telephone": "+1-214-555-0200",
      "areaServed": { "@type": "City", "name": "Dallas" }
    },
    {
      "@type": "LegalService",
      "@id": "https://firmdomain.com/offices/san-antonio/#legalservice",
      "name": "Doe Law Firm, San Antonio Office",
      "url": "https://firmdomain.com/offices/san-antonio/",
      "parentOrganization": { "@id": "https://firmdomain.com/#legalservice" },
      "address": {
        "@type": "PostalAddress",
        "streetAddress": "800 River Walk, Suite 400",
        "addressLocality": "San Antonio",
        "addressRegion": "TX",
        "postalCode": "78205",
        "addressCountry": "US"
      },
      "telephone": "+1-210-555-0300",
      "areaServed": { "@type": "City", "name": "San Antonio" }
    }
  ]
}

Two property choices carry this pattern. First, the parent is LegalService, not Organization, because it has a headquarters address; LegalService inherits from both Organization and Place, so the same node holds the brand identity, the HQ address, and the subOrganization links to the branches. Second, the link is subOrganization, not hasPart. In the Schema.org vocabulary, hasPart belongs to CreativeWork and is invalid on an Organization or LegalService; the organizational pair is subOrganization on the parent and parentOrganization on each child. Plenty of live law-firm schema gets both wrong, and they are exactly the class of error the Schema Markup Validator catches when the Rich Results Test stays silent.

The @id Convention That Ties Attorneys to the Right Office

Each attorney’s Person block ties to a specific office via worksFor using that office’s @id, not the parent entity’s @id (even when the parent is the HQ LegalService, an attorney who works in the Dallas branch points worksFor at the Dallas @id). If an attorney splits time across two offices, choose the primary office for worksFor and use workLocation as a secondary property for the second office.

{
  "@type": "Person",
  "@id": "https://firmdomain.com/attorneys/john-smith#person",
  "name": "John Smith",
  "worksFor": { "@id": "https://firmdomain.com/offices/houston/#legalservice" },
  "workLocation": { "@id": "https://firmdomain.com/offices/dallas/#legalservice" }
}

One vocabulary note on this pattern: workLocation expects a Place. Pointing it at a LegalService works only because LegalService inherits from Place as well as Organization; do not reuse the pattern against a pure Organization entity, which would ship invalid markup.

NAP Consistency Between Google Business Profile and Each Office’s Schema

NAP consistency between Google Business Profile and each office’s schema should be treated as exact, character for character, as the working standard. Google’s systems normalize common variants (St versus Street, Ste versus Suite), so a single abbreviation will not sink a listing, but every variation you remove is ambiguity Google no longer has to resolve, and exact alignment costs you nothing. A LegalService.address.streetAddress that reads 1400 Smith Street, Suite 300 against a Google Business Profile that reads 1400 Smith St., Ste 300 is resolvable ambiguity; ten of those variations across three offices is debt.

The alignment table below shows the specific GBP field to schema property mapping every multi-office firm should audit quarterly.

I audit around 30 PI firm sites a year, and NAP mismatch between schema and GBP is the single most common technical error I find. It’s silent, it never throws a validation error, and it leaves Google to guess which version of the firm’s identity is authoritative.

I said on a recent strategy call with a Texas firm.

The fix is a one-hour audit: open Google Business Profile in one tab, open the site’s schema in another, compare every property side by side, and fix the schema (never the GBP; GBP is what Google trusts as authoritative for local data). If your firm has three offices, run the audit three times. The payoff mechanism has a filed anchor: Google’s corroboration patent, Corroborating Facts Extracted from Multiple Sources, US Patent 8,682,913 B1, describes attribute-value pairs confirmed by cross-source agreement, which is exactly what identical NAP values across your schema, your GBP, the state bar record, and the major directories produce.

The patent record below carries the mechanism in its own words, with the corroboration phrase highlighted. The frame shows the patent number and the assignee event trail ending at Google LLC, so the “Google’s patent” attribution is verifiable at a glance.

Schema Placement Sequence by Page Template

Schema placement sequence should follow page template importance: homepage first, then attorney bios, then practice-area pages, then blog posts, then location pages. Ship in this order because the earlier templates carry more entity weight and their @ids get referenced by later templates.

The flow below sequences the implementation order for a typical PI firm site.

Homepage First: The LegalService Entity Home Plus WebSite

Ship the homepage @graph first. It anchors the entity graph for the entire site: one fully populated LegalService node defines the firm (brand identity and physical office data in the same entity, since LegalService inherits everything Organization carries), and WebSite defines the site entity that every WebPage points back to via isPartOf. Every other page template will reference these entities by @id, so getting them right on the homepage prevents cascading fixes across every other template. Multi-office firms extend this: the homepage LegalService becomes the headquarters parent with subOrganization links to the branches, or, only if there is no headquarters, a separate addressless Organization parent is added, per the multi-office section above.

Attorney Bios Second: Person Plus worksFor

Ship attorney bio @graphs second. Each bio carries a Person block with worksFor pointing back to the homepage LegalService @id (or, for multi-office firms, to the specific office LegalService @id). Bio pages also carry ProfilePage and BreadcrumbList entities in the same @graph, giving Google both the attorney entity and the page-scoped declaration, via ProfilePage.mainEntity, that this specific page is fundamentally about Jane Doe.

Practice-Area Pages Third: Service Plus FAQPage Plus WebPage

Ship practice-area page @graphs third. Each practice-area page carries a Service entity whose provider points at the firm’s canonical LegalService @id, plus a FAQPage block for the practice-area Q&A and a WebPage wrapper. Practice-area pages are your highest-intent local pages. The Service block names the practice area precisely, the FAQPage block structures the Q&A for machine extraction, and the areaServed property ties the practice to a specific geography.

Blog Posts and Guides Fourth: Article and BreadcrumbList

Ship Article schema on every blog post and long-form guide fourth. Article carries headline, author (Person), publisher (Organization), datePublished, dateModified, and image. The BreadcrumbList entity accompanies Article on every post. Blog Article schema improves display treatments in Google’s article surfaces and gives AI systems clean authorship and date data; Discover and News inclusion remain content-quality decisions, not schema switches, but the articles Google already likes display better with clean Article data. It also gives your bylined attorneys accumulated author-entity signal over time.

Location Pages Last (For Multi-Office Firms Only)

Ship location pages last, and only for firms with genuinely multi-office operations. Each location page carries a LegalService (or LocalBusiness) block for that office, with parentOrganization pointing to the sitewide Organization. Single-office firms should NOT create a location page for their one office. The homepage LegalService already carries the address; a duplicate location page splits entity signal and creates internal cannibalization on branded near-me queries.

The Underused Property Layer: Bar Numbers, Map CIDs, and Intake Actions Most PI Schema Never Ships

The nine types are the skeleton; the properties in this section are the muscle almost no PI firm attaches. Each one is cheap to ship, maps to a documented consumption mechanism, and shows up rarely enough in my audit samples that carrying it puts a firm in the top few percent of implementations. Several already appeared in the code blocks above (the hasMap CID, the bar-number identifier, the structured credentials); this section covers the remaining set.

Intake actions are the clearest example. The retirement of the sitelinks search box removed one use of potentialAction, but the property itself is alive for what a PI firm actually wants: declaring the intake paths. Google’s action-recommendation patent, Recommending Actions Based on Entity or Entity Type, US Patent 12,147,767 B2, describes surfacing actions tied to an entity, and a contingency-fee firm’s actions are “call now” and “schedule the free consultation.” The block below declares both.

{
  "@type": "LegalService",
  "@id": "https://firmdomain.com/#legalservice",
  "potentialAction": [
    {
      "@type": "ContactAction",
      "name": "Call for Free Consultation",
      "target": "tel:+17135550100"
    },
    {
      "@type": "ReserveAction",
      "name": "Schedule Free Consultation",
      "target": {
        "@type": "EntryPoint",
        "urlTemplate": "https://firmdomain.com/consultation",
        "actionPlatform": [
          "http://schema.org/DesktopWebPlatform",
          "http://schema.org/MobileWebPlatform"
        ]
      }
    }
  ]
}

Leadership roles are the second gap. A membership string says the attorney belongs to the bar association; an OrganizationRole says she chairs its personal injury section, with a start date. For attorneys who hold leadership positions, wrap the membership in a role node: "memberOf": { "@type": "OrganizationRole", "roleName": "Chair, Personal Injury Section", "startDate": "2022-01-01", "memberOf": { "@type": "Organization", "name": "State Bar of Texas" } }. Authority claims with structure and dates beat authority claims as adjectives.

The semantic layer is the third gap, and the one with the longest tail. Every practice-area page can declare its topic as a resolvable entity rather than a keyword: an about node naming the legal concept with a sameAs pointing at the page that IS that concept, plus mentions for the secondary concepts the page discusses.

"about": {
  "@type": "Thing",
  "name": "Personal injury law",
  "sameAs": "https://en.wikipedia.org/wiki/Personal_injury"
},
"mentions": [
  {
    "@type": "Thing",
    "name": "Statute of limitations",
    "sameAs": "https://en.wikipedia.org/wiki/Statute_of_limitations"
  },
  {
    "@type": "Thing",
    "name": "Comparative negligence",
    "sameAs": "https://en.wikipedia.org/wiki/Comparative_negligence"
  }
]

One discipline rule keeps this layer semantic rather than decorative: sameAs asserts identity, not relatedness. Link only to pages that ARE the concept; a wrong sameAs joins your page to the wrong global entity, which is worse than no link at all. Verify every URL before it ships. The same identity rule is why the firm’s own sameAs list should carry the state bar profile, the GBP CID URL, and the major directory profiles: each one is another source corroborating that the entities are the same firm.

Two smaller items close the set. For firms serving Spanish-speaking claimants, inLanguage on the firm and knowsLanguage on the attorneys make the bilingual capability machine-readable instead of a paragraph Google has to parse. And for the direct-answer passages your pages already carry (“In Texas, the statute of limitations for personal injury is generally two years”), speakable markup flags the two-to-three-sentence spans voice surfaces and AI answers extract best. Neither earns a rich result; both reduce the guesswork between your content and the systems reading it.

Rich Result Eligibility for Personal Injury Schema in 2026

Rich result eligibility for PI schema in 2026 is far narrower than most vendor pages admit. Google removed self-serving review stars in 2019, rolled back FAQ rich results for non-government sites and retired HowTo in 2023, and retired the sitelinks search box in 2024. What still works for a PI firm is LocalBusiness/LegalService entity data supporting the Knowledge Panel and local surfaces via Google Business Profile alignment, BreadcrumbList in the SERP snippet, Article display treatments, and review stars only where the reviews live on a third party’s own pages.

The SERP column below reflects Google Search Central guidance verified on the retrieval dates in the References. The AI columns are my assessment, since no vendor documents per-type citation eligibility. The two properties move independently: a schema type can help AI extraction even when it no longer renders anything in the classic SERP.

What Still Renders in Google: LocalBusiness, BreadcrumbList, Review (Third-Party), Article

The schema types that still produce visible SERP-level value for a PI firm are LocalBusiness/LegalService (entity data that supports the Knowledge Panel and local surfaces, in alignment with Google Business Profile), BreadcrumbList (rendering as the breadcrumb path under the SERP snippet), review stars on third-party platforms’ own pages (not on your site), and Article (improved display treatments for your content in Google’s article surfaces). These are the surfaces where schema investment produces observable lift. Every PI firm should prioritize implementations that hit these surfaces first.

What Google Rolled Back: FAQPage for Non-Government Sites, HowTo, Self-Attested Review Stars

The FAQ rich result was restricted to well-known, authoritative government and health websites in the change Google announced on August 8, 2023. The HowTo rich result was retired in stages through that same announcement, disappearing from desktop entirely as of September 14, 2023. Self-attested Review star ratings had been gone for years by then: Google removed review stars for LocalBusiness and Organization entities that control their own reviews in its September 16, 2019 update, Making Review Rich Results More Helpful.

What Feeds AI Citation Even Without a Visible Rich Result

FAQPage, Article, and Service schema all remain useful for AI surfaces (AI Overviews, ChatGPT, Perplexity) even though FAQPage no longer renders as a rich result and Service has no direct rich result at all. AI systems can read the underlying entity data regardless of what Google chooses to render in the classic SERP, and clean entity data costs them nothing to consume.

The rich result was the payoff for a decade. The AI citation is the payoff for the next decade.

I tell every firm on our first strategy call.

Firms that dismiss FAQPage because it stopped rendering are ceding AI citation surface to competitors who kept shipping it. Firms that dismiss Article schema because it produces a small SERP lift are ignoring the citation lift they get in AI Overviews and Perplexity, where authorship and publication date matter as authority signals.

Schema Markup and State Bar Advertising Rules for Personal Injury Attorneys

Schema markup interacts with state bar advertising rules in three specific ways: AggregateRating values on solicited reviews trigger the same rules as testimonial claims in ad copy, Person.jobTitle claims of specialization trigger the same rules as specialty claims in firm bios, and Article schema about past case results triggers the same rules as verdict statements in traditional advertising. Every state bar treats these differently, and the ABA Model Rules are the baseline.

The personal injury lawyer marketing compliance piece covers the full state-by-state variation for PI marketing surfaces. The table below is a compressed schema-property intersection view for the properties most likely to trigger a bar issue.

AggregateRating and the Solicited-Testimonial Prohibition

AggregateRating.ratingValue that reflects self-attested reviews from your own website is a compliance risk under ABA Model Rule 7.1 and every state bar’s version of it, because self-published ratings on the firm’s own site can create the impression of independent verification that does not exist. Google will not render self-attested Review markup as star ratings anyway, but the risk is not Google’s; it is your state bar’s.

The compliant approach is to keep Review and AggregateRating markup about your own firm off your own site entirely and let the third-party platforms (Google Business Profile, Avvo, Martindale) carry the reputation signal from their own pages. If your current schema carries an AggregateRating, removing it solves the Google ineligibility problem and the bar-rule exposure in a single edit.

Person Job Title and Specialist Certification Rules

Person.jobTitle of “Personal Injury Specialist” or any variation of “Specialist” is a compliance risk unless the attorney holds a state-bar-recognized specialty certification. ABA Model Rule 7.2 and most state bar rules restrict use of “specialist” language to attorneys who have earned the certification, and they treat any language that implies specialty (including “expert,” “leader,” “top”) the same way in structured data as in ad copy.

The compliant approach is to use Person.jobTitle of “Personal Injury Attorney” or “Trial Attorney” for uncertified attorneys, and reserve “Board Certified in Personal Injury Trial Law” (or the exact state-specific specialty title) only for attorneys who hold the certification. When you claim the certification, tie it to hasCredential referencing the certifying body’s exact name, and add memberOf to the certifying organization.

Article Schema and Past-Result Disclaimer Requirements

Article schema about past case results (settlements, verdicts, jury awards) does not override state bar requirements for past-result disclaimers in the article body itself. Every state with past-result rules requires disclaimer language explaining that past results do not guarantee future outcomes, and that language must appear in the visible body copy of the article, not just in the schema block.

The compliant approach is to write the disclaimer into the body copy of every case-result article and to reflect the specific state’s language verbatim (Florida’s disclaimer is different from Texas’s, which is different from California’s). Article schema should not attempt to encode a “disclaimer” property; that is a body-copy requirement, not a schema requirement.

Review Body Text and Confidentiality Boundaries

Review.reviewBody text should be carefully reviewed against attorney-client privilege and any settlement confidentiality provisions before it appears in schema. A client review that names a settlement amount, describes a specific defendant, or discusses a case’s procedural history may violate a settlement’s confidentiality clause even if the client wrote it themselves.

Client reviews are marketing gold and compliance dynamite at the same time.

I tell every firm during intake for the Personal Injury SEO Diagnostic.

The safest approach is to source Review markup exclusively from Google Business Profile and Avvo (both platforms have their own compliance moderation) and to skip self-hosted Review schema entirely. If you want testimonials on your own site for design reasons, run them as body copy without Review schema wrapping.

Common Personal Injury Schema Errors and How to Fix Them

Common personal injury schema errors fall into six categories, ranked by severity. Two are critical, three are major, one is minor. Each has a specific fix; each is common enough that you should audit your own schema against all six before assuming you are clean.

Critical: Using the Deprecated Attorney Type

If your attorney bio pages ship "@type": "Attorney", you are running markup deprecated roughly a decade ago. It adds nothing over LegalService and signals an unaudited implementation. Fix: replace every Attorney block with a Person block carrying worksFor pointing to your firm’s LegalService. Every attorney bio, every hasMember array on the Organization block, every page that referenced Attorney gets updated.

Critical: Self-Attested Reviews Marked as Star Ratings

If your homepage or practice-area pages ship AggregateRating.ratingValue reflecting reviews you gathered on your own site, you have a critical compliance and rendering issue. Google will not render the stars. Some state bars will treat the AggregateRating as a misleading independent-verification claim. Fix: remove Review and AggregateRating about your own firm from your own site entirely. The stars render on the third-party platforms’ own pages and through your Google Business Profile; importing their review data into your own markup is both ineligible and against Google’s sourcing guidelines.

Major: NAP Mismatch Between Google Business Profile and Schema

If your LegalService.address, LegalService.telephone, or LegalService.name differs from your Google Business Profile listing (Suite vs. Ste., St vs. Street, comma placement, phone formatting), you have a NAP mismatch. Google usually resolves minor formatting variants, but there is no reason to make it guess. Fix: audit each office’s GBP listing side by side with the site’s schema, and update the schema to match GBP character for character. Never edit GBP to match schema; GBP is what Google treats as the operative record for local data.

Major: Missing worksFor Link Between Attorney Person and Firm LegalService

If your attorney Person blocks lack worksFor, Google cannot connect the named attorneys to the firm entity. The attorney-to-firm relationship your bios should be establishing in the knowledge graph never forms, and named-attorney queries lose the entity association that makes those bios worth marking up at all. Fix: add worksFor to every Person block, pointing to the firm’s LegalService @id (or, for multi-office firms, to the specific office LegalService @id).

Major: FAQPage Schema Placed on Sidebar Q&A Rather Than Dedicated Page

If your FAQPage schema wraps a sidebar Q&A element rather than the main content of a dedicated FAQ page, you may fail validation and you definitely lose AI citation eligibility. FAQPage’s mainEntity property is meant to declare the primary content of the page. Fix: either move the Q&A into the primary content area (so FAQPage.mainEntity accurately describes the page) or drop FAQPage schema from that page and use dedicated FAQ pages for FAQPage markup.

Minor: Missing @id Causing Entity Duplication Across Templates

If your schema blocks omit @id, Google sees each block as a separate entity even when they refer to the same firm, attorney, or service. This creates entity duplication in the knowledge graph and dilutes the signal each block sends. Fix: add @id to every LegalService, Person, Organization, Service, WebSite, WebPage, and BreadcrumbList entity. Every @id is a canonical URL with a fragment identifier (#organization, #legalservice, #person, #article). Every cross-reference across pages uses the same @id. The good news from my audits is that the market is doing reasonably well here: 80.3% of PI firms with any schema carry @id in the 1,005-firm study, and 84.0% in the 500-firm study. Entity disambiguation is the strongest of the five Schema Completeness Index dimensions in both studies, at 4.1 and 3.9 out of 5.

That 84.0% figure is not an estimate. The first page of my 500-firm SSRN study is below, with the exact sentence highlighted; the title, my name, and the ORCID sit in the same frame so the finding is traceable to a published source.

Validation, Monitoring, and the Quarterly Personal Injury Schema Audit

Validation, monitoring, and quarterly auditing are the three-stage discipline that keeps schema working over time. Validation happens at ship time. Monitoring happens continuously through Google Search Console. Auditing happens quarterly, or more often when Google runs a core update or Schema.org changes a type.

The calendar below shows the quarterly audit cadence keyed to Google’s typical core update windows.

Google’s Rich Results Test Is the First Gate

Google’s Rich Results Test at search.google.com/test/rich-results is the first validation gate. Paste your URL or paste your JSON-LD directly, run the test, and verify zero errors. Treat warnings as a checklist of recommended properties worth filling wherever you have the data; warnings do not block eligibility and do not escalate into errors over time, they flag missing recommended fields. The Rich Results Test only validates against Google’s list of supported rich results. Types Google does not use for rich results (Service, Organization when not eligible for Knowledge Panel signals) will not throw errors but also will not be validated against the broader Schema.org vocabulary.

The Schema Markup Validator Catches What Google Silently Ignores

The Schema Markup Validator at validator.schema.org catches broader vocabulary errors Google’s Rich Results Test silently ignores. If a property expects a specific type and you passed a string, or if you put a CreativeWork-only property like hasPart on an Organization, the Validator flags it. It will not flag Attorney as deprecated, though; deprecation is a vocabulary note, not a validation error, which is why the manual grep in the audit section above is the reliable check for that one. Run the Validator on every schema block before shipping.

Google Search Console Enhancements Report for Ongoing Monitoring

Google Search Console’s Enhancements reporting is the ongoing monitor. It surfaces structured-data errors and warnings as Googlebot re-crawls your site. Check it monthly at minimum; set up email alerts if your Search Console access allows it. It is also where Google’s evolving stance shows up in blunt form: when FAQ rich results were restricted in 2023, the FAQ enhancement reporting was retired from Search Console along with the feature, and firms that watched the reports noticed immediately while everyone else kept expecting rich results that no longer existed. Validation is the single weakest dimension the market performs on: the average Validation Status score across sites with any schema was 1.4 out of 5.0 in the 1,005-firm audit and 0.9 out of 5.0 in the 500-firm study. Most PI firms have schema. Most PI firms have never validated it. If you run one audit this quarter, run this one.

The Quarterly Audit Calendar Keyed to Google Core Updates

The quarterly schema audit calendar aligns with Google’s core update cadence. Google has been running three to five broad core updates a year on an irregular schedule that averages out to roughly quarterly. Schedule a schema audit two to three weeks after each announced core update; that timing gives Google enough index refresh cycles to reflect any schema-related visibility shifts.

The firms with predictable visibility across core updates are the firms with disciplined schema audits. The firms with lumpy performance almost always trace it back to schema that drifted between audits.

I said on a strategy call with a multi-office California firm in June.

The audit itself takes two to four hours for a small firm and a day for a mid-size firm. It is cheap insurance against the visibility drops that catch unprepared firms every core update cycle.

Where Schema Markup Fits Inside the PI Organic Authority Engine

Schema markup lives inside the Technical Stability pillar of the PI Organic Authority Engine, alongside crawlability, indexation, site architecture, and Core Web Vitals. Technical Stability is Phase 1 of the engine. Its purpose is to reduce Google’s cost of reading and understanding your site, so the higher-signal parts of the engine (Intent Capture, Authority Reinforcement, Case Acquisition Optimization) get to compound their effect.

The grid below maps schema’s contribution across all four PIOAE phases.

Schema is not just a Phase 1 concern. It touches every pillar downstream. The full technical SEO for personal injury law firms treatment covers all five Phase 1 components; this article covers only schema. Firms that fix schema without fixing crawlability, indexation, and site architecture will see limited compound effect. Schema is necessary but not sufficient.