Metadata was a nice-to-have. Now it's whether the model can find you at all.
Khamir Purohit | |

Metadata was a nice-to-have. Now it's whether the model can find you at all.

@benalfrey posted something on X last week that stopped a lot of people mid-scroll. What's actually getting retrieved by ChatGPT and Claude right now isn't the best-written content, it's the most structurally extractable content. Programmatic listicles on “best x” and “x alternatives.” Competitor pricing pages. Content where the answer is a discrete unit the model can lift cleanly, not a sentence buried three paragraphs into an essay.

That's a different problem than most content teams are solving for.

But if you've been doing structured content at scale, you've been solving it for years. You just weren't calling it that.

At LexiConn, we've run two projects in the past five years that, in hindsight, were retrieval engineering. We called them metadata projects.

The Zee5 project: manual tagging at channel scale

From 2019 to 2022, our team manually watched Zee5 episodes and tagged what was in them, actor names, characters, themes, genres, scene-level keywords. Not automated. Not inferred. Humans watching content and label its meaning, field by field.

Why manual? Because automated tagging at the time was shallow. A tool could identify that an episode contained a person; it couldn't tell you it was a flashback scene featuring a character under a different name.

That nuance mattered for recommendations. A viewer who'd watched every episode featuring a particular supporting character needed the system to know that character appeared, even briefly, even without being named in the episode title.

The result: Zee5 ranked as the #2 most-watched entertainment channels in India.

Not because the content was different, the shows were the same, but because the metadata made the content findable at a level of granularity competitors hadn't matched. Discoverability was the product.

The M56 Studios project: 50,000 questions, each one a structured unit

The second project was M56 Studios. They had a trivia product, 50,000 questions, and each question was built as a deliberate structure: a difficulty rating (Easy, Medium, or Hard), a category, the question itself, four answer choices, and an image. The image wasn't decorative. It was chosen to be semantically connected to the question, either illustrating the topic directly or acting as a subtle visual hint toward the correct answer.

Our job was to source the right image for each question and tag it accurately to the question it belonged to.

That sounds simple until you're doing it at scale across categories like Entertainment, Politics, Food, Books, and True-or-False. Finding an image that is genuinely semantically connected to a question about an actor's nationality, and not just a photo of the actor, requires actual judgment about what the question is really testing and what a useful hint looks like. It's a content decision masquerading as a metadata task.

The schema was deliberate throughout: every question had its category embedded not just in the data fields but in the image filename itself. The meaning was machine-readable at every layer, not just at the page level.

The same requirement, a different surface

Look at what both projects actually did:

Both projects made the meaning of content explicit rather than implicit. Both tagged at the unit level, the episode, the question, not just the document level. Both embedded category and context into the asset itself, not only into the surrounding page.

And in both cases, every retrievable element ended up as a discrete, labelled thing rather than something a reader had to piece together.

Now look at what practitioners report LLMs retrieve well today: content where the answer is structurally explicit, where the question being answered is clear, where categories and intent signals are embedded in the content rather than inferred from it.

It's the same requirement. The surface changed. The underlying logic didn't.

What breaks without it

Most website content was written for a human who skims. The heading tells them what the section is about. The image is decorative. The answer is distributed across three paragraphs with connective tissue a person can follow but a model has to infer.

When a language model tries to retrieve an answer from that page, it often can't cleanly extract it. The answer exists, but not as a unit, it's dissolved in prose written for a different kind of reader.

The model either skips the page or surfaces a partial, uncertain answer. Think of a services page that explains pricing tiers through three paragraphs of narrative context, the discount logic, the caveats, the “talk to sales” nudge, instead of a single, labelled table.

A human reader follows the story. A model looking for “what does the Standard tier cost” often can't find a clean answer inside it at all, because the number was never given its own unit.

What retrieval rewards is what metadata always rewards: explicit structure, categorical tagging, answers that stand alone without the surrounding context to prop them up.

The question to ask your content

If you're rethinking your pages for AI discoverability, the framing isn't “how do I optimize for LLMs?” It's more basic than that: how explicitly have you labelled what this content is and what it answers?

A few checks that come directly from the tagging work above:

Does each page answer one clearly stated question, or several vaguely implied ones? A trivia question works because it has exactly one correct answer and signals its topic upfront. Most blog posts don't.

Is the category or topic of the page explicit in the content itself? Not just in a meta tag, in the body, in the heading structure, in the language used. The M56 image filenames had the category baked in. Your page should too.

If someone extracted just the answer, without the intro, the heading, the surrounding prose, would it still make sense? If not, the answer isn't really a unit yet. It's still embedded in a context that only a human reader can supply.

We were doing retrieval engineering in 2019. We called it metadata. The models crawling your content today are asking for exactly what we were building then: meaning that doesn't have to be inferred, structure that doesn't have to be reconstructed, answers that are already units before anyone asks the question.

The terminology changed. The work didn't.

Need expert content support? LexiConn has been India's B2B content partner since 2009, building content systems for leading enterprise brands across BFSI, technology, and media. Explore our content strategy services →

Book a Meeting