# How Big Is a Topic? Sizing at the Source and at Delivery > Topic size isn’t just a stylistic choice; it’s a financial and technical one, and it’s really two questions. How big should a topic be where it’s authored, and how big should the page be once it reaches a reader? Here is the strategic case for the 250-word target, and why it can still fall apart at delivery. Documentation leaders often ask about topic size when writers can't agree on where new content belongs, or when support portals start feeling like a maze. While frameworks like DITA and Diataxis define topic *types* (task vs. concept), they do not prescribe a length. When referring to topic size, we are really looking at length or, more precisely, word count. It's not the column inches or amount of disk space. **Are you concerned about topic length for your authors, readers, or both?** *How big should a topic be where it's authored and maintained?* This is a [management information architecture](/blog/strategic-value-management-ia) question. *And how big should the page be for a reader?* This is a [delivery information architecture](/blog/strategic-value-delivery-ia) one. A well-sized source topic can still arrive at the reader too big or too small, because delivery can combine, split, or transclude topics independently of how they're stored. This affects wayfinding and user experience of your content. Over time topics grow and the writer doesn't have a framework for when to say 'enough is enough; time to split.' It's a common pattern we see in many organizations. I described my own experiences in [rabbit holes vs rescue ropes](/blog/rabbit-holes-vs-rescue-ropes). Setting a maximum topic length target is dependent on you and your content. You can have a schema or your CMS validate or enforce size limits, though. ## How big should a topic be at the source? *The Language of Content Strategy* identifies the core tension: a topic should be large enough to be self-contained from a writer's perspective, yet small enough to be portable across different contexts. There are three primary pressures that determine this balance: * **Reuse (The Pull Toward Smaller):** Smaller topics are more portable, easier to assemble into multiple outputs, and cheaper to localize. However, stripping too much context turns a topic into a fragment that **cannot stand alone**, rendering the corpus practically unusable. * **Enough Context (The Pull Toward Larger):** Because most readers arrive via search or direct links, every topic must carry **the minimum context a reader needs to be successful** [without requiring them to read prior material](/blog/strategic-value-every-page-is-page-one). * **AI Retrieval (The Stakes Raiser):** Retrieval-augmented generation (RAG) systems pull individual chunks to build answers; if a topic is too dependent on surrounding context, **the AI surfaces the piece but loses the frame**, leading to immediate ambiguity in generated answers. ### How long should a topic be? The 250-word benchmark At DITA Europe 2026, content practitioners from ServiceNow spoke about a target of roughly **250 words per topic**. **It's not a rigid rule; it's a working constraint** that keeps writers honest about scope. Shorter topics cost less to localize, which is critical for organizations publishing in multiple languages. A team without a topic size expectation tends to let topics expand indefinitely, making it harder for readers to find the specific answer they need. We want **readers arriving on a page to get a complete answer**, or an AI system to reason and synthesize an accurate response from the content. ## How big should a topic be at delivery? A well-sized source topic doesn't guarantee a good reader experience. Can a user who arrives at a page get a complete answer to their question without clicking elsewhere? If the answer is no, the delivered page has a chunking problem that usually goes in one of two directions: the "Frankenbook" or the "infinite scroll," and neither is really about how the source topic was sized. It's about how delivery assembled it. It's important to isolate '*to their question*' in the previous paragraph. A person who gets an answer to one question may have follow-up questions. Follow-up questions are signal of a new user journey. That journey may be closely related to the one the user was just on, but it can be isolated and viewed independently. The answer to the follow-up questions do not need to be on the same page. They might be, and that is why user research and having a true understanding of what your readers need is necessary. ### The too-small "Frankenbook" When moving to topic-based authoring, teams often treat a "topic" as a page-building unit rather than an information design philosophy. This creates the [Frankenbook](https://everypageispageone.com/2012/02/24/frankenbooks-must-die-a-rant/) problem: content with required context is broken into individual pages that assume the reader has seen everything before it. These pages can be easy to spot. They tend to be mechanically and arbitrarily split at every heading, even heading 5s get their own page. ### The too-large "infinite scroll" Conversely, some delivery layers skip chunking entirely, stitching well-scoped source topics into long pages that force users to scroll for answers. While infinite scrolling works for social feeds where users are "browsing," it is not recommended for documentation, where wayfinding depends on finding specific information quickly. Nielsen Norman Group (NN/g) [research highlights the user experience (UX) cost of long pages](https://www.nngroup.com/articles/scrolling-and-attention/): * **Attention Drops:** 74% of viewing time is concentrated in the first two screenfuls. * **Scanning Efficiency:** Well-structured content enables users to focus efficiently on task-relevant information; removing that structure makes finding a "needle in a haystack" harder. ## Why a well-sized topic can still fail at delivery A topic sized correctly at 250 words in the CMS doesn't guarantee a well-sized reader experience. Delivery can assemble several well-written source topics into one long page (infinite scroll) or split a single coherent topic across multiple screens or paginated views (Frankenbook), independent of how disciplined the authoring was. Getting topic size right requires attention at both layers: [management IA](/blog/strategic-value-management-ia) governs what's authored and maintained as one unit; [delivery IA](/blog/strategic-value-delivery-ia) governs what's actually assembled and rendered for the reader. **The UX Audit:** Look at your five highest-traffic delivered pages, not your source topics. Can a reader have enough context to get a complete answer without leaving? If not, the problem may be delivery assembly rather than the authored topic size. --- If your content structure is making it harder for systems to surface answers, [schedule a conversation](https://calendly.com/intuitive-lief/discovery-initial-consultation) to work through your architecture.