Building Your Firm's Knowledge Graph for AI Citability

A knowledge graph is a structured representation of entities, their properties, and the relationships between them. Instead of storing information as loose text on a web page, a knowledge graph is a connected database of facts: your firm's name, its office locations, the attorneys who work there, their credentials, the practice areas you handle, the cases you've won, and how all of these connect. It is a machine-readable semantic map of what your firm is and what it does.

Why does this matter? Because AI search engines — ChatGPT, Claude, Gemini, Perplexity — use knowledge graphs to understand entities and their relationships when deciding which sources to cite. When you ask an AI search engine "What is a statute of limitations for personal injury in California?", the engine does not just search for keywords. It constructs a semantic query: "statute of limitations [concept] → personal injury [practice area] → California [jurisdiction]." Then it searches for sources that clearly encode these entity relationships. A page that says "we handle personal injury cases in California" and explicitly links "statute of limitations" to that practice area and jurisdiction is cited more often than a page with the same text buried in prose without entity clarity.

For law firms, the knowledge graph is not just an abstract concept — it is a practical tool for visibility and citation. Most law firm websites treat the web as a document repository: pages of text describing services. AI engines treat the web as a network of entities and their properties. The gap between these two worldviews is enormous. Building your firm's knowledge graph bridges that gap.

The practical implication: if your firm's name is spelled "Smith & Associates" on your website, "Smith & Associates LLC" on Google Business Profile, and "smith-associates.com" on LinkedIn, AI engines treat these as three separate entities. Your authority is fragmented across three identities, each with a third of your true strength. By contrast, if all three sources use byte-identical naming and link to each other with `sameAs`, AI engines recognize it as one firm, and your authority compounds.

A knowledge graph has three structural layers, and understanding each one is key to building your firm's graph. The first layer is entities — the nouns, the things themselves. For a law firm, entities include: the firm itself, individual attorneys, practice areas (personal injury, employment law, family law), jurisdictions (California, federal courts), case types (accident, medical malpractice, wrongful termination), courts, and procedures (trial, mediation, settlement).

The second layer is attributes — the properties or descriptors of those entities. A firm entity has attributes: name, address, phone, website, email, years in business, number of attorneys. An attorney entity has: name, bar license number, area of practice, education, certifications. A practice area has: name, description, typical statutes of limitations, comparative fault rules (for that jurisdiction). Attributes are the facts about entities.

The third layer is relationships — how entities connect to each other. An attorney has a relationship to the firm: "worksFor." A case type has a relationship to a practice area: "partOf" or "isA." A practice area has a relationship to a jurisdiction: "isAvailableIn." A court has a relationship to a jurisdiction: "locatedIn." Relationships encode the semantic structure of your domain.

Most law firm websites fail because they conflate these layers. They mention an attorney and a practice area on a page but do not explicitly state the relationship: "This attorney handles this practice area." To a human reader, it is clear. To an AI engine's embedding system, the connection is implicit and weak. By contrast, a website that explicitly encodes "Attorney John Smith [worksFor] Smith & Associates" and "Smith & Associates [offers] Medical Malpractice" and "Medical Malpractice [hasPractitioner] John Smith" creates a dense web of relationships that AI engines recognize and reward.

AI search engines retrieve content using a process called Retrieval-Augmented Generation (RAG). The system converts a user's question into a semantic embedding — a vector representation of meaning — then searches the web for pages whose content embeddings are semantically similar. But the quality of retrieval depends on semantic clarity: if your page does not clearly encode the relationship between a concept and your firm, the embedding will be noisy and your page will rank lower in the search results.

A concrete example: a user asks "Who handles medical malpractice cases in San Francisco?" The AI engine embeds this query: [medical-malpractice, San Francisco, case handling]. It then searches for pages whose embeddings align with this triple. A page that says "We are a law firm in San Francisco that handles many types of cases" has a fuzzy embedding: it mentions the location but not the specific practice area, so the alignment is weak. By contrast, a page that clearly states "Our firm offers medical malpractice representation in San Francisco" and encodes this in schema as LegalService [service=medical-malpractice, areaServed=San-Francisco, provider=YourFirm] has a sharp, aligned embedding. The second page is retrieved more often and cited more often.

This is why entity reconciliation matters. If your firm name varies across your website ("Smith and Associates" vs. "Smith Associates, Inc."), the embedding system treats these as slightly different entities, weakening the signal. By contrast, byte-identical naming everywhere ("Smith & Associates, Inc.") strengthens the signal.

Additionally, knowledge graphs enable AI engines to answer user questions by traversing relationships. If a user asks "What is the statute of limitations for medical malpractice in California?", the engine can (a) find your firm's entity, (b) follow the relationship "offers Medical Malpractice in California," (c) find content on your site about California medical malpractice and its statute of limitations, and (d) cite your page as authoritative for that jurisdiction-practice combination. Without the explicit relationships, the engine might find your content but not recognize that your firm is an expert in that specific combination.

Building a knowledge graph is not a one-time project — it is an ongoing practice of entity reconciliation and relationship encoding. Here is the five-step process:

Step 1: Inventory your entities. List every entity your firm cares about: the firm itself, each attorney, each practice area, each jurisdiction you serve, major case types, and any partnerships or affiliations (bar associations, legal directories, industry groups). For each entity, note where it appears: your website, Google Business Profile, LinkedIn, Avvo, Justia, your bar association profile, press mentions. Create a spreadsheet with columns: Entity, Type (Firm / Attorney / PracticeArea / Jurisdiction / CaseType), Instances (list URLs where it appears).

Step 2: Audit and reconcile naming. For each entity, check if it is named consistently across all instances. For example, is your firm always "Smith & Associates, Inc." or does it sometimes appear as "Smith and Associates" or "Smith & Assocs"? Are attorney names always spelled the same way? Are practice area names consistent? Create a "canonical" name for each entity — the official, byte-identical name that will appear everywhere. Then audit every page and directory entry to confirm they match. Inconsistency fragments authority; consistency concentrates it.

Step 3: Add attributes to each entity. For the firm entity, ensure you have: official name, address, phone, website URL, email, years established, areas of practice (list), number of attorneys, office locations (list), bar licenses, and any relevant credentials or awards. For each attorney, add: full name, bar license number, bar license state(s), areas of practice (list), education/degree, law school, graduation year, certifications, professional memberships. For each practice area, add: formal name, description (2–3 sentences), related statutes or regulations, typical procedures. For jurisdictions, add: name, state/federal status, relevant courts. These attributes populate your schema.

Step 4: Encode relationships in your site's schema. Use Schema.org JSON-LD to express relationships. The firm's main page should include a `LegalService` or `Organization` node with attributes (name, address, phone) and relationships (an attorney `worksFor` this firm, a `Service` node for each practice area, an `areaServed` property listing jurisdictions). Each attorney page should include a `Person` node with `worksFor` pointing to the firm's entity ID (by `@id`), and `knowsAbout` listing their practice areas. Each practice area page should include a `Service` node with `provider` pointing to the firm and `availableInRegion` for jurisdictions. Crucially: use shared `@id`s so every mention of "the firm" refers to one entity ID, not multiple declarations. This is how schema.org encodes the knowledge graph in machine-readable form.

Step 5: Reconcile external profiles. Your firm and attorneys appear in many places outside your website: Google Business Profile, LinkedIn, Avvo, Justia, bar association directories, legal aggregators. For each external profile, (a) check that the name, address, and phone match your canonical data byte-for-byte, (b) add links pointing back to your website (many platforms allow a website URL in the profile), and (c) link your website's schema `sameAs` property to the external profile's URL. This tells AI engines: "Smith & Associates (my website) is the same entity as Smith & Associates (Google Business Profile) is the same entity as Smith & Associates (LinkedIn)." External consistency is how you build entity authority at scale.

Once you have built your knowledge graph, the next step is to encode it in two places: your site's content (semantic internal links) and your site's schema (JSON-LD).

Semantic internal linking means that every page links to related entities and concepts using predictable, relationship-aware anchor text. For example, a page about "Medical Malpractice in San Francisco" should have links like: "Our medical malpractice practice serves the San Francisco area. Our lead attorney is John Smith, who specializes in [this practice]." These links are not just for users — they encode relationships that search engines parse. The page mentions three entities (Medical Malpractice, San Francisco, John Smith) and the links make the relationships explicit.

Schema.org JSON-LD is the machine-readable equivalent. The same page's schema should include a `Service` node (for medical malpractice), an `areaServed` property (referencing San Francisco), and a `provider` property (referencing the firm's main entity ID). A `Person` node for John Smith includes a `worksFor` property pointing to the firm. Every relationship encoded in the content is also encoded in the schema.

The highest-impact internal linking pattern for law firms is the hub-and-spoke model: one hub page ("Medical Malpractice") links down to every spoke page ("Medical Malpractice in San Francisco," "Medical Malpractice in Los Angeles"), and each spoke links up to the hub and sideways to sibling spokes. This structure is both human-navigable and machine-parseable: it makes clear that all the location-specific pages are variants of one topic, under one knowledge-graph entity. Learn more about hub-and-spoke structure for law firms.

Anti-Pattern 1: Hardcoded entity data in templates. A common mistake is to build a shared template for city pages that hardcodes the city name and practice area for one location, then copy-paste it for every other location without changing the data. This creates pages that falsely claim to serve jurisdictions they don't, have wrong court names, wrong law firms, and wrong practice areas. These are "doorway pages" — they exist only to capture keywords, not to provide real value. AI engines and Google's helpful-content systems penalize them. Every location page must render its own real, verifiable data: the actual courts in that jurisdiction, the actual population and demographics, the actual laws and statutes for that state.

Anti-Pattern 2: Inconsistent entity naming. The firm is sometimes "Smith & Associates," sometimes "Smith and Associates," sometimes just "Smith." The attorney John Smith appears as "John Smith," "John T. Smith," "John Terrence Smith." These variations fragment the entity identity. To AI engines, these are three different people or firms, each with a fraction of the true authority. Fix this by establishing and enforcing canonical names everywhere.

Anti-Pattern 3: Missing relationships in content. A page about personal injury lists several attorneys who handle such cases, but does not explicitly state "Attorney A handles personal injury" or "This attorney's practice areas include personal injury." The relationship exists conceptually but is not encoded. AI engines treat this as weak evidence. Encode relationships explicitly in text and in schema.

Anti-Pattern 4: Unverifiable claims. A page claims the firm won a specific case with a specific verdict, but the verdict is not verifiable (no court record, no real case name). Or it claims an attorney was "Top 10 lawyer in the state" without citing the source. Unverifiable claims are red flags for AI engines. They reduce citation because the engine cannot corroborate the claim against external sources. Every fact must be real and verifiable.

Anti-Pattern 5: Isolated pages with no context. A practice area page mentions jurisdiction and case type but does not link to the firm's main entity, the attorneys who handle it, or related practice areas. The page exists in isolation, with no relationships to the broader knowledge graph. AI engines downrank isolated pages because they can't infer how the page fits into the firm's overall expertise. Always link pages into the broader graph.

How do you know if your knowledge graph is working? There are several signals to track:

Entity recognition in AI search. Use tools like Google Search Console and Ahrefs to monitor whether AI search engines (Google AI Overviews, ChatGPT, Perplexity, Gemini) are citing your firm's pages. Are your pages appearing in AI-generated answers? Is your firm's name appearing as the source? Track the growth in AI citations over time as you build out your knowledge graph.

Entity authority growth. Monitor mentions of your firm name across the web using tools like Google Alerts, Mention, or Ahrefs' Brand Radar. As you reconcile your entity identity and ensure consistency across directories, you should see an increase in brand mentions. These mentions reinforce your entity's authority.

Ranking for multi-entity queries. Historically, you ranked for single-word or two-word queries: "personal injury lawyer" or "San Francisco attorney." With a well-built knowledge graph, you should begin ranking for multi-entity queries: "personal injury lawyer in San Francisco" or "medical malpractice statute of limitations in California." These longer queries are more specific and high-intent. Track ranking improvements for 2–3 word queries as a signal of entity clarity.

Internal-link network health. Use Screaming Frog or similar to audit your internal link structure. Are practice area pages linking to jurisdiction pages? Are attorney pages linking to practice areas? Are all pages linking up to the main hub? A dense, well-connected internal-link graph is a sign of a healthy knowledge graph.

Schema validation. Run your pages through validator.schema.org to ensure your JSON-LD is syntactically correct and semantically rich. Check that entity relationships are encoded (attorney worksFor firm, service provider is firm, etc.). A high-quality schema graph is correlated with AI citability.