LegalService and Attorney Schema: Structuring Your Firm for AI Citation

LegalService is a LocalBusiness subtype in schema.org that represents a specific legal service offered by a firm, often tied to a geography or practice area. When you declare a LegalService entity, you are telling AI search engines: "This firm offers this specific service (e.g., medical malpractice defense) in this location (e.g., San Francisco)." LegalService is not the same as Organization; an Organization is the firm itself (its name, addresses, phone number). A LegalService is one service that firm provides.

Think of it this way: your firm's Organization node is the umbrella. Your LegalService nodes are the specific offerings under that umbrella. If your firm has three offices and handles five practice areas, you might have 15 LegalService nodes (5 practice areas × 3 offices). Each one is a distinct entity with its own address, telephone, and areaServed. This specificity is what makes AI search engines able to match user queries to your firm.

Concretely, when someone asks ChatGPT or Gemini "Who handles family law in Los Angeles?", the AI engine is searching for LegalService entities where (a) the practice area matches "family law", (b) the areaServed includes "Los Angeles", and (c) the provider (firm Organization) has a strong reputation (measured by links, reviews, and entity consistency across the web). If your firm has a LegalService node with the right properties, you become a candidate for citation. If you only have a generic Organization node with no LegalService children, you are invisible to this query path.

One critical rule: declare your Organization node exactly once on your site (typically in the footer or root layout schema), then reference it by @id from every LegalService and Attorney node. Do NOT re-declare a full Organization node on every page with slightly different properties. A re-declaration creates a duplicate entity in Google's Knowledge Graph and fragments your firm's identity across the web. The whole point of schema.org is to tell AI engines "this LegalService belongs to this one firm, which also handles these other services and has these offices and these attorneys." Re-declarations break that story.

An Attorney is represented as a Person entity in schema.org — not a separate Attorney type. A Person node carries a lawyer's name, credentials, bar admission, photo, and a worksFor property that points back to the firm Organization by shared @id. This is how AI search engines learn that Jane Smith is an attorney at Acme Law Firm and she is licensed in California.

Person nodes are critical for E-E-A-T (Expertise, Authoritativeness, Trustworthiness) signals that AI models value. When you mark up an attorney as the author of a practice-area guide, or list an attorney's bar admission and years of experience, AI engines use this metadata to answer queries like "medical malpractice attorney in San Francisco with 20+ years experience." The Person node is your direct channel to AI visibility for individual practitioners.

A complete Person (Attorney) node includes: name; photo (image URL); worksFor (reference to Organization @id); barAdmission (state, year); hasCredential (any specialty certifications, board certifications); alumniOf (law school, university); jobTitle (e.g., "Partner", "Of Counsel"); sameAs (LinkedIn profile, bar directory, Avvo profile, Justia profile, Wikidata Q-ID if applicable); and optionally a URL to the attorney's profile page on your site.

Critically, sameAs links are how AI engines disambiguate individuals and connect signals across the web. If your Person node on your website has sameAs pointing to an attorney's LinkedIn profile, bar directory listing, and Avvo page, and those external profiles all say the same name and bar license, the AI model learns that Jane Smith is one real person with consistent credentials across platforms. This significantly boosts her authority and the firm's authority for queries tied to her expertise. Conversely, if you do not provide sameAs links and your Person profile is isolated on your site, the model has less reason to trust the profile — it could be fabricated.

LegalService and Person (Attorney) are separate but related entities. LegalService is about service offerings (what the firm does, where it does it). Person is about individual practitioners (who they are, what they specialize in). The relationship between them is not formally defined in schema.org — there is no "attorney" property on LegalService — but best practice is to wire them semantically via shared practice-area naming and location. Here is how it works in practice.

When you have a LegalService for "Medical Malpractice Defense in San Francisco," you should list the attorneys who specialize in that practice area on that LegalService's page (or mention them in the page HTML that the LegalService markup describes). Then, in your attorney directory or bio page, each Attorney node should clearly state their bar admission, their practice areas, and their office locations. The AI model learns through repeated co-occurrence: "Jane Smith handles medical malpractice," "the firm's medical malpractice service is in San Francisco," "Jane Smith works in San Francisco" → the model infers that Jane likely handles the firm's med mal work.

This co-occurrence signal is reinforced if the LegalService page and the attorney bio page both appear in AI search results for related queries. The model notices they are semantically aligned (same practice area, same location, same firm) and treats the firm's authority for that service as higher. In contrast, if you have a LegalService with no attorney names mentioned, and attorney pages with no practice-area specificity, the model has no signal that they are related. The semantic graph is fragmented.

For multi-office firms, the key rule is: each office should have its own LegalService nodes per practice area. If you have a San Francisco and Los Angeles office, and both handle medical malpractice, create two separate LegalService entities: one with areaServed="San Francisco" and address="SF office", another with areaServed="Los Angeles" and address="LA office". Then, in the attorney section of each office's page, list the attorneys licensed in that state who work there. This gives AI models the geographic specificity they need to match local queries.

A multi-office firm's schema architecture follows a hub-and-spoke pattern: one Organization at the center, one LegalService per (practice area × location) pair, one Person per attorney. The Organization node declares the firm's main address (often the headquarters), phone number, and metadata like sameAs (GBP profile, LinkedIn, Avvo). Every other LegalService and Attorney node references this Organization via shared @id.

For example, if Acme Law has San Francisco and Los Angeles offices, and handles medical malpractice, personal injury, and employment law, the schema graph includes: (1) Organization: Acme Law Firm (one instance); (2) LegalService: Medical Malpractice, SF; (3) LegalService: Personal Injury, SF; (4) LegalService: Employment Law, SF; (5) LegalService: Medical Malpractice, LA; (6) LegalService: Personal Injury, LA; (7) LegalService: Employment Law, LA; (8) Person: Jane Smith, works for Acme, licensed in CA, specializes in med mal; (9) Person: Bob Jones, works for Acme, licensed in CA, specializes in PI. That is nine schema entities all cross-linked by shared @id and practice-area/location names.

The critical guardrail: do NOT create a separate Organization node for each office or location page. That fragments your entity and tells AI engines that Acme SF and Acme LA are two different firms. Instead, use one Organization with the main address, and let the LegalService nodes carry the location-specific information (address property, areaServed, telephone, hasMap).

When you deploy this multi-office schema, test it against the Google Rich Results Test and validator.schema.org. The test will show you all the LegalService entities it detected and their properties. If it shows duplicate Organization nodes or missing areaServed properties, fix it. The goal is to see every LegalService listed with its location, practice area, and provider (the one Organization) clearly stated.

Not all LegalService properties are equally important for AI citation. Here is the ranked list, based on what AI search engines prioritize when matching queries to LegalService entities:

1. areaServed (highest impact). This is a location, typically a City or AdministrativeArea (state), sometimes a specific postal code. It tells AI engines what geographic region this service covers. For example, if your LegalService has areaServed="San Francisco, California", it will match queries like "attorney in San Francisco" or "law firm near San Francisco". Always include areaServed; never leave it blank. Ideally, add a sameAs link to the Wikipedia entity for the city or state so the model knows you are talking about the real geographic location, not a person or company with a similar name.

2. provider (second highest). This is a reference to the Organization (the firm). Use the shared @id: "provider": { "@id": "/#organization" }. This wires the LegalService to the firm so the model knows who is offering the service. Never inline a full Organization object on every LegalService page; reference by @id.

3. name / description (third). The name should be clear and specific: "Medical Malpractice Defense" or "Family Law in Los Angeles". The description should be 2–3 sentences explaining what the service is, what types of cases you handle, and who typically seeks it. AI models use this text to understand the service and match it to user queries. Be specific; generic descriptions like "We provide excellent legal services" are invisible to semantic search.

4. hasMap (fourth). A link to a Google Map showing the office or service area. This is particularly valuable for local queries. include it if you have a specific office address associated with the service.

5. telephone (fifth). A local or regional phone number for the service. If you have one number for the whole firm and another for a specific practice area, include both. AI models use phone numbers to disambiguate entities and confirm real-world existence.

6. priceRange (optional but valuable). If you are willing to disclose pricing (e.g., hourly rate range, flat fee for a specific service), include it. AI models value pricing transparency and it can influence citation decisions. If you do not disclose pricing on your site, omit this property rather than guessing.

7. image (optional). A photo representing the service (e.g., a photo of an attorney, a courtroom, the office). Helps AI models visually associate the service with your firm.

Do not rely on properties like awards or aggregateRating in the LegalService node to drive citations — those belong on the Organization or on individual service pages. Keep LegalService focused on geography, practice area, and provider.

The most common schema mistake law firms make is re-declaring the Organization (firm) on every page with slightly different properties, or using different @id strings for the same firm across pages. This fragments your entity in Google's Knowledge Graph and weakens your authority. Here is the right pattern:

1. In your site footer or root layout, declare the Organization once. Give it a stable @id, e.g., "@id": "https://yourfirm.com/#organization". Include the full set of properties: name, address, telephone, logo, image, sameAs (GBP URL, LinkedIn, Avvo, etc.), and any other firm-level metadata.

2. On every other page — practice-area pages, attorney bios, office pages, blog posts — when you need to refer to the firm, reference it by @id: "provider": { "@id": "https://yourfirm.com/#organization" }. Do not repeat the Organization properties; just use the @id.

3. If you need to update firm-level info (e.g., a phone number change or a new GBP link), update it in ONE place (the root layout), and the change propagates across all pages automatically.

Why this matters: Google's Knowledge Graph deduplicates entities based on sameAs, name, and other signals. If you declare the same firm with the same name but different @ids (e.g., "/#organization" on one page, "/org" on another), Google may treat them as separate entities or get confused about which one is canonical. One firm = one @id. Reference it everywhere; declare it once.

A secondary guardrail: never use relative @ids like "#organization" for sameAs properties or links that point outside your site. @id itself can be relative, but sameAs, url, and identifier should be absolute (full https://...URLs) so they resolve the same way for all AI crawlers regardless of which page they are reading.

Google Business Profile (GBP) is a separate system from schema.org, but they work together. When you create a LegalService entity with hasMap (a Google Map link or embed), you are creating a bridge between your site's schema and the local pack (the map and business listings that appear at the top of Google Search results for "attorney near me" type queries).

The hasMap property should point to the Google Map for your office address. You can generate this URL by searching your office address on Google Maps, then copying the URL from the browser. For example: hasMap: "https://maps.google.com/maps?daddr=123+Main+St+San+Francisco+CA". Alternatively, use a map embed iframe.

Critically: the address in your LegalService node must match the address in your GBP profile exactly. Name, street address, city, state, ZIP — byte-for-byte identical. If your GBP says "123 Main Street" and your schema says "123 Main St", Google's deduplication algorithm may treat them as separate entities and weaken your local ranking. This is the NAP (Name-Address-Phone) consistency rule that SEOs have known for years; it applies even more strictly to schema.

When you update your GBP profile (new phone, hours, photos, reviews), check your schema on the corresponding LegalService node and update them too. They are not automatically synced; it is your responsibility to keep them in sync. A mismatch tells AI engines that your data is inconsistent or outdated, which lowers trust.

For multi-office firms, each office should have its own GBP profile (or a single profile with multiple locations). Each location then maps to one LegalService node per practice area. If you have one GBP with multiple locations, make sure each LegalService references the correct location's address and phone number.