← Back to Blog

Article Schema Alone Didn't Make AI Recognize Me as the Author. The Entity Wiring That Did (in 4 JSON-LD Fields).

Part of LLMO Field Guide

I added Article schema to 239 pages. AI still cited the site instead of me.

Perplexity would write “according to kenimoto.dev” as if the domain wrote itself. ChatGPT would say “one blog post explains…” with no author. Google’s AI Overviews attributed the same paragraph I published under my byline to “an article on the site.” Three different agents, three different ways of pretending I don’t exist.

The Article schema was correct. author.name was set. The byline was on the page. And none of it made the AI treat me as an entity worth citing by name.

This is a follow-up to the “11 schemas, only 3 worked” post I wrote earlier. That earlier post covered which schema types survived AI ingestion. This one zooms into one of the three that did: Article schema was passing validation, but the author field was a dangling string. It named a person the AI had no way to resolve as a real entity.

The fix was 4 JSON-LD fields. Three weeks later, Perplexity started using my name.

What “Article schema” actually gives you (and what it doesn’t)

Here is the Article schema I had on every post:

{
  "@context": "https://schema.org",
  "@type": "TechArticle",
  "headline": "Some Post",
  "author": {
    "@type": "Person",
    "name": "Ken Imoto"
  },
  "datePublished": "2026-04-01",
  "dateModified": "2026-04-01"
}

This validates. Google’s Rich Results Test is happy. Schema.org’s validator is happy. And it tells any AI crawler nothing useful about who “Ken Imoto” is.

Here is what I did not realize for six months: the author field is a local Person object, scoped to the article it sits on. Nothing connects the Person on post A to the Person on post B. From the AI’s perspective, 239 articles about various topics each mention a person named “Ken Imoto.” Whether it’s the same Ken Imoto is left as an exercise for the reader. (The reader is a language model. It does not do exercises.)

Article schema on its own says something about the article. It says nothing about who wrote it.

Why the AI cares (and what “entity” means here)

Modern AI search (Perplexity, ChatGPT’s browsing, Google AI Overviews, Brave Leo) pipes retrieved passages into a generation step. During generation, the model has to decide how to attribute the passage. Its options, roughly:

  1. Cite the URL only (“according to a blog post at kenimoto.dev”)
  2. Cite the site brand (“kenimoto.dev says…”)
  3. Cite the author by name (“Ken Imoto reports…”)

Option 3 requires the model to be confident that a Person entity exists, is stable, has a name, and is the author of this specific passage. Without that, it defaults to option 1 or 2. Silence about the author is a downgrade to a weaker citation shape, and it reads as neutral behavior only because you don’t see the demotion happening.

Entity resolution here works the way it works everywhere in AI: give the model enough triangulating facts about a thing, and it starts treating that thing as a first-class node. Give it a floating name inside a JSON-LD blob, and it treats the name as string metadata.

The 4 fields that changed the shape

I already had the sitewide <script type="application/ld+json"> blocks. I added four things. None of them were “add more schema types.” All four were about making the author an entity the AI could resolve.

Field 1: author.@id as a stable URL

The Article schema went from this:

"author": {
  "@type": "Person",
  "name": "Ken Imoto"
}

To this:

"author": {
  "@type": "Person",
  "@id": "https://kenimoto.dev/#ken-imoto",
  "name": "Ken Imoto",
  "url": "https://kenimoto.dev/about"
}

The @id is the load-bearing part. It’s a URI that identifies the entity, not the page. Every Article schema across the site now points at the same @id. Six months of orphaned Person objects collapsed into one referenced entity.

The URI doesn’t have to resolve to a real page (though I made mine resolve to /about for humans). What matters is that it’s the same string every time.

Field 2: Person schema on /about with matching @id

On /about I emitted a standalone Person JSON-LD:

{
  "@context": "https://schema.org",
  "@type": "Person",
  "@id": "https://kenimoto.dev/#ken-imoto",
  "name": "Ken Imoto",
  "url": "https://kenimoto.dev/about",
  "image": "https://kenimoto.dev/images/ken-avatar.jpg",
  "jobTitle": "WebRTC & Voice AI Engineer",
  "description": "Engineer writing about Claude Code harnesses, LLMO, and Knowledge Graphs.",
  "sameAs": [...],
  "knowsAbout": [...]
}

Same @id as in every Article. This is the definition site of the entity: the one page that says “here is the Person, in full.” Every article’s author.@id points here.

If you skip this step, the @id in your articles is a URI that points to nothing. The AI has a stable identifier but no data behind it.

Field 3: sameAs (order matters more than I thought)

sameAs is where you list external URLs that identify the same entity. This is how the AI cross-references your identity across the web.

The order I settled on, after some testing:

"sameAs": [
  "https://github.com/kenimo49",
  "https://www.linkedin.com/in/kenimoto",
  "https://x.com/imodeicious",
  "https://zenn.dev/kenimo49",
  "https://dev.to/kenimoto",
  "https://arxiv.org/a/imoto_k_1"
]

Why this order: LLM training data over-indexes on developer profiles (GitHub) and professional profiles (LinkedIn) as identity anchors. X/Twitter is noisy. Many models trained on cutoffs where X data was deprioritized or partially scrubbed. Zenn/Dev.to give topical authority. arXiv, if you have it, is the strongest single anchor for “this is a real technical person,” even for one paper.

I don’t have hard numbers on whether the order changes crawler behavior. The schema.org spec doesn’t say order is significant. But the content of sameAs matters a lot: adding GitHub and LinkedIn shifted attribution more than adding X, which I read as a signal about which profiles LLMs treated as trustworthy identity roots during training.

Field 4: knowsAbout (topic anchoring)

"knowsAbout": [
  "Claude Code",
  "LLMO (Large Language Model Optimization)",
  "Knowledge Graph",
  "WebRTC",
  "Voice AI",
  "AI agent harnesses"
]

This one is a topic anchor for the Person, and it does real work. When a Perplexity query asks about Claude Code, the ranker looks for pages authored by people whose Person entity has Claude Code in knowsAbout. Without it, my authorship on Claude Code articles was a string coincidence; with it, it became a topical claim about the entity.

The list should be things you can back up with published work. Padding it with 30 topics you’ve never written about is the schema equivalent of listing “team player” on a resume.

What actually changed (three weeks of measurement)

I set up a weekly poll: 12 Perplexity queries, all in the form "Ken Imoto" <topic> where topic was a Claude Code, LLMO, or WebRTC keyword. I logged whether the response used my name in the answer body, or only in the source list, or not at all.

The rough shape of the change over three weeks:

  • Week 0 (before): my name appeared in the answer body of 1 out of 12 queries. Source list attribution was kenimoto.dev for 8 of them.
  • Week 3 (after): my name appeared in the answer body of 7 out of 12. Source list attribution shifted to including “Ken Imoto” in 9 of them.

Small sample, no controls, and Perplexity’s ranker moves under my feet. But the direction was clear enough that I stopped second-guessing and rolled the same schema out to the JA/PT/ES subdomains.

ChatGPT (browsing mode) moved less. Google AI Overviews hardly moved. Google appears to hold onto its own entity graph and does not take @id claims at face value the way Perplexity does. Brave Leo picked it up within days, which tracks with Brave’s Context API being explicit about preferring JSON-LD.

The one thing I did not measure: whether any of this translates into CTR from AI referrals. That data is a mess. AI referrers strip themselves at the browser level in most cases. This whole exercise was about attribution shape, not traffic.

The gap this closes vs. the passage-level problem

I wrote earlier that pages don’t get cited, passages do. That’s still true. What I didn’t cover then: even when a passage gets cited, the attribution layer can drop the author without any visible signal. Article schema without an entity-resolved author is precisely this failure mode. The passage survives, the byline does not.

The two problems compound. If your content isn’t chunkable at the passage level, you don’t get cited. If it is chunkable but your author isn’t an entity, you get cited as “a blog.” I fixed the chunking first (that was the 11 schemas post). Then I noticed I was still invisible by name. That was this fix.

What I would tell past-me

If I were doing this from scratch, I would not add Article schema first. I would emit the Person schema on /about first, pin the @id, then wire every subsequent Article to reference it. Bolting the @id onto an existing site works (I did it), but shipping Article schema without a matching Person entity leaves the identity layer empty.

Two smaller things I got wrong the first time:

  • I initially made the @id a page path (/about#author). Change your /about slug someday and everything breaks. Use a #-anchored fragment on the origin (https://kenimoto.dev/#ken-imoto) so it’s stable no matter what.
  • I forgot to add the Person schema to my sitemap’s list of important pages. /about was in the sitemap, but I hadn’t updated dateModified when I edited it. Crawlers were seeing the old version for weeks. Update dateModified on /about every time you edit the Person schema.

Author entity is one field in a bigger checklist

The four fields above only cover the identity layer. There’s a broader LLMO framework (llms.txt, passage-level structure, freshness signals, cross-language canonicals, citation reciprocity) that this fits inside. If you want the full checklist rather than the one slice I zoomed into here, the source-of-truth I refer to is llmoframework.com.

Article schema tells the AI what the article is. Author entity wiring tells the AI whose article it is. Both matter.


If you want the full playbook on structured data and AI citation (the JSON-LD types that move AI ranking and citation behavior, beyond the ones that merely pass validation), I wrote that up as LLMO: AI検索最適化 実践ガイド.