Law-firm schema works best when it describes real entities and relationships that are already clear on the page. Use LegalService for the law-firm or office entity when that type accurately describes the business, Person for individual attorneys, ProfilePage for attorney bio pages, and Service for practice areas or legal services when the page genuinely describes them. Connect those entities with stable URLs and identifiers instead of publishing several disconnected JSON-LD blocks that disagree about the same firm.
Structured data can help search systems understand which lawyer works for which firm, which office serves which location, and which service belongs to which provider. It does not prove bar admission, specialization, office legitimacy, or legal authority by itself. Google also says there is no special schema required for generative AI search, so the purpose is entity clarity and eligibility for supported search features—not an “AI ranking” shortcut.
Law-firm websites often accumulate schema in layers. A theme adds generic Organization markup, an SEO plugin adds LocalBusiness, a location plugin adds another business entity, an attorney plugin adds Person, and a page builder may insert FAQ or article markup. Every block can be syntactically valid while the combined graph still tells an unclear story.
The problem is not a lack of schema. It is usually a lack of entity discipline. The firm, each physical office, each attorney, each practice-area service, and each article have different identities and relationships. When those relationships are visible in the page content and represented consistently in structured data, search systems have cleaner clues to work with.
This guide focuses on that architecture. It explains which types fit common law-firm pages, which properties are useful, where law firms commonly overstate facts, and how to test the final implementation without confusing “valid markup” with guaranteed visibility.
1. Schema Clarifies a Law Firm; It Does Not Create the Law Firm’s Authority
Google describes structured data as a standardized way to provide explicit clues about page content. Its Organization documentation says organization markup can help Google understand administrative details and disambiguate an organization, while its LocalBusiness documentation covers physical-business facts such as address, hours and telephone.
That is useful, but it is narrower than many legal marketers imply. Structured data does not independently verify that a lawyer is admitted in a jurisdiction, that a firm has an office where it claims one, that a lawyer is a certified specialist, or that a practice area is actually handled by the office named on the page. Those facts need to exist in visible content and, when important, align with authoritative outside sources such as state-bar records and official business profiles.
| Question the site needs to answer | Primary entity | Useful schema type | What still needs visible proof |
|---|---|---|---|
| Who is the law firm? | Firm or physical office | LegalService, sometimes supported by broader Organization data |
Real business name, address or service model, phone, office facts and public identity. |
| Who is the lawyer? | Individual attorney | Person on an attorney profile; ProfilePage can describe the bio page |
Admissions, role, biography, education, actual firm relationship and current status. |
| What does the firm handle? | Practice area or legal offering | Service |
Real service scope, jurisdiction, office/provider relationship and substantive page content. |
| Who wrote or reviewed an article? | Author or reviewer | Article with a Person or Organization author |
Visible byline, profile link, review process and content accountability. |
| Where does the firm operate? | Office and/or service coverage | PostalAddress, areaServed, location relationships |
A real office where claimed, accurate service coverage and consistent public business information. |
A strong implementation forms one connected entity graph. The firm, office, attorney, service and article should refer to one another consistently instead of creating competing versions of the same identity.
2. Use LegalService for the Business; Do Not Model the Firm as an Attorney
Schema.org defines LegalService as a business that provides legally oriented services, advice or representation. It sits under LocalBusiness, which itself is both an organization and a place-oriented business concept. That makes LegalService a natural fit for a real law firm or physical legal office when the page describes that business.
Schema.org also currently marks the older Attorney type as deprecated and says LegalService is more inclusive and less ambiguous. That wording matters because the old type name encourages a conceptual mistake: an attorney is a person, while Attorney historically described a professional-service business. Individual lawyers should normally be represented with Person, not by attaching a deprecated business type to their bio pages.
A site may also carry broader Organization information on the homepage or About page. Google recommends using the most specific applicable organization subtype, especially when a site represents a local business. The goal is not to choose between “Organization” and “LegalService” as though only one can ever appear; it is to make sure the same real-world firm does not become two unrelated entities with different names, URLs, logos or contact information.
@id URL fragment and reuse that identifier whenever another entity refers back to the firm. A stable identifier helps the JSON-LD graph say “this attorney works for this exact firm” instead of creating a fresh anonymous organization object on every page.3. Separate the Firm Brand From Each Physical Office
Multi-office firms need more than one address array on a generic organization object. Each real office can have distinct address, telephone, hours, geographic coordinates, attorneys and services. When those differences matter to prospective clients, the site should make the office a visible entity with its own location page and corresponding structured data.
Google’s LocalBusiness documentation supports location-specific business facts such as address, telephone and opening hours. Schema.org also provides organization relationships such as parentOrganization and subOrganization. A multi-office firm can therefore model the overarching organization and location entities without pretending that every office is an unrelated company.
| Entity layer | Good use | Common mistake | Better relationship |
|---|---|---|---|
| Firm brand | Canonical name, legal name when appropriate, logo, primary URL and organization identity. | Repeating every office address and phone in one giant entity while location pages say something else. | Keep the firm identity stable and connect real offices as location/suborganization entities where appropriate. |
| Office | Unique street address, local phone, office hours, attorneys and services actually available there. | Marking a virtual office, mailbox or unstaffed lead-gen page as a full local office. | Only create office entities for places the visible site can honestly describe and users can understand. |
| Attorney | Person profile with role, firm relationship, admissions and current biography. | Embedding the same generic “attorney” object on every office page without saying where that lawyer practices. | Connect the Person to the firm and, when useful, explain office/service relationships in visible content. |
| Practice area | Service tied to the provider and the jurisdictions or areas actually served. | Creating hundreds of city + practice-area Service objects that merely restate keywords. | Use Service only where a substantive page and real offering exist. |
Location markup should also respect the difference between a physical office and an areaServed claim. Schema.org defines areaServed as the geographic area in which a service or offered item is provided, and it supersedes the older serviceArea property. A firm can serve a county without having an office in that county. The website and markup should not blur those two facts.
4. Attorney Bio Pages Need Person + ProfilePage, Not a Business-Type Shortcut
Google supports ProfilePage structured data and requires the page’s mainEntity to be a Person or Organization for that feature. On an attorney biography, the natural structure is a ProfilePage whose main entity is the lawyer as a Person.
The Person can carry basics such as name, jobTitle, url, worksFor, sameAs, and, when accurate, credential information. Schema.org’s worksFor property explicitly connects a Person to an Organization. Its hasCredential property can describe a credential awarded to a Person or Organization, while a Credential can identify the recognizing organization and geographic validity.
That does not mean every line in a lawyer’s résumé should become a credential object. A state-bar admission, board certification or other formal credential should be represented only when the page visibly states it and the firm has a process for keeping it current. Awards, memberships, speaking engagements and practice interests are different facts and should not be forced into hasCredential simply because the property sounds authoritative.
knowsAbout can describe topics associated with a Person, but it does not prove legal specialization. A page should not turn “handles estate planning matters” into “certified estate planning specialist” through schema unless that certification is real, allowed by applicable professional rules, and supported by the visible page.5. Connect Practice Areas With Service Instead of Stuffing Keywords Into the Firm Entity
Schema.org defines Service as a service provided by an organization or person. Useful properties include serviceType, provider and areaServed. For law firms, that creates a cleaner model than trying to make the firm’s business name, description or category carry every practice-area keyword.
A substantive personal-injury page, for example, can describe a legal service with the firm as its provider. A separate estate-planning page can describe a different service. If a service is available only in a certain jurisdiction or office, that limitation belongs in visible copy and can be reflected in the service relationship rather than hidden inside a generic sitewide schema block.
| Property or type | Useful law-firm use | What not to imply |
|---|---|---|
Service / serviceType |
Describe a real legal offering such as estate planning, criminal defense or business formation. | Do not create a Service solely because a keyword has search volume. |
provider |
Connect the service to the firm, office or qualified professional actually providing it. | Do not point every service to every office when the work is not actually handled there. |
areaServed |
Describe the geographic area where the service is genuinely offered. | Do not use dozens of cities as a substitute for meaningful location content or real service coverage. |
sameAs |
Link an entity to authoritative pages that represent that same entity. | Do not use it as a generic backlink list, citation dump or “authority” score. |
hasCredential |
Represent a real, visible credential connected to the lawyer or organization. | Do not convert ordinary memberships, awards or self-described expertise into formal credentials. |
6. Use sameAs and Stable @id Values for Identity, Not for Link Building
Two properties often carry too much SEO folklore: @id and sameAs. A stable @id is simply a useful way to identify an entity inside a linked-data graph. It can be a canonical URL with a fragment such as https://example.com/#lawfirm or https://example.com/attorneys/jane-doe/#person. Reusing the identifier allows multiple pages to refer to the same thing.
sameAs serves a different purpose. Google’s Organization documentation says the property can point to another website with additional information about the organization. For attorneys, an official state-bar profile, a genuinely controlled professional profile, or another page clearly representing the same person may be useful. A directory category, paid advertorial, unrelated award page or generic social feed is not automatically the “same entity.”
Law firms should audit these links like identity records. If an attorney leaves the firm, changes name, gains or loses an admission, or a public profile moves, the markup should not preserve stale relationships simply because an SEO plugin keeps emitting them.
7. Connect Legal Articles to Real Authors and Profiles
Legal content becomes easier to evaluate when the site identifies who wrote it or who is accountable for it. Google’s Article structured-data documentation recommends using Person or Organization for the author and linking a Person author to a URL that uniquely identifies that author. Google specifically notes that an internal author URL can be a profile page and recommends ProfilePage structured data for that profile.
For a law firm, that creates a useful chain: the legal guide is an Article; the author is a Person; the author URL points to the attorney bio; the bio’s ProfilePage has that Person as its mainEntity; and the Person’s worksFor points back to the firm. The markup reinforces the visible byline and biography instead of creating an anonymous “Attorney at Law” author that cannot be distinguished from anyone else.
The publisher remains a separate concept. Google advises keeping the author’s name in author.name and using the appropriate fields for job title or publisher. That prevents a common implementation error where the author string becomes “Jane Smith, Partner at Smith Law Group,” producing one text blob instead of a Person with structured relationships.
8. One Connected Graph Is Better Than Five Competing Schema Blocks
WordPress law-firm sites often contain several markup producers at once: the theme, an SEO plugin, a LocalBusiness plugin, a review widget, a page builder and custom code. The result can be duplicate organizations with different names, two addresses for one office, several logo URLs, or multiple Person objects for the same attorney.
The goal is not necessarily one physical <script> element. The goal is one coherent graph. Different blocks can coexist when they identify the same entities consistently, but each component should reuse stable identifiers and avoid redefining the same object with contradictory facts.
Validation proves that markup is parseable and policy-compliant; it does not guarantee a rich result, ranking, citation or recommendation.
9. Valid Schema, Google-Supported Schema and AI Visibility Are Three Different Things
Schema.org is a broad vocabulary. Google supports a smaller set of structured-data features and publishes requirements for specific appearances such as Organization, LocalBusiness, ProfilePage and Article. A property can be perfectly valid Schema.org without producing a visible Google feature.
Google’s general structured-data guidelines add another important boundary: markup must represent the page truthfully, describe visible content, remain relevant to the page and avoid misleading users. Google also says a valid implementation does not guarantee that a rich result will appear.
This distinction is especially important for law firms. Adding hasCredential can make an attorney relationship clearer to systems that understand the vocabulary, but Google does not advertise a special “bar-admission rich result” for law firms. Adding Service can express a practice-area relationship, but it does not create a guaranteed practice-area carousel. The markup still has value as structured entity information, but the firm should not sell or evaluate it as though every property maps to a Search feature.
10. Structured Data Is Not a Special Generative-AI Requirement
Google’s current generative AI Search guidance explicitly warns against overfocusing on structured data. Google says structured data is not required for its generative AI features and that there is no special Schema.org markup a site needs to add for AI Overviews or AI Mode. The same guidance says ordinary technical SEO, crawlability, indexability and useful content remain foundational.
That does not make schema irrelevant. It means the role is narrower and healthier: describe the firm, attorneys, offices, services and content accurately so search systems have consistent machine-readable clues. The real legal authority still comes from the underlying pages, professional records, outside corroboration and the quality of the legal information.
The same access principle applies to ChatGPT Search. OpenAI’s current crawler documentation says OAI-SearchBot controls whether pages can be surfaced in ChatGPT search features, while GPTBot is a separate control related to model training. A perfect JSON-LD graph cannot help a page in a search product that cannot crawl the page.
| Layer | What it can accomplish | What it cannot guarantee | Primary audit |
|---|---|---|---|
| Visible page | Explain the firm, attorney, office and legal service to people. | That every search system will select or cite it. | Accuracy, usefulness, jurisdiction, professional review. |
| Schema.org graph | Express entities and relationships in a standardized vocabulary. | A Google feature or an AI recommendation. | Correct type, properties, @id relationships, visible support. |
| Google-supported structured data | Help qualify pages for supported Search appearances and understanding. | That a supported rich result will actually display. | Rich Results Test, Search Console, feature-specific guidelines. |
| Crawler access | Allow search/retrieval systems to fetch the content. | Indexing, ranking or citation. | robots.txt, noindex, canonical, HTTP response, URL inspection. |
| Outside corroboration | Help verify firm and attorney facts beyond the website. | That every third-party profile is accurate or current. | Bar records, official profiles, Business Profiles and trusted directories. |
11. A 90-Day Law-Firm Schema Implementation Plan
Days 1–30: inventory the entities before touching the code. List the firm’s canonical name, legal name if used publicly, website, logo, phone, real offices, office hours, attorneys, practice areas, jurisdictions, author profiles and authoritative identity URLs. Identify duplicates across themes and plugins. Confirm which office and attorney facts are visible and which need content repairs before they can be marked up.
Days 31–60: build the connected graph. Assign stable @id values to the firm, each office and each attorney. Use LegalService where it accurately represents the law-firm business, Person for attorneys, ProfilePage for their bio pages and Service for substantive practice-area pages. Connect authors to articles and attorneys to the firm instead of recreating anonymous objects on every URL.
Days 61–90: validate, crawl and monitor. Test Google-supported features with the Rich Results Test, inspect representative URLs in Search Console and validate broader Schema.org vocabulary with the Schema.org validator. Remove contradictory blocks and stale relationships. Then monitor whether Google sees the intended canonical URLs, whether Business Profile and public attorney facts remain consistent, and whether AI/search answers describe the firm and attorneys accurately.
Key Takeaways
- Use the right entity for the right thing. The law firm or office can be a LegalService; an individual lawyer should be a Person.
- Treat Attorney as deprecated schema. Schema.org currently recommends LegalService instead of the old Attorney business type.
- Connect the graph. Reuse stable @id values so attorneys, offices, services and articles point back to the same firm entities.
- Do not manufacture proof in JSON-LD. Admissions, offices, specialization and services must be supported by visible, current facts.
- Keep expectations realistic. Structured data can improve clarity and eligibility, but Google says no special schema is required for generative AI search and no markup guarantees visibility.
Frequently Asked Questions
Should a law firm use LegalService or Organization schema?
LegalService is the more specific Schema.org type for a business that provides legal services and is a subtype of LocalBusiness. Broader Organization data can still describe the overarching firm, especially when the site has multiple offices. The important part is to keep one coherent identity and avoid creating contradictory firm objects.
Should attorney bio pages use the Attorney schema type?
No. Schema.org currently marks Attorney as deprecated in favor of LegalService, and that deprecated type describes a professional-service business rather than an individual lawyer. Model the lawyer as a Person; on a dedicated attorney biography, a ProfilePage can use that Person as its mainEntity.
Can schema prove that an attorney is licensed or certified?
No. Schema can describe a visible credential or relationship, but the markup itself is not proof. Bar admission, board certification and similar claims should remain accurate on the page and should be verifiable through the appropriate authority. Do not turn ordinary memberships or marketing language into formal credentials.
Does law-firm schema improve ChatGPT or Google AI rankings?
There is no guaranteed AI ranking benefit. Google says structured data is not required for its generative AI Search features and there is no special AI schema. Accurate structured data can still reduce ambiguity about firms, attorneys, offices and services, while crawl access, indexability, useful content and outside corroboration remain essential.
Law-firm schema is most valuable when it acts like a clean map of reality. The firm has one identity, each office has its own facts, each attorney is a real Person connected to the firm, and each practice area is a genuine Service supported by substantive content. When that graph matches what clients can see and what outside authorities can verify, structured data becomes useful infrastructure instead of another layer of SEO decoration.