The Organization schema AI engines actually read is a short list.

AI search resolves an entity before it retrieves content for it. When someone asks an engine which agencies do AEO well, the model first has to decide who your agency is — whether the many mentions of your name across the web point to one real, distinct organization or to several fuzzy ones. Organization structured data is the machine-readable version of that answer. It is a small block of JSON on your own site that states, in a format built for machines, the facts that identify you: your name, your canonical URL, your logo, and the links that tie your profiles together. It is the anchor everything else hangs from.

This is a form of entity disambiguation applied to your own footprint, and it matters more for an agency than for most businesses because roughly 85% of AI brand mentions come from third-party pages rather than your own domain. The version of your agency an engine describes is assembled mostly from what other sites say about you. Organization schema is how you give the model a clean, authoritative starting point on your own domain, and — through the sameAs field — how you point it at the off-site profiles that should confirm the same story. It does not buy a placement; it removes the ambiguity that makes a model hesitate.

Google is explicit that there are no required Organization properties — you add the ones that apply to you. That freedom is where agencies go wrong: they either ship a bare block with only a name, or they stuff it with fields that contradict the visible page. This guide names the fields that actually carry weight for entity resolution, shows how to build a sameAs array that mutually confirms your identity, and states the one rule that governs all of it: the schema and the visible copy must agree. It is the concrete, on-site companion to the broader entity consistency audit and to knowledge-graph readiness.

Not every property earns its place. For entity resolution, seven fields do the work. name is your one canonical brand name, stated exactly as it appears in your visible copy; add alternateName only for genuine former names or trading variants you want reconciled, never for keyword padding. url is your canonical homepage — one https address, trailing-slash-consistent, matching the domain the schema lives on; Google notes the url helps it uniquely identify your organization. logo is a crawlable image of at least 112x112 pixels that renders on a white background; it is the visual the knowledge panel and some AI surfaces reuse.

@id is the quiet one that makes the rest compose. It is a stable, canonical identifier — usually your homepage URL with a fragment such as #organization — that other schema on your site can reference. When your Article schema names a Person as author, and that Person references your Organization @id, and the Organization carries sameAs links to Wikidata and LinkedIn, an engine can traverse the whole chain of trust in one pass. Without a stable @id, each block is an island. address (with country code, locality, region, postal code and street) and foundingDate (in ISO 8601 form) are the descriptive facts that separate you from a similarly named firm; they matter most when your name is not globally unique.

And then sameAs, which deserves its own section below because it is the single field that most changes how confidently an engine resolves you. Everything else describes you; sameAs proves you are the same organization the rest of the web is talking about. A useful mental model: name, url and logo are your ID card; address and foundingDate are the distinguishing details on it; @id is the barcode that lets other records point at it; and sameAs is the set of countersignatures from institutions that already know you.

Everything above fails if the markup and the page disagree. Structured data is trusted precisely because it is meant to be a machine-readable restatement of what the page already says. When the schema claims a founding year, an address, a name or a specialty that the visible copy does not support, an engine has a contradiction on a single page — the weakest possible signal — and the safe move is to discount the markup entirely. Marking up facts that are not present on the page is the most common way agencies turn a helpful signal into a liability.

The rule is simple to hold: if a fact is in your Organization schema, it should be visible somewhere a human can read it, and stated the same way. Your name in the schema matches your name in the footer. Your address in the schema matches your contact page. Your sameAs profiles are ones your site actually links to or references. This is the on-domain half of the same discipline that entity consistency applies across every profile — and it is why the schema is a starting point, not a shortcut: it only helps to the exact extent that it is true.