Law Firm Schema Markup: What to Add Beyond the Basic Listing

Law firm schema markup should describe more than a firm’s name, address, phone number, and website.

A well-structured implementation can explain the relationships between the law firm, its attorneys, legal services, offices, service areas, website, individual pages, and published content. The goal is not to add the largest possible JSON-LD block. The goal is to represent the real business accurately and make those relationships explicit.

For most law firm websites, that means looking beyond a basic business listing and considering LegalService, Person, Service, location entities, WebSite, WebPage, Article or BlogPosting, and BreadcrumbList where those types genuinely match the visible content.

Schema.org currently defines LegalService as a business that provides legally oriented services and places it within the LocalBusiness and Organization hierarchy. Schema.org also currently marks the older Attorney type as deprecated, making Person a more appropriate type for representing individual lawyers when the page is about a person.

The important distinction is that Schema.org and Google Search are not the same thing. Schema.org provides a vocabulary for describing entities and relationships. Google separately documents which structured-data implementations can support Search features. Correct structured data does not guarantee rankings, rich results, or inclusion in AI features.

What Is Law Firm Schema Markup?

Law firm schema markup is structured data that describes a law firm’s real-world entities and relationships using the Schema.org vocabulary, usually in JSON-LD format.

At a basic level, a law firm website may contain these entities:

Law firm → provides → legal services
Attorney → works for → law firm
Service → areaServed → jurisdiction
Law firm → has location → office
WebPage → describes → service
Article → author → Person
Website → publisher → law firm

This structure is more informative than a disconnected collection of business fields.

For example, imagine a firm with three attorneys, four practice areas, and two offices. A single organization block may identify the company, but it does not fully explain who works there, what each lawyer does, which services are offered, where those services are available, or how the individual website pages relate to those entities.

That is where entity relationships become useful.

Why a Basic Law Firm Listing Is Not Enough

A minimal business schema might contain:

name
url
logo
telephone
address

Those properties can be important, but they describe only part of the business.

A more useful entity model can connect:

Law Firm
   ↓ provides
Legal Services
   ↓ served in
Locations / Jurisdictions

Attorneys
   ↓ worksFor
Law Firm

Practice Area Page
   ↓ mainEntity
Service

Article
   ↓ author
Person

The value is in the relationships.

A search system does not need a huge amount of JSON-LD simply for the sake of completeness. It needs accurate information that corresponds with the page and can be interpreted consistently.

Google’s structured-data guidelines specifically require structured data to be representative of the visible page content. Google also warns against misleading or irrelevant markup.

Which Schema Types Should a Law Firm Consider?

There is no universal schema stack that every law firm should copy.

The right implementation depends on the firm’s actual website, organization, number of locations, attorney pages, practice areas, and published content.

Schema.org’s Service type supports relationships such as provider and areaServed, while areaServed can identify the geographic territory where a service or offering is provided.

LegalService for the Firm

LegalService is the logical Schema.org type to consider when the entity being described is a law firm or legal practice.

A simplified example could look like:

{
  "@context": "https://schema.org",
  "@type": "LegalService",
  "@id": "https://example.com/#law-firm",
  "name": "Example Law Firm",
  "url": "https://example.com/",
  "telephone": "+1-000-000-0000",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "123 Main Street",
    "addressLocality": "Austin",
    "addressRegion": "TX",
    "postalCode": "00000",
    "addressCountry": "US"
  }
}

The values are placeholders. Real implementations should contain only facts supported by the website and the firm’s actual business information.

Do not add a city to the business name simply because the keyword is attractive. Do not invent opening hours, service areas, ratings, or office locations.

Person for Individual Attorneys

For an individual lawyer page, Person is generally a clearer entity type than treating the lawyer as the business itself.

Schema.org’s Person vocabulary supports properties such as jobTitle, worksFor, hasCredential, alumniOf, workLocation, and other person-related attributes.

A simplified relationship might be:

{
  "@type": "Person",
  "@id": "https://example.com/attorneys/jane-smith/#person",
  "name": "Jane Smith",
  "jobTitle": "Partner",
  "url": "https://example.com/attorneys/jane-smith/",
  "worksFor": {
    "@id": "https://example.com/#law-firm"
  }
}

This tells the system that Jane Smith is a person represented on the website and that she works for the same firm entity identified elsewhere.

That relationship is more useful than creating a completely separate description of the law firm on every attorney page.

What Happened to Attorney Schema?

Older law firm schema tutorials often recommend the Attorney type.

That advice is now outdated.

Schema.org currently marks Attorney as deprecated and describes LegalService as a more inclusive alternative. New implementations should therefore use current types that accurately represent the entity rather than copying older templates indefinitely.

For individual lawyers, Person is useful because the page is about an individual human being. The firm’s business entity can then be referenced through worksFor.

Service Schema for Practice Areas

A law firm’s practice areas are not the same thing as the firm itself.

Consider:

• Personal injury
• Family law
• Criminal defense
• Business law
• Immigration law
• Estate planning

These can be represented as service entities when the website has dedicated pages that genuinely describe those services.

A simplified example:

{
  "@context": "https://schema.org",
  "@type": "Service",
  "@id": "https://example.com/personal-injury-law/#service",
  "name": "Personal Injury Law",
  "serviceType": "Personal Injury Law",
  "provider": {
    "@id": "https://example.com/#law-firm"
  },
  "areaServed": {
    "@type": "City",
    "name": "Austin"
  },
  "url": "https://example.com/personal-injury-law/"
}

The important field here is not just name. The relationship tells us which business provides the service and where that service is offered.

Schema.org defines Service as a service provided by an organization, and its areaServed property is intended to describe where that service is provided.

Location and Service Area Are Not the Same Thing

This distinction causes frequent schema problems.

A physical office is a location.

A service area describes where the firm provides a service.

A firm could have:

Office:
Dallas, Texas

while its legal services cover:

Dallas County
Tarrant County
Collin County

Those are different relationships.

Place is available for geographic descriptions, while areaServed is used for the geographic area in which a service or offering is provided.

Do not create a fake office simply because the firm serves clients in that city.

Likewise, do not list every nearby location as a service area simply because those city names generate search demand.

The structured data should reflect the firm’s actual operations.

Connect the Firm With the Website

A law firm and its website are different entities.

The law firm is a real-world organization.

The website is the digital property representing it.

That distinction can be represented conceptually as:

LegalService
    ↓
WebSite
    ↓
WebPage
    ↓
Service / Person / Article

The use of stable @id values can make these relationships easier to express.

For example:

{
  "@id": "https://example.com/#law-firm"
}

can be referenced from an attorney page:

{
  "worksFor": {
    "@id": "https://example.com/#law-firm"
  }
}

and from a service:

{
  "provider": {
    "@id": "https://example.com/#law-firm"
  }
}

This is not a ranking trick. It is an entity-modeling technique that makes the intended relationships explicit.

WebPage Schema for Practice-Area and Attorney Pages

Every important URL has a page-level identity.

A practice-area page can describe the legal service.

An attorney page can describe the attorney.

A contact page can describe the firm’s contact information.

An educational article can describe an article and its author.

That means you should resist the temptation to paste one giant business block into every URL regardless of the page’s purpose.

A better approach is page-specific.

The exact combination should follow what the page actually contains.

Google’s general guidelines emphasize that structured data should accurately represent the primary content of the page.

BreadcrumbList Helps Describe the Site Hierarchy

A law firm website can become complicated quickly.

A visitor might move through:

Home
→ Practice Areas
→ Personal Injury

or:

Home
→ Attorneys
→ Jane Smith

BreadcrumbList can describe that hierarchy when breadcrumbs are visible on the page.

Google supports breadcrumb structured data and explains that it can help Search understand a page’s position within the site hierarchy.

The key rule is simple: the schema should correspond to the actual breadcrumb trail.

Do not create breadcrumb markup that does not match the visible navigation.

Article Schema for Legal Guides and Blog Content

Law firms often publish content answering questions such as:

• How long do personal injury claims take?
• What should I do after a car accident?
• How does a divorce work?
• What is the difference between a will and a trust?
• When should I speak with a lawyer?

Those pages can be represented as Article or BlogPosting content when appropriate.

The article entity can connect to its author:

Article
   ↓ author
Person

and to the publishing organization:

Article
   ↓ publisher
Organization

This is particularly useful when an attorney is a real author and the page clearly identifies that attorney.

Do not create fictional authors to make a page look more authoritative.

The visible author information and the structured data should describe the same person.

How Law Firm Schema Supports Local SEO

Structured data should support local SEO, not attempt to manufacture local relevance.

For a law firm with a legitimate office, the website, business information, location information, and structured data should tell a consistent story.

For example:

Law Firm
   ↓
Office
   ↓
City / Region
   ↓
Practice Areas
   ↓
Service Areas

That structure complements broader local SEO work.

It does not replace:

• Google Business Profile management
• Relevant service pages
• Local content
• Business information consistency
• Internal linking
• Reviews and reputation management
• Technical accessibility
• Strong local relevance

Google’s Local Business documentation explains that structured data can communicate business details such as hours and other information, but Google’s general structured-data guidelines make clear that correct markup does not guarantee a particular Search appearance.

For broader local visibility work, see Local SEO Service and Google Business Profile Optimization.

Schema Markup and AI Search

Law firms are increasingly interested in AI Overviews, AI Mode, answer engines, and generative search.

There is an important misconception to avoid.

Google says there are no additional technical requirements or special schema.org markup required specifically for AI Overviews or AI Mode. Google recommends the same foundational SEO practices that apply to normal Search, including crawlability, internal linking, useful textual content, and structured data that matches visible content.

That means a law firm should not search for a fictional “AI schema” that guarantees citations.

A better model is:

Useful Content
+
Clear Entities
+
Clear Relationships
+
Technical Accessibility
+
Consistent Business Information

This is where structured data can become useful as part of a larger search strategy.

For related work, see AEO and GEO Consulting.

What Schema Markup Does Not Do

Schema should not be treated as a shortcut to higher rankings.

Google explicitly says structured data can help systems understand page content and can enable eligibility for certain search features, but Google does not guarantee that a feature will appear even when structured data is implemented correctly.

So avoid claims such as:

“Add this schema and rank number one.”

or:

“This schema guarantees AI citations.”

Those claims are not supported by Google’s current documentation.

Structured data is better understood as a communication layer between the content and systems that need to interpret it.

Common Law Firm Schema Mistakes

1. Using Deprecated Attorney as the Main Business Type

Do not build a new implementation around outdated Attorney examples. Schema.org currently marks the type deprecated.

2. Putting Every Schema Type on Every Page

A practice-area page does not need to pretend it is simultaneously an attorney profile, office page, review page, and company homepage.

Use the entities that genuinely apply to the URL.

3. Creating Fake Locations

Serving clients in a city does not automatically mean the law firm has an office there.

4. Adding Fake Service Areas

Do not create location pages or service-area markup solely to capture search volume.

5. Inventing Reviews or Ratings

Only represent genuine ratings or reviews that are eligible and supported by the site content and applicable policies.

6. Creating Fictional Attorneys

A structured-data profile should represent a real person described by the website.

7. Adding Unsupported Prices

Do not insert an artificial price because a schema property exists.

8. Using Schema Instead of Better Content

Structured data cannot make an unhelpful practice-area page useful.

A strong legal service page should still explain the service, the client problem, the process, relevant locations, attorney information, and appropriate next steps.

9. Creating Duplicate Firm Entities

A common implementation problem is describing the same law firm separately on multiple pages without a consistent entity relationship.

Shared identifiers such as @id can help different nodes reference the same firm.

10. Ignoring Plugin and Theme Conflicts

WordPress websites can generate structured data from multiple sources.

An SEO plugin, theme, custom JSON-LD, and another schema plugin may all describe the same organization.

The result can be duplicate or conflicting markup.

For technical implementation work, see Technical SEO Service and WordPress SEO Service.

How to Validate Law Firm Schema Markup

A good implementation process is more than checking whether the JSON is syntactically valid.

Step 1: Check the Schema.org Vocabulary

Confirm that the selected types and properties actually exist and are being used appropriately.

Step 2: Validate the Structured Data

Use Google’s Rich Results Test where the relevant Search feature is supported, and use Schema.org’s own validation resources for broader vocabulary validation.

Google recommends validating structured data before deployment and then inspecting the live URL.

Step 3: Compare It With Visible Content

Check that these elements agree:

• Firm name
• URL
• Telephone
• Address
• Office details
• Attorney names
• Job titles
• Services
• Service areas
• Author information
• External profiles

Step 4: Test Entity Relationships

Ask:

Does each attorney point to the correct firm?

Does each service identify the correct provider?

Does each location represent a real office?

Do page URLs match the real URLs?

Are shared @id values used consistently?

Step 5: Inspect the Live URL

Google recommends using URL Inspection after deployment to understand how Google sees the page. The page should be accessible and should not be blocked by robots.txt, noindex, or access controls.

Step 6: Recheck After Business Changes

Schema can become inaccurate when a firm:

• Changes offices
• Adds or removes attorneys
• Changes its telephone number
• Adds new practice areas
• Changes branding
• Updates service areas

A schema block can still pass a syntax test while describing an outdated business.

A Practical Schema Architecture for a Law Firm Website

A useful conceptual model looks like this:

                 ┌───────────────┐
                 │   WebSite     │
                 └───────┬───────┘
                         │
                      represents
                         │
                 ┌───────▼───────┐
                 │  LegalService │
                 └───┬────┬──────┘
                     │    │
             worksFor│    │provides
                     │    │
              ┌──────▼┐  ┌▼────────┐
              │ Person │  │ Service │
              └────────┘  └────┬────┘
                                │
                            areaServed
                                │
                         ┌──────▼──────┐
                         │   Location  │
                         └─────────────┘

WebPage → describes → Service / Person / Firm
Article  → author    → Person
BreadcrumbList → describes → Page hierarchy

This model is useful because it starts with real entities rather than a list of SEO fields.

How Internal Linking and Schema Should Work Together

Structured data and internal linking solve different problems, but they can reinforce the same website architecture.

Imagine a law firm article about personal injury compensation.

That article can naturally link to:

• The personal injury practice-area page
• The relevant attorney profile
• The firm’s contact page
• A location page
• Related legal guides

The structured data can then express relationships such as:

Article → author → Attorney
Article → about → Legal Service
Service → provider → Law Firm
Service → areaServed → Location

This creates a consistent information architecture for users and search systems.

For the technical side of on-page structure, see On-Page SEO Service and SEO Audit Service.

A well-planned Keyword Research Service can also help map practice areas, supporting topics, locations, and questions before the content structure is finalized.

A Law Firm Schema Checklist

Before publishing, review the implementation against this checklist.

Firm identity

• Correct legal business name
• Correct LegalService or appropriate organization representation
• Canonical website URL
• Real telephone number
• Real logo
• Genuine business image where applicable
• Accurate external profile references
• Consistent @id

Attorneys

• Real attorney names
• Accurate job titles
• Correct profile URLs
• Appropriate Person markup
• worksFor relationship where applicable
• Genuine credentials and education information
• No fictional people

Services

• Real practice areas
• Accurate service names
• Correct service URLs
• provider relationship
• Appropriate areaServed
• No invented services

Locations

• Real office addresses
• Correct geographic information
• Accurate coordinates if used
• Correct relationship between office and firm
• Service areas represented separately from physical offices

Website and pages

• Correct WebSite
• Appropriate WebPage
• Accurate Article or BlogPosting where applicable
• Breadcrumb markup that matches visible navigation
• Consistent canonical URLs

Quality control

• No fake reviews
• No fake ratings
• No fake locations
• No fake authors
• No misleading service areas
• No unsupported prices
• No duplicate conflicting JSON-LD
• Structured data matches visible content
• Validation completed
• Live URL inspected

Frequently Asked Questions About Law Firm Schema Markup

What schema should a law firm use?

A law firm can consider LegalService for the firm, Person for individual attorneys, Service for practice areas, appropriate location entities for offices, WebSite and WebPage for digital properties and pages, Article or BlogPosting for articles, and BreadcrumbList for visible breadcrumb navigation. The exact combination depends on what the website actually contains.

Should a law firm use Attorney schema?

New implementations should not use the deprecated Attorney type as the foundation. Schema.org currently marks Attorney as deprecated. LegalService is appropriate for the legal service business, while Person can represent individual attorneys and their relationships with the firm.

Does law firm schema markup improve rankings?

Schema markup can help search systems understand page content and may make a page eligible for supported search features, but it does not guarantee higher rankings. Google explicitly states that correctly implemented structured data does not guarantee a rich result or any particular search appearance.

Can schema help a law firm appear in AI Overviews?

There is no special AI Overview schema that guarantees inclusion. Google says there are no additional technical requirements or special structured-data requirements for AI Overviews or AI Mode. Foundational SEO, useful content, crawlability, internal links, and accurate structured data remain relevant.

Should every practice area have Service schema?

A practice-area page can use Service when the page genuinely describes a service offered by the firm. There is no benefit in creating artificial service entities for topics that are not real services.

Should a law firm add every city it serves to schema?

Only where that information accurately represents the firm’s actual service coverage. A service area is not the same thing as a physical office.

Does FAQ schema matter for a law firm?

Visible FAQs can still be useful for clients because they answer real questions quickly. However, Google removed the FAQ rich-result feature for most sites starting May 7, 2026, so law firms should not create FAQs purely to chase that search enhancement.

How often should law firm schema be reviewed?

Review it whenever important business information changes, including attorneys, offices, phone numbers, services, URLs, branding, or service areas. A periodic technical SEO review is also useful for detecting duplicate or outdated markup.

The Better Way to Think About Law Firm Schema

The question is not:

“Which schema fields can I add?”

The more useful question is:

“Which real-world entities exist on this website, and how are they related?”

A typical law firm website may contain:

Firm
The organization providing legal services.

Attorneys
The people who work for the firm.

Services
The practice areas the firm actually offers.

Locations
Physical offices and legitimate service areas.

Website
The firm’s digital property.

Webpages
Pages describing the firm, attorneys, services, and locations.

Articles
Educational material authored by identifiable people.

Once those entities are clear, structured data becomes a way to express the model.

That approach is more durable than copying a large schema template from an outdated tutorial.

The strongest implementation is usually the one where the firm’s visible content, business information, internal links, website architecture, external profiles, and structured data all describe the same underlying reality.

For businesses that need the surrounding technical foundation, Content Strategy & SEO Content Writing, SEO-Friendly Web Design, and Website Speed Optimization can support the wider system around structured data.

Work With Md Mynul Hassan

I help businesses connect technical SEO, structured data, content architecture, Local SEO, AEO, GEO, and website optimization rather than treating each task as an isolated SEO tactic.

You can learn more through my Local SEO Service, AEO and GEO Consulting, Technical SEO Service, and SEO Audit Service.

For agencies that need additional delivery capacity, see White Label Local SEO Services.

You can also find my professional profiles and marketplace services here:

Upwork
Freelancer.com
LinkedIn
YouTube
Facebook

The goal is not to add more markup simply because it exists. The goal is to make the website’s entities, relationships, content, and business information easier to understand while keeping every claim grounded in reality.