Schema Markup Adoption in Personal Injury Law Firm Websites: What I Found After Studying 500 Sites
Two thirds of US personal injury law firms deploy some form of JSON-LD schema markup on their websites. Only 40 percent of them deploy LegalService, the Schema.org type built specifically for law firms. The median PI firm scores 12 out of 25 on the Schema Completeness Index I use to rate structured data quality. I know these numbers with confidence because I collected them myself, from a systematic audit of 500 personal injury law firm websites across the United States. The results are published as a working paper on SSRN, and this article is the plain language version.
The paper is dense with tables and dimension scores. This article is the version I would hand to a managing partner or a marketing director who wants to understand what schema markup does for a PI firm’s search visibility, where their site probably stands today, and what to do about the gap. If your firm’s site was in the sample, the odds are about 60 percent that you sit in the bottom half of the maturity distribution. That is a fixable problem, and the fix is more concrete than most industry guides admit.
I run a Personal Injury SEO Diagnostic service for firms that want an outside audit of exactly this kind of gap. But this article gives you enough to start on your own.
Table of contents
- What Schema Markup Actually Is for a Personal Injury Law Firm
- How I Studied 500 Personal Injury Law Firm Websites for Schema Adoption
- Schema Adoption Rates I Measured Across the 500 Personal Injury Law Firm Sample
- The Schema Types That Actually Move Case Acquisition for a Personal Injury Law Firm
- The Schema Completeness Index I Use to Score Personal Injury Law Firm Structured Data
- The Structured Data Maturity Model I Built for Personal Injury Law Firms
- Entity Disambiguation: The Schema Dimension Where PI Law Firms Lose the Most Ground
- Multi Office and Multi State Personal Injury Law Firm Schema Architecture
- Does Schema Markup Help Personal Injury Law Firms Get Cited in AI Overviews and ChatGPT?
- How to Implement Schema Markup on a Personal Injury Law Firm Website
- Validation and Ongoing Maintenance for Personal Injury Firm Schema Markup
- The Twelve Most Common Schema Errors I See in the Personal Injury Vertical
- Bar Rule Compliance for Schema Markup on Reviews, Case Results, and Attorney Credentials
- Work With Me on Personal Injury Law Firm Schema Implementation
- Closely Related Topics on Personal Injury Law Firm SEO
- References
- Frequently Asked Questions on Personal Injury Law Firm Schema Markup
What Schema Markup Actually Is for a Personal Injury Law Firm
Schema markup is a machine-readable data layer that sits alongside your visible website content and describes what each entity on the page actually is. For a personal injury law firm, that means declaring in structured form that this website belongs to a law firm named Firm X, that Firm X has three offices at specific addresses, that Attorney Y works for Firm X and specializes in motor vehicle accident law, and that this specific page describes a specific practice area. The data is written as JSON-LD, a JSON format that Google recommends over the older Microdata and RDFa serializations. Schema.org is the collaborative vocabulary that both parties speak, published and maintained by a consortium of Google, Microsoft, Yahoo, and Yandex since 2011.
The Hypernymic Chain: From Search Marketing to Schema Markup for PI Firms
Schema markup lives inside a larger hierarchy of digital marketing disciplines that a PI firm’s outside vendor, in-house SEO staff, or agency navigates every month. The full chain runs Digital Marketing at the top, then Search Marketing, then Search Engine Optimization, then Technical SEO as one of the five pillars of SEO alongside on-page, off-page, local, and generative engine optimization, then Structured Data as one of the four or five sub-disciplines of Technical SEO alongside crawlability, indexation, page experience, and internationalization, then Schema Markup as the specific structured data standard the web has settled on, then JSON-LD as the specific serialization format Google prefers, then the vertical-specific application to legal services, and finally the concrete personal-injury-law-firm implementation. Naming the chain matters because it locates schema in the reader’s mental map: schema is a Technical SEO discipline, and Technical SEO is one of five pillars of the broader field, and the broader field is one of several digital marketing channels that compete with paid ads, LSAs, and referral partnerships for the firm’s growth budget.
The Hypernymic Chain to Personal Injury Law Firm Schema
Nine tiers from Digital Marketing at the top down to Personal Injury Law Firm Schema at the bottom.
Why Google and AI Answer Engines Read Schema Markup on Law Firm Websites
Google uses schema markup as one of several signals for interpreting the entities described on a page. A page that declares a specific attorney as a Person entity with worksFor pointing at a LegalService entity, and that LegalService entity carrying sameAs references to Wikidata, LinkedIn, and the state bar, gives Google an anchor point to bind the on-page entity to a Knowledge Graph node. Google’s 2012 patent on entity disambiguation, US Patent 8,122,026 by Laroco, Jevtic, Yakovenko, and Reynar, titled Finding and Disambiguating References to Entities on Web Pages, documents the mechanics: the engine looks for stable identifiers and external cross-references before deciding which real-world entity a page’s mention refers to. When AI answer engines like Google’s AI Overviews, ChatGPT, Perplexity, and Gemini generate citations, they draw from the same entity graph. A firm whose schema does the disambiguation work upfront gets cited more accurately when a citation happens. Whether schema increases the raw rate of AI citations is a separate question I cover later; the honest answer is that the recent Ahrefs 1,885-page study suggests the direct lift is small.
The patent record below confirms Google’s authorship, the inventor list, and the specific mechanism the article cites: an iterative process that disambiguates references to entities across documents.
“Schema is not a ranking trick. It is the machine-readable version of your firm’s identity, and Google, Bing, and every LLM that pulls from web data reads that identity before deciding whether to include you in an answer.”
Behzad Hussain, Personal Injury SEO Strategist
How I Studied 500 Personal Injury Law Firm Websites for Schema Adoption
I ran the study between late 2025 and early 2026, using a custom Python pipeline against a sample of 500 US personal injury law firm websites drawn from Google SERP results for 20 high-volume PI queries across major US metropolitan areas. The pipeline crawled the homepage plus up to 20 internal pages per site, matching practice-area, attorney, FAQ, and contact URL patterns. It extracted every JSON-LD script block, parsed the extracted data, validated it against Schema.org specifications, and scored each implementation on a five-dimension Schema Completeness Index I designed for this study. The full methodology is in my 2026 SSRN paper on schema adoption in personal injury law firm websites. The parameters that mattered most for the results are in the table below.
| Parameter | Value |
|---|---|
| Sample size | 500 personal injury law firm websites in the United States |
| Selection method | Google SERP results for 20 high-volume PI-related queries across major US metros |
| Deduplication | By root domain |
| Data collection | Custom Python pipeline crawling homepage plus up to 20 internal pages per site |
| Extraction | Every JSON-LD script block per page |
| Validation | Parsed against Schema.org specifications |
| Scoring | Schema Completeness Index (SCI), 5 dimensions, each 0 to 5, max 25 |
| Publication | Working paper on SSRN, DOI 10.2139/ssrn.6551638 |
I want to name what the study does not measure. It does not measure the causal relationship between schema implementation and organic ranking position. Nobody has a clean way to do that at scale. It does not measure downstream case acquisition or intake volume. And it does not track the firms over time to see whether schema investment paid back within a fiscal year. Those are follow-up studies. What this study does establish is the current-state benchmark for a 500-firm cross-section, and that benchmark is the reference point every PI firm can compare its own site against.
Schema Adoption Rates I Measured Across the 500 Personal Injury Law Firm Sample
Of the 500 sites in the sample, 338 (67.6 percent) deployed at least one form of JSON-LD structured data. The remaining 162 sites (32.4 percent) had no structured data blocks at all. The distribution by schema type is the first surprise: the most common type in the sample is not LegalService but Person or Attorney at 41.2 percent, followed by LegalService at 40.0 percent, then Organization at 34.4 percent, then Review or AggregateRating at 30.2 percent, then FAQPage at 25.6 percent, and so on down to HowTo at 0.2 percent. LocalBusiness, which many outside vendors reach for as their default business type, appears on only 9.0 percent of the sampled sites.
Two Thirds of PI Firms Deploy Some Schema Markup, One Third Deploy None
The headline adoption rate is 67.6 percent. The gap between “has some schema” and “has no schema” defines the two populations the rest of the article speaks to. If your firm sits in the 32.4 percent without any schema, your first action is not perfection. It is presence. A minimum viable LegalService block plus a Person block for each attorney puts you into the two-thirds majority before you touch anything else.
Why is a 32.4 percent no-schema rate a big deal for a personal injury firm? Because in a crowded local pack where three or four firms cluster within a mile of each other, Google’s tiebreakers include entity clarity. A firm the engine cannot reliably bind to a Knowledge Graph node forfeits the tiebreaker it never realized it was in.
Only 40 Percent of PI Firms Use LegalService, the Schema Type Built for Them
Only 200 of the 500 sampled sites (40.0 percent) deploy LegalService, the Schema.org type built for legal service providers. The rest either deploy no business-type schema at all, or reach for the more generic Organization type, or use LocalBusiness. LegalService is the semantically correct type for a law firm because it inherits from LocalBusiness and adds legal-service-specific properties like serviceType, areaServed, and hasOfferCatalog, which let you declare practice areas as first-class entities the engine can match against queries. Many of my PI clients came to me with only Organization schema, deployed by a WordPress theme or a generic SEO plugin, and had no idea LegalService existed as a distinct option. That default-plugin behavior is the single largest reason the LegalService adoption rate is 40 percent when it could reasonably be closer to 80.
Person and Attorney Schema Adoption on PI Firm Bio Pages
Person or Attorney schema appears on 41.2 percent of the sampled sites, making it the single most common schema type across the sample. But that headline masks a serious quality problem. Of the sites that use Person or Attorney schema, only 32.5 percent include the worksFor property linking the attorney to the firm. Without worksFor, the schema declares a floating human entity that Google has to guess belongs to the firm hosting the page. Of the 2,480 individual Person entities across the sample, only 805 are linked back to their firm by worksFor.
| Attorney schema property | Coverage across Person entities |
|---|---|
| name | 99.4% |
| image | 92.5% |
| url | 78.1% |
| @id | 45.7% |
| sameAs | 43.0% |
| worksFor | 32.5% |
| description | 27.8% |
| alumniOf | 19.8% |
| jobTitle | 17.5% |
| knowsAbout | 11.0% |
| award | 7.5% |
The Attorney type itself is separately deprecated by Schema.org (the type page carries the exact notice “This type is deprecated, LegalService is more inclusive and less ambiguous”). Of the 39 sites in the sample still using the Attorney type, only 13 include an @id, meaning the deprecation is being ignored by firms whose implementations were probably last touched several years ago.
What Ranked Firms Use vs What Unranked Firms Use in the PI Vertical
The sample was drawn from Google SERP results for PI queries, so every site in it has some ranking signal. But even within that “already ranking” population, schema quality varies dramatically. Firms scoring in the top quartile of the Schema Completeness Index almost universally deploy the LegalService plus Person pair with entity anchoring via @id and sameAs. Firms in the bottom quartile most often deploy a single Organization block from a plugin default, or nothing.
“The best PI marketing directors I work with all deploy the same two-entity foundation. One LegalService on the homepage and one narrowed LegalService per practice area, plus one Person on every attorney bio. Everything else is optional layering on top.”
Behzad Hussain, Personal Injury SEO Strategist
The Schema Types That Actually Move Case Acquisition for a Personal Injury Law Firm
There are approximately 15 Schema.org types that materially affect a personal injury law firm’s search visibility. The list narrows fast once you filter for what a PI firm actually publishes. LegalService and Person form the load-bearing pair. LegalService is the single business-type declaration a PI firm needs: it inherits from LocalBusiness, which inherits from Organization, so a well-populated LegalService block carries the organizational identity, the physical office presence, and the legal service specialization in one entity. Person handles each attorney bio. FAQPage, Review, AggregateRating, BreadcrumbList, Article, BlogPosting, VideoObject, ImageObject, ContactPoint, PostalAddress, and GeoCoordinates cover the supporting content. HowTo is technically valid but rarely fits a legal-services page. The next six sections walk through the types that matter, in the order I would prioritize them for a firm building the schema stack from scratch.
LegalService: The Only Business-Type Declaration a Personal Injury Law Firm Needs
LegalService is the Schema.org type that declares your business as a legal service provider, and it is the only business-type declaration a PI law firm needs at the root of its entity graph. It sits at the bottom of the inheritance chain: Organization is the parent, LocalBusiness is the intermediate subtype, and LegalService is the specific subtype built for legal service providers. Because inheritance is cumulative, a LegalService entity automatically carries every property Organization defines (name, legalName, url, logo, description, sameAs) and every property LocalBusiness defines (address, geo, telephone, priceRange, openingHoursSpecification, currenciesAccepted). On top of the inherited properties, LegalService adds the vertical-specific properties that make it the right type for a law firm: serviceType for each practice area, areaServed for geographic scope, and hasOfferCatalog for structured service listings.
That inheritance is why you do not deploy a separate Organization block. You do not deploy a separate LocalBusiness block. Deploying either of those alongside LegalService creates two or three competing entities that the search engine has to reconcile back into one firm, and the reconciliation is where signal gets lost. A single well-populated LegalService entity is the correct choice for every PI firm from solo to national. Deploy it on your homepage as the root business-type declaration, and on each practice-area page with the serviceType narrowed to that specific practice area. A comprehensive LegalService block for a PI firm’s homepage looks like this:
{
"@context": "https://schema.org",
"@type": "LegalService",
"@id": "https://firm.example.com/#organization",
"name": "Firm Name",
"legalName": "Firm Name PLLC",
"url": "https://firm.example.com/",
"logo": "https://firm.example.com/logo.png",
"image": "https://firm.example.com/hero.jpg",
"description": "Personal injury representation across Texas since 2005.",
"telephone": "+1-555-555-5555",
"priceRange": "Free consultation",
"address": {
"@type": "PostalAddress",
"streetAddress": "123 Main Street",
"addressLocality": "Houston",
"addressRegion": "TX",
"postalCode": "77002",
"addressCountry": "US"
},
"geo": {
"@type": "GeoCoordinates",
"latitude": 29.7604,
"longitude": -95.3698
},
"openingHoursSpecification": [
{
"@type": "OpeningHoursSpecification",
"dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday"],
"opens": "08:00",
"closes": "18:00"
}
],
"areaServed": {
"@type": "State",
"name": "Texas"
},
"serviceType": [
"Personal Injury Law",
"Motor Vehicle Accident Law",
"Wrongful Death Litigation",
"Workers Compensation Law"
],
"sameAs": [
"https://www.linkedin.com/company/firm-name",
"https://www.wikidata.org/wiki/Q000000",
"https://www.justia.com/lawyers/law-firm/firm-name",
"https://www.avvo.com/law-firms/firm-name"
]
}The serviceType array is where a PI firm most often leaves signal on the table. Firms that name only “Personal Injury Law” as the serviceType are asking Google to guess whether they also handle truck accidents, premises liability, or product liability. Firms that name each practice area explicitly get matched to more query surfaces. In the 500-firm sample, the 200 firms that deployed LegalService averaged only 47.9 percent property completeness. Most of those firms populated name and url but left address, geo, openingHoursSpecification, and areaServed empty, which flattens LegalService back down to what a lazy Organization block would have carried anyway.
Person Schema for Every Personal Injury Attorney Bio Page
Person schema on every attorney bio page is one of the highest-impact moves a PI firm can make. It anchors the individual attorney as an entity, links them to the firm through worksFor, and lets you declare bar admissions, education, specializations, and awards in a form Google can match against attorney-specific queries. Google’s 2009 patent on author-level ranking, US Patent 7,565,358 by Minogue and Tucker, titled Agent Rank, documents why binding an attorney to the pages they wrote and the firm they work for is a first-order move: the engine receives multiple content items along with signatures that associate content with a specific agent, then assigns a reputation score to that agent based on the items the signatures bind to them, which is the ranking surface Person schema, worksFor, and author assertions expose in machine-readable form. A well-populated Person entity looks like this:
The patent record below documents the ranking surface Person schema and worksFor expose: the engine receives digital signatures binding content to specific agents, then assigns a reputation score to each agent based on the content they authored.
{
"@context": "https://schema.org",
"@type": "Person",
"@id": "https://firm.example.com/attorneys/jane-doe/#person",
"name": "Jane Doe",
"image": "https://firm.example.com/attorneys/jane-doe/photo.jpg",
"jobTitle": "Managing Partner",
"worksFor": {
"@id": "https://firm.example.com/#organization"
},
"alumniOf": {
"@type": "EducationalOrganization",
"name": "University of Texas School of Law"
},
"knowsAbout": [
"Motor Vehicle Accident Litigation",
"Traumatic Brain Injury Cases",
"Wrongful Death Representation"
],
"award": [
"Super Lawyers 2024",
"Best Lawyers in America 2023"
],
"sameAs": [
"https://www.linkedin.com/in/jane-doe",
"https://www.texasbar.com/member/12345",
"https://www.avvo.com/attorneys/jane-doe"
]
}When should you use jobTitle versus hasOccupation on an attorney Person entity? Use jobTitle for the plain-language title the attorney uses on their bio (“Managing Partner”, “Senior Trial Attorney”), and reserve hasOccupation for structured occupation data if you want to declare formal SOC codes or occupation categories. For 95 percent of PI attorney bios, jobTitle alone is sufficient.
The property that most firms skip is knowsAbout. Only 11 percent of Person entities in the sample include it, but knowsAbout is where you signal an attorney’s actual specialization to Google. An attorney with knowsAbout listing “Traumatic Brain Injury Cases” gives the engine a match surface for the query “TBI lawyer Houston” that plain job title alone does not provide.
FAQPage Schema on Dedicated FAQ Pages Only, Not Sprinkled Across a PI Firm Site
FAQPage schema declares a page as a question-and-answer collection. The Schema.org documentation for FAQPage is straightforward, but the Google side changed in September 2023: the FAQ rich result visual feature is now restricted to well-known, authoritative government and health websites only, per Google Search Central’s own FAQ structured data documentation. Regular firms no longer see the accordion rich result in the SERP. FAQPage schema still helps with AI Overview extraction and remains valid semantically, but it should be used only on dedicated FAQ pages, not sprinkled across every practice-area page that happens to have a small FAQ block at the bottom. Most PI firms I audit get this wrong because their SEO vendor was still deploying FAQPage schema on every practice-area page as of 2024. The correction is to remove the schema from mixed-content pages and consolidate FAQs onto a dedicated /faq page or a per-practice-area FAQ page where questions are the main entity.
Review and AggregateRating Schema Within State Bar Compliance Limits
Review and AggregateRating schema declares client reviews and aggregate star ratings for the firm or for individual attorneys. Google restricted the visual review rich result in April 2019 to a defined list of self-serving review markup targets, and law firms are on the list of types that can no longer generate a visual star rating in the SERP from self-hosted reviews. However, AggregateRating markup remains valid semantically, and it still populates knowledge panels when the engine can bind the reviews to a verified entity. The bigger constraint for a PI firm is not Google’s rich result restriction but state bar advertising rules. ABA Model Rule 7.1 prohibits false or misleading claims about a lawyer’s services, and many state variations impose specific disclaimer requirements when testimonials or ratings appear in marketing. The state-by-state disclaimer rules that govern testimonial and rating markup are covered in the compliance article linked in the Bar Rule Compliance section below.
BreadcrumbList, Article, and VideoObject as Supporting Schema Types for PI Firm Sites
Three supporting schema types complete a typical PI firm stack. BreadcrumbList declares the hierarchical navigation path from home to the current page. It appears on 7.6 percent of sampled sites, and among sites that deploy it, property completeness is 100 percent (meaning firms either do it or do not). Deploy BreadcrumbList on every non-homepage page. Article, BlogPosting, or NewsArticle applies to editorial content (case studies, legal news, firm updates) and links back to the attorney author via a Person @id and to the firm via a publisher LegalService @id. VideoObject applies to any embedded video (attorney explainer, case type overview, testimonial video), with a contentUrl, thumbnailUrl, uploadDate, and duration. All three are supporting, not primary. Get LegalService and Person right first; then layer these on.
Why the Attorney Schema Type Is Deprecated and How PI Firms Should Migrate to Person
Schema.org deprecated the Attorney type. The current Attorney type page on schema.org carries the exact notice “This type is deprecated, LegalService is more inclusive and less ambiguous.” That single sentence tells you two things. First, the schema.org consortium considers Attorney redundant with LegalService for describing legal services. Second, they consider it ambiguous for describing individual attorneys, and Person is the correct type for that. In practice, a firm that has been using Attorney schema for attorney bios should migrate to Person, and a firm that has been using Attorney schema as a business-type declaration should migrate to LegalService. Of the 39 sampled sites still using the Attorney type in 2026, only 13 include an @id, which suggests these implementations were last touched several years ago and have not been maintained since. I see this pattern repeatedly in PI practices whose original SEO vendor deployed schema once, never came back, and left the firm with a deprecated type on every attorney bio.
The Schema Completeness Index I Use to Score Personal Injury Law Firm Structured Data
The Schema Completeness Index (SCI) is the scoring framework I built for the 500-site study to move past binary “has schema” or “does not have schema” measurement. Binary tests miss the entire question of implementation quality. A firm that deploys a single Organization block from a plugin default passes a binary test just as a firm with a fully anchored LegalService plus Person stack passes it. SCI grades the depth. It scores each site across five dimensions, each on a 0 to 5 scale, for a maximum score of 25.
The Five Dimensions of the SCI: Type Coverage, Properties, Entity Disambiguation, Nesting, Validation
The five dimensions each measure a distinct aspect of schema quality. Type Coverage measures how many of the load-bearing schema types the site deploys, weighted by the site’s actual content mix. A firm publishing five practice areas gets more Type Coverage credit for having LegalService on each than a firm publishing one. Property Completeness measures how many optional-but-descriptive properties are populated within each deployed type. Entity Disambiguation measures @id coverage and sameAs population across the site’s schema graph. Hierarchical Nesting measures whether related entities are properly nested (PostalAddress inside address, employees inside Organization, ContactPoint inside Organization) versus flattened into disconnected blocks. Validation Status measures whether the deployed schema passes Google’s Rich Results Test and the Schema.org Markup Validator without errors.
The dimension scores across the sample tell a specific story. Entity Disambiguation scores highest on average (4.1 out of 5), Property Completeness comes second (2.4), Type Coverage third (2.3), Hierarchical Nesting fourth (2.1), and Validation Status dead last (0.9). The gap between the highest and lowest dimension is more than 4 points, meaning a typical PI firm with schema does the entity anchoring reasonably well when they anchor at all, but fails validation on nearly every implementation. The 0.9 validation score aligns with the 77.8 percent of sampled sites with at least one validation error.
Where the Median PI Firm Sits on the SCI: 12 out of 25
The mean SCI across the 338 sites with schema is 11.8 out of 25, with a standard deviation of 2.6 and a median of 12.0. Scores range from 3 to 20. No site in the sample hit the ceiling of 25. Breaking down by firm size does not shift the picture meaningfully: solo and small firms (1 to 3 attorneys) score a mean of 10.6, mid-size firms (4 to 20 attorneys) score 10.8, and large firms (21+ attorneys) score 11.3. The largest firms score a full point higher than the smallest, but the gap is smaller than most industry commentary would suggest. Large firms do not automatically have better schema. Many enterprise PI firms I audit have big SEO budgets but weak schema because the budget goes to content and links, and schema is treated as an afterthought.
The Weakest Dimension in the Personal Injury Vertical: Validation at 0.9 out of 5
Validation is the weakest dimension across the entire sample. 77.8 percent of sites with schema contain at least one validation error, and the mean Validation score is 0.9 out of 5. The most common errors are missing required properties (name, address, or url absent from a block that requires them), unstructured address fields where the schema uses a string instead of a PostalAddress subtype, and missing image or logo properties that Google warns about even though it does not always reject the block. One of my clients, a mid-size PI firm in Ohio, had schema on every page but a syntax error in the JSON-LD template that broke the entire block. Google silently discarded the schema for eighteen months before we caught it during a diagnostic. The firm had been paying an outside SEO agency the whole time. Validation errors are silent failures. The schema deploys, the page loads, nothing visually breaks, and the search engine ignores the block.
The Structured Data Maturity Model I Built for Personal Injury Law Firms
I built the Structured Data Maturity Model to give PI firms a diagnostic tool that translates SCI scores into a next best action. A number is not a plan. A ladder rung with a description and a next step is. The model has five levels. Every site in the 500-sample study falls onto one rung or below. Level 0 (no implementation) captures the 162 sites in the sample with no schema at all. The remaining 338 sites distribute across Levels 1 through 5. In the study population, 30.0 percent sit at Level 1, 30.4 percent at Level 2, 38.2 percent at Level 3, 1.4 percent at Level 4, and zero at Level 5.
Structured Data Maturity Model for Personal Injury Law Firms
Five rungs from Level 1 basic identity at the bottom to Level 5 full semantic integration at the top.
Next action: build the schema operation as a first-class product with quarterly audits, versioning, and a maintenance owner.
Next action: layer Speakable declarations, FAQPage on dedicated FAQ pages, VideoObject on every video, and multi-office LocalBusiness.
Next action: expand the entity graph with knowsAbout, alumniOf, award on attorney Person entities plus BreadcrumbList and Article schema.
Next action: add Person schema on every attorney bio, link each Person to the firm via worksFor, and add @id URIs to every top-level entity.
Next action: add LegalService as the primary business-type declaration and populate address, telephone, and priceRange properties fully.
The lowest rung is where most firms sit. The top rung is where none do.
The bar chart below shows the same maturity distribution in absolute site counts, so the concentration at Level 3 (191 sites) and the near-empty upper rungs at Levels 4 and 5 are visually easier to compare against the Level 1 and Level 2 populations.
“The maturity model exists because scoring a site is only useful if it points to the next move. Every rung has a specific next action. The action is what moves the score.”
Behzad Hussain, Personal Injury SEO Strategist
Level 1: Basic Identity, Where 30 Percent of PI Firms Sit
Level 1 is basic identity. The site deploys Organization schema (possibly through a plugin default) with core properties like name, url, and logo. No LegalService. No Person entities for attorneys. No @id or sameAs on the Organization. This is the plugin-default state. It gets the firm out of Level 0 but signals nothing specific about legal services. Your next action from Level 1 is to add LegalService as the primary business-type declaration and to populate address, telephone, and priceRange properties fully.
Level 2: Service Declaration, Where 30.4 Percent of PI Firms Sit
Level 2 adds LegalService as the primary business-type declaration. Practice areas may be declared via serviceType. Address, telephone, and image are populated. But entity anchoring (@id) is missing or partial, sameAs references are thin or absent, and there are no Person entities for individual attorneys. Your next action from Level 2 is to add Person schema on every attorney bio page, link each Person to the firm via worksFor, and add @id URIs to every top-level entity.
Level 3: Entity Network, Where 38.2 Percent of PI Firms Sit
Level 3 is the largest cluster in the sample. The site deploys LegalService as the root business-type entity and Person for every attorney, with @id URIs on every top-level entity and worksFor links from each Person to the LegalService. sameAs references anchor the firm to at least 3 external identity sources (LinkedIn, Justia, state bar). Practice areas are declared with structured serviceType arrays. Validation is largely clean. Level 3 is the current best-in-class for a competitive PI firm, and 38.2 percent of the sampled sites already reach it. Your next action from Level 3 is to expand the entity graph with knowsAbout on attorney Person entities, alumniOf for education, award for recognition, and to add BreadcrumbList and Article schema across the content library.
Level 4: Semantic Authority, Where Only 1.4 Percent of PI Firms Reach
Level 4 is semantic authority. Only 7 of the 500 sampled sites reach this rung. Level 4 sites deploy a fully populated LegalService root plus Person for every attorney with complete property coverage (jobTitle, knowsAbout, alumniOf, award, sameAs to LinkedIn, state bar, and law school), plus BreadcrumbList across every non-homepage page, plus Article schema on editorial content with author and publisher @id references, plus per-office LegalService architecture where the firm operates multiple locations. Site-wide deployment consistency across templates. Validation errors close to zero. Many enterprise PI firms with big budgets sit at Level 3 not Level 4 because the schema work stopped after the initial deploy. Level 4 requires an ongoing owner of the schema layer, not a one-time build. That is the pattern I see repeatedly.
Level 5: Full Semantic Integration, Which No PI Firm in the Study Reached
Level 5 is the ceiling. No site in the sample reached it. Level 5 requires everything at Level 4 plus a proactive semantic layer: FAQPage on dedicated FAQ pages with a full mainEntity array, VideoObject on every embedded video, custom Speakable declarations, structured LawyerVerdict or LegalCase data (if published within bar rules), and a schema management operation that treats structured data as a first-class product with a versioning discipline, quarterly audits, and a maintenance owner. That the sample of 500 firms yielded zero Level 5 sites is the honest ceiling of the current-state benchmark.
“I have never seen a PI firm at Level 5. The economics of getting there require ongoing investment most firms have not committed. But Level 4 is achievable within a year of focused work, and Level 3 is achievable within a quarter.”
Behzad Hussain, Personal Injury SEO Strategist
Entity Disambiguation: The Schema Dimension Where PI Law Firms Lose the Most Ground
Entity disambiguation is the process of making sure a search engine or LLM can unambiguously identify your specific firm and specific attorneys, distinct from every other similarly named entity on the web. In the SCI dimension breakdown, Entity Disambiguation scores the highest at 4.1 out of 5, which sounds like the vertical is doing well. That framing is misleading. The 4.1 is the mean, and it captures the fact that 84.0 percent of sites with schema include @id somewhere and 81.4 percent include sameAs somewhere. But “somewhere” is the trap. The specific gaps show up when you look at coverage by schema type. LegalService, the load-bearing type for the vertical, carries @id on only 51.5 percent of sites that deploy it. Attorney schema (deprecated but still present on 39 sites) carries @id on only 33.3 percent. LocalBusiness carries @id on only 31.4 percent. Every top-level entity that lacks @id is invisible for cross-referencing within the site and unbindable to a Knowledge Graph node from outside.
What @id Does for a Personal Injury Law Firm’s Schema Graph
@id is a stable URI identifier attached to a schema entity that lets multiple JSON-LD blocks refer to the same underlying entity. Without @id, each JSON-LD block declares a fresh anonymous entity. The search engine has to infer whether the LegalService declared on the homepage is the same as the LegalService declared on the attorney bio page. With @id, you make the identity explicit. Every mention of the firm across every page points at the same URI. Here is what @id linking looks like in practice: on the homepage, the LegalService block declares @id equal to https://firm.example.com/#organization. On an attorney bio page, the Person block declares worksFor pointing at @id equal to https://firm.example.com/#organization. Google now knows the two blocks describe entities that belong together.
{
"@context": "https://schema.org",
"@graph": [
{
"@type": "LegalService",
"@id": "https://firm.example.com/#organization",
"name": "Firm Name",
"url": "https://firm.example.com/"
},
{
"@type": "Person",
"@id": "https://firm.example.com/attorneys/jane-doe/#person",
"name": "Jane Doe",
"worksFor": {
"@id": "https://firm.example.com/#organization"
}
}
]
}The URI itself is arbitrary. What matters is that it is stable and consistent across every block on every page. Some firms use https://firm.example.com/#organization for the root LegalService. Others use https://firm.example.com/#firm or https://firm.example.com/entity/firm. Any of those work. What breaks is inconsistency: a LegalService declared with one @id on the homepage and a different @id on the contact page becomes two separate entities the engine has to reconcile.
The sameAs Targets Every PI Law Firm Should Anchor To
sameAs is a property on a LegalService, Person, or other entity that points to external URLs describing the same entity. sameAs anchors your entity to the wider web of identity references. Google’s 2019 patent on knowledge graph reconciliation, US Patent 10,331,706 by Yakhnenko and Vesdapunt, titled Automatic Discovery of New Entities Using Graph Reconciliation, documents the mechanism sameAs plugs into: the engine clusters source data graphs from multiple documents by entity name and type, then reconciles each cluster against a target data graph so a real-world entity ends up with one canonical node rather than a scatter of duplicates. For a personal injury law firm, the sameAs array on the root LegalService entity should point to a defined checklist of external targets. Below is the target list I recommend to every PI firm. Not every firm will have every target populated (a boutique firm may not have a Crunchbase listing), but every populated target strengthens the entity graph.
The patent record below confirms Google’s authorship and documents the graph reconciliation mechanism that sameAs feeds: clustering source data graphs across documents so a real-world entity ends up with one canonical node.
The sameAs Anchor Checklist for a PI Law Firm’s Organization Entity
Ten external identity targets. Every populated target strengthens the firm’s entity graph.
For individual attorney Person entities, the sameAs array should point to the attorney’s LinkedIn profile, state bar member profile URL, Avvo attorney profile, Justia attorney profile, Super Lawyers profile if listed, and (if published) an author page on any legal publication where the attorney has written. The specific mix depends on the attorney’s actual footprint.
The @id Coverage Gap on LegalService and Attorney Schema in the PI Vertical
The @id coverage gap by schema type is the single most actionable statistic in my study. WebSite and WebPage carry @id on 93.5 percent and 95.7 percent of sites that deploy them respectively (the plugin defaults tend to handle these correctly). BreadcrumbList carries @id on 94.0 percent. Organization drops to 86.8 percent. Person drops to 83.8 percent. But LegalService, the type that most needs @id because it is the primary business-type declaration, sits at only 51.5 percent. Attorney (deprecated) sits at 33.3 percent. LocalBusiness sits at 31.4 percent.
| Schema type | @id coverage across sites deploying the type |
|---|---|
| WebPage | 95.7% |
| BreadcrumbList | 94.0% |
| WebSite | 93.5% |
| Organization | 86.8% |
| Person | 83.8% |
| LegalService | 51.5% |
| Attorney (deprecated) | 33.3% |
| LocalBusiness | 31.4% |
If your firm’s site deploys LegalService, LocalBusiness, or Person schema and any of them lack @id, that is the fix that most cheaply moves your SCI score up. It is a template edit, not a content project.
Multi Office and Multi State Personal Injury Law Firm Schema Architecture
Multi office and multi state firms have a schema problem that single-office firms do not. Each office is a distinct physical presence with its own address, geo coordinates, opening hours, and phone number. But the parent firm is a single legal entity. Naively duplicating the root business-type block on each office page produces three or more competing root entities that the search engine has to reconcile. The correct structure is one parent LegalService representing the firm brand, with each office as a per-office LegalService child linked to the parent via parentOrganization and via @id. The @graph wrapper lets you express the hierarchy in a single JSON-LD block per page.
Schema Stack for a 3 Office PI Firm Serving One State
A three-office firm serving one state should declare one LegalService at the firm-brand level as the root, and one LegalService per office as children. Each per-office LegalService carries the office-specific address, geo, opening hours, and phone number, and inherits the vertical-specific properties from the LegalService type just as the root does. Deploy the parent LegalService block on the homepage and on every practice-area page. Deploy the parent plus the specific per-office LegalService on each office page. Here is the shape of the root plus one office block:
{
"@context": "https://schema.org",
"@graph": [
{
"@type": "LegalService",
"@id": "https://firm.example.com/#organization",
"name": "Firm Name",
"url": "https://firm.example.com/",
"logo": "https://firm.example.com/logo.png",
"areaServed": {
"@type": "State",
"name": "Texas"
},
"serviceType": [
"Personal Injury Law",
"Motor Vehicle Accident Law"
],
"sameAs": [
"https://www.linkedin.com/company/firm-name",
"https://www.wikidata.org/wiki/Q000000"
]
},
{
"@type": "LegalService",
"@id": "https://firm.example.com/offices/houston/#office",
"name": "Firm Name Houston Office",
"parentOrganization": {
"@id": "https://firm.example.com/#organization"
},
"address": {
"@type": "PostalAddress",
"streetAddress": "123 Main Street",
"addressLocality": "Houston",
"addressRegion": "TX",
"postalCode": "77002",
"addressCountry": "US"
},
"geo": {
"@type": "GeoCoordinates",
"latitude": 29.7604,
"longitude": -95.3698
},
"openingHoursSpecification": [
{
"@type": "OpeningHoursSpecification",
"dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday"],
"opens": "08:00",
"closes": "18:00"
}
],
"telephone": "+1-555-555-5555"
}
]
}Every attorney’s Person block on their bio page links via worksFor to the parent LegalService @id, not to any office. The office affiliation, if you want to signal it, goes on a separate property or in the description.
Schema Stack for a National Mass Tort Personal Injury Firm
A national mass tort firm operating across multiple states has two options. Option one: declare one LegalService at the national level and use areaServed with an array of State entities to signal geographic scope. Option two: declare one root LegalService with a subOrganization array of state-level LegalService entities. Option one is simpler and works well for a firm without dedicated state-level offices. Option two is right for a firm with dedicated presence in each state.
{
"@context": "https://schema.org",
"@type": "LegalService",
"@id": "https://firm.example.com/#organization",
"name": "National Mass Tort Firm",
"areaServed": [
{"@type": "State", "name": "California"},
{"@type": "State", "name": "Texas"},
{"@type": "State", "name": "Florida"},
{"@type": "State", "name": "New York"},
{"@type": "State", "name": "Illinois"}
],
"serviceType": [
"Mass Tort Litigation",
"Defective Drug Cases",
"Defective Medical Device Cases"
]
}I had a mass tort firm come to me last year with 27 state landing pages that each declared a full root LegalService block with the firm’s HQ address duplicated verbatim. The engine was reconciling 27 competing top-level entities and defaulting to the strongest one, which happened to be a page that ranked well but was not the firm’s intended homepage. Cleaning up the architecture with one root LegalService and per-state LegalService references linked via subOrganization and @id collapsed the confusion. The firm’s Knowledge Graph node consolidated within about six weeks.
Does Schema Markup Help Personal Injury Law Firms Get Cited in AI Overviews and ChatGPT?
The honest answer is that schema markup does not force AI citations. The recent Ahrefs study titled “We Tracked 1,885 Pages Adding Schema. AI Citations Barely Moved,” published on the Ahrefs blog on May 11, 2026 by Louise Linehan and Xibeijia Guan, tracked 1,885 web pages that added JSON-LD schema between August 2025 and March 2026 against 4,000 control pages, and measured citation changes across Google AI Overviews, Google AI Mode, and ChatGPT. The study found no meaningful lift in AI citations attributable to schema addition. That result is the honest headline that most competing legal marketing guides skip.
Does adding schema markup guarantee my personal injury firm gets cited in ChatGPT? No. What schema markup does is different, and it is worth naming precisely. Schema anchors your firm’s identity in a machine-readable form that AI answer engines can consume when they generate citations. Google’s 2024 patent on the AI Overviews synthesis pipeline, US Patent 11,900,068 by Gray, Blitzer, Herrick, Venkatachary, Madhavan, Oates, Parakh, Shah, Rofouei, and Badr, titled Generative Summaries for Search Results, documents the mechanic that makes schema load-bearing: the large language model does not answer from the query alone, it draws on additional content retrieved beyond the query to reduce inaccuracy and specification errors in the summary, which is the exact surface on which machine-readable entity data earns its way into the citation set. If an AI names your firm, schema makes it more likely to name your firm correctly, attribute the right practice area, cite the right office location, and link to the right URL. It does not force the citation to happen in the first place. The citation depends on the AI’s ranking of your content as an answer source, and that is a function of content quality, entity authority, and other ranking signals, not schema alone.
The patent record below confirms Google’s authorship of the AI Overviews synthesis pipeline and documents the specific mechanic that makes schema load-bearing: the LLM does not answer from the query alone but processes additional retrieved content beyond the query.
“Schema is the correctness layer, not the visibility layer. Content and links move visibility. Schema makes sure the visibility you earn attaches to the right firm entity.”
Behzad Hussain, Personal Injury SEO Strategist
How to Implement Schema Markup on a Personal Injury Law Firm Website
Schema implementation on a PI firm site comes down to three delivery paths: a WordPress plugin, direct code in the theme, or Google Tag Manager. Each has trade-offs by firm size and technical resource. The section below covers where the JSON-LD script belongs, which delivery path fits which firm, and the practical stack recipes for four firm sizes.
JSON-LD Placement Conventions for Law Firm Site Templates
JSON-LD script blocks belong inside a <script type="application/ld+json"> tag placed in the HTML head. Google reads schema from the head or the body, but the head placement is the convention and it avoids ordering issues where content-injected schema might not be parsed before the page renders. For a WordPress site, the theme’s header.php file or the SEO plugin’s schema output hook is where the schema lands. For a custom-built site, the schema goes into the template that renders each page type. Practice-area templates output a narrowed LegalService block. Attorney bio templates output a Person block. Office pages output the parent LegalService plus the per-office LegalService child. Blog post templates output an Article block.
WordPress Plugins vs Custom Code vs Google Tag Manager for PI Firm Schema Deployment
Three delivery paths cover 95 percent of PI firm implementations. WordPress plugins like Rank Math, Yoast Premium, and Schema Pro handle the common types (Organization, LocalBusiness, Article, BreadcrumbList) automatically with a UI. Custom code in the theme templates gives full control over the graph structure and every property. Google Tag Manager can inject JSON-LD via a Custom HTML tag, which is useful when you cannot access the theme code directly.
| Delivery method | Ease of setup | Maintenance burden | Version control | Attorney bio flexibility | Multi office support | Ideal firm size |
|---|---|---|---|---|---|---|
| WordPress plugin (Rank Math, Yoast, Schema Pro) | High | Low | Weak (settings in database) | Moderate | Moderate | Solo, 5 to 20 attorneys |
| Custom code in theme | Low | Medium | Strong (in Git) | Full | Full | 20 to 100 attorneys, technical team available |
| Google Tag Manager | Medium | Medium | Moderate (versioned in GTM) | Moderate | Moderate | Any size where theme access is restricted |
My default recommendation for firms up to 20 attorneys is Rank Math or a similar plugin with the schema module enabled, then custom-coded overrides on the templates where plugin output is insufficient (typically the attorney bio template, which most plugins handle poorly). For firms above 20 attorneys with a dedicated technical resource, custom code is worth the initial investment because it gives you a graph structure that matches your actual entity architecture. GTM is a fallback when the CMS is off-limits.
Practical Schema Stacks by PI Firm Size: Solo, 5 to 20 Attorney, 20 to 100 Attorney, Multi State
The right schema stack scales with the firm’s actual content mix and office footprint. The table below shows my recommended defaults by firm size.
| Firm size | Recommended types | Delivery method | Audit cadence |
|---|---|---|---|
| Solo (1 to 3 attorneys) | Root LegalService, Person for each attorney, BreadcrumbList | Plugin (Rank Math or Yoast Premium) | Semi-annual |
| Small (5 to 20 attorneys) | Root LegalService with per-office LegalService children (if multi-office), Person for each attorney, BreadcrumbList, Article | Plugin plus template overrides | Quarterly |
| Mid (20 to 100 attorneys) | Root LegalService, narrowed LegalService per practice area, per-office LegalService children, Person for each attorney with full properties, BreadcrumbList, Article, VideoObject | Custom code in theme | Quarterly |
| Multi state (national mass tort or multi state firm) | Root LegalService with subOrganization array of state-level LegalService entities, per-office LegalService children, Person for each attorney, BreadcrumbList, Article, VideoObject, FAQPage on dedicated FAQ pages | Custom code with template partials | Monthly for first year, quarterly thereafter |
Validation and Ongoing Maintenance for Personal Injury Firm Schema Markup
Validation and maintenance are the parts of schema work that most firms skip. Deployment happens once. Validation happens the day of deploy and never again. Six months later, a content editor updates the homepage template, a plugin auto-updates and changes its output, or an SEO plugin gets replaced during a redesign, and the schema breaks silently. The three tools plus the audit cadence below prevent that pattern.
The Three Tools That Verify Personal Injury Law Firm Schema
Three tools cover 95 percent of validation and monitoring needs.
- Google Rich Results Test at search.google.com/test/rich-results validates whether Google sees your schema and shows the specific rich result eligibility (or the specific reasons for ineligibility). Test the homepage, one attorney bio page, one practice area page, one blog post, and one office page as a minimum spot check.
- Schema Markup Validator at validator.schema.org validates the schema against the vocabulary itself, catching type mismatches, unknown properties, and syntax errors that the Rich Results Test may not surface if it decides the block is not eligible for a rich result anyway.
- Google Search Console’s Enhancement reports (accessible in the left navigation under Enhancements) surface site-wide validation errors that Google has already discovered during crawling, plus impression and click data for each rich result type. Check the Enhancements section monthly.
The Quarterly Schema Audit Cadence I Recommend for Personal Injury Law Firms
Quarterly audits catch schema drift before it costs the firm visibility. The audit is a one-hour task once the checklist is set: pull a sample of five page templates (homepage, attorney bio, practice area, office page, blog post), run each through the Rich Results Test and the Schema Markup Validator, review the current-quarter Enhancement report in Search Console, cross-check the current schema output against the version-controlled reference implementation, and log any deltas. One of my clients, a mid-size PI firm in Illinois, had schema quietly break for three months after a routine plugin update in Q2 changed a serialization pattern. The Q3 audit caught it. Without the cadence, they would have found out only after the next redesign or a random Google penalty conversation.
How long from schema deployment to rich results appearing in Search Console? Typically two to six weeks for Google to crawl the affected pages and populate the Enhancement report with impressions, though initial validation warnings appear within days. If nothing shows up after 30 days, that is signal to re-run validation.
The Twelve Most Common Schema Errors I See in the Personal Injury Vertical
Below are the twelve errors I see most often across the 500-site study and my own client audits, ranked by prevalence in the sample. Every error has a specific fix.
| Rank | Error | Prevalence in sample | Fix |
|---|---|---|---|
| 1 | Missing required property (name, address, or url absent from a block that requires them) | Highest single-error prevalence, appears in a large majority of validation failures | Populate the required property from the source of truth (the firm’s canonical NAP data) |
| 2 | Unstructured address (address property is a string, not a PostalAddress subtype) | Very common on legacy plugin implementations | Convert the string to a nested PostalAddress with streetAddress, addressLocality, addressRegion, postalCode, addressCountry |
| 3 | Missing image or logo on Organization | Frequent | Add an image property pointing to a canonical logo URL |
| 4 | LegalService or LocalBusiness missing @id | 48.5 percent and 68.6 percent of deploying sites respectively | Add a stable @id URI to every top-level entity |
| 5 | Person entity missing worksFor | 67.5 percent of Person entities | Add worksFor pointing to the firm’s root LegalService @id |
| 6 | FAQPage deployed on pages where the FAQ is a secondary component | Common on practice-area pages with a small FAQ block at the bottom | Restrict FAQPage to dedicated FAQ pages or per-practice-area FAQ pages where questions are the main entity |
| 7 | Attorney type used instead of Person on attorney bios | 39 sites still use the deprecated type | Migrate Attorney to Person; use LegalService for the firm’s business-type declaration |
| 8 | Multiple disconnected top-level blocks instead of @graph | 0.7 percent of schema-carrying sites | Wrap related entities in @graph so the search engine sees them as a connected graph |
| 9 | AggregateRating populated from self-hosted reviews without a valid publisher context | Frequent | Only mark up aggregate ratings from a review platform Google recognizes; do not self-aggregate |
| 10 | Missing sameAs on Organization | 18.6 percent of Organization entities | Populate sameAs with the checklist targets (LinkedIn, Wikidata, Justia, state bar) |
| 11 | Duplicate Organization declarations across pages with inconsistent @id | Common on multi-page CMS templates | Establish one canonical @id per entity and reference it consistently |
| 12 | serviceType absent on LegalService | Frequent | Populate serviceType with the specific practice areas the firm handles |
The companion audit ran the same instrument against the competitive layer: schema markup adoption across 1,005 Google Page-1 personal injury firms. The implementation guide built on both findings is schema markup for personal injury law firms, and the reasoning behind why structured data supports rather than replaces authority is in how schema markup builds topical authority.
Work With Me on Personal Injury Law Firm Schema Implementation
The 500-firm study made one thing clear. Most PI firms sit at Levels 1 or 2 of the Maturity Model (60.4 percent of the sample), and the fastest path from there to Level 3 is a focused schema and entity-architecture project. That is the specific problem my Personal Injury SEO Diagnostic is scoped for. The diagnostic scores your current SCI, audits your entity graph, catches every one of the twelve most common errors above, and gives you a 90-day plan with priorities ranked by expected search visibility impact. Delivery is 7 to 10 days from kickoff. The output is a written report plus a 60 to 90 minute strategy call.
For firms that want the schema work folded into a full case-acquisition program (schema plus content plus links plus conversion architecture), my PI Authority Growth System is the monthly retainer that bundles all four pillars of the PI Authority Engine into one owned engagement. Growth System engagements start at 3-month commitments and are the right shape for firms that want the schema work maintained across quarterly audits, not just a one-time build.
Ship Level 3 Schema
Move your firm from Level 1 or 2 up to Level 3 in a fiscal quarter
Firms leaving Level 1 or Level 2 that reach Level 3 within 90 days see the fastest downstream rich result eligibility gains. Book a diagnostic to start with a scored SCI, or commit to the monthly retainer to maintain Level 3 across quarterly audits.
500 firms studied. Median SCI: 12 out of 25. Reaching Level 3 within 90 days is a clear scope with a measurable artifact. Diagnostic is 60 to 90 minutes; no obligation to retain.
Frequently Asked Questions on Personal Injury Law Firm Schema Markup
Does adding schema markup violate any state bar advertising rules?
Schema markup itself does not violate bar rules. What can violate bar rules is the content of the schema. If your Review or AggregateRating schema publishes testimonial content or outcome claims that would violate ABA Model Rule 7.1 or your state’s variation when printed on a page, the same content in JSON-LD carries the same risk. The audit is content, not format.
How do I merge two Google Knowledge Graph entities that describe the same firm?
Two Knowledge Graph entities for the same firm typically arise from inconsistent entity references across the web (one set of sameAs URLs points at one identity, another set points at another). The fix is to consolidate all external references (Google Business Profile, LinkedIn, Wikidata, Justia, Avvo) onto a single canonical identity, then wait for Google to reconcile. There is no direct merge tool. Wikidata is often the fastest lever because Google trusts Wikidata as a Knowledge Graph seed source; ensure your firm’s Wikidata entry (if it exists) has the correct set of sameAs and no duplicates.
What is the fastest single change that moves a PI firm from Level 2 to Level 3 of the maturity model?
Deploying Person schema on every attorney bio page with worksFor linking to the firm’s root LegalService @id. That single change moves the site from “declares the firm as a legal service provider” to “declares the firm as a legal service provider with a network of anchored human entities.” It is a template-level change, not a content project, and it is the highest-impact move for firms currently at Level 2.
Can a solo PI attorney’s team implement schema without a developer?
Yes for a Level 2 or Level 3 implementation using a plugin like Rank Math or Yoast Premium with the schema module enabled. Most plugins default to Organization or LocalBusiness output; you will need to switch the type to LegalService (Rank Math and Schema Pro both support this in their business-type dropdown; Yoast requires a schema graph filter). Person schema on attorney bios usually requires a template override or a per-bio schema entry, which most plugins support through a UI. Level 4 typically requires a developer because it involves entity anchoring across a full graph and site-wide template consistency that plugin UIs are not built for.