HomeAbout
Part of: AI Visibility

What structured data markup do law firms and lawyers need for AI search?

By Mohammad Kashif, Chief Technology OfficerLast updated

Four types cover almost every law firm: LegalService for the firm, Person for each lawyer, FAQPage for question blocks, and BreadcrumbList for hierarchy. Everything else is optional. Getting these four correct and consistent matters more than adding a fifth.

The common failure is not absence, it is contradiction. A firm whose LegalService name differs from its Business Profile name, or whose lawyer nodes carry no stable identifier, gives a model conflicting claims about the same entity, which is worse than giving it none.

The four types that matter, and what each one does

Each type answers a question a model would otherwise have to guess at. Shipping them is a one-time change that takes effect on the next crawl.

  • LegalService identifies the firm as a business: name, address, phone, practice areas, service area. This is the node an assistant attributes a recommendation to.
  • Person identifies each lawyer, with their job title, bar admissions and profile URL, and worksFor ties them to the firm. Without it, individual lawyers are just text on a page.
  • FAQPage marks a question block as questions and answers, which is the format most readily lifted into an answer.
  • BreadcrumbList states where a page sits in the site, which helps a model understand that a practice-area page belongs to a firm rather than standing alone.

Structured data markup for each lawyer's bio page

On a firm site each lawyer is a person, so their bio page carries a Person node: name, job title, photo, the bio page URL, and worksFor pointing at the firm's identifier. Bar admissions go in as credentials that match what the page visibly states.

schema.org files Attorney under LegalService as a kind of business, not a person, and now marks it deprecated in favour of LegalService. It does not describe an individual lawyer at a firm, and using it that way tells a model the lawyer is a second business.

Connect the nodes, do not leave them floating

The single highest-value detail, and the one most often skipped, is giving each entity a stable identifier and referencing it from the others. A page carrying three unconnected blocks describes three unrelated things. A page whose Person node for a lawyer points at the firm's identifier describes a lawyer who works at a specific firm, which is the claim you actually want made.

Use a URL fragment as the identifier, keep it identical across every page, and reference it rather than repeating the whole node. One firm identifier, reused everywhere, is what lets a model merge everything it reads about you into one entity.

  • Give the firm one identifier, for example the homepage URL followed by a firm fragment, and reuse it on every page.
  • Have each lawyer's Person node reference that identifier in worksFor rather than restating the firm's details.
  • Never publish two full versions of the same entity with the same identifier on one page. Duplicate identifiers make the graph ambiguous, which defeats the purpose.

Mistakes that quietly invalidate the markup

Most broken implementations validate cleanly and still fail, because the problem is truthfulness or consistency rather than syntax.

  • Marking up content that is not on the page. Structured data labels visible content; inventing fields is a manual-action risk, not a shortcut.
  • Review markup for reviews the firm collected about itself. Self-serving review markup is against Google's guidelines and has been for years.
  • A street address for a virtual or coworking office. That asserts a place of business, and it becomes an address-consistency problem the moment a directory scrapes it.
  • Details that disagree with the Google Business Profile. When the two conflict, a model has no way to tell which is right and will usually trust neither.
  • Markup that only exists after JavaScript runs. If it is not in the HTML a crawler receives, assume it is not being read.

How to check it is actually working

Two checks, both free, both worth running after any template change. Fetch the page as a crawler would and confirm the markup is present in the raw HTML rather than injected later. Then run the URL through a structured data validator and confirm the entities resolve and reference each other as intended.

Worth doing on a schedule rather than once. Template changes and plugin updates remove structured data silently, and nothing about the page will look different when they do.

What each type is for, and what breaks without it

TypeAnswers the questionWhere it belongsWithout it
LegalServiceWhat is this business and where does it work?Homepage and contact pageThe firm is not a recognised entity, only text
Person (each lawyer)Who practises here and what are they admitted to do?Each lawyer bio pageIndividual lawyers cannot be attributed or recommended
FAQPageWhich spans on this page are questions and answers?Any page with a question blockAnswer blocks compete as ordinary prose
BreadcrumbListWhere does this page sit in the site?Every page below the homepageDeep pages look unrelated to the firm

Common questions

Does structured data directly improve AI visibility for a law firm?
It does not create authority, and it will not make a model cite a firm nothing else references. What it does is remove ambiguity: it tells a system what the page is, who the firm is, and how the entities relate, instead of leaving all three to inference. That reliably improves how often a firm is attributed correctly, which is a precondition for being cited at all.
Should a law firm use LegalService or LocalBusiness or Attorney?
LegalService for the firm, because it is the specific subtype and inherits everything LocalBusiness offers. Person for each individual lawyer, with worksFor pointing at the firm's identifier. schema.org's Attorney type is itself a subtype of LegalService, a business rather than a person, and is now deprecated, so it does not describe a lawyer at a firm.
Is review schema safe for a law firm to use?
Only for reviews collected by an independent third party and displayed as they appear there. Marking up reviews a firm gathered about itself is against Google's guidelines and risks a manual action. Several state bars also restrict how client testimonials may be presented, so check the advertising rules in your jurisdiction before publishing them at all.
How do I know if my structured data is actually being read?
Fetch the page as a crawler would and confirm the markup appears in the raw HTML rather than only after JavaScript runs. Then run the URL through a structured data validator to confirm the entities parse and reference each other. Re-check after any template or plugin change, because those remove markup silently.
What structured data markup does a lawyer's bio page need?
A Person node for the lawyer with name, job title, photo and the bio page URL, a worksFor reference to the firm's identifier, and bar admissions stated as credentials that match what the page displays. Give each lawyer one identifier and reuse it wherever that lawyer is marked up, so every mention resolves to the same person.
Is schema markup the same thing as structured data?
In practice, yes. Structured data is the general idea of labelling page content for machines; schema markup is structured data written in the schema.org vocabulary, usually as JSON-LD in the page's HTML. On a law firm site the two terms almost always mean the same thing.
Does a law firm also need local schema markup?
Local schema markup is the same LegalService node with the address, phone, opening hours and service area filled in, which is what local search reads. A firm with a physical office should publish it. A virtual or coworking office should leave the street address out, because a street address asserts a place of business the firm does not have.

Find out whether assistants name your firm

We run a fixed prompt set across the major assistants and report which sources they quoted instead of you.

Talk to us