The node of AI presence: why entity connections in JSON-LD decide what models cite

What does your site’s code say about you, exactly? If you open your home page today and look for the JSON-LD block, you will probably find a statement that your brand exists, but with no direct connection to the author who signs the texts or to the holding company that owns the official registration. That fragmentation is what makes artificial intelligence assistants ignore your authorship even when the user’s prompt cites your name word for word.

Language models do not browse the internet the way old search indexers did. They are not looking for keywords scattered across a friendly layout, but trying to resolve semantic entities inside an internal knowledge graph. If your metadata structure delivers only flat, disconnected data, the machine is forced to guess the relationships between what you say and who you actually are. And in the stochastic environment of generated answers, any ambiguity is an invitation for the artificial intelligence to simply ignore your content or attribute your authorship to a competitor with more consistent presence.

Declaring data without establishing semantic connections is a common mistake

Most brands trying to position themselves in the environment of generated answers make the mistake of treating structured data as though it were merely identification labels. They fill in basic Schema.org fields using automated assistants and believe the semantic infrastructure work is finished. That kind of shallow markup only tells the model that an organisation exists at a given URL, but fails to establish the logical relationship that AI systems use to validate information.

How can a language model associate your name with your work if nothing in the code declares that they are the same thing? When information about authorship, editorship, ownership and location appears as loose statements, with no identifier binding them, the machine has no way of knowing that the person described in one place is the same one who wrote the article described in another. And here a common confusion is worth undoing: the problem was never the number of code blocks on the page. Two separate scripts using the same identifier say exactly the same thing as a single block — and a single block with no identifiers says nothing. What connects is identity, not proximity.

We observe that the absence of that identity creates gaps the models fill with hallucinations or, worse, with silence. If your brand has no explicit connections in the code, the language model simply cannot correlate your company’s historical facts with the products you sell. The direct consequence is an invisible presence in conversational search systems, where your real authority is disregarded because it was not translated into the appropriate machine language.

The easy path of shallow markup against the path that works

The traditional marketing market tends to sell quick solutions promising to solve digital presence in a few clicks. That is the easy path: installing a generic SEO plugin that generates automatic surface-level markup, without any customisation or semantic depth. That method benefits only those selling the convenience, since it delivers static code that changes according to standardised rules, without reflecting the real complexity of your organisation or of your authored body of work.

The path that works demands detailed entity engineering, and it is laborious. It consists of mapping your brand’s semantic infrastructure to build a knowledge graph of your own, using the @graph directive in your JSON-LD. Instead of publishing loose statements, we gather every entity into a single block, each declared once only, with its own identifier — and we link them by reference: the web page is part of a site, which in turn is published by a specific organisation, represented by a spokesperson who holds a recognised and verifiable authored body of work.

This cross-referencing process ensures the machine can read your home page and extract, in a single reading pass, the entire tree of your brand’s relationships. That removes the need for probabilistic interpretation on the model’s part. The path that works does not seek shortcuts to fool algorithms, but rather to provide the cleanest and most verifiable data infrastructure possible so generative systems can consume and cite your legacy without hesitation.

How semantic graphs connect entities by identity

What happens when the artificial intelligence crawler finds this loose information? It tries to connect it on its own, and it is precisely in that translation process that coherence is lost. To keep models from autonomously deciding the meaning of your brand, JSON-LD markup needs to declare each entity a single time, with a unique identifier known as @id, and to reference that same identifier at every other point where that entity appears.

By defining a unique URI for each entity within your code, you create anchor points that can be referenced anywhere on the site or in external databases. This makes it possible to connect complex properties without duplicating information and without generating noise for crawlers. And duplication is the real risk: the same person described at length inside three different nodes becomes, over time, three versions that diverge from one another.

To structure this relationship correctly, there are three connections that must be implemented in the code:

• The site node (WebSite) must point directly to the organisation node (Organization) as its official publisher, through the publisher property.
• The organisation node must carry the founder and employee properties pointing directly to the person node (Person) of your spokesperson.
• Each work by the spokesperson — book, article, lecture — must exist as a node of its own (Book, Article, CreativeWork) with the author property pointing back to the person node. The edge runs from the work to the author, not the other way round.

A common mistake here is trying to hang the work on the person using properties that serve another purpose. hasCredential describes a degree, a certification, a professional registration — not a book. publishingPrinciples points to the page describing your editorial policy, not to your body of work. Using a property outside its scope is not specialist purism: it is declaring a wrong fact in a vocabulary the machine reads literally.

If you take care of every small detail of that chain, the final code stops being a list of metadata and starts working as a precise map of your business. It is at that level of technical precision that we manage to establish the authorship of a thesis deterministically, without depending on algorithmic guesswork. It is that structural work that makes artificial intelligence recognise that the authorship of your content belongs to a creator with real authority.

How Wikidata anchors the structured entity in the global ecosystem

The internal JSON-LD markup of your site is only half the entity engineering work. For the information declared in your code to hold validity for language models, it needs to be corroborated by external sources acting as high-authority anchors. Wikidata is the highest-leverage anchor for that purpose, acting as the great hub of structured data on which entity resolution systems lean to cross-reference.

I, Bruno Rosa, of Sumaúma AI Presence, tend to repeat in every diagnostic meeting: Wikidata does not stop anyone at the door. It has a notability test, not registration rejection. That means an item created without a basis gets deleted afterwards. When a professional’s or a company’s entity does not yet hold up there, the correct method demands identifying that fragility and building the sources of validation before attempting to force a profile into existence.

The strength of well-connected JSON-LD markup reveals itself when you use the sameAs property to point your organisation node or your spokesperson node directly to the respective Wikidata identifier, the QID. That QID is your brand’s ID card inside the models. On finding that exact correspondence, the AI system can unify your brand’s history present in the global public graph with the statements of original content you publish on your site.

It is worth saying where we ourselves stand on this. Sumaúma AI Presence still has no QID, and the absence is deliberate. Our entity is being built in secondary sources before any attempt at creation, for exactly the reason we have just described. If you open our code today and count the sameAs entries, you will not find Wikidata among them. Creating the item before the basis exists would contradict the method we sell, and we prefer a declared absence to a presence the community deletes in three weeks.

How to measure the solidity of your semantic infrastructure honestly

Why do we insist on a measurement that takes work instead of promising magical positions on voice assistant screens? Because we understand the nature of the environment we are operating in. G-SoV (Generative Share of Voice) measures how often a brand is cited in machine-generated answers. That metric varies between runs: the same question, in the same model, on the same day, can return different answers.

For that reason, we never promise a fixed percentage of appearance in ChatGPT or Gemini. Anyone making that kind of promise is selling an illusion they cannot control. Instead, we concentrate our work and our commercial delivery on EPS (Entity Prominence Score), a deterministic and auditable metric that assesses the real strength of your infrastructure. EPS is inspectable pillar by pillar, letting you check exactly where your code is strong and where it needs correction.

Our methodology assesses brand presence across four pillars, without revealing weights or proprietary formulas from our calculation algorithm. We analyse the technical quality and the connectedness of the Schema.org markup present on your site, the consistency and validation of the entity’s record on Wikidata, the density of your knowledge graph in relation to other entities in your niche, and the coherence of the brand’s public information spread across the internet in order to avoid contradictions.

To ensure this structure is maintained and monitored constantly, we developed specific tools. Our platform, GenPres, actively builds and maintains your entity’s presence in language models. Before starting any work, we run AI-Scan, a deep audit that queries 15 AI systems and declares the valid ones in the report delivered to you. We also have Sentinel designed, not yet built, a future instrument aimed at continuous monitoring of your entity’s reputation.

This level of engineering is not suitable for those just starting out or without a body of work. We publicly turn down clients who do not hold an authored body of work, a method of their own or a consistent historical legacy. Without that raw material, any attempt to model a Digital Twin or structure an entity graph will result in generic answers, and we would rather not sell than deliver work that will not bring real authority to your digital presence.

The limit of technical infrastructure and what this text does not solve

Implementing well-connected JSON-LD markup establishes the technical foundation needed for language models to understand who you are.

This text does not solve the quality of the content you publish. There is no point having perfect semantic code if the content of your pages is generic, redundant or created merely to fill space. Artificial intelligence cites what is exclusive, authored and corroborated by facts; if your body of work is poor, the machine will go on ignoring your brand.

This article also does not address the particularities of server configuration or the integration of dynamic schemas in different content management systems (CMS), which requires individualised development work for each site architecture. In the next article in our series, we will demonstrate how the consistency of NAP (Name, Address and Phone) in public records acts as the tie-breaker for artificial intelligence when two brands compete for the same citation.

If you suspect your current semantic infrastructure is leaving your work invisible to generative AI systems, open the code of your home page and count how many sameAs entries point back to your authoritative sources.