Personal Injury Schema Markup: The SEO Element Most PI Firms Skip

Most personal injury firm websites fall into one of three categories when it comes to schema markup: no schema at all, generic Organization schema auto-generated by a WordPress plugin, or the deprecated Attorney schema type that Google and most AI systems no longer honor. None of these three positions help an AI system decide whether to cite your firm when someone asks a question your firm could genuinely answer — and increasingly, that citation decision is happening before a prospective client ever sees a traditional search result.

This guide covers what schema markup actually is, why most PI firms are implementing it incorrectly or skipping it entirely, and the specific, current 2026 implementation that closes this gap.

What Schema Markup Actually Does

Schema markup is structured code, typically implemented as JSON-LD, that sits in a page’s HTML and explicitly tells search engines and AI systems what the content on that page means — not just what it says. A visitor sees your homepage as text and images; a search engine or AI system without schema has to infer what your firm does, where it’s located, and who its attorneys are purely from unstructured content. Schema removes that guesswork by stating it directly in a machine-readable format.

For a personal injury firm, this matters for two related but distinct reasons. First, traditional search engines use schema to determine rich result eligibility and to populate knowledge panel information accurately. Second, and increasingly more significant, AI systems generating summarized answers rely heavily on structured data to verify and cite content with confidence — recent citation studies show sites with proper schema markup get cited meaningfully more often in AI-generated answers than sites without it, and schema functions less like a minor ranking boost and more like a gating signal for whether an AI system trusts your site enough to cite confidently at all.

Why So Many PI Firm Sites Get This Wrong

The single most common mistake is continuing to use the Attorney schema type, which Schema.org has formally deprecated. Many older WordPress legal marketing plugins still generate this type automatically, and firms using them are often unaware their schema is technically broken, even though the plugin interface shows no error. Google and current AI systems no longer meaningfully honor this type, meaning firms relying on it are getting essentially zero value from schema they believe is working correctly.

The second common mistake involves FAQPage schema specifically. This type used to generate visible expandable FAQ dropdowns directly in search results, but Google restricted this rich result feature to government and health authority sites during 2024-2025, meaning most law firm sites no longer see the visual SERP benefit they might remember from a few years ago. This has led some firms to conclude FAQPage schema is no longer worth implementing — which is a mistake, since the schema still feeds AI citation systems directly, even without producing the visual search result feature it once did.

The third mistake is a newer risk specific to 2026: Google’s March 2026 core update began penalizing schema that doesn’t accurately describe the actual content on a page. A practice area page with a small, tacked-on FAQ section at the bottom, wrapped entirely in FAQPage schema as though the whole page were FAQ content, is now the kind of mismatch that update specifically targets. Schema needs to accurately reflect what a page actually contains, not be applied broadly in hopes of qualifying for AI citation value it hasn’t earned through genuine content structure.

The Correct Schema Stack for a Personal Injury Firm in 2026

LegalService schema is the foundation and should be implemented before anything else. This identifies your firm as a legal services provider, specifies your practice areas explicitly, and establishes your geographic service area. Critically, practice areas should be listed specifically — “personal injury,” “auto accident law,” “premises liability” — rather than a vague catch-all like “legal services,” since specific entries create precise matching opportunities when an AI system is trying to determine whether your firm is relevant to a specific query.

A basic LegalService implementation looks like this:

json

{
  "@context": "https://schema.org",
  "@type": "LegalService",
  "name": "Firm Name",
  "url": "https://www.example.com",
  "telephone": "+1-555-555-5555",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "123 Main St",
    "addressLocality": "City",
    "addressRegion": "State",
    "postalCode": "00000",
    "addressCountry": "US"
  },
  "areaServed": "City, State",
  "priceRange": "$$",
  "knowsAbout": [
    "Personal Injury Law",
    "Auto Accident Claims",
    "Premises Liability",
    "Workers Compensation"
  ]
}

Person schema replaces the deprecated Attorney type for individual attorney profiles. Each attorney page should include Person schema connected back to the firm’s LegalService entity through the worksFor property, with credentials, bar admission details, job title, and a professional headshot included. This structure feeds E-E-A-T signals directly at the structured data level, giving AI systems an explicit, verifiable connection between an individual attorney’s credentials and the firm as a whole.

json

{
  "@context": "https://schema.org",
  "@type": "Person",
  "name": "Attorney Name",
  "jobTitle": "Personal Injury Attorney",
  "worksFor": {
    "@type": "LegalService",
    "name": "Firm Name"
  },
  "alumniOf": "Law School Name",
  "image": "https://www.example.com/attorney-photo.jpg"
}

Organization schema operates at the firm level, covering name, logo, founding date, and social profile links, and feeds Google’s Knowledge Graph directly, supporting Knowledge Panel eligibility. This becomes particularly important for multi-location firms — without a clear Organization layer connecting each location back to a single firm entity, search engines and AI systems can end up treating each office as a separate, disconnected entity, leading to fragmented knowledge panels and inconsistent AI citations about which attorneys work where.

FAQPage schema remains genuinely valuable despite no longer producing visible SERP dropdowns for most law firm sites. Recent data shows FAQPage schema appears in a majority of AI-generated answers for relevant legal questions, meaning its real value now lives entirely in AI citation extraction rather than traditional search appearance. The critical implementation detail, given the March 2026 update, is applying FAQPage schema only to genuine, substantial FAQ content — not wrapping an entire practice area page in FAQPage schema because it happens to include three questions near the bottom.

Practical Placement: Which Schema Goes on Which Page

Homepage: LegalService and Organization schema, establishing the core firm entity.

Practice area pages: LegalService schema scoped to the specific practice area being discussed, plus FAQPage schema if the page includes genuine, substantial FAQ content specifically — not a token few questions added purely to justify the schema.

Attorney bio pages: Person schema for the individual attorney, connected back to the firm via worksFor.

Contact page: LegalService schema repeated or referenced, ensuring location and contact information is consistently machine-readable wherever a user or AI system might look for it.

Why Entity Consistency Matters as Much as Schema Presence

Beyond simply having schema in place, consistency across every instance matters significantly. If your firm’s name, address, or phone number in schema doesn’t exactly match what’s shown in your Google Business Profile, legal directory listings, or other citations across the web, search engines and AI systems can struggle to confidently merge these signals into a single, trusted entity record. This is the same NAP consistency principle relevant to directory citations, applied at the structured data level rather than just the visible content level.

Without accurate schema feeding this entity graph directly from your own site, search engines and AI systems fall back to pulling information from third-party directories instead — sometimes with stale phone numbers, outdated office hours, or missing attorneys who’ve since joined the firm. Implementing accurate schema is effectively how a firm takes ownership of its own entity record at the source, rather than leaving that record to be assembled secondhand from potentially outdated directory data.

A Fifth Schema Type Worth Adding: Review Schema

Beyond the four core types above, Review schema aggregated from your firm’s genuine review sources deserves a place in a complete implementation, particularly given how heavily prospective PI clients weigh social proof when selecting representation. Rather than hand-entering review content directly into schema, this is best implemented by aggregating genuine reviews from platforms like Google Business Profile, Avvo, or Martindale-Hubbell, ensuring the structured data reflects real, verifiable review activity rather than static or fabricated content.

json

{
  "@context": "https://schema.org",
  "@type": "LegalService",
  "name": "Firm Name",
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.8",
    "reviewCount": "127"
  }
}

This connects directly back to the aggregateRating property on your core LegalService entity, giving both traditional search results and AI systems a structured, verifiable trust signal alongside the practice area and location data already covered.

A Worked Example: Auditing and Fixing a Typical Existing Implementation

To make this concrete, consider a common starting point: a mid-sized PI firm’s WordPress site running an older legal marketing plugin that auto-generates Attorney schema on each attorney bio page, alongside a generic Organization schema block on the homepage with no practice area detail and no FAQPage schema anywhere on the site.

The audit process starts with running the Rich Results Test against the homepage and each attorney bio page, confirming the Attorney type is indeed still present and identifying exactly which fields the current Organization schema does and doesn’t cover. From there, the fix sequence is straightforward: replace each Attorney schema block with the Person schema structure covered above, explicitly connecting each attorney back to the firm via worksFor; expand the homepage Organization schema into a full LegalService implementation with explicit practice areas listed rather than a generic services description; and add appropriately-scoped FAQPage schema to practice area pages that already contain genuine FAQ content, while resisting the temptation to add it everywhere just to claim the schema type broadly.

For this firm, the entire fix — assuming Rank Math or a similar plugin is already installed and simply needs correct configuration rather than custom code — typically takes under two hours across a homepage, five to eight practice area pages, and however many attorney bio pages the firm maintains. This is a genuinely small time investment relative to the AI visibility gap it closes, which is exactly why it’s worth prioritizing even though it doesn’t produce the same immediately visible feedback as a new blog post or backlink.

Common Implementation Mistakes Beyond the Deprecated Attorney Type

Applying identical LegalService schema across every page without practice-area-specific scoping. A firm handling both personal injury and other practice areas should scope schema on each practice area page to reflect that specific service, rather than repeating a single, undifferentiated firm-wide schema block everywhere, which weakens the precise-matching value schema is meant to provide.

Leaving sameAs properties unconnected to real profiles. The sameAs property, which links your schema entity to your firm’s official social media and directory profiles, is frequently omitted entirely or left incomplete. This property is specifically how search engines and AI systems confirm that your website’s claimed identity matches your presence elsewhere, and skipping it weakens the entity verification schema is meant to support.

Inconsistent implementation across multi-location pages. A firm with several office locations needs schema that clearly distinguishes each location while still connecting them under a single Organization entity. Treating each location’s page as though it were an entirely separate, unconnected firm creates exactly the fragmentation problem covered earlier in this guide.

Forgetting to update schema when firm details change. New attorneys, practice area expansion, and office relocations all require corresponding schema updates. A firm that updates its visible website content after a change but forgets the underlying schema ends up with a mismatch between what a page visibly says and what its structured data claims — precisely the kind of inconsistency that undermines the trust the schema is meant to build.

Implementation Practicalities

For most firms using WordPress with Rank Math, checking existing schema output is a necessary first step before adding anything new, since many legal marketing plugins have already generated some schema — often the deprecated Attorney type — that needs to be identified and replaced rather than simply added to. Rank Math’s Schema Generator supports LegalService, Person, and FAQPage types directly through its interface, avoiding the need to hand-code JSON-LD for most standard implementations, though custom code may still be necessary for more specific entity relationships like the worksFor connection between attorney and firm.

For a small firm with a straightforward site structure, implementing this full stack correctly is realistically a short, focused task — often achievable in well under an hour once the correct schema types and field mappings are understood. Larger, multi-attorney or multi-location firms should expect a more involved implementation, given the need to correctly connect multiple Person entities and potentially multiple location-specific LegalService instances back to a single consistent Organization entity.

Validating Your Implementation

After implementing schema, validation against Schema.org’s current specifications and Google’s Rich Results Test is essential, both to catch technical errors and to confirm the deprecated Attorney type has actually been fully removed rather than simply supplemented with newer types alongside it. Schema.org periodically deprecates types and Google periodically adjusts rich result eligibility requirements, meaning a firm should treat schema as something to periodically revalidate rather than a true set-and-forget implementation — firms that treat it as permanent once implemented risk running increasingly outdated markup for years without realizing it, invisible to the AI systems their competitors are actively feeding with current, accurate structured data.

Frequently Asked Questions

Does schema markup directly improve traditional search rankings, or only AI citation likelihood?

Its direct traditional ranking impact is modest and mostly indirect, primarily through rich result eligibility and clearer entity signals that support overall trust and relevance evaluation. Its more significant, measurable current value is in AI citation likelihood, where properly structured entity data appears to function as something closer to a gating requirement than a minor optimization.

Is it worth implementing schema markup on a brand-new firm website with minimal content?

Yes — schema implementation doesn’t require extensive existing content to be worthwhile, since it’s describing your firm’s core identity, practice areas, and attorneys regardless of how much additional content exists yet. It’s a genuinely foundational technical element worth implementing early rather than treating as a later-stage optimization.

How can a firm check whether its current schema is using the deprecated Attorney type?

Google’s Rich Results Test tool, run against key pages like attorney bio pages, will show which schema types are currently detected. Firms using an older legal marketing WordPress plugin should check this directly rather than assuming their existing schema is current, since many plugins haven’t updated their default output to reflect the deprecation.

Should FAQPage schema be removed entirely given it no longer produces visible search result dropdowns for most law firm sites?

No — while the visual SERP benefit has largely disappeared for law firms specifically, FAQPage schema continues to feed AI citation extraction directly, and removing it would give up genuine current value in exchange for a minor cleanup that isn’t actually necessary. The correct response to the visual benefit disappearing is continuing to implement it correctly for genuine FAQ content, not abandoning the schema type.

How often should schema markup be revalidated after initial implementation?

An annual check against current Schema.org specifications and Google’s Rich Results Test is a reasonable baseline, with additional checks warranted after any major site redesign, WordPress plugin update, or awareness of a relevant algorithm update like the March 2026 core update that specifically affected schema eligibility criteria.

Does implementing schema markup require ongoing technical maintenance, or is it primarily a one-time setup?

While the initial implementation is the larger task, schema does require periodic revalidation as covered above, plus updates whenever firm details change — new attorneys, practice area expansion, office relocations — similar to the ongoing maintenance directory citations require to stay accurate and consistent.

Can schema markup be implemented without a developer, using only a plugin like Rank Math?

For most standard implementations covered in this guide, yes — Rank Math’s Schema Generator handles LegalService, Person, and FAQPage types directly through its interface without requiring hand-coded JSON-LD. More complex custom entity relationships, like precisely connecting multiple attorneys and multiple office locations under a single Organization entity for a larger multi-location firm, may benefit from developer involvement to implement cleanly, but this exceeds what most solo practices or small firms need.

How does a firm know if its schema implementation is actually influencing AI citations, given there’s no direct visible metric for this?

Direct measurement is genuinely difficult, since AI systems don’t provide the kind of citation-source reporting that Google Search Console provides for traditional search. The most practical approach is periodically asking major AI systems directly — ChatGPT, Perplexity, Google’s AI-generated summaries — a query a prospective client might realistically ask, and checking whether your firm appears among the cited or recommended sources over time as implementation matures and the broader content and backlink strategy develops alongside it.

The Bottom Line

Schema markup is one of the more overlooked elements in personal injury firm SEO precisely because its most significant current value — AI citation likelihood — doesn’t show up in the visible, familiar metrics most firms are used to tracking, like rich result snippets or immediate ranking position. Implementing the correct current stack — LegalService, Person, Organization, and appropriately-scoped FAQPage schema — while avoiding the deprecated Attorney type and the schema-content mismatch risk introduced by the March 2026 core update, is a genuinely high-leverage, low-cost technical investment that closes topical authority signals most competing firms haven’t yet addressed correctly.