A reader arriving at this article from a Google search has done one kind of work. The page is ranked. The headline matched the query. The click was the reward. A reader arriving here because an answer engine cited the page in response to a question has done a different kind of work. The page was extracted, summarised, and presented as an authoritative source. The citation was the reward.

Both kinds of work require the page to be well-written, but the writing decisions are not identical. Writing for search engines optimises for ranking. Writing for answer engines optimises for being quoted. The two overlap, but the techniques that produce a quotable page are specific enough that it is worth naming them.

This article is about those techniques. Five of them, in plain terms, with examples from how the Metarelic Studio website itself is built.

The direct-answer paragraph

The single most useful technique is also the simplest. Within the first 150 words of any page, state the direct answer to the question the page is intended to answer.

Answer engines do not read pages the way humans do. They look for a quotable passage that answers the query that brought them to the page in the first place. If that passage is in paragraph six, behind an anecdote, a quote, and a setup paragraph, the engine will often give up and move to a different page. If it is in paragraph one or two, stated cleanly, the engine has something to work with.

The direct-answer paragraph is not the entire article. It is the central claim, stated once, in a way that could be quoted on its own. Everything that follows is the supporting argument and the context. The reader gets the claim early. The engine gets the citation early. Both readers are served by the same paragraph, which is the point.

A useful test: imagine a reader who only reads the first 150 words. Could they leave the page knowing what the article is actually saying? If yes, the direct-answer paragraph is doing its work. If not, the article is buried and the engines will treat it as such.

One question per page

A page that answers one specific question is more likely to be cited than a page that addresses three or four related questions in a survey style. This is counterintuitive. The longer page contains more information. The longer page covers more ground. The longer page should, in theory, serve more reader needs.

In practice the longer page serves none of them as well. An answer engine evaluating which page to cite for "what is a digital product partner" is choosing between a page that answers that question directly and a page that mentions the answer somewhere inside a broader discussion of agency models, freelance work, and procurement. The page that answers the question directly wins, almost every time.

The discipline this requires is editorial. Each Insights article on the studio's website is structured around one question, named in the title. Related questions become their own articles, linked through topic clusters rather than folded into a single long piece. This makes the writing slower in the short term, because each piece has to earn its independence. It makes the writing more discoverable in the long term, because each piece is a clean answer to a clean question.

Scannable structure with substantive headings

Answer engines parse structure. So do skim-readers. A page with clear headings, short paragraphs, and visual hierarchy is easier to extract from and easier to read at speed. A wall of dense prose is harder, regardless of how well it is written.

Headings should be substantive, not clever. A heading like "What gets skipped, and why" is useful because it tells both the reader and the answer engine what the section contains. A heading like "Let's dive in" or "The big idea" is filler that takes up space and conveys nothing.

Paragraphs should be short. Two to three sentences is a reasonable default, four is the maximum, five-plus is almost always two paragraphs trying to be one. This is not a style preference. It is a recognition that most readers are on mobile, that scrolling past dense paragraphs is the default behaviour, and that an answer engine extracting a citation needs to find a paragraph small enough to quote.

Sentence length should vary. Long sentences that develop a thought sit next to short sentences that land it. Short sentences are scannable. Long sentences carry argument. A page made entirely of one or the other reads as either lecture or staccato.

Specificity over generality

Vague writing is increasingly invisible. An answer engine looking for a citation prefers a specific claim with a specific number to a general claim with adjectives. A reader looking for an authoritative source prefers the same.

"We achieved significant performance improvements" is invisible. "When we moved T-Stats Solutions impact story from a JSON blob schema to a GA4-inspired flat event model, standard queries got 7.4x faster" is quotable. The first is a marketing sentence. The second is evidence. Answer engines prefer evidence because evidence is what they need to cite. Readers prefer evidence because evidence is what they need to trust.

This applies to claims about results, claims about clients, claims about methods, and claims about what an organisation does. Every general claim is worth interrogating: is there a specific version of this claim that would be quotable? If yes, write the specific version. If no, the claim probably should not be in the article at all.

Schema markup and topic clusters

The two techniques above are stylistic. The next two are structural.

Schema markup makes explicit to an answer engine what kind of content a page is, who is responsible for it, and how its claims are structured. FAQ schema, How-To schema, Article schema, Organisation schema. These are not optional decorations. They are the difference between a page an engine can parse confidently and a page it has to guess at.

The studio's website uses schema markup across services, industries, impact stories, and Insights articles. The implementation is not glamorous. It is invisible to the reader. It is what allows the page to be cited reliably by answer engines that need to validate the source before quoting it.

Topic clusters are the architectural version of the same idea. A service page that links to ten supporting articles, each answering a specific related question, builds a coherent web of authority on a topic. A single article on the same topic, however well written, looks shallower to an answer engine than a cluster does. The studio's Insights hub is built as topic clusters under the four service lines and the four industries, with each cluster reinforcing the authority of the others. This is not a content marketing tactic. It is how answer engines decide which sources are worth trusting on a topic.

What this looks like in practice

The studio's Product Growth service line is shaped around these techniques as foundational practice rather than as an add-on. AEO is not a chapter at the end of the engagement. It governs how the website is structured from the first wireframe, how the copy is written from the first draft, and how the publishing rhythm is set from the first article.

This article is itself written to the rules it describes. The direct-answer paragraph appears in the first 150 words. The structure is scannable. The five techniques are named explicitly and ordered for citation. The claims about T-Stats Solutions are specific. The article is one question per page, linked into a cluster around AEO and SEO are not the same thing and the broader Product Growth pillar.

A page that practises what it preaches is the strongest case for the practice. A page that argues for AEO and is itself invisible to answer engines is making the opposite case. Writing for answer engines is not a separate skill from writing well. It is a specific application of writing well, governed by an understanding of how the new readers, the AI systems, actually read.

The question for any organisation publishing content right now is not whether to write for answer engines. It is whether to do it deliberately or to do it badly by accident.

‍