How Schema Markup Helps Personal Injury Law Firms Build Topical Authority
Schema markup does not build topical authority. Your content builds it, and schema markup makes it legible to the systems that decide whether Google believes you. Structured data tells search engines which entities your personal injury firm is talking about, how those entities relate, and where they match records Google already trusts. When your markup and your content assert the same facts, Google’s confidence in your firm rises. This piece shows the mechanism, and what my audits of 1,505 PI law firm websites, including 1,005 Google page-one sites, reveal about who actually does it.
On this page
- What topical authority means for a PI firm
- Why schema markup is not a ranking factor
- Entities, attributes, and triples
- Schema turns your topical map into entities
- How sameAs reconciles you to the Knowledge Graph
- The PI firm entity network, mapped
- Where PI firms actually stand (two studies)
- The schema maturity ladder
- When schema markup hurts a firm
- Schema and semantic SEO inside the PI Organic Authority Engine
- Does schema help in AI Overviews and AI search?
- How to measure schema completeness
- Work with me on your firm’s semantic SEO
- Closely related PI SEO topics
- Frequently asked questions
- References
Why Schema Markup Is Not a Ranking Factor for Law Firms
Schema markup is not a ranking factor. Google Search Central states the actual role plainly: Google uses structured data that it finds on the web “to understand the content of the page, as well as to gather information about the web and the world in general.” Understanding, not ranking. Google’s own John Mueller has repeated through 2025 that adding structured data does not, by itself, move a page up. His analogy was that structured data is like directions to a party, while ranking factors are the invitation. The directions get you nowhere if you were never invited.
Google’s own documentation states this in the section on how structured data works, quoted below with the operative phrase highlighted.
“Schema does not earn authority. It reports the authority you already earned.”
Behzad Hussain, on every first strategy call
That single reframing kills most of the bad advice in this niche.
So why bother? Because understanding is upstream of everything you want. Structured data makes your firm eligible for rich results, which lift click-through when they appear. It feeds Google’s entity systems the who, what, and where of your firm in a form they parse reliably, instead of forcing them to infer it from prose. It lowers the cost of retrieval, the resource Google spends to figure out what your page is about. A page that hands Google a clean set of entities and relationships is cheaper to trust than a page that buries them in text. Cheaper to trust means more likely to be chosen when two firms are otherwise close.
Most PI firms I audit get this backwards. They treat schema as a lever they can pull to rank, bolt on nine types, and wait for movement that never comes. The firms one block over who actually outrank them did the boring thing first: they covered the topic, then they described it accurately in markup. The markup did not beat the content. It matched it.
The best PI marketing directors I work with already understand this. They treat schema as documentation of a decision the content already made, not a substitute for making it. That mindset is why their firms compound while their competitors keep buying plugins and waiting.
Does adding more schema types raise my authority? No. A page with LegalService, Person, Service, FAQPage, Article, BreadcrumbList, Organization, Review, and WebSite markup is not more authoritative than a page with two well-built types that match deep content. Type count is vanity. Entity accuracy is the metric.
Entities, Attributes, and Triples: What Google Reads on a PI Firm’s Page
Google reads your page as entities and the relationships between them, not just as a bag of keywords. An entity is a distinct thing: your firm, a named attorney, a practice area, a city, a court. An attribute is a fact about an entity: a firm’s address, an attorney’s bar admission, a service’s area served. A relationship joins two entities through a predicate, and search engineers call that unit a triple, written as subject, predicate, object.
Three examples make it concrete. “The firm handles truck accident cases” is a triple: firm, handles, truck accident cases. “Maria Reyes works for the firm” is a triple: Maria Reyes, worksFor, firm. “The firm serves Harris County” is a triple: firm, areaServed, Harris County. Stack enough true triples about the same entity and you have described that entity so precisely that Google can tell it apart from every other firm with a similar name.
You already emit triples in your prose. Every declarative sentence on your practice-area pages is one. The problem is that prose triples are expensive to extract. Google’s systems have to parse the language, resolve the pronouns, and guess at the entities. Structured data emits the same triples in a format that needs no guessing. The diagram below shows one triple expressed in both channels.
One triple, two channels
Content persuades the reader. Schema confirms the entity for the machine. They say the same thing.
Prose channel
Maria Reyes works for the firm.
Schema channel
"Person": { "worksFor": { "@id": "#firm" } }
Authority compounds when both channels assert the same triple about the same entity.
This is the hinge of the whole topic. Content and schema are two channels emitting the same triples. The content channel persuades the reader. The schema channel confirms the entities for the machine. Authority compounds when both channels say the same thing about the same entities, because agreement across channels is exactly the corroboration Google’s entity systems look for.
There is direct evidence that structured data feeds this understanding. Google’s 2014 Knowledge Vault research describes building a web-scale research knowledge base by fusing four kinds of web extraction: free text, tables, page structure, and human annotations. That last lane, human annotations, is the structured data a publisher declares. The paper’s own quality scores make the case: the annotation extractor scored 0.920 on area under the ROC curve against 0.867 for text extraction. Prose triples ride the noisy text lane; schema triples ride the cleaner annotation lane. The paper describes published research machinery, not a promise your markup ranks, but it shows why the annotation lane is the cheapest way to hand a search system a fact it can trust.
Schema Markup Turns Your Topical Map Into Machine-Readable Entities
Schema markup turns the topical map you built in content into a set of machine-readable entities and relationships. A topical map is the plan of what you cover and how the pieces connect: the firm at the center, practice areas branching off, locations, attorneys, injuries, the claims process. Content expresses that map to humans. Schema expresses the same map to the entity layer, node by node, edge by edge.
The types below are the canonical vocabulary for a PI firm. Each is a node type. Together they reconstruct your topical map in a form Google parses without inference. I keep the code light here on purpose. For the full build, with every property, the deprecation history, and the office variants, read my companion guide on schema markup for personal injury law firms. This article is about why the entities matter, not how to hand-code every property.
LegalService: Your Personal Injury Firm as a Legal-Service Entity
LegalService is the type that declares your firm a legal-service provider. Its Schema.org hierarchy runs Thing to Organization to LocalBusiness to LegalService, and separately Thing to Place to LocalBusiness to LegalService, so a LegalService node is both an organization and a place. That dual identity is why it carries a physical address, an area served, and hours, alongside the firm’s name and brand. Schema.org’s own type page states both inheritance chains and the definition, shown below.
The minimal node below shows the shape of the declaration.
{
"@context": "https://schema.org",
"@type": "LegalService",
"@id": "https://firmdomain.com/#legalservice",
"name": "Firm Name",
"areaServed": { "@type": "AdministrativeArea", "name": "Harris County, Texas" },
"address": { "@type": "PostalAddress", "addressLocality": "Houston", "addressRegion": "TX" }
}The @id matters more than any single property. It is the stable name for your firm entity, the anchor every other node points back to. Give the firm one canonical @id and reuse it everywhere. My audits keep finding firms with a different implied firm entity on every template, which tells Google there are five firms, not one.
Person: Each Attorney as a Verifiable Author Entity
Person is the type for each attorney, and it is where firms leave the most authority on the table. A Person node carries the attorney’s name, job title, the credentials that qualify them, the topics they know, and a worksFor edge back to the firm’s @id. The old Attorney type is deprecated in favor of LegalService plus Person, so Person is now the canonical home for the individual lawyer.
{
"@type": "Person",
"name": "Maria Reyes",
"worksFor": { "@id": "https://firmdomain.com/#legalservice" },
"knowsAbout": ["truck accident litigation", "wrongful death claims"]
}Google’s patent on identifying entity attribute relations, US Patent 11,263,400 B2, describes pulling entity-attribute pairs out of text as input to search. An attorney’s expertise topics are exactly such pairs. The patent is filed machinery, not confirmed ranking behavior, but knowsAbout hands the system that pair directly instead of making an extractor infer the attorney’s topics from prose.
One of my clients, a multi state PI firm, wired every attorney’s Person node to their authored articles and their bar profile. Within two crawl cycles the attorneys surfaced as distinct entities, and the firm’s expertise stopped living only in prose nobody structured. The bio page does the heavy lifting here; Person schema confirms it. If your attorney pages are thin, the schema has nothing true to confirm, which is why I send firms to fix attorney bio page optimization before they touch Person markup.
Service: Every Practice Area as a Declared Legal Offering
Service is the type that declares each practice area a distinct offering. A Service node names the service, points its provider at the firm’s @id, and states the areaServed. This is how you tell Google that “truck accident representation in Houston” is a specific thing your firm does, not a keyword you sprinkled.
{
"@type": "Service",
"serviceType": "Truck Accident Representation",
"provider": { "@id": "https://firmdomain.com/#legalservice" },
"areaServed": { "@type": "City", "name": "Houston" }
}Service nodes only earn their keep when a real practice-area page sits under them. Markup for a service you describe in two sentences is a label on an empty box. The copy, layout, and intent handling that make a Service node true live in practice area page structure for personal injury firms.
Organization and subOrganization: One PI Firm Across Many Offices
Organization is the firm’s brand entity, and subOrganization is how a multi-office firm models its real offices without fracturing into separate brands. Each office becomes a subOrganization node under the parent, sharing the brand and pointing back to it. The pairing is subOrganization and parentOrganization. It is not hasPart, which Schema.org scopes to creative works, not organizations, a mistake I have had to unwind on more than one firm’s site.
A California firm came to me convinced their developer’s schema was finished. It declared the firm an Organization, one attorney a Person, and one practice a Service, and it never connected any of them. Three islands, no bridges. Google saw an organization, a person, and a service on a page, with nothing telling it they belonged together.
FAQPage, Article, and BreadcrumbList: The Supporting Schema Nodes
FAQPage, Article, and BreadcrumbList are the supporting nodes that describe the content around your entities. FAQPage marks up genuine question-and-answer blocks through its mainEntity property. Article binds an educational page to its author, which is how content authority connects to a real Person. BreadcrumbList expresses your site hierarchy as an ordered itemListElement, so Google reads the structure you built.
Two cautions carry over from Google’s own changes. FAQPage rich results are restricted to well-known government and health sites, so mark up FAQs for understanding, not for stars. Do not ship Review or AggregateRating about your own firm on your own site; Google treats self-attested review markup as ineligible for star display, and state bar advertising rules add their own risk on top.
How sameAs Reconciles Your Firm to Google’s Knowledge Graph
The sameAs property reconciles your firm’s entity to records Google already trusts. Schema.org defines sameAs as the URL of a reference page that unambiguously indicates the item’s identity. In plain terms, sameAs says “this firm is the same firm as the one described over there.” Point it at your Google Business Profile, your state bar listing, your Wikidata entry if you have one, your firm’s verified social profiles. Each link is a thread stitching your on-site entity to the wider web. The flow below shows the reconciliation.
How sameAs binds your firm to the Knowledge Graph
One on-site firm entity, linked out to trusted records, resolved into one graph entity.
sameAs →
sameAs declares the identity link. Corroboration across the sources decides whether Google believes it.
The Knowledge Graph is Google’s store of entities and their relationships. Your firm becomes a confident entity in it not by adding markup, but by being described consistently across many sources that markup then connects. Google’s own help documentation on Knowledge Panels is clear that panels are assembled from entities corroborated across the web, not minted from a site’s own claims. So sameAs is powerful and limited at the same time. It declares the identity link. Corroboration decides whether Google believes it.
Google’s 2014 patent, Corroborating Facts Extracted from Multiple Sources, US Patent 8,682,913 B1, describes this in machine form: a fact is accepted when it appears across several independent sources, with the agreement weighted by each source’s importance. The patent is filed machinery, not a description of live behavior, but it is the logic sameAs leans on. Your on-site claim earns belief when the records you point to agree with it, and earns nothing when they contradict it.
“Entities beat adjectives. Google does not rank you for calling yourself the best; it ranks the firm it can identify most confidently.”
Behzad Hussain, to partners who want more superlatives on the page
The identity work that makes a firm confidently known is the same work that builds a durable brand entity, which is why sameAs sits so close to brand context optimization for personal injury law firms.
Here is the failure I see most. A firm’s name, address, and phone number read three different ways across the site, the Business Profile, and the directories. The sameAs links point at records that disagree with the page. Google reconciles nothing, because the sources it was pointed to contradict each other. Consistency is the precondition. sameAs only helps once the facts already line up.
The Personal Injury Firm Entity Network, Mapped
A PI firm’s schema, done right, is one connected entity network, not a pile of disconnected nodes. The firm entity sits at the center. Attorneys attach through worksFor. Practice areas attach through provider. Cities and counties attach through areaServed. Articles attach to attorney authors. Every office attaches through subOrganization. Read as a graph, the markup mirrors the topical map your content already draws.
The PI firm entity network
One firm entity at the center, every node connected by a named predicate.
The predicates are the edges. A firm with connected edges tells Google one complete, checkable story.
The best entity graphs I audit are almost never the ones with the most schema types. They are the ones whose nodes connect and whose connections are true. A firm with LegalService, three Person nodes wired by worksFor, four Service nodes wired by provider, and clean areaServed edges has told Google a complete, checkable story. A firm with eleven disconnected types has told Google nothing it can trust.
This is where topical authority and schema finally meet. Your content builds the topical map. Your internal links express the map’s connections to readers and crawlers. Your schema expresses the same connections to the entity layer as explicit edges. Three channels, one map. When they agree, the firm reads as a single, well-understood authority on its topics. When they disagree, the firm reads as noise.
Put the pieces in order and the mechanism is one chain, each link backed by filed or published work. The step below marked in navy is the only one schema owns.
From schema to topical authority, step by step
The chain the patents and papers describe. Each link is filed or published machinery, not a promise of live ranking behavior.
Schema owns step 1. Content, links, and corroboration carry the rest. Skip them and the chain breaks at step 3.
Where Personal Injury Firms Actually Stand on Schema (Two Structured-Data Studies)
Most personal injury firms implement structured data shallowly, and I have the data to say so. I ran two audits of the PI market and published both. The first, in my SSRN paper on schema markup adoption across North American legal services, scored 500 firms on a Schema Completeness Index built from five dimensions: type coverage, property completeness, entity disambiguation, hierarchical nesting, and validation status. The second, my ResearchGate audit of 1,005 Google Page-1 firms across 50 states, checked what the firms already winning actually ship.
The headline numbers are not close to what the market assumes. In the 500-firm study, LegalService adoption sat at 40.0%, Person or Attorney markup at 41.2%, and FAQPage at 25.6%. Only 1.4% of firms reached the Semantic Authority tier of maturity. Validation testing found errors in 263 of the 338 firms that had any schema, 77.8%, so most structured data that exists does not cleanly validate. Entity disambiguation scored as the weakest of the five dimensions, the exact layer that tells one firm apart from another. The paper’s own findings table records the LegalService figure, highlighted below.
The five dimensions of the Schema Completeness Index each measure a different failure. Type coverage asks whether the right types exist at all. Property completeness asks whether the types carry the properties that make them useful. Entity disambiguation asks whether the firm is described precisely enough to tell it apart from similarly named firms. Hierarchical nesting asks whether the nodes connect into a graph. Validation status asks whether any of it parses. Firms do best on type coverage, the easy dimension a plugin handles, and worst on entity disambiguation, the dimension that actually tells one firm from another. The market ships the vanity layer and skips the load-bearing one.
The 1,005-firm Page-1 study, drawn only from firms already ranking, tells a sharper story. The bars below show how shallow adoption stays even among the winners.
What 1,005 Page-1 PI firms actually ship
Adoption and maturity among firms that already rank on Google Page 1.
First five bars are shares of all 1,005 sites; the areaServed bar is a share of the 640 sites with any schema. Mean completeness among schema-using sites: 11.5 out of a possible 25.
Among firms on Page 1, LegalService adoption was 35.3%, higher in the top 3 at 40% and lower at positions 7 to 10 near 30%. Person or Attorney markup reached only 20.6%. FAQPage adoption was 18.5%. The largest share of the market, 44.0%, sat at the Service Declaration tier, and only 1.3% reached Semantic Authority. The mean Schema Completeness Index among the sites that had any schema was 11.5 out of a possible 25, essentially unchanged from the 11.8 benchmark in my broader 500-firm sample. And among those 640 schema-using sites, 366, or 57.2%, still omitted areaServed. The 1,005-firm paper states the LegalService figure directly, highlighted below.
The finding that matters most for this article is the correlation with rank. The Spearman correlation between rank and rich-result feature count was -0.084, and between rank and the completeness score -0.0581, both weakly negative. In the paper I called schema quality a tiebreaker, not a primary lever. Firms in the top 3 averaged 2.73 eligible rich-result features; firms at positions 7 to 10 averaged 2.36. The gap is almost nothing. Schema is necessary for eligibility and understanding. It is not sufficient for rank. The firms winning Page 1 win on content, links, and brand, and their schema is along for the ride.
“The market is not stuck because schema is hard. It is stuck because nobody reads what they shipped.”
Behzad Hussain, while pulling the 1,005-firm numbers
A 77.8% error rate on the schema that already exists is not a knowledge problem. It is an attention problem.
The Schema Maturity Ladder for Personal Injury Websites
Schema maturity for a PI website climbs five rungs, and knowing your rung tells you the next move. I built the ladder from the two studies so a firm can locate itself instead of guessing. Each rung adds a layer of entity meaning, not just another type. The ladder below marks where the market actually sits.
The schema maturity ladder
Five rungs from bare identity to full integration. Find your firm, then climb one.
Basic Identity
The firm declares itself, name and address, and stops.
Service Declaration
Adds practice-area Service nodes. The plurality of ranking firms sits here.
Entity Network
Connects the nodes: attorneys by worksFor, services by provider, offices by subOrganization. The cheapest authority upgrade in this discipline.
Semantic Authority
Adds sameAs reconciliation, knowsAbout topic binding, and author-to-article edges. Only 1.3% reach it.
Full Semantic Integration
Keeps the whole graph consistent as the site grows, schema and content updated together on every publish. Zero sites reached it in either study.
The Level 2 to Level 3 jump costs no new content. It costs attention to @id and the edges between nodes.
Level 1, Basic Identity, is a firm that declares itself, name and address, and stops. Level 2, Service Declaration, adds practice-area Service nodes; 44.0% of ranking firms sit here. Level 3, Entity Network, connects the nodes: attorneys wired by worksFor, services by provider, offices by subOrganization, so the graph is joined. Level 4, Semantic Authority, adds sameAs reconciliation, knowsAbout topic binding, and author-to-article edges, so the firm is corroborated against the wider web; only 1.3% reach it. Level 5, Full Semantic Integration, keeps the entire graph consistent as the site grows, with schema and content updated together on every publish. Not one of the 1,505 sites across my two studies has reached it. The top rung is empty, which means the first firm in a market to hold it has no company there.
Most firms I audit live at Level 2 and think they are done. The jump that actually moves entity confidence is Level 2 to Level 3, from declaring nodes to connecting them. It costs no new content. It costs attention to @id and the edges between nodes. That is the cheapest authority upgrade in this entire discipline, and almost nobody takes it.
When Schema Markup Hurts a Law Firm: The Content Mismatch Penalty
Schema markup hurts a firm when it claims things the page does not support. Google’s structured data policies require markup to represent content the user can actually see, and Mueller has been direct that structured data should match the visible page. The documented consequence of a mismatch is a spammy structured markup manual action: your rich results disappear until the markup is cleaned up and re-reviewed. My read is that the same logic carries into AI answers, where a system that catches your markup contradicting your page has every reason to trust the source less. Markup is not a free layer. Wrong markup is a liability. The three panels below show the penalty.
The content mismatch penalty
When the markup claims more than the page delivers, Google pulls rich-result eligibility.
Schema claims
“Serves 12 counties” across 12 location nodes.
Page shows
One thin paragraph with a swapped city name.
Google’s response
Cross-references the two, flags the gap, eligibility drops.
Precise markup on weak content just makes the weakness precise.
I had a firm come to me last year with immaculate LegalService markup on 40 location pages, each page carrying near-identical thin content under a swapped city name. The schema was clean. The content told Google the 40 pages were duplicates wearing different hats. The markup did not rescue the pages. It documented, in a format Google reads perfectly, that the firm was claiming 40 service areas it had not genuinely built. Precise markup on weak content just makes the weakness precise.
“If your content and your schema disagree, believe the content, because Google does.”
Behzad Hussain, to firms who ask which side to fix first
Fix the content. Then let the schema describe something true.
Do I need to mark up a page before the content exists? No. Ship the content first, prove the entity in prose and structure, then add markup that confirms what is already there. Schema-first, content-later is how firms end up with a validator full of green checks and a site full of empty claims.
Schema Markup and Semantic SEO Inside the PI Organic Authority Engine
Schema markup is the machine-readable expression of Phase 3 in the PI Organic Authority Engine, the entity and authority layer. The engine runs four phases, and schema touches two of them directly. It belongs to Phase 1, Technical Stability, because clean structured data lowers the cost of retrieval, the same reason the phase cares about crawl health and response time. Read the full technical layer in my guide to technical SEO for personal injury law firms. It belongs more deeply to Phase 3, where the work is turning your firm from a website into a recognized entity.
Phase 3 uses an entity, attribute, value model and a practice I call algorithmic authorship: writing declarative, entity-first sentences that state facts as clean triples a machine can extract. Schema is the same triples, expressed structurally instead of in prose. Do both, and you emit each fact twice, once for the reader and once for the parser, in agreement. That agreement is the corroboration signal. The complete phase-by-phase model, and where schema sits inside it, lives in the PI Authority Engine overview.
Semantic SEO is the discipline this all belongs to. It optimizes for entities, attributes, and relationships rather than keyword strings, and it treats content, internal links, and schema as three expressions of one topical map. Schema is not a separate task on a checklist. It is the structured half of a sentence your content already started.
Does Schema Markup Help Personal Injury Firms in AI Overviews and AI Search?
Schema markup helps AI systems represent your firm accurately, which matters more as answers move into AI Overviews, ChatGPT search, and Perplexity. It is not an AI-citation button. Mueller’s position on schema and large language models is that it depends on the feature: some uses genuinely rely on structured data, others only enrich what the system already understood. The consistent thread is precision. When an AI system assembles an answer about your firm, structured data gives it clean facts to pull, so it is likelier to state your practice areas, service area, and attorneys correctly instead of guessing from directory scraps.
The crawlers reading your pages are named
OAI-SearchBot reads for ChatGPT search, PerplexityBot for Perplexity, alongside Google’s own systems that feed AI Overviews. None of them publishes a rule that says correct schema earns a citation. What structured data does is reduce the chance they get your firm wrong, and it raises the odds your entity is the one they resolve to when a prospect asks for an injury lawyer in your city.
There is measured evidence that authority markers help here. A 2024 study, GEO: Generative Engine Optimization, tested nine content strategies against visibility in AI answers and found the right ones lift a page’s presence in generative responses by up to 40%. Its top performers were quotation addition at roughly 41%, statistics addition at roughly 31%, and source citations at roughly 30%, while keyword stuffing did almost nothing. Those are in-content signals, not schema properties, but they are the same epistemic kind that schema mirrors in structured form through credentials and authorship. Structured data does not buy a citation. It hands these systems the clean, attributable facts they prefer.
Accuracy is the whole game in AI answers, because a confident wrong answer about your firm costs you the case with no chance to correct it. The mismatch rule bites hardest here. I treat a markup-to-page contradiction as disqualifying, because a system that catches one has little reason to trust either channel. Clean, honest schema is the price of being represented well. It is not a shortcut past the content and corroboration that earn the mention.
How to Measure Whether Your Firm’s Schema Is Actually Complete
Measure schema completeness on two axes: does it validate, and does it describe a connected, true entity network. Type count is not the measure. A firm at Level 4 with five connected types beats a firm at Level 1 with ten disconnected ones. Run the check in this order.
- 1Validate every template. Run each page type through the Rich Results Test and the Schema Markup Validator, and treat warnings as work, not noise.
- 2Confirm one canonical
@id. The firm entity should carry the same@idon every page, reused rather than reinvented per template. - 3Trace the edges by hand. Does every attorney point to the firm through worksFor, every service through provider, every office through subOrganization.
- 4Check the sameAs targets. Confirm each resolves to a record whose name, address, and phone match the page exactly.
Nine out of ten firms I review have never opened the validator. They assume the plugin got it right, and on the properties that decide entity confidence, the plugin usually did not. A quick pass on those four steps surfaces the gap between “we have schema” and “our schema describes one confident firm.”
How long before schema changes show up? Expect 4 to 12 weeks after re-crawl for corrected markup to settle into how Google understands the firm, often 2 to 6 weeks on AI surfaces that re-crawl more aggressively, and longer for entity reconciliation that depends on external sources updating too. This is entity understanding, not a switch. It moves at the speed Google re-reads and re-corroborates your site.
Work With Me on Your Personal Injury Firm’s Semantic SEO
Schema is the machine-readable half of topical authority. The content, the internal links, the entity corroboration, and the conversion paths are the other half, and they only compound when one hand builds them together. Firms that want the whole semantic setup reviewed, not just the JSON-LD, start with the Personal Injury SEO Diagnostic. The Diagnostic scores your schema completeness against the same five dimensions I used across 1,505 audited sites, then maps the content and entity gaps that keep your authority from compounding.
Signed cases, not just structured data
Start with a Personal Injury SEO Diagnostic
Structured data is a means, not the metric. The metric is signed cases from organic, and clean entities only help when the content behind them earns the click and the call. If your firm signs 6 to 20 cases a month from organic and wants a structured review before committing to retainer work, start here. Written findings and a 60 to 90 minute strategy call.
Request a Personal Injury SEO DiagnosticFrequently Asked Questions About Schema and Topical Authority
My developer installed a schema plugin. Is that enough?
A plugin is a start, not a finish. Plugins reliably add the type and the obvious properties, and reliably miss the entity edges that build authority: one canonical @id, worksFor and provider links, sameAs reconciliation, and areaServed. The 500-firm study found validation errors in 77.8% of the sites that had any schema. In my own audits, most of that broken markup is plugin-generated. Audit what the plugin shipped before you trust it.
JSON-LD or microdata for a law firm site?
Use JSON-LD. Google recommends JSON-LD because it sits in one script block, separate from your visible HTML, which makes it the easiest to maintain across templates and the least likely to break when your design changes. Microdata tangles markup into the page and is harder to keep consistent at scale.
Does a small single-office firm need this?
Yes, and a small firm often benefits more. A single-office firm competes on entity clarity it can fully control: one firm, one address, a handful of attorneys, a clear service area. A clean Level 3 entity network is achievable in days for a small firm, and it separates you from the local competitors still sitting at Level 1 identity markup.
How often should I re-audit my firm’s schema?
Re-audit at every site change and at least twice a year. Structured-data guidance shifts, rich results get re-scoped, and template updates silently break markup. A twice-yearly validation pass, plus a check after any redesign, keeps the entity graph honest.