NAP Consistency and the Off-Site Entity Graph: Why Byte-Identical Information Matters for AI Citation

NAP stands for Name, Address, and Phone — three pieces of information that, when byte-identical across the web, tell AI engines that every occurrence of that NAP refers to the same organization. If your website lists your firm as "Smith & Associates Law, 500 Oak Avenue, Denver, CO 80202, 303-555-0123" and your Google Business Profile says the exact same thing, word-for-word, character-for-character, then every AI engine indexing the web will recognize that "Smith & Associates Law" on your website, in a legal directory, in a press article, and on your review profile all refer to one entity.

NAP consistency is the foundation of entity SEO for law firms. In traditional SEO, the ranking signal is the page—which page ranks for a query. In entity SEO, the ranking signal is the entity—which organization, person, or place the query is asking about. An AI search engine like Gemini or Perplexity does not ask "which page should I show?"; it asks "which entity does the user want information about?" Then it pulls together passages from multiple pages and sources that mention or describe that entity. If your NAP is inconsistent, the engine cannot confidently say "all these pages and profiles are about the same entity." The result: your firm gets fragmented visibility — each inconsistency splits your entity signal into weaker, separate signals.

The stakes are higher for law firms than for most industries. Your address and phone number are hyperlocal signals. A user asking "lawyer in Denver" expects a result with a Denver address. If your website says Denver but your GBP says the address is in Boulder (because you moved and forgot to update the profile), you lose the query. An AI engine, presented with conflicting information, will either pick the wrong one or deprioritize your profile entirely in favor of a competitor with consistent information.

Byte-identical means exactly that: every character, every abbreviation, every space matters. "500 Oak Avenue" is not the same as "500 Oak Ave." for entity purposes — they are technically different strings. If one profile uses the abbreviation and another uses the full word, an automated system comparing the two will see them as non-matches. For maximum clarity and cross-compatibility, the standard is (a) use the official, full-word form everywhere ("Avenue" not "Ave.", "Suite" not "Ste."), (b) use the same formatting for the city/state/ZIP combination everywhere, and (c) never swap phone numbers between locations or abbreviate address components inconsistently.

An entity graph is a network of nodes (entities: organizations, people, places) and edges (relationships: works for, located in, member of, sameAs). AI engines build and use entity graphs to understand which entities are mentioned in which documents and how they relate. For your law firm, the entity graph includes: your firm organization node, each attorney node (with worksFor → firm), your office locations, your service areas (cities/states you serve), and your external profiles (GBP, LinkedIn, Avvo, Justia, Wikidata).

Schema.org provides the vocabulary to encode this graph. On your website, you declare the firm with an Organization node (or LocalBusiness for multi-office firms) and each attorney with a Person node. The firm node carries `name`, `address`, `telephone`, `url`, and critically, `sameAs` — a list of URLs pointing to your profiles on Google Business Profile, LinkedIn, Avvo, and Justia. Each attorney node carries `worksFor` (pointing back to the firm `@id`) and their own `sameAs` (personal LinkedIn, bar profile). This is the schema-side entity graph.

The web-side entity graph is built by AI engines crawling the web and extracting mentions. When an AI engine encounters your firm name on Avvo, it extracts that mention and links it to your firm node. When it finds your name on Justia, the same thing. When it finds a review of your firm on Google, another link. Over time, the engine accumulates hundreds or thousands of mentions and reviews of your firm across the web, all pointing to the same entity. This is your firm's mention graph. The denser and more authoritative the mentions, the higher the engine's confidence that you are a real, legitimate, cited entity.

The critical insight: the schema-side graph (the `sameAs` links in your JSON-LD) is the *declared* identity. The web-side graph (the actual mentions across the internet) is the *earned* identity. A strong entity requires both. If your schema declares `sameAs` to GBP, LinkedIn, and Avvo, but you have no profile on those platforms, the declaration is a false signal. Conversely, if you have profiles on every platform but do not declare the `sameAs` links in schema, the engine has to infer the connections (which it usually can, but not always). Best practice: declare the `sameAs` links in schema AND actively maintain the profiles so the earned mentions match.

Off-site corroboration—mentions of your firm on high-authority third-party websites like Avvo, Justia, Google Business Profile reviews, legal directories, and LinkedIn—is how AI engines validate that you are a real entity. If your website claims you are "the best personal injury firm in Phoenix," that is a self-serving claim. But if Avvo, Justia, and five Google reviews independently say you handle personal injury in Phoenix, the AI engine treats that as third-party corroboration. Trust is earned through repetition and consistency across independent sources.

This is why law firms have traditionally relied on legal directories—Avvo, Justia, FindLaw, LawInfo—as part of their online presence strategy. These directories aggregate attorney profiles and are indexed by Google, Bing, and increasingly by AI search engines. A strong directory profile is not primarily for direct traffic (few users navigate to Justia to find a lawyer; they Google and land on you or a directory). Instead, it is for entity authority. The directory profile is a third-party corroboration point: "X Law Firm was listed on Justia for 12 years with N reviews and a description of their practice." That history and review volume becomes a signal to AI engines that the firm is legitimate.

Google Business Profile is the single most important corroboration source for local law firms. A GBP profile with (a) byte-identical NAP, (b) a complete description, (c) hundreds of real reviews, and (d) verified business attributes (license number, service areas, office hours) is how Google—and through Google, AI engines—validates your firm's local identity. GBP is not primarily a marketing channel; it is your firm's official card of local entity identity. Law firms that neglect GBP are leaving their entity signal on the table.

LinkedIn serves a different function: founder and attorney entity clarity. If your firm founder is a named LinkedIn profile with a detailed history, education, and connections, AI engines can corroborate that the founder is a real person. When your website schema includes a `Person` node with `sameAs` pointing to the founder's LinkedIn, the engine can cross-verify. This is especially valuable for solo practitioners and small firms where the attorney's reputation IS the firm's authority.

Wikidata and Wikipedia are emerging entity validators for law firms. If your firm is large enough or well-known enough to be mentioned in a Wikipedia article about your practice area (e.g., a notable law firm mentioned in the "Personal injury law in California" article), Wikidata will assign your firm a Q-ID (entity identifier). Claiming that Q-ID in schema (`sameAs: wikidata.org/entity/Q...`) is a powerful entity signal—it tells AI engines "this firm is notable enough to be in a knowledge base." Most solo and small firms will not reach Wikipedia; mid-market and large firms can strategically pursue this.

Implementing NAP consistency and the entity graph in schema.org is straightforward but requires discipline. The pattern is (1) declare one firm Organization node with `@id` (e.g., `#organization`), (2) list byte-identical name, address, phone, and `sameAs` on that node, (3) declare Person nodes for each attorney with `worksFor` pointing to the firm node and their own `sameAs`, and (4) on every location page, reference the firm node and add location-specific LocalBusiness or GeographicalArea nodes where appropriate. Never re-declare the firm node on every page; always reference the single source-of-truth definition by `@id`.

The firm Organization node should live in your root layout or footer (included on every page) and carry: `@context: schema.org`, `@type: LegalService` (or `LocalBusiness` for a single physical office), `@id: http://yoursite.com/#organization`, `name: byte-identical official name`, `address: {streetAddress, addressLocality, addressRegion, postalCode, addressCountry}`, `telephone: E.164 format, e.g. +1-555-0123`, `url: https://yoursite.com`, `image: logo`, and critically, `sameAs: ["https://www.google.com/business/profile/...", "https://www.linkedin.com/company/...", "https://www.avvo.com/...", "https://justia.com/lawyers/...", "https://www.wikidata.org/entity/Q..."]`. Each URL in `sameAs` must actually exist and must refer to your actual profile.

The Person nodes for attorneys should carry: `@type: Person`, `@id: http://yoursite.com/#attorney-name`, `name: full name`, `jobTitle: Practice areas and title`, `worksFor: {"@id": "#organization"}` (relative reference to the firm node), `sameAs: ["https://www.linkedin.com/in/...", "https://www.avvo.com/attorney/...", "https://justia.com/lawyers/..."]`, `hasCredential: {barLicense, issuer: state bar}`, and optionally `alumniOf: university`. The attorney's Person node does not redeclare the firm's details; it references the firm and adds attorney-specific information.

On local pages (city or practice-area pages), reference the firm node and optionally add geographic or service context: `"areaServed": {"@type": "City", "name": "Phoenix", "sameAs": "https://www.wikidata.org/entity/Q16561"}`. The `sameAs` link to Wikidata for the city tells AI engines that when you say "Phoenix," you are referring to the specific geographic entity in Arizona, not any other place named Phoenix. This disambiguation is high-value.

A key anti-pattern to avoid: do not update `dateModified` on your firm Organization node unless the NAP or firm description actually changed. If you are only updating a blog post, update the `dateModified` on the blog article node, not the organization node. Constantly changing the org node's modification date can signal to AI engines that the entity itself is unstable.

The most frequent NAP errors law firms make are (1) abbreviating the firm name inconsistently ("Smith Law" on website, "Smith & Associates" on GBP, "Smith & Assoc" in directories), (2) using different formats for the address ("Suite 100" vs. "Ste. 100" vs. omitting the suite entirely), (3) listing multiple phone numbers but different ones on different platforms ("Main office" on website, "Intake line" on GBP), (4) forgetting to update NAP after a move or merger, and (5) adding special characters or extra words to the firm name on some profiles but not others.

The consequence of each error: (1) Name inconsistency causes AI engines to treat "Smith Law" and "Smith & Associates" as potentially different entities, fragmenting your signal. (2) Address format inconsistency triggers entity-matching algorithms to say "these are close but not identical," which is worse than very close—it introduces doubt. (3) Multiple phone numbers on different profiles create ambiguity: does the firm have two offices? Are these old numbers? The engine will prefer the profile with the most reviews or authority and prioritize that phone number. (4) A move creates a temporal problem: old mentions of your old address pile up, and the engine might weight them heavily, leading to confusion about your current location. (5) Special characters (trademark symbols, apostrophes, unusual punctuation in firm names) sometimes get stripped or encoded differently across platforms, causing mismatches.

Audit your NAP quarterly. Pull your website's Organization node schema, your GBP profile, and your top five directory profiles (Avvo, Justia, LinkedIn, LawInfo, State Bar listing), and compare them directly. Make a spreadsheet: Website NAP, GBP NAP, Avvo NAP, Justia NAP, LinkedIn NAP. If any cell differs, it is a bug. Fix the source of the inconsistency (usually the secondary profiles lag behind website changes), and retest weekly until they converge. Tools like BrightLocal or Yext can automate some of this, but for law firms, manual quarterly audits combined with a consistent update protocol ("every time the website NAP changes, we update GBP and notify the directories") is sufficient and more cost-effective.

Every local page on your website—city pages, office pages, service-in-location pages—must render the byte-identical NAP for that location. If your Phoenix office's actual address in Google Business Profile is "Smith Law, 123 Main Street, Suite 100, Phoenix, AZ 85001, 602-555-0123," then your website's Phoenix page must display that exact address and phone number in the visible content and in the structured data. No shortcuts, no abbreviations, no variations.

This is where many law firms fail. A lazy implementation creates a template ("[City] Office: [Address]") and fills in the city name dynamically but hard-codes the address/phone for one office. The result: the Denver page displays the Denver office's real address, but the Chicago page displays the Denver address with just the city name swapped. This is a doorway page—it lies about the Chicago office, and AI engines will either fail to cite it or demote it for false information.

Best practice: parameterize the NAP data by office/location. Store each office's address and phone in a data file (a JSON object or a Supabase table), then render it dynamically on each location page. This ensures (a) consistency—you update the data once, and every page reflects it, and (b) scalability—when you open a new office or move, you update one data source and every page automatically uses the correct NAP.

For multi-office firms, create a locations page that lists all offices with consistent formatting and schema. Each office gets its own LocalBusiness node with its own address, phone, and hours. On individual city pages, reference the specific office. This builds the entity graph: the firm node → many office LocalBusiness nodes → each office rooted in a specific place. AI engines can then correctly attribute information to the right location.

The reason entity SEO is the emerging competitive moat for law firms is compounding. A traditional SEO strategy for a law firm might target specific keywords: "personal injury lawyer in Phoenix," "medical malpractice attorney in Arizona," etc. Each keyword is an isolated ranking battle. Competing against the top 10 pages for each keyword is expensive and finite—there are only so many high-value keywords.

Entity SEO reverses this. Instead of competing on individual keywords, you compete on entity authority: "Is your law firm such a well-known, corroborated, consistently-mentioned entity that AI engines recognize you as the answer for ANY query about personal injury law in Phoenix?" Once your entity is strong (byte-identical NAP, fifty directory mentions, five hundred Google reviews, multiple `sameAs` links, consistent internal entity graph), you win queries you never explicitly targeted. An AI engine receives a query like "what happens if I'm partially at fault in a car accident in Phoenix?" It does not search for that exact phrase; it searches for relevant entities and passages. If your firm is a recognized entity for personal injury in Phoenix, and your website has a passage answering that question, you get cited—without ever optimizing for that keyword.

This compounds because each new directory listing, each new review, each new `sameAs` link increases your entity's visibility and trust. A firm with one directory listing competes in one place. A firm with ten directories plus strong reviews plus a Wikipedia mention competes everywhere AI engines look. The entity becomes self-reinforcing: more mentions → higher authority → more likely to be included in retrieval results → more traffic from AI → potential for more reviews and earned media.

For law firms, the implication is clear: invest in entity infrastructure (NAP consistency, directory enrollment, review management, schema implementation) first. It is cheaper and more durable than keyword-by-keyword content and PPC. It compounds over time. And it is the only strategy that scales to the dozens (or hundreds, for large firms) of practice-area and location combinations you might target. Build the entity once, correctly, and it works for all of them.