Content architecture
Should a subtopic get its own page, or live on the page you already have?
Picture a SaaS pricing page that gets a steady trickle of visitors asking whether it integrates with Slack, Salesforce, or Jira, answered today in one throwaway line. The question every content team asks next is where the real answer should live: a dedicated Integrations page, or a proper section on the pricing page itself.
We ran the experiment instead of guessing, and in a controlled test of AI retrieval, identical content was found exactly as often either way, 70% on its own URL and 70% as a section, meaning the new page added nothing on its own. What actually moved retrieval, from 15% up to 70%, was how well the subtopic had been developed, not where it sat.
The short answer
Develop the subtopic where it already lives, write the real integrations section on the pricing page itself. Only create a new page when the subtopic serves a genuinely different reader task, not because the topic feels big enough to deserve its own URL.
The question behind the question
Every content team runs into this decision sooner or later. A subtopic buried inside an existing page starts pulling its own search demand and its own questions, and someone on the team asks whether it has earned a dedicated page of its own. The advice you will find online is mostly framework advice: one topic per page, split it off if it can target its own keyword, build a hub and spoke structure so every idea gets its own address. What that advice rarely tells you is that none of it comes from an actual experiment.
And all of it quietly assumes the same thing: that the URL itself does work, that giving a subtopic its own page is what makes it easier for people, or for AI systems, to find. That assumption happens to be testable, so we tested it.
What we tested
We started with 20 real pages, each carrying one subtopic that people clearly ask about but that the page itself barely covered, and for each of those pages we built three versions so we could compare them directly. Picture the pricing page from the intro: the original page, unchanged, still answering integrations in one line; a dedicated Integrations page carrying nothing but that content; and a third version where the same integrations content, word for word, becomes a real section on the pricing page itself. That is the shape of the comparison, repeated across 20 different pages and topics, not just this one:
- The original page, left unchanged, with the subtopic still underdeveloped.
- A new dedicated page about the subtopic, running 600 to 900 words.
- The same content, word for word, rebuilt as a section on the original page.
Because the dedicated page and the section carry identical content, any difference in how well they performed could only come from one thing: whether the content lived at its own URL or not.
From there we asked 160 real questions, drawn from what people genuinely ask about these topics, and measured whether AI retrieval systems could actually find the content and answer from it. The full method, corpus, and judging setup live in the Architecture Study.
What happened
On questions about the subtopic itself
On questions about the whole topic
Findability = a top-5 retrieved passage plus a 2-of-3 cross-family AI judge panel confirming the question is answered. n = 20 sources.
Findability deltas (percentage points)
95% CI 38.8 to 70
95% CI 43.8 to 72.5
95% CI −7.5 to 7.5
The dedicated page and the section carry identical content. They differ only in whether that content sits on its own web address or inside the page it came from. The zero in the last row is the whole finding: the address made no difference.
Developing the subtopic properly is what moved retrieval on its own questions, from 15% all the way up to 70%. The URL, on the other hand, did not move the number at all: the dedicated page and the section landed on the exact same 70%, which is the whole finding in miniature. Once the content itself was developed, giving it a separate address bought nothing extra.
The dedicated page also had a blind spot the section did not. On questions about the whole topic, the kind a reader asks when they want the full picture rather than just the subtopic, the dedicated page scored only 13%, because by design it contained nothing but the subtopic. The section version kept whole-topic coverage at 57% while still matching the dedicated page on subtopic questions, so the one page quietly did both jobs. It is worth being precise about what that comparison shows: we measured each version standalone, not against a site that kept the original page and added a new one alongside it, so this is not evidence that your site loses coverage by adding a page. It only means the new page, on its own, could not answer the broader questions the original page could.
Translate that back to the pricing page: a dedicated Integrations page and a real integrations section on the pricing page would land at the same 70% on integration questions, but only the pricing-page version would still be able to answer someone asking about pricing itself.
How to decide, in three steps
Check whether the gap is real
Most of the time it is not. In a separate study, about 62% of the concepts flagged as missing from a page turned out to already be answerable from that same page, just through related wording that never named the concept outright. Before the pricing page team builds anything, they should check whether the page already answers the integration questions in some form, maybe a partner logo strip or a feature comparison table nobody thought to call an integrations section. If it does, there is no real gap to fix and nothing worth splitting off. When the gap was genuinely real, though, adding the concept mattered a great deal, which is exactly why this first check is the one that decides whether you need to act at all.
In a separate test, about six in ten concepts flagged as missing from a page turned out to be answerable already, through related wording that never named the concept outright. Before deciding a subtopic needs a new home, it’s worth checking whether it already has one.
If the gap is real, develop it in place
Write the subtopic as a clear, self-contained section that covers what it is, how it works, when it applies, and ideally an example a reader can hold onto. For the pricing page, that means an actual integrations section: which tools, how the connection works, what is required to set it up, not just a logo row. That single step, developing the content, is what moved retrieval from 15% to 70% in our test, while the URL it lived at added nothing on top of that gain. A dedicated Integrations page, meanwhile, is simply a second thing you now have to write, link, and keep maintained.
Split only when the subtopic serves a different task
Not because the page is getting long, and not because integrations could target a keyword of its own. Split when the reader who needs the detail is doing a genuinely different job at a different moment: a technical buyer running due diligence on a dedicated Integrations page with setup steps and API scopes, not a prospect skimming pricing. The same rule holds wherever it shows up: a troubleshooting page next to a setup guide, an API reference next to a tutorial. Different moment, different intent, different page.
What this test does not tell you
We measured AI retrieval, not Google rankings. The test measured whether AI retrieval systems could find the content and answer real questions from it, which is a different thing from measuring rankings, organic traffic, or citations. So if your decision rests mainly on ranked search behavior, this evidence can inform it, but it does not settle it on its own.
Each version was measured on its own. In practice you would keep your original page when you add a new one, so this is not evidence that your site loses whole-topic coverage by splitting content out. The accurate reading is narrower than that: the new URL added nothing the section did not already deliver on the subtopic’s own questions, and taken by itself, the new page could not answer the broader questions about the topic the way the original page could.
It is one experiment, on 20 pages. The subtopics we tested were filtered to ones people actually ask about, which skews the sample toward higher-demand concepts rather than a random cross-section. The result is strong enough that it should change your default assumption, but it is not a law.
Common versions of this question
Should a subtopic get its own page, or stay as a section on the page it is already on?
Default to a section on the page it already lives on; a dedicated page gave it no retrieval advantage. Our test found identical content retrieved at 70% either way, whether it lived on its own URL or as a section. Create a new page only when the subtopic serves a different reader task.
Does a long page hurt AI retrieval?
No, page length on its own does not hurt AI retrieval. AI retrieval works at the passage level, since systems retrieve chunks of a page rather than whole pages, so a page does not compete as one single block. In our test, the page carrying both the main topic and a developed subtopic section did well on both kinds of questions. Length was not the variable that moved retrieval; how well the subtopic was developed was.
What about keyword cannibalization?
This test did not measure rankings, so it does not test cannibalization directly, but it points the same way as standard cannibalization advice. Cannibalization is about two of your pages competing against each other in ranked search results. If a new page would only answer the questions a section already answers, it adds nothing, and now you have two candidates competing for the same query instead of one strong one.
Check before you decide
The first two steps of the checklist above are things you can actually measure rather than guess at. ContentGrapher maps which concepts on your page are present but underdeveloped, which are genuinely missing, and which would be better served by a separate, more focused page, which is exactly the evidence this decision needs.
How an AI reads your page: dashed nodes are concepts it would expect but didn't find.