Read it, chapter by chapter
The full 7-chapter guide for law firms — pick any chapter to read it here.
What Exactly Is Schema Markup?
Schema markup is a set of standardized labels that describe the meaning of content on a web page, written in a machine-readable format (usually JSON-LD) that tells search engines, AI systems, browsers, and other software exactly what information is present and what it means. Without schema markup, a search engine's crawler sees only raw HTML — it can read the text, but cannot know for certain whether "(555) 123-4567" is your law firm's phone number, a client's phone number quoted in an article, or just a random sequence of digits. Schema markup says: "This is a telephone number. It belongs to us. It is our main office line."
Schema.org is the global standard vocabulary for schema markup, created in 2011 as a collaboration between Google, Microsoft (Bing), Yahoo, and Yandex. It defines hundreds of types and properties (name, description, address, telephone, image, priceRange, etc.) that cover virtually every domain — business, products, events, news, recipes, medical, legal services, and more. When you use Schema.org types, you are using the same vocabulary that Google's algorithms, Bing's search engine, Apple's Siri, and LLM-based AI systems (ChatGPT, Claude, Gemini, Perplexity) rely on to understand your content.
| Aspect | Plain HTML | With Schema Markup |
|---|---|---|
| Meaning | Text is human-readable but ambiguous to machines | Each element is labeled with its type and meaning |
| Phone number | <p>Call us: (555) 123-4567</p> | "telephone": "(555) 123-4567" (machine-explicit) |
| Address | <p>123 Main St, Los Angeles, CA</p> | "address" with structured street, city, state, zip (parseable) |
| What machines learn | Unclear; could be a fact, a quote, noise | Explicit type and meaning; machines know exactly what it is |
| Rich results eligible | No; machines cannot extract structured data | Yes; machines can extract and format for display |
JSON-LD (JSON for Linked Data) is the format Google recommends for schema markup. You place a <script type="application/ld+json"> block in your page's HTML (usually in the <head> or <body>) containing JSON-formatted schema. The schema is invisible to users but fully parseable by machines. When Google crawls your page, it reads the JSON-LD, extracts the structure, and uses it to build a knowledge graph (a machine-readable map of entities and their relationships). For law firms, this means search engines and AI systems learn who you are, where you practice, what services you offer, and how to contact you — all automatically from the markup.
There are other markup formats — microdata (uses HTML attributes) and RDFa (uses semantic HTML markup) — but Google strongly prefers JSON-LD because it is clean, easy to validate, and does not pollute the visible HTML. Most modern implementations use JSON-LD exclusively.
Why Does Schema Markup Matter for Law Firms?
Schema markup directly affects your visibility in Google Search, Google Business Profile, rich search results, local pack ranking, and AI search engines (ChatGPT, Gemini, Perplexity, Claude) because all of these systems rely on schema to understand what your firm is, where you are located, and what services you provide. Without proper schema, you are essentially invisible to these discovery and ranking systems, even if your site has great content and strong backlinks.
First: Google Search and Local Pack Ranking. Google uses schema markup to validate and enhance your Google Business Profile listing. If your website's schema matches your GBP profile (same name, address, phone — byte-identical), Google gains confidence that your business information is consistent and trustworthy. This strengthens your local pack ranking (the three-result map box). Conversely, if your schema is missing or contradicts your GBP profile, Google deprioritizes you locally.
Second: Rich Results. Schema markup enables rich search results — the enhanced snippets with stars, images, sitelinks, FAQ dropdowns, and other formatting that appear above regular organic results. A law firm using FAQPage schema can display a FAQ section directly in the SERP (search engine results page), answering common client questions before they even click. LocalBusiness + aggregateRating schema enables the 5-star review snippet. These rich results attract clicks and signal authority.
Third: AI Search Engine Citation. AI search engines like ChatGPT (with web browsing), Gemini, Perplexity, and Claude (with web search) use schema markup to extract structured, citable information about your firm. When an LLM retrieves your page, schema helps it understand which facts are most important (your name, locations, services, credentials). If your page has clear schema, the AI engine is more likely to cite your firm as an authoritative source. Schema is a trust signal: well-formed schema suggests the firm took care to be accurate and verifiable.
Fourth: Knowledge Graph. Google builds a Knowledge Graph — a global database of entities and their relationships. If your law firm's schema includes consistent identifiers (a unique @id for your firm, @id per attorney), Google recognizes these entities and consolidates their appearances across the web into a single entity node. This is powerful: when someone searches "[Your Firm Name] attorneys" or "[Your Firm] practice areas," Google can return rich entity cards and related information drawn from your Knowledge Graph. Firms without good schema are fragmented in the Knowledge Graph — if at all.
Fifth: Future-Proofing. Search ranking factors change, but structured data is stable. Google's algorithms evolve yearly, but Schema.org has been stable since 2011. Investing in schema markup is investing in a future-proof signal that search engines (and AI systems) have relied on for over a decade and will continue to rely on.
How Schema Markup Works: The Entity Graph Model
Schema markup works by defining entities (things) and relationships (how they connect). Your law firm is an entity (type: LegalService or LocalBusiness). Each attorney is an entity (type: Person). Each location is an entity (type: Place or LocalBusiness). The services you offer (personal injury, family law, etc.) are entities (type: Service). These entities are connected with relationships: an attorney "worksFor" the firm; a location "isPartOf" the firm; a service "isProvidedBy" the firm. This network of entities and relationships is the entity graph.
The key innovation is the shared identifier (@id). Instead of re-declaring your firm's information on every page (name, address, phone on the homepage, on the contact page, on the attorney bio page, on the location page), you declare it once and reference it by @id everywhere else. For example: you might declare your firm as @id: "https://yourfirm.com#organization" on the homepage, then on every other page, you reference that entity via { "@id": "https://yourfirm.com#organization" } without re-stating the address, phone, etc. This tells search engines: "This is the SAME entity on every page." Consistency is crucial. If you vary the phone number or address across pages (or use different spellings of your firm name), the graph fragments, and search engines cannot consolidate the information.
| Entity | Type | @id (identifier) | Key Properties |
|---|---|---|---|
| Your Firm | LegalService / LocalBusiness | https://yourfirm.com#organization | name, address, telephone, email, openingHours, areaServed, image |
| Attorney 1 | Person | https://yourfirm.com/attorney-jane-smith#person | name, worksFor (→firm @id), hasCredential, sameAs (LinkedIn), image |
| Attorney 2 | Person | https://yourfirm.com/attorney-john-doe#person | name, worksFor (→firm @id), hasCredential, sameAs (LinkedIn), image |
| Personal Injury Service | Service | https://yourfirm.com/personal-injury#service | name, description, provider (→firm @id), areaServed |
| Los Angeles Office | Place / LocalBusiness | https://yourfirm.com/los-angeles#place | name, address, telephone, geo (lat/lng), isPartOf (→firm @id) |
Once you have this entity graph, Google (and AI systems) can reason about your firm as a cohesive unit. They understand: "This firm has 2 attorneys, serves Los Angeles and San Diego, practices personal injury and family law, and can be reached at this phone number." This structured knowledge is far more powerful than any amount of plain text about your firm.
The relationships in your entity graph also hint at topical authority. If a page about "personal injury in Los Angeles" links to the personal injury service entity, the location entity, and the firm entity (all via @id), Google infers that your firm is topically authoritative for this niche. This reinforces your rankings.
Schema Types for Law Firms: The Core Taxonomy
Schema.org provides a taxonomy of pre-built types for law firms, ranging from the broad (Organization) to the specific (LegalService, Attorney, CourtHouse). Here are the core types and what they represent for a law firm.
LegalService: This is the primary type for representing a law firm or a legal service. It is a subtype of LocalBusiness, so it inherits all the local business properties (address, telephone, openingHours, etc.). Key properties include: name (your firm's name), address (structured postal address), telephone, email, priceRange (if applicable), areaServed (jurisdictions you serve), hasOfferingDescription (a description of your firm), image (logo or firm photo), aggregateRating (if you have verified reviews), review (individual review objects), and provider (if this service is offered by a specific person or firm). Many law firms use LegalService as their primary type.
LocalBusiness: A more general type for any local business. It includes all the local properties (address, phone, hours, reviews, rating). LocalBusiness is broader than LegalService, so if your firm is not strictly a "legal service" entity (e.g., you are structuring it as a holding company or a corporation), you might use LocalBusiness. But for law firms, LegalService is preferred because it is more specific and signals the industry.
Attorney: This is a deprecated type (Schema.org no longer recommends it). Use Person instead. A Person entity represents an individual attorney, with properties like name, image, jobTitle, worksFor (the firm), hasCredential (bar admission, education), sameAs (LinkedIn, Avvo), and email. This is crucial for E-E-A-T (Experience, Expertise, Authoritativeness, Trustworthiness) because it links a human face and credential to your firm.
Person: The general type for any person. For attorneys, use Person with properties specific to law: hasCredential (bar admission, CLE certifications), hasOccupation, worksFor (linked to your LegalService @id), alumniOf (law school), and sameAs (LinkedIn, Avvo, state bar directory). This is the modern, recommended type for individual attorneys.
Organization: Use this for your firm if you want to emphasize corporate identity and partnerships. It includes properties like name, logo, sameAs (website, LinkedIn, legal directories), and owns (linked properties or sub-entities). Some multi-office firms use Organization for the parent company and LegalService for each office or practice area.
Service: If you want to describe a specific service (personal injury representation, contract review, mediation) separately, use Service type. Properties include name, description, provider (linked to your firm), areaServed, and offers (pricing if applicable).
CourtHouse: If you mention courts your firm serves (which you should for credibility), use CourtHouse type to describe the real court by name, address, telephone, geo (latitude/longitude). This is table-stakes for jurisdiction-specific pages.
FAQPage: Use this type to mark up a FAQ section on your page. Each question-answer pair is an individual faqEntity (not a separate type; it is part of the FAQPage). This enables Google to display FAQ rich results.
BreadcrumbList: Mark up navigation breadcrumbs (e.g., Home > Practice Areas > Personal Injury) so Google understands your site structure and can display breadcrumbs in search results.
How to Implement Schema: Basics and Best Practices
Implementing schema markup for a law firm involves five steps: (1) audit your current schema to identify gaps; (2) design your entity graph (decide which entities you need and their relationships); (3) write JSON-LD for each page; (4) validate the JSON-LD using tools; and (5) monitor Google Search Console to see if Google processes the markup and displays rich results.
Step 1: Audit. Use Google's Rich Results Test or Schema.org's validator to crawl your homepage and key pages. The tests will flag any schema errors (invalid syntax), warnings (missing optional properties), and will show you which rich-result types are detected. If your site has no schema, the output will be empty. If your site has incomplete schema, the warnings will show you what properties are missing.
Step 2: Design. Decide on your core entities and relationships. At minimum, every law firm should have: a LegalService node for the firm (with name, address, telephone, email, image, areaServed, aggregateRating), a Person node per attorney (with name, worksFor linking to the firm, hasCredential, sameAs for LinkedIn/Avvo), and a WebPage node for each important page (homepage, practice-area pages, location pages, etc.). Optionally, add Service nodes for specific practice areas, CourtHouse nodes for courts you serve, and Place nodes for each office location. Each entity should have a unique, stable @id (e.g., https://yourfirm.com#organization for the firm; https://yourfirm.com/attorney-jane-doe#person for an attorney).
Step 3: Write JSON-LD. Use a JSON-LD generator (like JSON-LD.org's generator, or write it manually if comfortable with JSON). Place the script tags in your page template so they are included on every page. The JSON-LD should be in the page's <head> or <body>. Ensure that every page that talks about a service, location, or attorney references the correct @id for that entity. Never re-declare the entity; always reference it by @id. This is the key principle: declare once, reference everywhere.
Step 4: Validate. Use validator.schema.org (recommended) to check syntax and completeness. Upload your JSON-LD (or paste it) and the tool will report errors, warnings, and valid items. Fix all errors. Address warnings if possible (most are for optional properties, but adding them (name, image, aggregateRating) significantly improves visibility to AI systems and Google's rich results). Google's Rich Results Test will show you which rich-result types are eligible based on your schema. Note: the Rich Results Test only shows eligible types (those that map to a live Google rich result); it omits valid-but-ineligible types like FAQPage, Service, Person. These are still there and are still valuable; their absence from the Rich Results Test does NOT mean they are missing.
Step 5: Monitor. In Google Search Console, go to Enhancements and check for "Structured Data" or "Rich Results" reports. These show how many pages have valid schema and whether Google is processing it. Over time (2–4 weeks), Google should start displaying rich results for your firm's homepage, attorney bios, and practice-area pages if the schema is complete.
Best practices: (a) Always use root-relative URLs for @id, @type references, and image URLs — never hardcode your live domain. (b) Keep @id stable; changing it breaks the entity graph. (c) Use byte-identical NAP (name, address, phone) across all schema and GBP. (d) Include real, third-party aggregateRating and review objects only — never fabricated ratings. (e) Ensure schema matches visible content on the page; Google penalizes pages where schema claims facts the page does not state.
Schema Markup and AI Citation: The Emerging Standard
AI search engines (ChatGPT with web browsing, Gemini, Perplexity, Claude with web search) use schema markup to understand your law firm's content and decide whether to cite it when answering user queries about legal services, attorneys, or practice areas. Well-formed schema is increasingly a prerequisite for AI citability.
Here is how the process works. When an AI engine retrieves your page (via its retrieval-augmented generation pipeline), it parses both the plain HTML and the schema markup. The schema tells the AI: "This is a law firm named [X], located in [Y], practicing [Z] areas of law, with attorneys [A1, A2], and a phone number [P]." The AI engine uses this structured information to decide: (1) Is this a credible source? (2) Does this source answer the user's question? (3) How should I cite this source? (4) What information should I extract and quote?
Schema also enables AI engines to build a knowledge graph of your firm — much like Google does — and to recognize your firm when it is mentioned elsewhere on the web. If your firm's schema uses consistent @id and sameAs properties (linking to LinkedIn, Avvo, your GBP profile, bar directories), the AI engine learns that these are all the SAME entity. When the engine later sees a mention of your firm on Reddit or a legal directory, it can link that mention back to your official website, strengthening your entity in the AI system's knowledge graph.
As of 2026, AI engines are increasingly rewarding pages with high-quality, complete schema. Pages with well-formed LegalService + Person + aggregateRating + FAQPage schema are cited more frequently than pages with minimal schema. The trend is clear: schema markup is table-stakes for AI visibility, just as it is for Google.
Additionally, some AI engines are beginning to surface schema-extracted information in their answers. For example, an AI might say: "According to [FirmName]'s structured data, they practice [areas] in [locations] and have [N] attorneys." This is extracted directly from your schema, so having complete, accurate schema ensures that the AI's description of your firm is correct and authoritative.
Common Schema Mistakes and How to Avoid Them
Law firms commonly make several schema mistakes that reduce visibility and AI citability. Here are the most frequent and how to fix them.
Mistake 1: Incomplete schema. The most common error is having schema on the homepage but not on practice-area pages, location pages, or attorney bios. Schema markup is powerful only when it is comprehensive. Every important page should have schema. If your personal injury page has no schema, Google and AI engines cannot extract the practice area information from that page, even if the visible content is good. Fix: Use a template so schema is automatically included on every page type.
Mistake 2: Duplicate or conflicting entities. Some firms declare their firm entity on every page, each time with slightly different information (name, phone, address). This fragments the entity graph. Google sees multiple versions of the same firm and cannot consolidate them. Fix: Declare the firm entity once (on the homepage or in a shared footer template) with a stable @id, then reference that @id on every other page using { "@id": "https://yourfirm.com#organization" } without re-stating properties.
Mistake 3: Fabricated ratings or reviews. Some firms use schema to claim fake reviews or inflated ratings that do not match their GBP profile or visible reviews on the page. Google and AI engines check schema against visible content and against GBP data. Fabricated schema is a violation of Google's helpful-content policies and will be ignored or penalized. Fix: Use only real, third-party reviews from GBP, Avvo, or your website's verified review system. Quote real reviews, not made-up ones.
Mistake 4: No sameAs linking. Many firms have schema for their firm and attorneys but never include sameAs properties linking to LinkedIn, Avvo, the bar directory, GBP, or Wikidata. Without sameAs, search engines cannot confirm that your website's entity is the same entity you claim elsewhere. This weakens your entity graph and reduces citation by AI engines. Fix: For every firm node, include sameAs: [...all verified profiles...]. For every attorney, include sameAs: [...LinkedIn profile, Avvo profile...]. This is the single highest-leverage schema property for entity disambiguation.
Mistake 5: Schema does not match visible content. A page's schema claims an attorney works at the firm, but the attorney bio page does not exist. Or the schema states an address, but the page does not display that address. Google and AI engines check schema against visible HTML and penalize mismatches. Fix: Ensure every schema property is also stated in the visible page content. The schema is a translator of content that already exists, not a source of truth for invisible data.
Mistake 6: Hardcoded domains in schema. Some firms put absolute URLs in their schema (https://yourfirm.com/attorney-bio) instead of root-relative (/attorney-bio). When the site is migrated to a new domain or a staging domain is deployed, the old hardcoded URLs become broken, and the schema breaks. Fix: Use root-relative URLs and @id references (e.g., /attorney-jane-doe#person instead of https://yourfirm.com/attorney-jane-doe#person).
Mistake 7: Missing image properties. Schema allows firms to include logo, attorney photos, office photos, etc. Images make schema more complete and help Google and AI engines display richer information. Many firms omit images, missing an opportunity. Fix: Include image properties for your firm's logo, each attorney's headshot, and each location's office photo. Use root-relative or stable absolute URLs.
