Telling search engines who you are, in JSON-LD

The mistake is assuming a search engine will connect the dots on its own — that because the same name appears across pages, it'll figure out they're the same entity and understand how the pieces relate. Sometimes it guesses right, but guessing is exactly what you don't want it doing about your identity. Ambiguity here means it might conflate you with someone else who shares your name, or fail to connect your person to your work, or simply not build the coherent picture that helps it surface you for the right things.

JSON-LD lets you stop hoping it guesses right and state the relationships outright. This is a Person. This Person founded this Organization. This Person works for that one. These are the entities, and here is exactly how they connect. You're not optimizing keywords; you're handing the search engine a labeled diagram of your identity so it doesn't have to reconstruct one from fragments. Declaration beats inference every time your identity is on the line.

In my own portfolio the relationships are named exactly, not left to chance. I founded AutonomousAJ and QuantAIze; I work through Purcell Analytics, the consulting practice that ships client work. In JSON-LD each is a single labeled edge — a `founder` or `worksFor` arrow from my Person node to the organization — so the connection is a fact in the data, not a coincidence of two names on the same page across the sites I run.

Don't hope the search engine infers who you are from scattered mentions. Hand it a labeled graph — this person, these companies, these projects, connected like so.

The keystone of the whole graph is a single canonical identifier for the person — one authoritative place that says "this is the entity." Everything else hangs off that anchor. Without it, you have a set of pages each making its own local claims, with nothing tying them to one durable identity. With it, every other page and mention can point back to the same anchor, and the search engine can accumulate everything it learns about you onto one entity rather than smearing it across several half-formed ones.

That anchor is what makes the graph coherent instead of just present. It's the node that says "all of these references are about the same me," so the founder relationship and the works-for relationship and the project connections all attach to one identity the engine can build a complete picture of. Get the anchor right and the rest has something solid to connect to; skip it and you've drawn a diagram with no center.

In my portfolio that anchor is one canonical Person node — literally a `/#person` id that every owned site points back to. Hanging off it is a `sameAs` list of the profiles that prove the identity is real and singular: the GitHub account, the LinkedIn profile, the site itself. Those aren't decoration; they're the corroboration a search engine follows to confirm there is one person here — the same operator behind each site, not a name shared with strangers.

Naming the relationships once isn't enough; the graph has to knit together across domains, not just within a single page. Every organization node carries an `@id` that matches that organization's own website — `autonomousaj.com/#organization`, `quantaize.ai/#organization`, and so on — and each of those sites emits the same identifier back. When two sites on different domains use the identical `@id` for one entity, a search engine can merge them into a single node instead of treating them as two lookalikes. The entity resolves across the whole portfolio, not one page at a time.

That reciprocity is what turns a list of nodes into a mesh. The MVP Machine node, for instance, declares a `parentOrganization` edge up to QuantAIze, and QuantAIze's own site confirms the relationship from its side. Nothing depends on a single page being authoritative; the same claim shows up from both ends, which is exactly the kind of corroboration a machine trusts. It's also the signal an AI answer engine leans on when it decides whether a scattered set of brands is really one operation worth citing as a source.

There's a discipline that comes with this power, the same one that governs everything else I do: the structured data has to be true. It's a set of machine-readable claims, and claims that don't match reality are a liability, not an asset. If the graph says a project is something it isn't, or overstates a relationship, you've handed the search engine a precise, legible falsehood — worse than vagueness, because it's exactly what erodes trust when the reality doesn't back it up.

So I keep the entity graph honest and current: it claims the relationships that actually exist, at the strength they actually exist, and it gets updated when the reality changes. A founder relationship that's real, stated plainly. A company connection that's accurate, not inflated. The graph is powerful precisely because it's specific and machine-readable, which means every claim in it should be one I'd stand behind — the structured-data version of the honesty I try to hold everywhere: say exactly what's true, no more, in a checkable form.

The honesty shows up in small choices. All of my brands are DBAs of one company, so every organization node carries the same `legalName` — the single LLC behind them — rather than pretending each is its own incorporated business. And The MVP Machine, still in early access, gets no `Offer` and no invented pricing in its structured data; it's described as what it actually is now, not what I hope it becomes. The graph earns trust by refusing to overstate, the same standard I hold for every dataset I publish.

A graph the crawler never sees does nothing, so where the JSON-LD lives matters as much as what it says. My site is a React app, but the structured data isn't assembled in the browser — it's written into the static HTML at build time, during the prerender step, as a `@graph` block on the home page and the about page. A crawler or a language model reading the raw HTML gets the whole entity graph immediately, without running a line of JavaScript. If it only appeared after the app hydrated, half the machines that matter would never load it.

Baking it in also keeps the graph in lockstep with the truth, because it's generated from the same code that builds the pages, not hand-maintained in a separate file that quietly drifts. When a relationship changes, one place changes, and every page that carries the graph updates with it. That is the whole point: to hand a search engine, and increasingly an AI overview, a clean authorship signal a bare page can't carry — this is who wrote this, this is the operation behind it, and here is how to verify it.

The payoff is that a search engine stops seeing a loose collection of pages and starts seeing an identity with structure — a person, connected to specific organizations and projects that reinforce each other. Instead of a dozen weak, disconnected signals, you have one strong, coherent one. That coherence helps the engine understand what you're actually about and surface you for the things that genuinely match, rather than treating each page as an island competing on its own.

None of this requires a platform or a budget — it's a bit of structured data added to pages you already have. But it's the difference between letting a search engine guess at your identity from fragments and telling it plainly, in its own language, exactly who you are and how your work connects. For anyone whose presence is spread across a person, some companies, and a set of projects, drawing that graph explicitly is one of the highest-leverage, lowest-cost things you can do — turning a scatter into a self.

This piece is part of my series on search, answer engines, and content quality. The anchor is AEO and GEO: optimizing for answer engines.