Should you split facts and narrative onto separate pages
Usually no, but separate them in the page structure

When does splitting facts and narrative help?

Splitting helps when your page is trying to do two jobs that conflict. One job is to give a model or a human a stable, quotable set of facts. The other is to persuade, explain trade offs, and add context. Those are related, but they are not identical.

If the narrative keeps pushing the facts down the page, wraps them in vague claims, or mixes old and current statements together, extraction gets worse. Not because the model is stupid, but because you are making retrieval and interpretation harder than it needs to be.

• Split when facts need their own maintenance cycle, such as product specs, policy details, definitions, compatibility lists, or methodology statements.
• Split when third parties need to cite the fact set without inheriting the whole sales story.
• Split when one page is trying to serve several intents and none of them are being served well.
• Split when your story changes often, but the reference facts must stay stable and easily auditable.

A practical example is a category page with a strong point of view, plus a separate methodology or evidence page. The category page can speak like an operator. The evidence page can state claims in a tighter, more extractable format. That pattern works because the second page is not a content farm duplicate. It exists to make verification easier.

When should you keep facts and narrative on one page?

For most marketing pages, one page is the better default. Splitting too early creates thin pages, duplicate maintenance, and internal confusion over which URL is canonical for the truth. That is how teams accidentally create a story page that ranks and a fact page that no one sees, or a fact page that stays accurate while the main page drifts.

The better pattern is usually structural separation inside one document. Put the answer first. State the core claims in short paragraphs or lists. Use descriptive headings. Keep the narrative after the facts, not before them. This preserves context while still making extraction easier.

This matters even more on JavaScript heavy sites. The verified server log evidence we have is simple and useful: AI crawlers fetch JavaScript files and do not execute them. So if your fact layer only appears after client side rendering, hiding it on a separate page will not save you. You still have a rendering problem.

What should the fact layer actually contain?

Think of the fact layer as the part of the page that can survive quotation without your sales rep in the room. It should contain statements that are precise, current, and easy to attribute.

• A direct answer near the top of the page.
• Definitions and scope statements, so a model does not generalize beyond what you mean.
• Named attributes, requirements, limitations, and exclusions.
• Change dates or update notes when recency affects interpretation.
• Evidence or method notes when you are making a claim that depends on process.

The narrative layer then does a different job. It explains why the facts matter, what trade offs sit behind them, and how a buyer or operator should interpret them. Good narrative reduces misreading. It is not fluff if it removes ambiguity. But it should not be the only place where your real answer appears.

What goes wrong when you split too aggressively?

You can easily end up with a nice sounding architecture that performs worse in practice. I see this when teams create a resource center full of tiny reference pages while leaving their main commercial pages vague. The result is fragmented authority. The quotable material lives over here. The demand capture page lives over there. Neither page becomes the obvious source.

Another failure mode is contradiction. If the narrative page says one thing and the fact page says another, a human can sometimes reconcile it. A model may not. It may choose the plainer statement, the newer crawl, or a third party source that looks more internally consistent.

This is one reason I tell operators to treat split pages as a governance decision, not just an SEO or GEO decision. Every extra URL becomes another truth surface to maintain.

How do you decide without guessing?

Run a simple decision test. Ask what you want the page to be used for, then inspect whether the current structure supports that use. If you want citation, the facts must be self contained enough to quote. If you want conversion, the facts must still be connected to a believable argument. If you want both, one page with internal separation is usually the cleanest compromise.

• If the core answer cannot be copied from the top section in plain language, improve the page before creating a new URL.
• If the facts need independent updates or references, create a dedicated fact page and link it clearly from the narrative page.
• If the page is rendered client side, fix delivery first. Architecture does not solve missing HTML.
• If the audience needs interpretation to avoid misuse, keep narrative close to the facts.

Ignore the folklore metrics that float around GEO threads. The circulating multipliers about tables, FAQ schema, and recency are not a solid basis for architecture decisions. Use them as a warning sign for hype, not as operating guidance.

Who should not follow the one page default?

Do not follow the one page default if you run documentation heavy products, regulated content, or research led pages where the fact set has a life of its own. In those cases, a dedicated fact URL can reduce confusion and make review easier.

Also do not follow it if your team cannot maintain a page with two layers well. Some teams say they will keep facts and narrative together, but what they really mean is that the page will stay vague because no one owns the reference section. A separate page is better than a badly maintained all in one page.

The advice also fails for very low authority sites expecting structure alone to force citations. It does not work like that. Better extraction improves your chances, but it does not guarantee usage. If nobody trusts the source, separation by itself changes very little.

What is the practical recommendation?

Start with one page. Put the answer first. Create an explicit fact layer in the initial HTML. Keep the narrative close enough to explain trade offs and limits. Then split only when the facts need independent governance, updates, or citations.

That recommendation is less exciting than a hard rule, but it is more useful. Most teams do not have a page count problem. They have a clarity problem. Solve that first.