Schema markup helps machines interpret facts and relationships that the law firm's visible pages already establish. It does not make an unhelpful page authoritative, create a rich result, repair inconsistent office data, or guarantee visibility in search or AI answers.
Use structured data after the firm decides which business, office, person, service, and article each page represents. The smallest accurate graph is better than a large template filled with guesses.
Separate three questions
- Is the vocabulary valid? Does the markup use Schema.org types and properties in an allowed structure?
- Is it eligible for a Google search feature? Does Google document and support a feature for that content, and does the page meet its additional requirements?
- Will Google show the feature? Eligibility does not guarantee display.
A Schema.org validator can answer much of the first question. Google's Rich Results Test addresses supported Google features. Neither proves that the business facts are true or that a result will appear.
Google's general structured-data policies require markup to represent the page and avoid misleading content; feature-specific documentation adds further rules. Read Google's current structured-data guidelines.
Model the business and lawyer as different entities
LegalService describes a business that provides legally oriented services and is a subtype of LocalBusiness. Person describes an individual attorney.
Schema.org's older Attorney type is deprecated; its current page directs users to LegalService as a more inclusive and less ambiguous business type. Despite the name, Attorney is not the reason to mark an individual lawyer as a business.
Use stable @id values so pages can refer to the same entity. Keep the visible page and data source authoritative. A typical relationship may be:
- organization/firm;
- real office represented as a
LegalServiceor appropriate local-business node; - attorney represented as a
Personwho works for the firm; - page/article whose author or about-entity refers to the person or firm; and
- service relationships only where the public pages accurately establish them.
Do not create a separate “law firm” entity for every page. Do not collapse every office and attorney into one object when their facts and URLs differ.
Build a small governed graph
The following JSON-LD is fictional teaching material. Replace every URL and fact; choose the model that matches the actual firm. This example uses a parent organization, one real Denver office, and one lawyer.
{
"@context": "https://schema.org",
"@graph": [
{
"@type": "Organization",
"@id": "https://example.com/#firm",
"name": "Example Business Law",
"url": "https://example.com/"
},
{
"@type": "LegalService",
"@id": "https://example.com/locations/denver/#office",
"name": "Example Business Law — Denver",
"url": "https://example.com/locations/denver/",
"parentOrganization": { "@id": "https://example.com/#firm" },
"telephone": "+1-303-555-0100",
"address": {
"@type": "PostalAddress",
"streetAddress": "100 Example Street",
"addressLocality": "Denver",
"addressRegion": "CO",
"postalCode": "80202",
"addressCountry": "US"
}
},
{
"@type": "Person",
"@id": "https://example.com/attorneys/jordan-lee/#person",
"name": "Jordan Lee",
"url": "https://example.com/attorneys/jordan-lee/",
"jobTitle": "Partner",
"worksFor": { "@id": "https://example.com/#firm" }
}
]
}
The example omits opening hours, ratings, prices, coordinates, images, admissions, and services because no governed source was supplied. More properties would not make it more accurate.
For an implementation intended to qualify for a Google local-business feature, follow Google's current LocalBusiness documentation and the applicable content rules. A Schema.org-valid LegalService node does not by itself promise that feature.
Give every field a source and owner
Apply the AI-content accuracy controls when tools supply draft facts, and use how AI search finds and cites content to keep structured claims aligned with visible evidence.
Scroll sideways to review every column.Each row is shown as a labeled card.
| Field | Appropriate source owner | Recheck trigger |
|---|---|---|
| Firm name and main URL | Firm/brand record | Name, domain, merger change |
| Office address and phone | Operations/location owner | Move, closure, routing change |
| Attorney role and office | HR/firm biography owner | Join, departure, promotion, move |
| Service relationship | Practice leader/public page owner | Practice or represented-side change |
| Article author/date | Editorial record | Author correction or material update |
| Review/rating | Eligible third-party/review source plus feature rules | Source, count, policy, page control change |
The page template should draw from maintained facts when possible. If office hours differ by location, a global hard-coded block is a future error.
Do not buy FAQ markup for a retired Google feature
Google's documentation update log says the FAQ rich result stopped appearing in Google Search starting May 7, 2026, with the feature documentation later removed. Read the May 2026 update.
Helpful visible FAQs may still serve readers. Schema.org vocabulary can still describe content for other consumers. The retired Google feature means a provider should not sell FAQ markup as a way to win that rich result.
The existing Juris Digital FAQ schema guide remains a current review/update candidate because its historical search-benefit framing predates the retirement. Final update or consolidation is Casey's decision.
Do not promise self-review stars
Google says a local business or organization is ineligible for its star review feature when the reviewed entity controls the reviews about itself, including an embedded third-party review widget on the entity's own site. Read Google's review-snippet guidelines.
Client stories and testimonials can still be useful when accurate, permitted, contextualized, and professionally reviewed. Do not add AggregateRating to the firm's pages merely because the rating exists elsewhere, and do not treat valid syntax as feature eligibility.
Work through a schema cleanup
A fictional two-office, six-lawyer firm runs a validator and receives no syntax errors. A factual comparison still finds:
Scroll sideways to review every column.Each row is shown as a labeled card.
| Current markup | Visible/source reality | Decision |
|---|---|---|
| Every office uses the main-office address | Two real offices have different addresses/phones | Create separate governed office identities |
Six lawyers use deprecated Attorney business nodes |
They are individual biography subjects | Use Person; connect to the firm |
openingHours repeats on all pages |
No approved public hours record | Remove until operations supplies one |
AggregateRating marks the firm's embedded reviews |
Firm controls the page | Remove self-serving review markup |
24 FAQs retain FAQPage for Google expansion |
Google FAQ rich result retired | Keep useful visible answers; remove the feature promise |
| One departed partner remains author and employee | Biography and HR records changed | Correct authorship only where editorial record supports it; remove current employment relationship |
The team starts with false firm, office, and person facts because they can misdescribe the business across many pages. It removes unsupported hours and ratings. It reviews authorship rather than automatically replacing a historical author's name. The FAQ decision follows content usefulness, not a retired rich-result pitch.
After correction, the team runs a Schema.org validator, the relevant Google test, rendered-page inspection, and source comparison. It records errors, warnings, feature eligibility, and factual approval separately. Search display remains Google's decision.
Keep schema in proportion to the page
Use the technical SEO problem guide to diagnose contradictory markup, the complete technical SEO guide to verify rendered truth, and the website architecture guide to keep entity relationships consistent.
Schema cannot compensate for:
- a practice page that does not explain service fit;
- an office page for a location the firm does not operate;
- an attorney profile with stale credentials or role;
- an article with unsupported claims;
- broken links, canonical conflict, or indexing exclusion; or
- a contact path the firm cannot support.
Fix the visible truth and user path first when they are wrong. The law firm schema generator is a live contextual tool, but its rendered form/output was not validated for this draft; any generated markup still needs current vocabulary, Google-feature, page, and fact review.
Maintain the graph with the website
Treat schema as one bounded input to the practical AI-search visibility plan, not a substitute for useful page content.
Assign owners and tests for firm, office, attorney, service, author, breadcrumb, and other implemented nodes. Trigger review on office/phone changes, attorney moves, practice changes, mergers, URL migrations, CMS/template releases, policy changes, and retired Google features.
Juris Digital's current law firm SEO service includes technical/site foundations within a broader managed program, while its law firm website design service provides the relevant path when templates or a rebuild own the defect. Bring representative URLs, rendered markup, governed firm facts, validator/test results, and the feature or entity question. We can help scope the correction; neither service page promises a rich result, ranking, or AI citation.
