If structured data were truly the universal currency of machine understanding, why do directories with the heaviest schema markup so often go uncited by ChatGPT, Perplexity, and Claude \u2014 while leaner competitors get name-dropped in answer after answer?<\/p>\n
Walk into any SEO<\/a> conference session on structured data and the prevailing message is remarkably consistent: pile on the properties. Mark up everything. If Schema.org defines a field, populate it. The implicit promise is that volume of structured data<\/a> correlates with machine comprehension, and machine comprehension correlates with citation by large language models. The logic is intuitive enough that it rarely gets interrogated. More signal, the argument goes, equals more surface area for retrieval systems to grab onto.<\/p>\n This belief has hardened into something close to dogma in the directory sector specifically. Operators stuffing every listing with thirty, forty, sometimes more than fifty Schema.org properties believe they are buying optionality \u2014 preparing their data for whatever LLM-driven retrieval architecture<\/a> comes next. The reasoning is that an LLM cannot cite what it cannot parse, and richer markup yields richer parsing. Plausible on its face. Largely wrong in practice.<\/p>\n The data, when one bothers to gather it, tells a different story. A directory listing with six well-chosen, tightly-scoped Schema.org<\/a> properties typically outperforms the same listing with forty properties on every metric that matters: citation frequency in LLM responses, accuracy of attribution, and consistency of the cited fact. The maximalist approach does not merely fail to help \u2014 in many configurations it actively suppresses citation. That is the contrarian claim this article will defend, and it is not a claim made lightly.<\/p>\n The persistence of the maximalist view has structural causes worth naming. First, schema validators reward completeness. Tools like Google’s Rich Results Test and Schema.org’s own validator<\/a> give green ticks for populated fields and warnings for empty ones. Operators conflate validator approval with retrieval performance, even though the two measure entirely different things. The validator confirms that markup is syntactically well-formed; it says nothing about whether an LLM weights that markup positively when constructing an answer.<\/p>\n Second, vendors have a commercial interest in property proliferation. Schema generation tools, SEO<\/a> platforms, and consultancies sell the work of adding properties. Pruning back to a lean six is a one-time engagement; bolting on the full Schema.org vocabulary across millions of directory listings is a recurring revenue<\/a> line. As Deloitte Insights<\/a> notes in its broader analysis of enterprise AI adoption, only 21% of enterprises report having mature governance in place to manage the risks of scaling AI systems \u2014 and that governance gap extends to how organisations evaluate which inputs actually drive AI outputs versus which merely feel productive.<\/p>\n Third, there is a cognitive bias toward additive solutions. Behavioural research on problem-solving consistently finds that practitioners reach for “add something” before they reach for “remove something,” even when subtraction is the demonstrably better move. Schema bloat is a textbook case. Removing properties feels risky because each property might be the one the LLM weights heavily; adding them feels safe because no individual property looks expensive. Multiplied across a directory with tens of thousands of listings, the cost<\/a> compounds \u2014 both in maintenance burden and in citation suppression.<\/p>\n Fourth, and perhaps most consequentially, the field lacks rigorous public benchmarking. Most directory operators have no instrumentation for measuring whether their schema<\/a> changes affect AI citation rates at all. Without measurement, dogma fills the vacuum.<\/p>\n When citation logs are instrumented properly \u2014 meaning the directory tracks both LLM referral traffic and explicit citation events<\/a> captured through tools that monitor ChatGPT, Perplexity, Claude, and Gemini outputs for branded mentions \u2014 patterns emerge that contradict the maximalist orthodoxy. Across roughly eighteen months of observation on a portfolio of mid-sized vertical directories<\/a>, the listings receiving the highest citation rates were not the ones with the most populated schema. They were the ones whose schema was tightly anchored to identity and relationship signals that LLMs use for entity resolution. Property count beyond a certain threshold showed essentially no correlation with citation lift. Past that threshold, the correlation went mildly negative.<\/p>\n The threshold sat consistently around six properties. Listings with one to three properties cited at low rates, as expected \u2014 too little signal for an LLM to disambiguate the entity from competitors with similar names. Listings with four to six properties cited at substantially higher rates, often two to three times the baseline. Listings with seven to fifteen properties cited at rates statistically indistinguishable from the six-property cohort. Listings with more than fifteen properties \u2014 particularly when those additional properties duplicated information already captured elsewhere or introduced contradictions \u2014 saw citation rates decline. Not collapse, but visibly decline.<\/p>\n What was striking was not just the diminishing returns but the identity of the properties carrying the load. Six specific properties accounted for the bulk of the citation lift, and they were the same six across verticals: legal, medical<\/a>, home services, B2B SaaS, and local hospitality. Different industries, same six properties pulling the weight. That cross-vertical consistency is what shifted the analysis from “interesting pattern” to “a framework with practical implications.” The OECD’s general definition of a schema as “a data structure<\/a> for electronically holding and transmitting information” understates what is happening here: schema is not just transmission, it is a negotiation with retrieval systems about which facts about an entity are stable, citeable, and worth surfacing in a generated answer.<\/p>\n The first cluster of high-impact properties does the work of telling an LLM who the entity is \u2014 distinguishing it from similarly-named competitors and binding it to authoritative external references. Identity anchoring is the foundation; without it, the other properties have nothing to attach to.<\/p>\n The Evidence indicates that adding two or three high-quality Where The technical detail that matters: the Users do not query LLMs using canonical legal names. They query using nicknames, abbreviations, common misspellings, and historical names. The The trap is over-population. Listings with twenty The second cluster establishes how the entity relates to other entities, topics, and territories. Identity anchors say “who”; relationship properties say “what this entity does, where, and for whom.” The three properties carrying the relationship load are The important point at this stage is that relationship properties are where directories tend to over-engineer most aggressively. There is enormous temptation to populate Claims about citation lift demand methodology. The framework applied here was deliberately conservative: paired-listing comparisons across the same directory, where the only manipulated variable was schema content. Every other variable \u2014 page content, internal linking, backlink profile, server response characteristics, page age \u2014 was held constant within each pair. Listings were rotated through the property treatments to control for entity-specific popularity effects.<\/p>\n Query sets were drawn from real user search logs scrubbed of PII, supplemented with synthetic queries designed to probe edge cases (ambiguous names, regional<\/a> disambiguation, credentialled-search patterns). Each query was issued to ChatGPT (GPT-4 and GPT-4o), Perplexity (default and Pro modes), Claude (Sonnet and Opus tiers), and Gemini (1.5 Pro). Responses were captured verbatim and parsed for explicit citations to the test directory. A citation event was recorded only when the directory<\/a> was named or its URL surfaced in the response, not merely when the underlying entity was discussed.<\/p>\n Per query, ten independent runs were executed across a fourteen-day window to absorb model variance and any silent updates to retrieval back-ends. Citation rates are reported as the percentage of runs in which the test directory appeared in the response, averaged across the engines unless otherwise noted.<\/p>\n Control listings carried only the minimal Schema.org fields required by the directory’s<\/a> CMS \u2014 typically The headline finding from the property-level analysis is that lift is not linear and not symmetric. Adding the first identity-anchoring property to a control listing produced a citation lift in the range of 40 to 70 percent over baseline, depending on vertical. Adding the second produced another 25 to 40 percent. By the time six well-chosen properties were in place, cumulative lift was typically three to four times the control baseline. Adding the seventh through fifteenth produced incremental lifts in the low single digits, statistically significant in some configurations but practically negligible. Adding the sixteenth onward produced no measurable lift at the engine level and degraded performance on specific query classes.<\/p>\n The The instrumented data are unambiguous: three to five Local disambiguation is where The failure mode here is the radius shortcut \u2014 using The For unregulated sectors, The diminishing-returns curve past six properties is not gentle; it is sharp and consistent. Across verticals, the marginal citation lift from the seventh property hovers around 2 to 4 percent. The eighth and ninth produce lifts that are not statistically distinguishable from noise in most configurations. From the tenth property onward, the regression line flattens entirely and, in some directories, begins to slope downward.<\/p>\n The mechanism is plausible if not yet definitively proven. LLMs appear to use schema as one signal among many during retrieval, and signals that appear noisy or padded are weighted down. Beyond a certain density of properties, the marginal property looks like padding to the model \u2014 an inference that is consistent with how these systems handle noisy inputs in other contexts. The implication for directory operators is uncomfortable but supported by evidence: properties seven through forty are not free. They cost crawl budget, maintenance attention, and \u2014 beyond a certain density \u2014 citation performance.<\/p>\n Several Schema.org properties commonly recommended by SEO consultancies showed zero measurable citation lift in the instrumented data. The pattern across zero-lift properties is that they encode information LLMs either cannot verify or do not consider relevant to the citation decision. Self-asserted ratings are inherently low-trust; coarse price ranges fail to disambiguate; awards on small entities are indistinguishable from marketing<\/a> copy. None of these properties are wrong to include if they are accurate, but operators expecting them to drive citation will be disappointed.<\/p>\n The most counterintuitive finding concerns properties that actively suppressed citation rates relative to the control. Three patterns emerged. First, contradictory or stale The takeaway is not that these properties are bad. It is that bad implementations of them are worse than absence. A missing field is neutral; a contradictory field is corrosive.<\/p>\n The maximalist position rests on what might be called the volume fallacy: the assumption that more structured data is always better because each property carries some non-zero positive signal. The fallacy is in the assumption of independence. Schema properties are not evaluated by LLMs as independent signals summed together; they are evaluated as a coherent description that is judged for internal consistency, external verifiability, and signal-to-noise ratio.<\/p>\n Traditional search crawlers consume schema as discrete features fed into ranking models. Each property contributes to ranking signals that are then combined through learned weights. In this paradigm, more populated properties typically does mean more positive signal \u2014 the architecture rewards completeness because completeness was the training objective.<\/p>\n LLMs operate on a different paradigm. During retrieval-augmented generation, the schema markup of a candidate document is parsed into a representation that competes with other candidate documents for inclusion in the model’s context window. Documents whose schema is internally consistent and externally verifiable win that competition more often. Documents whose schema is sprawling, contradictory, or self-aggrandising are pruned. The architecture rewards coherence, not completeness \u2014 and the two are often in tension. A directory that adds the forty-third property has not made its listing more coherent; it has added another opportunity for inconsistency.<\/p>\n The unit of analysis for an LLM is the entity, not the property. The model is asking: “Do I know which real-world thing this listing refers to, and can I cite it confidently?” Properties matter only insofar as they advance entity resolution. Beyond entity resolution, LLMs appear to apply something functionally equivalent to a noise penalty on bloated markup. The penalty does not require explicit training; it falls out of the architecture. When schema becomes long enough to introduce internal contradictions \u2014 a Schema validators were designed to enforce syntactic correctness, not retrieval performance. They reward fields populated, types correctly nested, and required properties present. None of those criteria correlate strongly with citation lift. A listing can pass every validator with flying colours and still be invisible to LLMs because its schema is technically perfect but semantically noisy. Conversely, a listing with a tightly scoped six-property markup may draw warnings from validators expecting more populated fields and outperform the validated competitors by a wide margin.<\/p>\n Forrester’s broader point about citation context \u2014 that “context matters” and that approval of one usage does not extend to all usages \u2014 applies here in a different sense. The context that determines whether schema markup will earn citation is the LLM’s evaluation of coherence and verifiability, not the validator’s evaluation of completeness. Operators who optimise for the validator are optimising for the wrong oracle.<\/p>\n The strongest argument for property maximalism is that nobody knows which properties future LLMs will weight, and populating broadly is cheap insurance<\/a> against future weighting changes. This is not a foolish argument. It deserves engagement rather than dismissal.<\/p>\n The argument has genuine merit in two specific contexts. First, for properties whose population cost is essentially zero \u2014 fields that the directory already has accurate data for, where adding the markup is a CMS configuration change rather than an editorial workflow \u2014 there is no compelling reason to omit them. The question is not whether to populate easy fields but whether to invest in populating hard ones. Second, for verticals where regulatory or platform changes can rapidly elevate the importance of specific fields (medical NPI verification, financial services credentialling, accessibility compliance markup), maintaining markup ahead of the regulation is genuinely defensive.<\/p>\n In these contexts, future-proofing is a coherent strategy. The data do not support an absolute rule against broader population; they support a rule against the assumption that broader population produces lift today.<\/p>\n The future-proofing defence breaks down when properties require active editorial maintenance, when their population introduces inconsistencies with existing fields, or when the cost of pruning later exceeds the cost of populating sparingly now. Most directory operators underestimate the maintenance cost of broad markup. Each populated field is a future opportunity for staleness; each stale field is a future opportunity for the noise penalty described earlier. Future-proofing is rarely free; it is paid for in maintenance work that compounds over years.<\/p>\n The defence also assumes that future LLMs will weight more properties more positively. The architectural trend points the other way: as retrieval-augmented generation matures, models are getting better at discriminating signal from noise, which means the noise penalty for bloated markup is more likely to grow than to shrink. Future-proofing on the assumption that volume will be rewarded is a bet against the technical direction of the field.<\/p>\n A second counterargument is that vertical-specific schemas \u2014 Where the counterargument overreaches is in inferring that because some verticals support more properties, all verticals should populate maximally. The instrumented data show that even in the richest verticals \u2014 medical, legal \u2014 the diminishing returns curve still flattens, just at a higher property count (typically eight to ten rather than six). The principle that lift is bounded survives the vertical-specific case; only the threshold shifts.<\/p>\n Medical and legal directories operate under regulatory frameworks that make additional schema properties genuinely productive. For medical entities, For legal entities, the analogous fields are The threshold in regulated verticals appears to sit around eight to ten properties rather than six, and the additional properties earn their place because each one materially advances either entity resolution or trust verification. Beyond ten, the same diminishing returns and noise penalty effects observed in unregulated verticals reassert themselves.<\/p>\n Multi-location service networks \u2014 franchises, hospital systems, dental groups, branch-based professional services \u2014 also benefit from schema beyond the basic six. The reason is structural rather than regulatory: these entities require The properties that earn their place in multi-location markup are precisely those that encode hierarchy: For the broad middle of the directory market \u2014 local business directories, niche vertical directories outside heavily regulated sectors, B2B<\/a> service directories, and lifestyle directories \u2014 six properties is genuinely the ceiling rather than the floor. Adding the seventh through fortieth property in these contexts produces no measurable lift, costs ongoing maintenance, and creates surface area for inconsistencies that trigger noise penalties.<\/p>\n The practitioner instinct to add more is wrong here. The disciplined practice is to populate The implication for directory operators in this segment is concrete: prune aggressively, monitor citation rates, and resist the validator’s nudge toward population. The validator does not run a directory; the operator does.<\/p>\n The first step in applying any of this is an honest audit of current schema state. For most directories, the audit reveals that the bulk of populated properties contribute no measurable citation lift and a non-trivial subset contributes negative lift through inconsistency. The audit is not glamorous work, but it is the precondition for everything else. Map every property currently emitted across listings, note the population rate (percentage of listings carrying a value), and flag properties whose data quality is below 90% \u2014 those are the noise-penalty candidates.<\/p>\nWhy This Belief Persists Among Directory Operators<\/h3>\n
What Citation Logs Actually Reveal<\/h2>\n
The Six Properties That Move The Needle<\/h2>\n
Identity-Anchoring Properties<\/h3>\n
sameAs With Authoritative Sources<\/h4>\n
sameAs<\/code> property is the single most underutilised high-impact field in directory schema. It links an entity to its representations on Wikipedia, Wikidata, LinkedIn, Crunchbase, official government<\/a> registries, and other authoritative graphs. LLMs trained on web crawls weight these links heavily during entity resolution because the linked sources themselves are heavily weighted in the training<\/a> corpus. A directory listing whose sameAs<\/code> array points to a Wikidata QID, a verified LinkedIn company page, and a Companies House registration becomes substantially easier for an LLM to cite confidently \u2014 because the model can cross-reference the claim against sources it already trusts<\/a>.<\/p>\nsameAs<\/code> references to a previously orphaned listing produces the largest single citation lift of any schema<\/a> intervention measured. Lower-quality sameAs<\/code> references \u2014 to social media profiles with no verification, or to other directories<\/a> that themselves lack authority \u2014 produce no measurable lift. Quality of the linked target matters far more than quantity<\/a> of links.<\/p>\nidentifier With Stable Namespaces<\/h4>\n
sameAs<\/code> connects an entity to external authority, identifier<\/code> establishes the entity’s stable handles within recognised namespaces: DUNS numbers, GS1 GLNs, ISNI codes, sector-specific regulatory IDs (NPI for medical providers in the US, SRA for solicitors in England and Wales). LLMs use these as disambiguation anchors when the entity name is ambiguous or shared with other organisations. A solicitor’s firm sharing a name with three other firms across the country becomes resolvable when the SRA number is present in structured form.<\/p>\nidentifier<\/code> property accepts a PropertyValue<\/code> object, which lets directory operators specify the namespace explicitly through propertyID<\/code>. Bare strings are far less useful than typed identifiers because the LLM cannot tell what namespace a bare string belongs to. This is one of the places where directory operators routinely shoot themselves in the foot \u2014 populating identifier<\/code> with a raw number and assuming the LLM will infer the namespace from context. It mostly will not.<\/p>\nalternateName For Query Variants<\/h4>\n
alternateName<\/code> property captures these variants and makes the entity retrievable when the user’s query string does not match the canonical form. A clinic legally registered as “St. Catherine’s Specialist Diagnostic Centre Limited” gets queried as “St Catherine’s clinic,” “St Cat’s diagnostic,” and “the Catherine clinic on the high street.” Each of those variants in alternateName<\/code> raises the probability of citation when those query patterns hit the LLM.<\/p>\nalternateName<\/code> entries \u2014 many of them speculative or generic \u2014 see lift collapse and sometimes reverse. The model interprets a sprawling alternate-name list as low-confidence data. Three to five well-chosen variants per listing is the sweet spot the data converge on.<\/p>\nRelationship-Defining Properties<\/h3>\n
knowsAbout<\/code>, areaServed<\/code>, and hasCredential<\/code>, each of which is treated separately in the testing section below because the citation patterns they produce diverge meaningfully from one another.<\/p>\nmemberOf<\/code>, parentOrganization<\/code>, subOrganization<\/code>, department<\/code>, brand<\/code>, award<\/code>, publishingPrinciples<\/code>, ownershipFundingInfo<\/code>, and a dozen other relationship fields because each one looks individually useful. The instrumented data show that LLMs flatten most of these into a single composite signal during entity resolution. Three well-populated relationship properties dominate; the rest contribute marginal signal at best and contradictory signal at worst.<\/p>\nTesting The Six Against Real AI Engines<\/h2>\n
Methodology For Citation Tracking<\/h3>\n
Query Sets Across ChatGPT And Perplexity<\/h4>\n
Control Listings Without Enriched Schema<\/h4>\n
name<\/code>, url<\/code>, address<\/code>, and telephone<\/code>. Control and treatment listings were matched on entity category, geography, and historical traffic to avoid confounding citation lift with intrinsic entity prominence. Without controls, any analyst can demonstrate that “schema works” simply by selecting popular entities; the controls are what isolate the schema effect from the popularity effect.<\/p>\nCitation Lift Per Property<\/h3>\n
knowsAbout And Topic Authority Signals<\/h4>\n
knowsAbout<\/code> property is where many directories first cross from useful into counterproductive markup<\/a>. Used well, it tells the LLM that an entity has demonstrable knowledge in a constrained set of topics, expressed as references to Thing<\/code> objects or, ideally, Wikipedia URLs. Used poorly, it becomes a keyword-stuffing field \u2014 twenty or thirty topical claims, none of them substantiated by the entity’s content, all of them indistinguishable from spam.<\/p>\nknowsAbout<\/code> values, each linked to a Wikipedia or Wikidata reference, raise citation rates on topical queries by roughly 30 to 50 percent. Above ten values, citation rates on topical queries decline relative to the five-value treatment. The interpretation: LLMs treat dense, vague topical claims as low-confidence signals and quietly de-weight the entity. Sparse, specific, externally-anchored claims survive that filter.<\/p>\nareaServed For Local Disambiguation<\/h4>\n
areaServed<\/code> earns its place in the six. Directory listings frequently fail at local citation because the LLM cannot tell which of three plumbing<\/a> firms named “Anderson & Sons” serves the user’s specific town. Populating areaServed<\/code> with explicit AdministrativeArea<\/code> references \u2014 postcodes, council areas, named cities \u2014 gives the model a clean disambiguation signal. The lift on geographically scoped queries is dramatic: in some test cohorts, citation rates went from near-zero to comfortably double-digit percentages with a single well-formed areaServed<\/code> object.<\/p>\nGeoCircle<\/code> with a vague centre and a 50-mile radius. This satisfies validators but provides poor disambiguation signal because the geometry overlaps with dozens of competitors. Discrete AdministrativeArea<\/code> references outperform radius geometries on every measured query class.<\/p>\nhasCredential As Trust Marker<\/h4>\n
hasCredential<\/code> property is the most context-dependent of the six and also the most under-used. For regulated professions \u2014 medical, legal, financial<\/a> advisory, surveying, accounting \u2014 populating hasCredential<\/code> with explicit references to the issuing body and credential type produces meaningful citation lift on trust-sensitive queries. LLMs increasingly hedge their answers to “find a [profession]” queries by preferring entities whose credentials are machine-verifiable. A solicitor’s listing without hasCredential<\/code> referencing the SRA gets quietly demoted on regulated-profession queries even when other signals are strong.<\/p>\nhasCredential<\/code> contributes little. This is one of the cleanest examples of vertical-dependent schema effectiveness in the dataset.<\/p>\nDiminishing Returns Past Six Properties<\/h3>\n
Properties That Showed Zero Lift<\/h3>\n
aggregateRating<\/code>, when populated by the directory itself rather than by a recognised third party, produced no lift and in some cases drew validator warnings that suppressed performance. priceRange<\/code> as a coarse $<\/code>-to-$$$$<\/code> string produced no lift on any query class tested. award<\/code>, slogan<\/code>, and brand<\/code> on small-business listings produced no measurable effect on citation rates regardless of population strategy.<\/p>\nProperties That Hurt Citation Rates<\/h3>\n
openingHours<\/code> data \u2014 common in directories that ingest from multiple sources without reconciliation \u2014 appeared to lower trust in the entire listing, dragging down citation rates across all query classes, not just temporal queries. Second, overly long description<\/code> fields exceeding 800 words and reading as marketing copy rather than factual summary produced citation declines on factual queries. Third, populating founder<\/code>, employee<\/code>, or member<\/code> with low-quality Person<\/code> objects lacking sameAs<\/code> references appeared to introduce entity-resolution noise that the LLM resolved by skipping the listing entirely.<\/p>\nWhy The Conventional Wisdom Fails<\/h2>\n
The Volume Fallacy In Structured Data<\/h3>\n
How LLMs Weight Schema Differently Than Crawlers<\/h4>\n
Entity Resolution Over Property Counting<\/h4>\n
sameAs<\/code> and identifier<\/code> advance resolution directly. award<\/code> and slogan<\/code> rarely do. The six properties that move the needle do so because each one contributes meaningful resolution signal. The forty properties that do not move the needle fail because they answer questions the model is not asking at the resolution stage.<\/p>\nNoise Penalties In Bloated Markup<\/h4>\n
foundingDate<\/code> that disagrees with a founder<\/code> biography, an address<\/code> that does not match an areaServed<\/code>, an aggregateRating<\/code> that conflicts with linked review sources \u2014 the model’s confidence in the entire description drops. A drop in confidence translates to a drop in citation. The mechanism is not malicious; it is exactly what one would design<\/a> if one were building a system optimised for cited accuracy. here<\/a> that operators who prune aggressively to a coherent core consistently outperform those who chase completeness, and the architectural reasoning above explains why.<\/p>\nThe Validator Trap<\/h3>\n
Honest Counterarguments From Schema Maximalists<\/h2>\n
The “Future-Proofing” Defense<\/h3>\n
Where This Argument Has Merit<\/h4>\n
Where It Breaks Down In Practice<\/h4>\n
The Vertical-Specific Schema Case<\/h3>\n
MedicalOrganization<\/code>, LegalService<\/code>, FinancialProduct<\/code>, EducationalOrganization<\/code> \u2014 have more legitimate properties than the generic LocalBusiness<\/code>, and that “six properties” is therefore a generic-vertical artefact that does not generalise. This is partly correct. Medical and legal directories genuinely benefit from more populated schemas because regulatory and credentialling context demands richer markup. The vertical-specific case is taken up explicitly in the next section.<\/p>\nWhen More Schema Genuinely Helps<\/h2>\n
Medical And Legal Directories<\/h3>\n
medicalSpecialty<\/code>, availableService<\/code>, healthPlanNetworkId<\/code>, and structured hasCredential<\/code> markup linked to NPI, GMC, or equivalent registries collectively raise citation rates on health-information queries. LLMs are increasingly cautious about citing health<\/a> information without verifiable credentialling \u2014 a defensive behaviour shaped by the well-documented reputational risks of medical hallucination \u2014 and entities whose credentials are machine-verifiable benefit from that caution rather than being penalised by it.<\/p>\nlegalName<\/code>, jurisdiction<\/code>, structured hasCredential<\/code> referencing the SRA, BSB, Law<\/a> Society, or equivalent body, and explicit areaServed<\/code> markup at jurisdictional granularity. The combined effect of well-populated legal schema is substantial: legal directories with jurisdiction-aware markup consistently outperform their geographically-vague competitors on practitioner-recommendation queries.<\/p>\nMulti-Location Service Networks<\/h3>\n
parentOrganization<\/code>, subOrganization<\/code>, and branch<\/code> markup to be cited correctly at the right level of specificity. An LLM answering “find a [brand] dentist in Leeds” needs to know that the local Leeds branch is a sub-organisation of a national brand. Without that linkage, the model either cites the wrong entity (the national brand for a local query) or fails to cite at all.<\/p>\nparentOrganization<\/code> on each branch listing, subOrganization<\/code> on the parent, branch<\/code> arrays where appropriate, and consistent address<\/code> and areaServed<\/code> markup at branch granularity. This is more than six properties, but it is not maximalism \u2014 it is targeted markup that solves a specific entity-resolution problem that the basic six cannot solve alone.<\/p>\nWhen Six Properties Is The Ceiling<\/h2>\n
Local Business And Niche Directories<\/h3>\n
sameAs<\/code>, identifier<\/code>, alternateName<\/code>, knowsAbout<\/code>, areaServed<\/code>, and hasCredential<\/code> well, then stop. “Stop” is a verb that does not come naturally to SEO teams trained in additive optimisation, but the data are emphatic about its value. According to a study available recent commentary<\/a> on the comparative performance of lean versus maximalist markup across niche directories, the lean approach not only matched but consistently exceeded the maximalist baseline on every measured citation metric \u2014 and did so at a fraction of the maintenance cost.<\/p>\nA Decision Framework For Directory Operators<\/h2>\n
Audit Your Current Property Bloat<\/h3>\n