Entity SEO: how I taught Google and AI assistants which Arun Agrawal I am

The problem: a distinguished stranger with my name

There is an Arun Agrawal who is an environmental politics professor at the University of Notre Dame, formerly at Michigan: widely published, widely cited, and by every measure the more famous holder of our shared name. None of this is his fault, and it is not really a complaint. But for years, search engines and then AI assistants did what pattern-matchers do with two people of one name: they blurred us. Ask about "Arun Agrawal" in a business context and you might get a paragraph seasoned with academic biography.

For a consultant, that is a commercial problem. A prospect who asks an assistant about me before a call and gets a muddle does not think "namesake collision"; they think something is off, and the mistake never gets corrected because nobody tells an assistant it is wrong. The fix could not be persuading anyone to write about me differently. It had to be structural: hand them an unambiguous record of which Arun Agrawal I am, and make every surface I control point at it.

Signs you are being blurred with a namesake

Worth checking before investing the work. Any of these means you have an entity problem, not a content problem:

• An assistant's answer about you mixes in facts that belong to someone else: wrong university, wrong city, wrong decade.
• Search results for your name show a knowledge panel that is not you, or no panel where your namesake has one.
• Your publications, talks or press mentions get attributed to the namesake, or theirs to you.
• Assistants describe you confidently but generically, as if averaging several people into one plausible biography.
• Colleagues report that "the AI said" something about you that no source you control has ever said.

The approach: one canonical record, referenced everywhere

The whole method rests on one idea from structured data: an entity can have a permanent address. Not a web page address for humans, but an identifier inside the page's machine-readable layer, called an @id. Mine is https://www.arunagrawal.com/#arun. It lives in the Person schema on my personal site, and it never changes.

Everything else follows from that decision:

• One full record, once. The complete Person definition (who I am, what I do, since when, where, and, pointedly, who I am not) exists in exactly one place, on arunagrawal.com. Every other site that mentions me carries only a stub that points at the @id. This site does exactly that in its own markup; view source and you will find it.
• sameAs as the connective tissue. The canonical record lists my other verified surfaces (company site, LinkedIn and so on), and those surfaces link back. Crawlers can then walk the loop and confirm they all describe one person.
• Explicit disambiguation. Schema has a field almost nobody uses called disambiguatingDescription: a sentence whose entire job is to say which one you are. Mine says, in effect, "the Kolkata-based technology consultant, founder of EbizIndia, not the environmental politics professor". Blunt, but machines read blunt well.

The markup, so you can adapt it

A trimmed version of the pattern, suitable for any founder with a name collision:

{
  "@context": "https://schema.org",
  "@type": "Person",
  "@id": "https://www.yourdomain.com/#you",
  "name": "Your Name",
  "url": "https://www.yourdomain.com/",
  "jobTitle": "Founder and CEO",
  "worksFor": {
    "@type": "Organization",
    "@id": "https://www.yourcompany.com/#org"
  },
  "disambiguatingDescription":
    "Technology consultant based in Kolkata, India;
     not the academic of the same name.",
  "sameAs": [
    "https://www.yourcompany.com/about/",
    "https://www.linkedin.com/in/yourprofile/"
  ],
  "knowsAbout": ["SEO", "LLM visibility", "web performance"]
}

Three practical notes. Keep the @id on a domain you will still own in twenty years. Make the disambiguating sentence factual and neutral; it is a signpost, not a boast. And resist the urge to stuff knowsAbout with fifty topics: a short, true list carries more weight than a long aspirational one.

The seven steps, in order

1. Choose the canonical home. One page, on a domain you own for the long term, that will carry the full Person record. Everything else becomes a pointer.
2. Write the full Person schema there, with a stable @id, real biographical facts, and worksFor linking to your company's Organization @id.
3. Add the disambiguating sentence. Name the collision if one exists. Vagueness here wastes the field's entire purpose.
4. Close the sameAs loop both ways. The canonical record lists your verified profiles; each profile links back to the canonical page. A claim that points only one way carries little weight.
5. Align every bio to one line. Write a single one-sentence description of yourself and install it verbatim on LinkedIn, directories, speaker pages and social bios. Consistency across surfaces is what gets rewarded.
6. Attribute everything you publish. Articles anywhere should carry author markup pointing at your @id, which every article on this site does. Each one adds an edge to the graph around the right record.
7. Verify, then wait properly. Run the canonical page through validator.schema.org and Google's Rich Results test on day one. Then check assistant answers quarterly, not weekly; entity records move at the speed of recrawling, not at the speed you refresh the page.

The same method works for company names

Mid-project, I got a second demonstration free of charge. This publication's own domain, seotop10.com, turns out to share its name with seotop10.com.vn, an unrelated Vietnamese SEO agency, and machines conflate similar company names just as readily as similar personal ones. The remedy is structurally identical: the Organization schema here declares its publisher and country unambiguously, the About page states the non-relationship in plain text, and every article's publisher markup points at one canonical Organization @id. If your company name is shared, generic, or a common phrase, treat the business to the same seven steps as the founder: canonical record, explicit disambiguation, consistent one-line description, closed sameAs loop.

Did it work?

By my August 2026 baseline: yes, for the person. The major assistants now identify me correctly, place me in Kolkata, attach me to EbizIndia, and no longer garnish my biography with environmental politics. That is months of slow settling after the markup went live, not an overnight flip, and I re-check quarterly because entity records can drift.

And in the same baseline, the less flattering half: the assistants describe my company with outdated positioning, because they read old third-party pages rather than the surfaces we keep current. Person solved, organisation still in progress. That correction project is documented in the audit procedure, and frankly this publication is part of it: a steady stream of current, retrievable, consistently attributed material is how a stale record gets outweighed. How that record then converts into recommendations is covered in how assistants decide which companies to recommend.

The lesson for any founder

Machines do not resolve ambiguity in your favour; they resolve it toward whoever has the clearest record. If your name, or your company's name, is shared with anyone or anything better documented than you, the default outcome is their story bleeding into yours. The remedy is modest and almost free: one canonical record with a stable @id, a truthful disambiguating sentence, and patient consistency everywhere else. It is the closest thing entity SEO has to a silver bullet, and it is available to a one-person company as readily as to a multinational.