Structured data for law firm websites: the schema types that actually matter

Structured data tells a search engine what the things on a law firm page are: that this address is an office, this person is an attorney admitted in a particular state, this page describes a specific service, and this page sits inside that section of the site. Google Search Central describes it as a standardised format for providing information about a page and classifying the page content, and it is what makes a page eligible for certain search features. It is not a ranking trick, and most law firm sites carrying schema today have either the wrong types, markup for content that is not on the page, or review markup that should not be there at all. This article covers the types that earn their place on a law firm site, how to write them in JSON-LD, how to handle multiple offices, and the mistakes that are worth real trouble.

This is general information about law firm websites and technical search. It is not legal advice. Attorney advertising rules vary by state, and compliance with them is the firm’s responsibility rather than the website company’s.

What structured data does, and what it does not

Structured data does three useful things for a law firm website and one widely believed thing it does not do.

It makes pages eligible for search features. Google Search Central explains that structured data is used to enable special search result features and enhancements, and that eligibility for a given feature depends on having the right type with the required properties. Without the markup, the page cannot qualify for the feature at all.

It gives machines an unambiguous description of the firm. A page can say “Serving Philadelphia and the surrounding counties since 2009” in prose, and a language model or a crawler has to infer what that means. Structured data states the office address, the areas served, the practice areas and the attorneys as data, with no inference required. As AI answer systems increasingly summarise rather than link, being described accurately in machine-readable form matters more than it used to.

It forces internal consistency. Writing the markup exposes the fact that the phone number in the footer differs from the one on the contact page, or that an attorney listed on a practice area page has no bio.

What it does not do is raise rankings by itself. There is no ranking bonus for adding a script tag. A page with excellent markup that does not answer the question a person typed will still lose to a page that answers it, which is the argument made at length in our guide to how a small law firm website earns the first call. Treat structured data as description, not promotion.

The types that matter, and when each applies

The types that matter for a law firm site are a short list. Everything else is noise.

Page	Primary type	Also used
Home page	Organization, or LegalService for a single-office firm	WebSite
Office or location page	LegalService, or Attorney for a solo office	PostalAddress, GeoCoordinates, OpeningHoursSpecification
Practice area page	Service	BreadcrumbList, FAQPage where questions are on the page
Attorney bio	Person	BreadcrumbList, worksFor pointing at the firm
Blog post	BlogPosting or Article	Person as author, BreadcrumbList
Any page inside a section	BreadcrumbList

LegalService, Attorney, LocalBusiness and Organization

Choose between these four by asking what the page is describing: a place of business, or a company.

Schema.org defines LegalService as a more specific type of LocalBusiness, described as a business that provides legally oriented services, advice and representation. Attorney is defined as a more specific type of LegalService. Because both inherit from LocalBusiness, both expect what a local business entity expects: a name, a postal address, a telephone number, opening hours, a URL and a geographic position.

The practical rule for a law firm:

• A single-office firm with several attorneys is best described as LegalService on its home page or contact page. Attorney is a reasonable choice for a solo practitioner’s single office.
• A firm with multiple offices creates one LegalService entity per office, on that office’s own page, and one Organization entity for the firm as a legal entity. The office entities reference the Organization through parentOrganization.
• Do not use LocalBusiness when LegalService fits. Google Search Central’s local business guidance is explicit that you should use the most specific applicable subtype, and LegalService is more specific.
• Do not apply a business type to a practice area page. A practice area page is not an office. It describes a service.

Here is a complete, correct office entity for a single-office firm. Every value shown is a placeholder for the firm’s real details, which must match its Google Business Profile and directory listings exactly.

{
  "@context": "https://schema.org",
  "@type": "LegalService",
  "@id": "https://example-lawfirm.com/#office-philadelphia",
  "name": "Example Law Offices",
  "url": "https://example-lawfirm.com/",
  "telephone": "+1-215-555-0148",
  "email": "intake@example-lawfirm.com",
  "priceRange": "$$",
  "image": "https://example-lawfirm.com/images/office-front.jpg",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "1500 Market Street, Suite 1200",
    "addressLocality": "Philadelphia",
    "addressRegion": "PA",
    "postalCode": "19102",
    "addressCountry": "US"
  },
  "geo": {
    "@type": "GeoCoordinates",
    "latitude": 39.9526,
    "longitude": -75.1652
  },
  "openingHoursSpecification": [
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday"],
      "opens": "08:30",
      "closes": "17:30"
    }
  ],
  "areaServed": [
    { "@type": "AdministrativeArea", "name": "Philadelphia County, Pennsylvania" },
    { "@type": "AdministrativeArea", "name": "Montgomery County, Pennsylvania" }
  ],
  "sameAs": [
    "https://www.linkedin.com/company/example-law-offices",
    "https://www.avvo.com/law-firms/example-law-offices"
  ]
}

Two details in that example do real work. The @id gives the office a stable identifier that other entities on the site can point at, so an attorney bio and a practice area page can both reference the same office rather than describing it again. And sameAs lists the firm’s profiles elsewhere, which helps a search engine connect the site to the listings it already knows about.

Person schema for attorney bios

Person is the type for an attorney bio page, because the page describes a human being rather than a business. It is one of the most underused types on law firm sites, and one of the most useful, because a bio page carries exactly the facts a Person entity is built to hold.

The properties worth filling in are name, jobTitle, the firm through worksFor, the office through workLocation, an image, a description, alumniOf for the law school, knowsAbout for practice areas, and sameAs for the attorney’s professional profiles. The one property firms most often want and should treat carefully is any statement of credentials: describe admissions accurately and only where the bio page states them in visible text.

{
  "@context": "https://schema.org",
  "@type": "Person",
  "@id": "https://example-lawfirm.com/attorneys/dana-reyes/#person",
  "name": "Dana Reyes",
  "jobTitle": "Partner",
  "url": "https://example-lawfirm.com/attorneys/dana-reyes/",
  "image": "https://example-lawfirm.com/images/dana-reyes.jpg",
  "description": "Partner at Example Law Offices, admitted in Pennsylvania and New Jersey, handling criminal defense matters in state and federal court.",
  "worksFor": {
    "@type": "Organization",
    "@id": "https://example-lawfirm.com/#organization",
    "name": "Example Law Offices"
  },
  "workLocation": { "@id": "https://example-lawfirm.com/#office-philadelphia" },
  "alumniOf": {
    "@type": "CollegeOrUniversity",
    "name": "Temple University Beasley School of Law"
  },
  "knowsAbout": ["Criminal defense", "DUI defense", "Federal criminal procedure"],
  "sameAs": ["https://www.linkedin.com/in/example-dana-reyes"]
}

Note how workLocation refers to the office by its @id rather than repeating the address. That is the pattern to use everywhere on the site: describe each thing once, then reference it. It keeps the markup consistent when an address changes, because there is only one place to change it.

Service schema for practice area pages

Service is the type for a practice area page, because the page describes something the firm offers rather than the firm itself. This is the piece most law firm sites are missing, and it is the one that maps most directly onto how the site is actually organised. If the firm has one page per matter type, as it should, each of those pages has a Service entity describing that matter type, the provider, and the area served.

The properties that matter are serviceType, which names the practice area in plain words, provider, which points at the firm or office entity, areaServed, and a description that matches the visible page. Where the firm publishes consultation terms on the page, an Offer can describe them, but only if the terms are genuinely stated in the visible copy and only in wording the firm’s state rules permit.

A page such as a criminal defense practice area page carries a Service entity naming criminal defense as the serviceType, the office as the provider, and the counties the firm covers as areaServed. The same pattern repeats across every page under the practice areas index, which is why building the site as one page per matter makes the markup straightforward rather than laborious.

FAQPage, and what Google currently shows it for

FAQPage markup describes question and answer pairs that appear on the page. The important current fact is that Google Search Central states FAQ rich results are limited to well-known, authoritative government and health websites. A private law firm should therefore not add FAQPage markup expecting the expanded question list to appear under its result.

It is still worth adding, for two narrower reasons. It describes the page’s questions and answers in machine-readable form for AI answer systems and other consumers of the vocabulary. And it enforces a discipline that improves the page anyway: the markup must match visible content exactly, so writing it makes a firm check that the questions on the page are the ones people actually ask. The questions on our own FAQ page are marked up this way, and every answer appears in the visible copy.

The rule that must never be broken here: only mark up questions and answers that a visitor can read on that page. Google Search Central’s general structured data guidelines prohibit marking up content that is not visible to the reader, and FAQ markup is the most common place law firm sites break it, usually by including a question that was cut from the page during a redesign.

BreadcrumbList

BreadcrumbList describes where the page sits in the site’s hierarchy, and it is the cheapest markup on this list to get right. It affects how the path is displayed in search results and it gives a crawler an explicit statement of structure rather than one inferred from the URL.

A practice area page’s breadcrumb runs from the home page, to the practice areas index, to the page itself. An attorney bio runs from the home page, to the attorneys index, to the bio. A blog post runs from the home page, to the blog, to the post. Each item carries a position, a name matching the visible breadcrumb, and the item URL.

Article and BlogPosting

BlogPosting, a more specific type of Article, is for the firm’s articles and legal guides. It carries the headline, the publication and modification dates, the author as a Person entity, the publisher as an Organization, and the main image. Keep the author a real named person with a bio page on the site, and keep the dates honest: a modification date that changes every night without the content changing is a bad signal to give.

For a law firm this markup pairs naturally with the content itself. A guide explaining what happens after a particular kind of filing is an Article. It is not a Service, and it should not be marked up as one because it mentions a practice area.

Multiple offices, and the NAP problem

A firm with more than one office needs one entity per office and one page per office, and it needs the name, address and phone number to match everywhere.

One page, one entity, one @id

Each office gets its own location page carrying its own LegalService entity with its own @id, its own address, its own phone number and its own hours. Do not put three addresses into one entity, and do not list every office on the home page entity. An entity describes one place of business.

Above them sits a single Organization entity for the firm, and each office entity points at it. This is how a search engine understands that these are three offices of one firm rather than three unrelated businesses.

{
  "@context": "https://schema.org",
  "@type": "LegalService",
  "@id": "https://example-lawfirm.com/offices/allentown/#office",
  "name": "Example Law Offices, Allentown",
  "url": "https://example-lawfirm.com/offices/allentown/",
  "telephone": "+1-610-555-0193",
  "parentOrganization": {
    "@type": "Organization",
    "@id": "https://example-lawfirm.com/#organization",
    "name": "Example Law Offices"
  },
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "40 North Seventh Street",
    "addressLocality": "Allentown",
    "addressRegion": "PA",
    "postalCode": "18101",
    "addressCountry": "US"
  }
}

NAP consistency, and why it is not a pedantic point

NAP consistency means the name, address and phone number are identical in the structured data, in the visible page copy, in the Google Business Profile and in every directory listing the firm appears in. Not similar. Identical, down to the suite format and whether the street is written as “Street” or “St”.

It matters because those signals are how a search engine decides that the office described on the website is the same office described in a listing. Small inconsistencies weaken that association, and firms accumulate them easily: a second phone number added for call tracking, a suite number that changed, an office that still uses the old firm name after a partner change. The structured data is where these show up, because you cannot write the entity without deciding what the canonical values are.

A specific warning for legal sites. If the firm uses a call-tracking number, decide which number is canonical and keep the structured data, the visible copy and the listings on that one. A tracking number that appears only in markup, or only after a script rewrites the page, is exactly the kind of inconsistency that causes trouble.

JSON-LD, not microdata

Write structured data as JSON-LD in a script tag in the page head or body, rather than as microdata attributes woven through the HTML. Google Search Central recommends JSON-LD and describes it as the format it prefers, and there are three practical reasons beyond the recommendation.

The markup is separate from the presentation, so a design change cannot silently break the data by removing an element that carried an itemprop. The whole entity is readable in one block, which makes review and validation far easier than tracing attributes across a template. And it can be generated from the same data that renders the page, which is how it stays correct: the office address in the markup and the office address in the footer come from one source, so they cannot drift apart.

That last point is the whole game. Hand-written markup pasted into a page goes stale the first time something changes. Markup generated from the site’s own content data stays right by construction, which is how every site we build handles it, as described on our features page.

Validating it

Validate with two tools, because they check different things, and then watch Search Console.

The Rich Results Test answers whether Google considers the page eligible for a search feature, and reports errors and warnings against Google’s own requirements for that feature. It is the right tool for checking that a required property is not missing.

The Schema Markup Validator at validator.schema.org checks the markup against the schema.org vocabulary itself. It reports types and properties Google’s tool ignores, so it catches a misspelled property name or a type used in a place the vocabulary does not allow. Run both on one example of every page template: home, office, practice area, bio, blog post.

After publishing, the structured data reports in Search Console are what catch problems at scale. A template error affects every page built from that template at once, and that is the kind of error a single-page test can miss because the one page you tested happened to have every field filled in.

The mistakes that cost something

Four mistakes account for most of the trouble law firm sites get into with structured data.

Marking up content that is not on the page

Marking up content that is not on the page is the most common violation and the easiest to commit accidentally. Google Search Central’s general structured data guidelines state that structured data must describe content that is visible to the reader. An FAQ entry left in the markup after the question was removed from the copy, an attorney still listed in the firm entity after they left, a practice area marked up on a page that no longer covers it: all of these are the same error.

The fix is structural. Generate the markup from the same content that renders the page, and the two cannot disagree.

Review markup for reviews hosted on your own site

Review markup for reviews on your own site is not allowed. Google Search Central’s review snippet guidance treats reviews about the entity that hosts the review content as self-serving, and states that self-serving reviews are not allowed for LocalBusiness and Organization types. Client testimonials on the firm’s own testimonials page fall squarely into that description.

Firms still add it, usually because a plugin offered to, and the result is at best ignored and at worst a manual action against the site. Display the testimonials on the page for human readers. Do not mark them up as Review or AggregateRating.

Inventing an aggregate rating

Inventing an aggregate rating is worse than useless. A ratingValue and reviewCount that do not correspond to real, verifiable reviews violate the structured data guidelines, and Google can remove the site’s rich result eligibility for it.

For a law firm there is a second dimension. ABA Model Rule 7.1 prohibits false or misleading communications about a lawyer or the lawyer’s services, and every state has its own version of that rule along with its own advertising requirements. A fabricated rating published in the firm’s own markup is a communication about the firm’s services. This is one of several reasons we treat review snippets as off the table for legal sites rather than as an optimisation with a risk attached, and it is a decision the firm should confirm against its own state’s rules.

Using the wrong type because it sounds more specific

Using the wrong type happens when someone reaches for a type that sounds impressive. A practice area page marked up as Attorney, a blog post marked up as Service, a contact page marked up as an Organization when it describes one office. The vocabulary is precise and the tools will usually accept these, because validity and correctness are different things.

The test is simple. Say aloud what the page is about. If it is a place where the firm works, it is a LegalService or an Attorney. If it is a human, it is a Person. If it is something the firm offers, it is a Service. If it is something the firm wrote, it is an Article. If it is the company itself, it is an Organization.

What this looks like when it is done properly

Done properly, structured data on a law firm site is invisible and boring. Every office page carries one LegalService entity generated from the firm’s own address data. Every bio carries a Person entity that references the office rather than repeating it. Every practice area page carries a Service entity naming that matter and the counties served. Every page carries a BreadcrumbList. FAQ markup exists only where questions are visible on the page. There is no review markup anywhere.

That set takes an afternoon to specify and then never needs touching again, as long as it is generated from the content rather than pasted into it. It will not by itself move the firm up the results. What it will do is make sure that when a search engine or an answer system describes the firm, it describes it correctly: the right offices, the right attorneys, the right practice areas, the right phone number. Combined with pages that are genuinely fast on a phone and written to the question a person typed, it is the technical half of a site that gets found. The rest of what we build into every plan is set out on our services page and priced on the pricing page.

See the markup on a site built for your practice area

If you want to see exactly what this looks like on a working site, a demo shows a site built for your practice area, and you can run the Rich Results Test against it while you are looking at it. Bring the firm’s current site and test both. The difference between generated markup and pasted markup is usually obvious within a minute.