Common Legal Schema Mistakes: aggregateRating, @id, and Content Drift

A law firm adds an aggregateRating node to its Organization schema: "ratingValue": 5.0, "ratingCount": 47. Google ignores it. Worse, the firm wonders why its schema is valid in validator.schema.org but no rich-result snippets appear in search results. The reason: Google's helpful-content policy explicitly penalizes self-serving claims, and a firm rating itself 5.0 stars on its own website looks exactly like that.

The correct rule: aggregateRating on the firm Organization node must come from a third-party source (real Google Business Profile reviews, Avvo ratings, Justia reviews). These are signals the firm did not create; they carry credibility. If you put your own fabricated or unsourced rating on your org node, it is ignored. If you misrepresent the GBP rating (claiming 4.8 when GBP says 4.2), it is ignored and harms your domain authority with Google.

For multi-office firms, the mistake multiplies: a single firm-wide 5.0 rating is copied to every city page, even though each city's office has a different GBP rating. A page for your San Francisco office renders a 5.0 star snippet from a Compass Law Group overall rating, even though the SF office's actual GBP rating is 4.6. Clients read the 5.0 and feel misled when they see the real 4.6 on the GBP profile.

The fix: (a) aggregateRating belongs on result/service pages with real, visible third-party reviews — customer testimonials, case-result kudos, GBP reviews quoted with permission. (b) For multi-office firms, each location page gets ITS OWN office's aggregateRating from that office's GBP profile (San Francisco page → SF office's GBP 4.6; Burbank page → Burbank office's GBP rating). (c) Derive the schema value from the same data source as the visible content (a constant or API query), so visible rating + schema rating are always in sync.

One more clarification: Google's "Detected structured data" list in the Rich Results Test will show an aggregateRating even when it is ignored for SERP ranking. The presence in the list does not mean the rating earns you a star snippet. To verify it is being used, check Google Search Console's Rich Results report — only items Google actually uses appear there. If aggregateRating appears in validator.schema.org but NOT in GSC, Google is reading it and ignoring it.

A law firm declares its organization schema with @id: "#organization". On the home page, it works. But on a location page, a developer uses @id: "#org" (a typo, or a copy-paste error from a different template). On another page, @id: "#firm". Now the schema graph contains three separate entities, not one. AI engines see three different "organizations" and cannot link them together. Citations scatter across three entities instead of reinforcing one firm identity.

The root cause: when you use @id, you are naming an entity. The name becomes a global identifier within the schema graph. Any two nodes with the same @id are treated as the same entity; different @ids create different entities. If you want to reference the same firm from multiple pages (as you should), you must use the identical @id string everywhere: @id: "/#organization". Never abbreviate, never vary the casing, never use different aliases.

Here is what the mistake costs: (a) Entity fragmentation — Google's Knowledge Graph sees three separate "law firms" instead of one brand. (b) Citation loss — when an AI engine wants to cite your firm, it has three nodes to choose from, and they are not linked. Your citations get split across them. (c) Relationship breakage — attorney Person nodes have a worksFor property pointing to @id: "#organization", but if the attorney page uses a different org @id, the worksFor link is orphaned. The schema graph becomes a disconnected mess.

The fix: (a) Choose one canonical @id for your firm, your attorneys, your locations. Examples: "/#organization", "/#attorney-scott-wiseman", "/#location-burbank". (b) Declare each entity ONCE in a shared root layout (footer, base template, root schema include) — never re-declare. (c) On every other page, REFERENCE the entity by its @id only, never re-state its properties. (d) Test with validator.schema.org — expand the @graph to see the full entity list. If you see duplicate "Organization" nodes, the @id is split.

Crucially: the @id must use the final, production domain in its URI, not staging or localhost. If you build with @id: "/#organization" on staging and then deploy to production, the @id URL is now wrong (staging domain != production domain). Always pin @ids to the production domain so they are correct at deploy time and do not break during cutover.

A practice-area page visibly displays "Initial consultation: $0 (free)" but the schema has "priceRange": "$200–$500". An FAQ accordion shows six real questions and answers, but the FAQPage schema lists eight invisible questions no one can read. An office page renders the wrong phone number because someone hardcoded it into the address component but forgot to update the schema. These are drift: the visible content and schema no longer describe the same thing.

Drift happens for three reasons: (1) Dynamic updates — content changes (office moved, price went up) but schema is static. (2) Separate sources — visible content is pulled from one API/config, schema from another, and they go out of sync. (3) Invisible content in schema — a developer adds fields to the schema "just in case" (FAQ answers that aren't rendered, ratings that are hidden, comments in code) expecting that fields no longer on the page won't matter. They do matter: Google and AI engines read the schema and expect to find those fields when they visit the page.

Why it damages rankings and citations: Google's Quality Rater Guidelines explicitly warn against schema-content mismatch as a sign of low-quality content. An AI search engine retrieves passages from your page and feeds them to an LLM for citation. If the schema claims an FAQ answer that is not visible, the engine sees a lie and downgrades your credibility. Sites with visible-schema mismatches are associated with low E-E-A-T (expertise, experience, authoritativeness, trustworthiness).

The fix: (a) Derive BOTH visible content and schema from one source of truth — a config file, a database row, or a component prop. (b) Use template logic: if visible content renders a field, the schema renders it from the same variable. (c) Audit before deploy: compare schema fields against the visible page. grep for every schema field name in the page HTML; if it is missing, either add the field to the page or remove it from the schema. (d) Test with curl -A GPTBot to see the server-rendered HTML and verify schema fields are present.

A city page template hardcodes the phone number: . It works in Burbank. But when the template is reused for the Phoenix office, the Burbank number stays hardcoded. Clients in Phoenix call a Burbank number. Or a developer hardcodes the firm's main address into the schema, then a new location opens and the schema still lists only one office. Or a practice-area page hardcodes "We've recovered over $50 million" — a figure that was true in 2023 but is now outdated and the claim is stale.

Hardcoding is a readability problem that scales into a truthfulness problem. Visible hardcoded content is less obvious (you can see the wrong info on the page), but hardcoded schema is invisible and more dangerous. An attorney or AI tool reads the schema and assumes it is accurate, then propagates the false/stale information elsewhere.

The fix: Parameterize everything. (a) Move all dynamic values (phone, address, office name, team member names, case results, statistics) into a data layer (constants, config, API, database). (b) Pass those values as component props. (c) Derive both visible content AND schema from the same prop. (d) On every code review, grep for hardcoded numbers, place names, and phone numbers in the component source. If you find one, move it to data.

Real examples from recent audits: a multi-office firm had 12 location pages, all with the main office address hardcoded in the schema; a practice-area page claimed a settlement amount that had not been updated in two years; an attorney bio page listed credentials that were from a prior role. All were invisible in the schema, discovered only by comparing schema to the live firm database. The fix took hours per site. Parameterizing from the start would have prevented all of it.

A developer adds @type: "SoftwareApplication" to reference ChatGPT, Gemini, or Claude on a page explaining which AI tools law firms use. The type is valid schema.org, but SoftwareApplication is rich-result-eligible, meaning Google has a specification that defines required fields: operatingSystem, applicationCategory, offers (with Offer/priceRange), aggregateRating, url. When the validator scans it, it finds some fields but not all. Google's Rich Results Test shows a warning: "Missing recommended field: aggregateRating". The schema does not earn a rich result in SERP.

The mistake: using a rich-result-eligible type when you only want to mention the app, not describe it fully. You don't have the app's operatingSystem list or price. You don't have real user ratings. You are just naming it.

The solution: for a bare mention (a reference/co-occurrence), use @type: "Thing" or @type: "Organization" (for a company) with name + url + sameAs (link to Wikidata, Wikipedia, or the app's official site). These types have no required fields. Drop the reference in, move on. Save SoftwareApplication, LegalService, Product for nodes where you have the full, required data.

Similarly: do not use @type: "Article.hasPart" pointing to an ItemList or HowTo. Google reads this as a paywall WebPageElement spec and throws an error. Instead, keep ItemList and HowTo as standalone @graph nodes and link them back via isPartOf → #webpage.

An attorney's schema declares name: "Scott Wiseman" on the bio page, but name: "S. Wiseman" on the results page and name: "Scott Michael Wiseman" on a podcast appearance page. The firm is "InterCore Legal Marketing" on the home page, "InterCore Inc." in the footer schema, and "InterCore, Inc." in the state bar listing. Each variation is technically valid, but search engines see them as different entities. The single attorney Scott gets fragmented into three Person nodes; the firm gets fragmented into three Organization nodes. Citations and authority scatter.

The fix: (a) Choose one canonical spelling for every entity: the firm name, every attorney, every practice area, every location. (b) List it in a constants file or schema config. (c) Use it everywhere — visible content and schema. (d) For variations that are real (nicknames, abbreviations, legal vs. common names), use the "alternateName" property in schema, not different "name" values. "name": "Scott Wiseman", "alternateName": ["S. Wiseman", "Scott M. Wiseman"].

Also: every Person and Organization node should carry "sameAs" linking to external authorities: LinkedIn, Wikidata, Wikipedia (for the firm or person), Google Business Profile (for the firm), state bar listing (for attorneys), Avvo, Justia, etc. This is the single strongest signal for entity disambiguation. If two nodes both have name: "Scott Wiseman" but one has sameAs: "https://www.linkedin.com/in/scott-wiseman" and the other does not, Google can tell they refer to the same person. Omitting sameAs leaves the model guessing.

A client blog post ships with inline style="background:#f0f0f0; color:#000; border:1px solid #ddd". On a light website, it looks fine. On a dark website, the text becomes invisible — black text on a dark gray background. Or a table ships with bgcolor="#ffffff" (white), rendering as a bright white block on the dark page, visually jarring and unreadable.

This is not a schema issue, but it is a common drift problem in AI-generated or scraped content. AI writing tools and content-scraping scripts often emit HTML with hardcoded light-theme colors. When imported into a dark site, the colors are wrong.

The fix: strip inline style attributes from content tags (especially tables, divs, blockquotes) at ingest or render time. Let the site's CSS control colors. If you must preserve structure from imported content, move inline styles into a CSS class that the site's theme overrides.