Add structure to language; not the other way around

Before we dive in, I have a request. Can you do me a small favor? It's worth the effort. You'll understand this article better and it won't cost you much time. Just a little bit of honesty.

Yes?

Great, so here is my assignment for you: go to your own website and pick a high-value page. The one that answers the question most important to your business. Your main product, or one of them.

Then, pick a sentence from the middle. Not the intro, not the conclusion. The middle.

Copypaste that sentence into your note taker or somewhere else out of the context of your website. A new text doc in your editor, or just a quick draft in your email client. Doesn't matter much, just copypaste it somewhere else.

Now read that sentence in complete isolation. Pretend you're not you but someone else who reads it. A prospect, a reasonable surfer, someone anonymous. Then, from that viewpoint and in all honesty, answer these questions with either yes or no:

If any of the answers is no, you've found the problem this article is about.

And you're not alone. I've been testing quite a lot, and it fails about 99% of the time. Even on well-written, well-ranking pages. So there's a 99% chance that applies to you too.

This isn't a ranking problem. It's a utility problem. And the fix isn't what most of us expect.

SEOs know about structured data. We've spent a decade adding Schema.org, LD+JSON, and currently many are debating whether they should offer a markdown version of their bloated HTML to LLM bots.

Sigh.

While I definitely don't dispute the usefulness of structured data (quite the opposite! I love it, I'm a fanboy! Just to be clear on this), I think however we're forgetting what all this is about, what's actually easier to fix, and what is right there sitting in front of us.

Many treat structure as something you bolt onto text. A technical layer separate from the writing itself.

I'd say we don't need more of those technical layers, but should be using better structured language.

Let me explain what I mean.

Structured data translates human text into machine format. Structured language writes human text that is inherently machine-processable. One adds a layer. The other enriches the text itself. And then that text is useful food for content-eating machines to represent it correctly in different renderings, like chats, AI overviews, and even classical Google rankings.

Here's a concrete example. You could add Product schema to a page declaring the name is "Sony WH-1000XM5", the price is € 349, and availability is InStock. That helps a search engine understand the basics. But it can't carry why someone should buy it, how it compares, or under what conditions it's the right choice.

Natural language already has all the tools you need to achieve this though! You could for example write:

That sentence doesn't need a machine-readable overlay. It is machine-readable. It contains entities, relationships, conditions, comparisons, and specifics. A knowledge graph can extract triples from it¹. A proposition-based system can decompose it into atomic claims². And a human reads it just fine. No markup needed. And it carries far more than schema ever could: the comparison, the benchmark, the weight difference, the trade-offs.

Or take a completely different domain:

Same principle. Named entities (the property, the subsidy, the agency). Explicit relationships (qualifies for, on the condition that). Conditions preserved inline (EPC above 400, certified contractor). No markup required.

That's the whole idea. Everything else in this article is technique, with a lot of examples, for doing it well.

There's a gap between what humans consider good content and what machines can actually use. Duane Forrester calls it the Utility Gap³. We read to understand. We tolerate warm-up paragraphs, appreciate narrative, scroll to find what matters. AI retrieval systems do something else entirely: they consume content in chunks and extract what they need to complete a task⁴.

A page can be great for humans and useless to a model. Indexed, credible, well-written, and still fail the moment a system tries to turn it into an answer⁵.

You should realize this isn't just about LLMs.

Google has been evaluating content at the passage level since 2021. The same qualities that make content useful to ChatGPT or Perplexity (clear passages, resolved references, explicit entity relationships, self-contained statements) are the same qualities that Google's passage ranking, AI Overviews, and featured snippets reward. I wrote about this in more detail in The Shared Mechanism: the underlying retrieval infrastructure is the same. You're not optimizing for different systems. You're optimizing for one evolving system that evaluates content at the passage level.

So when I say this should have mattered years ago: I mean it. The techniques in this article aren't "GEO tricks." They're better writing. And they've been rewarded by search engines since passage ranking went live.

A lot of GEO advice right now is built on a correlation trap. The reasoning: brands that get cited in AI search tend to have pages with expert quotes, statistics, structured formatting, and topical depth. Therefore: add those things and you’ll get cited too.

Wrong!

That’s observing a trait of authoritative content and calling it a cause. High-authority pages happen to have those features. Adding the features doesn’t create the authority.

The techniques in this article are different. They’re not authority proxies. They’re structural requirements.

When a sentence contains an unresolved “it” or “this,” a proposition-based retrieval system mechanically fails to extract it as a self-contained claim. That’s not a correlation. It’s a documented failure mode in the Dense X Retrieval research. When your best content sits in the middle third of a long page, Google’s passage scoring assigns it a lower position bonus. That’s not a heuristic. It’s the heading vector and position scoring mechanism Kopp describes.

These things either work mechanically or they don’t. You can verify them. You can break them deliberately and observe the result.
So when someone asks “but how do you know these techniques cause citations rather than just correlate with them?” -> that’s the right question. And for most GEO advice out there, there’s no good answer. For the techniques here, there is: they map to observable retrieval mechanisms, not to the content traits of pages that were already winning.

Olaf Kopp's work on LLM readability describes how this plays out in practice⁶. First, your page needs to pass source qualification: the traditional authority checks (E-E-A-T, domain trust, topical authority). That gate hasn't gone away. But once your page passes that gate, it's your individual chunks that compete. Your page gets in the door on authority. Your passages get cited on quality⁷.

This article focuses on your own content: making the language on your own pages more useful to machines. But the same principles carry over to how your brand shows up on other websites too, making sure your brand entity is connected to the right concepts in external sources. That's a different but equally necessary discipline, and beyond the scope of what I'm covering here.

Now, there's also a hard physical constraint that I think a lot of people underestimate.

Dan Petrovic's research on Google's Gemini system analyzed over 7,000 queries and found a grounding budget of roughly 1,900 words per query, split across sources⁸. The top source gets about 530 words. The fifth source? About 270⁹. For individual pages, the typical selection is around 380 words¹⁰.

It gets worse. Pages under 5,000 characters get about 66% of their content used. Pages over 20,000 characters? 12%¹¹. Adding more content dilutes your coverage without increasing what gets selected¹².

So yeah. Your best content needs to be dense, self-contained, and positioned where systems will find it. Not longer. Denser. Petrovic's own summary: density beats length¹³.

Want to see this framework in action? I created a version that is optimized for refactoring conference and guestpost bio texts. You put in your bio, and it's optional to provide a little more details to make things sharper. Then the tool will analyze your text through my model, and return a machine-readable version, along with honest feedback if there are still things to modify to make it better. Use it to improve your E-E-A-T! :)

Check it out -> right here.

I look at the utility of a text through five lenses. Let me walk you through what each one means in practice.

I'll use an extensive amount of examples because when I started looking at content this way, I learned that I learn best from concrete examples that actually show how it's done. So my aim is for you to find stuff in here that is useful for your own situation.

Research on long-context models shows that information position matters. Claims near the beginning or end of content get used more reliably than claims buried in the middle¹⁴. Forrester's advice: If the most important part of your answer sits in the middle, promote it or repeat it in a tighter form near the beginning¹⁵.

This maps directly to web content. If your key conclusion sits halfway down a 3,000-word page, it will probably become functionally invisible.

Tech review

A Tweakers review of the Samsung Galaxy S25 Ultra runs 3,000 words. The conclusion sits in the last 10%:

That's fine, end-of-page works.

But the critical comparison data? If that's buried in paragraph 18 of 25, it might never get extracted:

A hospital

A hospital page about hip replacement recovery runs 2,500 words. The most decision-critical bit sits in section 5 of 8:

That's the Lost in the Middle zone. A patient asking "How soon can I walk after hip replacement?" might get an answer built from a competitor's page that put recovery timelines in the first paragraph. Not because your content was worse. Because it was in the wrong place.

SaaS

A product page leads with the company mission statement, brand values, and customer logos. The actual differentiation sits in the comparison section halfway down:

That comparison data is exactly what an LLM needs to answer "What's a good free CRM for a small team?" But it's positioned where systems are least likely to find it.

The principle: within any piece of content there's a core block of ~500-600 words containing the most important claims. Know where that block is. Make sure it's in the first 20% or last 20%. Not the middle.

Getting retrieved isn't the same as getting cited. Research on product descriptions tested 15 different rewriting strategies, and after optimization, they all converged on the same features: alignment with user intent, comparison against alternatives, inclusion of external evidence like reviews, and preserved factual accuracy¹⁶.

Makes sense when you think about it.

Duane Forrester formalizes this into a formula: state what it is, who it's for, what job it does, and under what constraint it wins¹⁷. When your opening line is a slogan, the system has to infer what the product is actually for. And inference introduces uncertainty, uncertainty reduces selection¹⁸.

Let me show you what this looks like across industries, with some more example goodness :)

Real estate

A user asks an AI: "What are good neighborhoods in Antwerp for families under €400,000?". The following text might resonate on an emotional level, but it offers nothing useful:

Which neighborhood? What price? How many bedrooms? The system has to guess. It won't need to guess with this text though:

E-commerce

Marketing fluff text coming up:

But machines would prefer:

B2B/SaaS

Another amazing piece of text you've read nowhere else, anywhere, anytime (i'm joking of course, just so we're clear on this):

And then the structured version:

Legal services

Versus:

The difference isn't literary quality (as said before, I'll get back to that). It's utility. The first versions could describe any company anywhere. The second versions answer the actual questions a potential client (or the AI answering on their behalf) would have, and make it possible for machines to use it in their answers, with way less room for hallucination.

This is where structured language gets concrete. The most common failure mode is coreference. Pronouns and vague references that break the moment a sentence gets extracted without its neighbors.

Research backs this up. Proposition-level retrieval (where systems decompose text into atomic, self-contained claims) outperforms passage and sentence-level retrieval¹⁹. And the main quality problem in automated proposition extraction? Failure to resolve coreferences. Exactly the "it" and "this" problem²⁰.

Some concrete examples.

Tech review

Breaks when extracted:

What is "it"? Which Wi-Fi standard? Which previous model? What improvements?

This works though:

Healthcare

This breaks too:

But this doesn't:

Finance

This breaks:

And this works:

Travel

This breaks:

But this works:

In summary, a nice reference table for you

Here are the most common extractability killers. They show up everywhere, in every industry:

A simple rule of thumb: if a sentence doesn't survive the journalist's 5W test (who, what, when, where, why, and how), a machine can't do anything useful with it either.

This is what most content strategies miss entirely. And I find this one the most interesting, because it's so counterintuitive.

It's not about which concepts you mention. It's about whether you explicitly connect them.

Graph-based retrieval systems build knowledge graphs from content by extracting (subject, predicate, object) triples from natural language. No predefined schema needed²¹. And it turns out: content with clear subject-verb-object structures gets extracted more accurately than bullet lists without verbs, tables without context, or fragments that require inference²².

Same point as before. Natural language with structure baked in beats both unstructured prose and stripped-down data points.

Again some examples.

Real estate

A listing mentions all the right entities separately:

Four entities, zero relationships. A knowledge graph built from this has four disconnected nodes. Useless.

Now with relationships stated:

Healthcare

Without relationships:

And with:

Now the system can answer: "How much will metformin lower my A1C?" and "How often should I get my A1C tested on metformin?" directly. Because you stated the relationships, not just the entities.

Some more examples.

Finance

Without relationships:

And with:

SaaS

Without:

And with:

Multi-hop reasoning chains are where this gets interesting. "Is it worth buying a fixer-upper in Antwerp with a bad energy label?" requires a chain: energy label D means lower price → renovation costs X → subsidies offset Y → renovated properties appreciate Z%. If any link is missing, the chain breaks²³.

Same principle everywhere. "Should I refinance my mortgage?" needs: current rate → new available rate → closing costs → break-even timeline → remaining term impact. "Which cloud provider is cheapest for my workload?" needs: workload specs → pricing per unit → committed use discounts → egress costs → total cost comparison. Each link must be explicitly stated. Otherwise the system can't build the answer, and it'll use someone else's content instead.

Last one. And maybe the simplest test.

Does your content contain a single passage that an AI system would confidently drop into a response? Forrester calls these "anchorable statements": sentences that look like stable claims with clear definitions, explicit constraints, and direct cause-and-effect phrasing²⁴.

E-commerce

Not citeable:

And in contrast, citable:

Healthcare

Not citeable:

Citable:

Travel

Not citable:

Citable:

Legal

Not citable:

Citable:

You're seeing the pattern. The citeable versions aren't simpler. They're richer. More information, more structure, more useful.

Longer too. I'll get to that, I promise.

Here's how all five things work together on one piece of text. I'll use a real estate example, but the same analysis applies to anything.

Before (typical marketing copy):

Every sentence fails every lens. No extractable core. No specifics. Unresolved references. No relationships. No citeable statements.

After:

More words. More data. More complexity. But every sentence carries its own structure. Entities named ("the property at Cogels-Osylei 12" not "this home"). Relationships stated ("EPC score of 380 kWh/m², corresponding to energy label D"). Conditions preserved inline ("for properties with an EPC score above 400 kWh/m²").

No structured data markup needed. The language is the structure.

Same transformation, different industry. B2B SaaS:

Before:

After:

Same transformation. Generic marketing replaced with structured language. Entities named, relationships stated, conditions preserved, alternatives compared.

One important warning. "Optimizing for LLMs" by dumbing content down doesn't work.

Research tested a minimalist strategy (reducing product descriptions to single sentences) and it scored second-worst of 15 strategies tested, behind only a deliberately anti-factual storytelling control²⁵. Let that sink in for a moment. Oversimplifying your content performs almost as badly as actively making stuff up.

"Battery: 18 hours" is easy to extract but dangerously incomplete. 18 hours doing what? Under what conditions? "Starts at $49/month" without stating what's included, what's limited, and what triggers the next tier is equally incomplete. "Recovery takes 6-8 weeks" without specifying which procedure, which patient population, and what counts as "recovery" is medically misleading and computationally useless.

Dense, specific, condition-preserving prose beats both verbose marketing copy and stripped-down data points. Add structure to your language. Don't strip your language down to structure.

Both. I wrote about this in detail in The Shared Mechanism, but the short version: Google's passage ranking, AI Overviews, featured snippets, and third-party LLMs like ChatGPT all evaluate content at the passage level using similar retrieval infrastructure. A sentence that works for one works for all of them.

One thing worth adding here though. Doug Turnbull's work on semantic search points out that precise categorical language matters more than most people think²⁶. Retrieval systems don't just measure similarity, they also need to match: deciding whether something should be included or excluded from results. And that's where generic language fails²⁷.

"Handheld gaming PC in the portable console category" gives these systems more to work with than "gaming device." Same goes for "semi-automatic espresso machine" vs "coffee maker" and "anterior approach hip replacement" vs "hip surgery." The more precisely you name what something is, the better systems can match it to the right queries.

Everything above focuses on the factual, structural side of content: entities, relationships, conditions, specifics. And I'm pretty confident about that part. But... it's boring and quite intensive to read, to be honest.

Content isn't just facts. It's also tone, emotion, persuasion, storytelling. And that's where I'm still searching.

The tension most people assume exists ("write for humans OR write for machines") is, I think, a false one. But it's not trivial to resolve either.

Here's what I've found useful so far. Dorron Shapow writes about the distinction between germane and extraneous cognitive load. Extraneous load is noise: friction that serves no purpose, that makes someone work harder without helping them understand anything better. That should go. But germane load (the kind that actually helps someone process what they're reading, that slows them down just enough to grasp something important) is not a bug. It's a feature.

I think that distinction maps directly to what I'm doing here. Structured language removes the extraneous stuff: the vague pronouns, the missing subjects, the stripped conditions. That's noise for humans and machines. But it keeps (and even strengthens) the germane stuff: the specifics, the conditions, the relationships, the context that helps someone actually make a decision.

A page that helps someone understand a complex decision is allowed to be harder to read than a landing page selling socks. And a system that gives personalised answers to nuanced questions needs exactly that kind of depth to cite you reliably.

So the question I keep running into is not "human vs machine" but: how do you write sentences that carry both emotional weight and factual structure? A property listing that makes you feel something about the neighborhood while also stating the price, the EPC score, and the subsidy conditions. A product page that tells a story about who this is for while naming the specs, the comparisons, and the trade-offs.

I've been testing this in my analysis: scoring content on both its factual extractability and its human readability, and looking for patterns in content that scores high on both. I don't have a neat conclusion yet. But I think this is where the real work is heading.

Remember the sentence test from the top of this article and the Bio Rewriter? If you haven't tried them yet, now's the time.