LegalService vs Attorney vs LocalBusiness schema

Use LegalService as your primary schema type, nest LocalBusiness properties inside it, and skip Attorney. That's the whole answer, and it trips up firms because all three types look like they describe a law practice. They do. They're just not equal, and one of them is quietly deprecated. Here's how the three relate and what to actually put on your site.

What's the difference between these three schema types?

They sit in a hierarchy. LocalBusiness is the broad type for any business with a physical location. LegalService is a more specific type that extends LocalBusiness, meaning it inherits all the location properties and adds legal-specific ones. Attorney was an older, narrower type that has since been folded into LegalService and is no longer the one to reach for.

Schema.org, the vocabulary all of this runs on, is built as a tree of types that get more specific as you go down. A restaurant and a law firm are both LocalBusiness, but that's a weak description of either. The point of picking a more specific type is to tell an engine precisely what you are, in a vocabulary it already understands. For a law firm, the specific type that exists for exactly this purpose is LegalService, defined by schema.org as a business that provides legally-oriented services, advice, and representation. That's your firm.

Why not just use LocalBusiness?

Because generic LocalBusiness sends the same signal as a coffee shop or a dry cleaner. It tells an engine you're a business with an address and hours, and nothing about the fact that you practice law. You lose the whole benefit of the specific legal vocabulary, and you describe your firm in the vaguest terms the schema offers.

LocalBusiness isn't wrong, it's just incomplete on its own. Its properties (name, address, phone, opening hours, geo-coordinates) are exactly what you need for your firm's location and NAP consistency, and you should absolutely include them. The mistake is stopping there, using bare LocalBusiness as your type when a more precise one exists. It's the schema equivalent of setting your Google Business Profile category to "Business" instead of "Family Law Attorney." Technically true, strategically pointless.

Isn't Attorney the obvious type to use?

It looks obvious and it's the wrong pick. The Attorney type is deprecated for Google's rich results, which means you shouldn't use Attorney markup to target enhanced search features. Its role has effectively been absorbed into LegalService, so marking your firm up as Attorney targets a type that's on its way out instead of the one that's current.

This is the kind of detail that makes schema feel like a trap, and it's a fair complaint. The vocabulary evolves, types get deprecated, and guides written three years ago still recommend Attorney with confidence. The current, safe choice is LegalService as your firm's type. If you want the type for an individual lawyer as a person, that's the separate Person type on each attorney's bio, which is a different job from typing the firm itself. Attorney sits awkwardly between the two and is best left alone.

So what should a law firm actually implement?

LegalService as the primary type for your firm, carrying the LocalBusiness properties (address, phone, hours) inside it, plus a few supporting types for the rest of the site. Put the firm markup on your homepage and contact page where your location lives, and use LegalService on each practice-area page to say what legal work you do there.

The practical set, page by page. On your homepage and contact page, LegalService with full NAP so your location and identity are unambiguous. On each practice-area page, LegalService describing that specific service. On each attorney bio, Person markup with their credentials and a link to the firm. Where you have a real FAQ section, FAQPage, which we cover in how to write a law firm FAQ page that gets cited. And Organization plus BreadcrumbList to tie the site together. That's the full stack, and it's laid out end to end in the seven schema types every law firm website needs. You don't invent any of this. You pick the right type and fill in true information.

How do the three actually nest and combine?

You don't stack them as three separate blocks. You pick LegalService as the type and fill in the properties it inherited from LocalBusiness. Because LegalService is a descendant of LocalBusiness in the schema.org tree, every LocalBusiness property is already valid on a LegalService node. So address, telephone, openingHoursSpecification, geo, and priceRange all belong directly on your LegalService, no second type required. That's the "nesting" people mean, and it's simpler than it sounds: one type, inheriting one parent's fields.

The real nesting is between nodes, not types. Your firm is one node, each lawyer is a Person node, and you tie them together with references rather than by burying one type inside another. Give the firm an @id, then point each attorney's worksFor at that id, and point the firm's employee or founder back at the people. Now an engine can see that these bios belong to this firm, which is the relationship you actually want it to understand. Combining types on a single node with an array (say, marking one node as both LegalService and Attorney) is technically valid JSON-LD, but it buys you nothing here and muddies the signal. One node, one clear type.

Illustrative example only — placeholder firm, not a real one. This is roughly what a firm's homepage node looks like, LegalService carrying its inherited LocalBusiness properties and linking one attorney:

{
  "@context": "https://schema.org",
  "@type": "LegalService",
  "@id": "https://example-firm.com/#firm",
  "name": "Example Family Law",
  "url": "https://example-firm.com/",
  "telephone": "+1-555-0100",
  "priceRange": "$$",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "123 Main St",
    "addressLocality": "Austin",
    "addressRegion": "TX",
    "postalCode": "78701",
    "addressCountry": "US"
  },
  "geo": {
    "@type": "GeoCoordinates",
    "latitude": 30.2672,
    "longitude": -97.7431
  },
  "openingHoursSpecification": {
    "@type": "OpeningHoursSpecification",
    "dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday"],
    "opens": "09:00",
    "closes": "17:00"
  },
  "areaServed": { "@type": "City", "name": "Austin" },
  "employee": {
    "@type": "Person",
    "name": "Jane Roe",
    "jobTitle": "Partner",
    "worksFor": { "@id": "https://example-firm.com/#firm" }
  }
}

Nothing there is exotic. Every property is a real schema.org field on the type it's attached to, and the whole point of the @id is that other nodes on the site (an attorney bio, a practice-area page) can reference the same firm without redefining it.

Which properties actually matter for each type?

Fill in the true ones, skip the rest. For the firm as LegalService, the properties that earn their keep are name, url, address, telephone, openingHoursSpecification, geo, areaServed, priceRange, and sameAs pointing at your real profiles. If you have practice areas you want to enumerate, makesOffer or hasOfferCatalog is the honest way to list services rather than stuffing keywords. On the identity side, image, logo, and founder round it out.

For each attorney as Person, the useful fields are name, jobTitle, worksFor, knowsAbout for their practice focus, alumniOf for their law school, and hasCredential for a bar admission or certification. Use sameAs to link a verified profile if you have one. Every one of these is a genuine schema.org property, and every one should be filled from fact, not aspiration. If a firm doesn't have a rating you can substantiate, you leave aggregateRating off entirely rather than inventing one, the same discipline we apply everywhere.

A simple way to decide which type goes where

Ask what the page is about, then match the node to it. If the page is the firm, its home or contact, the node is LegalService with full NAP. If the page is a service you offer, it's LegalService describing that specific work. If the page is a human, an attorney bio, the node is Person linked back to the firm. If the page is a question-and-answer block that genuinely exists on the page, add FAQPage on top. And Organization plus BreadcrumbList sit across the whole site regardless of the page. That's the entire decision. You're never really choosing between LegalService, Attorney, and LocalBusiness, because the answer to that is fixed: LegalService for the firm, its inherited LocalBusiness fields for the location, and Attorney not at all.

Common mistakes that quietly break it

Most schema problems aren't exotic, they're a handful of the same errors. Using bare LocalBusiness when LegalService exists, so you describe a law firm as generically as a laundromat. Reaching for the deprecated Attorney type because an old guide said to. Marking the whole firm up as Person, which types your practice as a human being. Contradicting your own site by listing an address or phone in schema that doesn't match the visible page or your Google Business Profile, since NAP consistency only helps when every source agrees. Padding makesOffer with services you don't provide, or inventing a rating, both of which are the kind of thing that gets markup ignored or worse. And the quiet one covered below: valid markup that never actually renders in the HTML.

None of these is hard to avoid once you know the shape of them. Pick LegalService, fill it from fact, link the people to the firm, and keep the schema honest against what's on the page. Good technical SEO is mostly this kind of unglamorous correctness, done once and left alone.

Does any of this get you cited or ranked?

No, and it's worth being blunt about it. Schema is hygiene and rich-result eligibility, not a lever that makes an engine rank or cite you. It makes your pages legible to machines and eligible for enhanced results. What earns the ranking or the citation is the content underneath the markup being genuinely the best answer to the question. Anyone selling schema as the secret to getting cited is selling you the easy part.

Getting the type right still matters, because malformed or missing markup can cost you rich-result eligibility and makes your pages harder for engines to parse cleanly. It's the floor, not the ceiling. A firm with perfect LegalService markup and thin, generic content won't get cited, and a firm with strong content and no markup is leaving legibility on the table. Do both. The markup is a morning's work done once; the content is the ongoing job. This is the same reason a site built on a locked-down platform struggles, because it often can't deploy custom schema at all, which we get into in why website builders hurt law firm AI search.

How do you check you got it right?

Generate it, validate it, then confirm an engine can actually read your page. Our law firm schema generator builds valid LegalService markup from your firm's details, Google's Rich Results Test confirms it parses, and a crawler's-eye view shows whether the schema is even present in the HTML an engine receives. Do all three before you consider it done.

That last check catches the most common failure, which isn't wrong markup but absent markup: the schema exists in your CMS preview but never renders in the actual HTML a crawler sees, usually because a plugin or builder injects it in a way engines don't read. Validate the code, then verify it's really on the page. Once it is, leave it alone; schema isn't something you tend weekly. If you'd rather have it audited and fixed as part of a proper once-over, the free audit includes a schema check, and every site we build ships with the full set correct from launch.