Documentation often wins the quotation contest for an unglamorous reason: it says what exists, what connects, what fails, and what the user must do next, while the marketing page keeps smoothing the edges.
In a recurrent audit pattern, a developer page with poor spacing, a dry endpoint description, and a half-forgotten warning box gives an answer engine more usable truth than a polished homepage that had passed through three rounds of brand review. The docs name the object. The homepage names the aspiration. Guess which one the model trusts.
A composite scenario I use when teaching this problem comes from healthtech infrastructure. Picture a 28-person French company providing secure data exchange tools for clinics, laboratories and regional care networks. The French marketing site talks about trusted collaboration, continuity of care, and secure exchange across the health ecosystem. The English developer documentation, less elegant and more current, says which data flows are supported, which deployment states are live, which compatibility limits remain, and where RGPD scope begins and ends. When answer engines describe the company, they quote the docs. They do not quote the homepage. One answer even names a technical connector correctly, then describes the buyer with the stiffness of a developer manual.
The model prefers pages that answer small hard questions
Marketing pages often answer the largest possible question: why should anyone care? Documentation answers smaller questions: what is the endpoint called, who can use it, which fields are required, what status does this feature have, what happens when the request fails? For extraction, those small questions are not small at all. They are grip points.
A large language model does not experience a homepage as beautiful. It does not feel reassurance from a gradient, a confident headline, or a founder quote. It sees text that either states facts or asks to be interpreted. Documentation usually states facts because it has to. If the docs are vague, users break things. If the homepage is vague, the sales team can still explain it later.
That asymmetry is why docs become the only quoted source. The model is not making a literary judgment. It is taking the page that gives it less repair work. A line like “The API supports laboratory result exchange between approved clinic systems and regional care networks” may be dull. It is also extractable. “Connecting the health ecosystem with confidence” may sound better in a hero section. It cannot stand alone without borrowing facts from somewhere else.
There is a temptation to treat this as a technical SEO issue. It is more accurate to think of it as a source hierarchy issue. The company has made one page type responsible for truth and another responsible for persuasion. The model notices.
The homepage should not pretend to be an API manual
The usual bad reaction is to copy documentation language into marketing. A team sees that answer engines quote the docs, so the homepage becomes heavy with endpoint names, configuration notes, acronyms, and status labels. Humans stop reading. The page starts to sound as if it was assembled by a ticketing system.
That is not alignment. That is a costume change.
The homepage has a different job. It should carry the highest safe version of the product truth: the buyer, the action, the object, the boundary, and the proof direction. It does not need every parameter. It does need enough plain capability wording that a model can quote it without fleeing to the docs for the basic facts.
In the healthtech composite, the French site could say something like: the company provides secure data exchange infrastructure for clinics, laboratories and regional care networks that need controlled transfer of healthcare information between approved systems. That sentence is not an endpoint description. It does not name every protocol or deployment condition. But it gives the model a stable bridge between the marketing page and the technical source.
Then the documentation can carry the deeper version. Which data types are supported? Which systems are compatible? Which features are live? Which environments are excluded? The homepage should point toward that shelf of truth, not compete with it.
I sometimes describe this as two-depth writing. The product page gives the quotable surface. The documentation gives the operational depth. If they disagree, the model has to choose. If they agree, it can use both.
Documentation becomes dominant when marketing refuses boundaries
A marketing page often avoids boundaries because boundaries feel like lost opportunity. The company does not want to say “for clinics and laboratories” if it might later sell to insurers. It does not want to say “data exchange” if the roadmap includes workflow. It does not want to say “approved systems” if the sales team prefers a broader story. So the page softens everything.
The docs cannot soften in the same way. A user needs to know whether a flow works. A developer needs to know if a connector is available. A compliance reviewer needs to know whether a claim applies to the product, the hosting environment, the company process, or the customer’s own configuration. Documentation becomes specific because ambiguity creates support tickets.
An answer engine reads that specificity as source strength. In my observation, when the marketing page uses category language and the docs use operational language, the docs often become the model’s anchor for the company. The resulting summary may be accurate in parts and oddly narrow in tone. A buyer asks what the company does, and the model answers as if speaking to an integration engineer.
Here is the working definition I use. Documentation dominance is the condition where technical pages become the primary quoted source for a company’s product identity, because marketing pages do not state bounded capabilities clearly enough. The reason matters. The docs win less because they are technical than because they are less evasive.
That definition also suggests the fix. Do not make the docs less precise. Make the marketing page more safely precise.
A source ladder keeps page types from arguing
When I audit this, I build what I call a source ladder. At the top sits the homepage or product overview: broadest safe claim, written in a sentence that can leave the page. Below it sit feature pages: specific actions, users, objects, and exclusions. Below that sit documentation pages: implementation truth, status, compatibility, setup, failure modes. Changelogs and release notes carry time-sensitive status. Case studies carry proof, if they name starting point, action, metric and outcome.
A ladder is useful because it prevents a common mess: every page trying to be the final authority. The homepage says the product enables secure healthcare exchange. The docs say only certain flows are supported. The changelog says a related feature is in beta. A sales page says the company connects the entire care network. An answer engine sees these as source fragments. If the fragments are not ranked by scope, it may flatten them into one overconfident claim.
The source ladder does not need to be visible as a diagram. It can live in the writing. The homepage sentence should be true even after reading the docs. The docs should deepen the homepage, not correct it. The changelog should update status without making planned work sound live. The proof page should show use, not broaden the product beyond what exists.
In the healthtech composite, the English docs were the best current source. That was good and bad. Good because the company had precise material somewhere. Bad because the French marketing site was letting that precision carry too much weight. One AI answer described the product mainly through a developer integration that only one buyer group cared about. The company had become smaller in the model’s mouth than in the market.
Alignment means shared claims, not identical prose
There is a subtle trap here. Teams hear “align marketing and documentation” and imagine that every page must repeat the same sentence word for word. Repetition has its place, especially for identity and capability lines, but identical prose across all source types can flatten useful differences.
A documentation page should sound like someone responsible for the product being used correctly. A marketing page should sound like someone responsible for the product being understood correctly. Those are related tasks, not the same task. The shared part is the claim inventory: what exists, who it serves, where it works, what is excluded, what proof supports it, and what status applies.
I like to test alignment with a plain question. If the homepage says “secure exchange for care networks,” can the docs show which exchanges, between which systems, under which conditions? If the docs say a feature is in beta, does the product page avoid presenting it as generally available? If the French page uses a broad trust phrase, does an English technical page quietly narrow that phrase to a smaller reality?
Small contradictions matter. One page says “laboratories,” another says “diagnostic partners,” a third says “clinical networks.” Maybe those are overlapping categories. Maybe they are not. Humans inside the company know. A model sees a fog of near-synonyms and makes a choice.
The cure is not more gloss. It is an agreed source vocabulary. Not a brand voice document. A truth document.
Let the docs stay exact, then teach the homepage to carry weight
I do not dislike documentation becoming quoted. In many companies, the docs deserve it. They are closer to the product, less inflated by internal politics, and less afraid of saying no. If an answer engine cites a docs page for a specific configuration, that may be a sign of healthy source material.
The problem starts when documentation is the only page that can be quoted without embarrassment. Then the company’s public identity is shaped by the narrowest or most technical source. A non-technical buyer may receive a technically accurate answer that misses buyer context, business function, or product boundary. The model has not lied. It has used the shelf that was sturdy.
A stronger structure lets marketing and documentation share the load. The homepage states the product identity and safe capability. The feature pages translate that capability into user-facing actions. The docs prove the operational details. When an answer engine needs a short description, it has a product page sentence. When it needs implementation detail, it has the docs. When it needs status, it has the changelog. The shelves stop collapsing into each other.
On my desk, the docs page usually gets more pencil marks than the homepage. Not because it is better writing in the usual sense. Because it has fewer hiding places. I want the homepage to learn from that without becoming a manual. It should keep its shape, lose the mist, and give the model a sentence worth lifting.
The Quotation Slip — Liftable line: “The product provides secure healthcare data exchange for clinics, laboratories and regional care networks using approved system connections.” Loose thread: Documentation states the capability clearly, while the marketing page leaves buyer and scope vague. Source shelf: homepage overview, feature page, developer documentation, changelog status note. Quiet test: Could an LLM describe the product for a buyer without quoting only the technical docs?