Make your law firm machine-readable to AI search engines — so they can find, trust, and cite you without ambiguity. Schema.org markup is the translator between your visible content and how models understand it.
Schema markup (JSON-LD) is structured data that tells AI search engines and models exactly who your law firm is, where it practices, and what it does — in a machine-readable language they trust. A complete entity graph (Organization, LegalService, Attorney, LocalBusiness, Court) linked by shared identifiers lets models quickly find, corroborate and cite you across ChatGPT, Claude, Gemini, Perplexity and Google AI Overviews.
Use the interactive map below to explore each one — click any node to read what it covers and jump to its page.
The guides that make your firm machine-readable and trustworthy to AI.
The machine-readable layer — and how to get it right.
Schema markup is structured data (JSON-LD format) that adds semantic meaning to web pages, telling search engines, AI systems, and browsers exactly what information is on your page: who you are, where you are, what services you offer, and how to contact you.
LegalService is a LocalBusiness subtype that describes a legal service offered by a firm. It carries properties like areaServed (the jurisdictions you serve), telephone, address, and a provider reference to the firm Organization. LegalService is the entity type that AI search engines use to match user queries about legal services to your firm.
FAQPage schema marks frequently asked questions on your site so Google and AI search engines can understand and surface your Q&A content. Each question and answer pair becomes its own indexed entity.
LocalBusiness is a schema.org type for location-specific entities: a single office, a restaurant, a retail location. Law firms with multiple offices need multiple LocalBusiness nodes, each representing one office with real, verified geo-coordinates, address, phone, hours, and reviews.
Self-serving aggregateRating on your org node is ignored by Google and penalizes your schema. Use real, third-party reviews only (Google Business Profile, Avvo, Justia); put aggregateRating on individual result/service pages, not the firm itself.
Schema markup is structured data — text in a machine-readable format — that tells AI search engines and language models exactly what your law firm is, where it operates and what it does. The standard format is JSON-LD (JavaScript Object Notation for Linked Data), hosted in a <script> tag on your page alongside your visible HTML.
Law firms need it because it solves the ambiguity problem. When an AI engine reads prose about 'a law firm in Austin handling personal injury,' it has to guess which details are core facts and which are marketing flavor. Schema removes the guessing: you declare Organization { name: 'Your Firm', address: '...' } and the model knows instantly what to expect. That speed and certainty makes you more retrievable and trustworthy.
The payoff is directness: instead of an AI engine parsing your site to infer your details, it reads schema and finds them in a fraction of a second. That efficiency matters when models are deciding which firm to cite first.
The core types for law firms are Organization (the firm itself), LegalService (what you do), Attorney or Person (the lawyers), LocalBusiness (your offices), WebPage (every page you publish), BreadcrumbList (your site navigation) and FAQPage (if you have a FAQ). These types, wired together with a shared @id for your firm, form an entity graph that models can traverse and understand.
Organization is the root. It holds your firm's name, address, phone, logo, aggregate rating (if real and displayed) and sameAs links to your Google Business Profile, Avvo, Justia and LinkedIn company page. This node is declared once in your site footer and referenced by @id everywhere else.
LegalService describes each practice area or service you offer — what it's called, what it covers, the provider (your firm, by @id), and the area served (your jurisdiction). One LegalService per major practice area; each linked to your firm.
Attorney (a subtype of Person) represents each lawyer. It carries the attorney's name, credentials (admitted to the state bar), the firm they work for (provider pointing to your firm @id), and ideally a photo and biography URL.
LocalBusiness is optional for your firm, but essential for multi-office firms — each office is a separate LocalBusiness node with its own address, hours and phone, all linked to the parent Organization.
WebPage, BreadcrumbList and FAQPage are utility types that structure your content. Every page gets a WebPage node; navigation gets a BreadcrumbList (visible on the page and in schema); FAQs get a FAQPage with question-and-answer pairs.
| Type | Carries | Declared once or per item? | Example |
|---|---|---|---|
| Organization | Firm name, address, phone, logo, aggregate rating, sameAs links | Once (in site footer) | yourfirm.com/#organization |
| LegalService | Service name, description, practice area, provider (firm @id), areaServed | One per practice area | LegalService for 'Personal Injury Litigation' |
| Attorney/Person | Name, credentials, firm (provider), photo, bio URL | One per lawyer | Person for 'Sarah Chen, Partner' |
| LocalBusiness | Office address, hours, phone (for multi-office firms only) | One per physical office | LocalBusiness for 'Downtown Office' |
| WebPage | Page title, description, author, datePublished, dateModified | One per page | Article or BlogPosting for blog posts |
| BreadcrumbList | Navigation breadcrumbs (visible on page) | Once (site-wide) | Home > Practice Areas > Personal Injury |
| FAQPage | Question-and-answer pairs (visible on page) | Per FAQ page | FAQPage for 'Frequently Asked Questions' |
The core schema types for law firms and what each carries.
An @id is a unique, stable identifier for an entity. For your firm, it's typically your site URL with a fragment — yourfirm.com/#organization — or a standard URN. When you declare your firm's full details (name, address, phone, aggregate rating) under that @id once, every page on your site references that @id instead of re-declaring the firm.
This prevents fragmentation. Without @id, you might list your firm on the homepage with all details, then on a practice-area page list it again with fewer details (maybe just name and phone). An AI model reading both declarations might think they're two different firms — 'InterCore, Inc.' and 'InterCore Legal Marketing' — and fail to connect them. With @id, you declare it once and reference it everywhere, so models know it's the same entity.
Technically, @id is a pointer: instead of { '@type': 'Organization', 'name': 'Your Firm', 'address': '...' } on page A and again on page B, you put the full declaration in one place and on page B you use { '@id': 'yourfirm.com/#organization' }, which tells models 'look up the entity at that ID.' This is how you avoid duplication and ensure models treat your firm as one coherent identity across your site.
sameAs is a list of URLs pointing to profiles that represent the same entity. For a law firm, it includes your Google Business Profile, Avvo page, Justia profile, LinkedIn company page and maybe your Wikipedia entry or Crunchbase profile. When an AI engine reads your schema and sees 'sameAs': [ 'https://maps.google.com/...', 'https://avvo.com/...', ...], it knows to look at those profiles to verify you.
This is powerful because third-party profiles are corroboration. Your site can claim anything; your Google Business Profile and Avvo are independently maintained by you with real reviews and data entry friction. When models see your schema linking to a verified GBP with a real address and a 4.8-star rating, they become confident that the claim 'We practice in Austin' is genuine — because Google already verified it.
The payoff is higher citation confidence. If your schema includes sameAs links to 3+ major directories (GBP, Avvo, Justia) all showing the same firm name and location, models prefer citing you over a competitor whose schema points only to themselves. Corroboration is the difference between 'this firm says they're in Austin' and 'Google, Avvo and Justia all say this firm is in Austin.'
| Directory | What models verify | Why it matters | How to get your URL |
|---|---|---|---|
| Google Business Profile | Real address, phone, hours, reviews, categories | First-party trust; no single source is more authoritative for local. | Claim your business at business.google.com |
| Avvo | Bar admission, practice areas, reviews, years in practice | Lawyer-specific; directly credentialing expertise. | Claim at avvo.com/connect |
| Justia | Bar admission, practice areas, firm profile, website link | Long-standing legal directory; models recognize it. | Claim at justia.com for free profile |
| Martindale-Hubbell | Ratings, practice areas, firm size, years in practice | Oldest legal directory; legacy trust signal. | Martindale.com; claim your firm |
| LinkedIn Company | Firm size, founded date, industry, follower count, posts | Corroborates the firm as a real organization; shows activity. | linkedin.com; create a company page |
| Wikipedia | Firm description, history, notable cases (if notable enough) | Rare for smaller firms; very high trust if present. | Only if the firm is nationally prominent |
The sameAs directories that corroborate law firms, and what models check.
Schema is a translator for content that already exists on your page. If you mark up an aggregate rating of 4.8 stars in schema, that exact rating must be displayed visibly on the page — quoted from your Google Business Profile, with a screenshot, or with the real stars. Never mark up an invisible rating or a different number than what's actually on your site.
The reason is model behavior: when an AI engine retrieves your page and reads both your visible HTML and your schema, it checks them against each other. If schema says 'aggregateRating: 4.8' but the visible page shows 4.6, the mismatch signals either incompetence or dishonesty. Models learn to distrust mismatches and may penalize you or lower your citation likelihood.
The strict rule: if a field is in your schema, it must match your visible content. If you don't have a visible, third-party aggregate rating on the page, don't mark up aggregateRating. If you have an FAQ on the page, mark it up as FAQPage; if the FAQ is invisible (client-side only or hidden), don't mark it. This is why we say the truthfulness gate is absolute — uncorroborable schema is a liability, not an asset.
Most AI engines use Retrieval-Augmented Generation (RAG): the model embeds a user's question, retrieves candidate passages from the web, then writes an answer citing the best sources. After retrieval, the model verifies each source's identity and credibility using schema and third-party signals. Your firm's schema is the machine-readable identity proof.
Here is the flow: an AI engine retrieves a passage from your site saying 'InterCore specializes in AI-driven legal marketing.' It then checks: Who published this? Is there schema claiming this is from InterCore? Does the schema have sameAs links to GBP, Avvo and LinkedIn? Are those profiles consistent? If yes to all, the model is confident this passage is genuine and cites it first. If schema is absent or sameAs links don't corroborate, the model may distrust the passage and cite a competitor instead.
This is why sameAs is the strongest field: it transforms your schema from an unsupported self-claim into a corroborated identity. A complete entity graph — one firm @id, full details declared once, linked to real GBP, Avvo and Justia profiles — is how you become unmistakable to AI.
The intents AI engines fan a search into — and where we make your firm the answer.
Schema markup is structured data (JSON-LD) that translates your visible content into machine-readable language AI engines understand. Law firms need it because it makes your firm, practice areas, locations and contact details machine-checkable — so models can quickly find, disambiguate and verify you without relying on natural-language parsing, which is slow and error-prone.
The core types are Organization (your firm), LegalService (the services you offer), Attorney or Person (the lawyers), LocalBusiness (your physical offices), WebPage (every page), BreadcrumbList (navigation), FAQPage (your FAQs), and Article/BlogPosting (if you publish content). These types, wired together with a shared @id for your firm, build an entity graph AI engines can traverse.
An @id is a unique identifier for an entity — typically your firm's URL like yourfirm.com/#organization. Instead of redeclaring your firm's name, address and phone on every page, you reference it by @id. This tells models 'this is the same firm' across your entire site. One @id, referenced consistently, prevents the engine from splitting your firm into multiple identities.
sameAs is a list of URLs proving 'all these profiles are the same firm' — your Google Business Profile, Avvo page, Justia profile, LinkedIn company page, maybe your Wikipedia entry. When models see your firm's schema includes sameAs links to real, verified third-party profiles, they're confident in who you are and cite you accordingly.
Just once. Declare your firm's full Organization node (with all addresses, phones, sameAs links) in your site layout or footer once, then reference it by @id on every other page. This makes updates easy and keeps the schema consistent. Never redeclare the same firm with different (fewer) details on different pages.
Only if you have a real, visible aggregate rating displayed on the page (from Google Business Profile, Avvo or similar third-party source, not self-reported). Schema must match visible content — never mark up a rating you don't display. If your GBP has 4.8 stars and you quote that on the page, then yes, include the aggregateRating with the exact number.
No. Schema must match visible content exactly. If you mark up a question-and-answer pair in FAQPage schema, it must appear on the page where a visitor can read it. Invisible schema is a mismatch and signals unreliability to engines.
Most AI engines use Retrieval-Augmented Generation (RAG). After retrieving passages, they verify the source's entity details using schema — who the author is, which firm published it, what credentials are claimed. Rich, consistent schema with corroborating sameAs links helps models confirm they can trust the passage and cite it confidently.
No. Create a Person or Attorney node only if the lawyer actually authored or reviewed the page. If the page is published by the firm without a named author, use the firm's LegalService @id as the provider or publisher. Never create invisible schema nodes.
The core required fields are name, serviceType (or knowsAbout for practices), provider (linked to your firm by @id), areaServed (your jurisdiction), and ideally price/priceRange if applicable. You can add telephone, email, url and image. Never declare a LegalService and leave provider empty — that breaks the entity link.
Update it whenever your firm's details change — a new address, phone, service area or attorney. Update dateModified on the WebPage whenever the page content changes. Schema is a living document tied to your real, current firm state. Don't let it drift from reality.
Run it through validator.schema.org (checks syntax and completeness) and Google's Rich Results Test (checks eligibility for rich results). Both are free. Validate your visible content matches every schema field. Then test real retrieval: run a client query through Claude or ChatGPT and see if your firm is cited — if not, the schema alone isn't sufficient, and you likely need deeper content or off-site corroboration.
Start with a free 23-point AI visibility report — see exactly where ChatGPT, Gemini, Claude and Perplexity cite your firm today, and what closes the gap. Delivered in 24 hours. No credit card.
