Why a growing publication needs a separate index and bodies

I narrowed what the index actually needs

Choosing a post requires its title, short description, category, publication state and update information. Detailed steps, comparison tables and frequently asked questions belong to the reading stage. Separating those groups reduces the need for the first screen and archive to know every complete article.

The search scope must be chosen before making this division. A title-and-summary search can work with a small index. Finding every sentence deep inside an article may require a separate search index or server search. I do not present an archive search as full-text search simply because it returns some posts. Visitors and the person maintaining the site should understand what is being searched.

I made each body a connection resolved when needed

The current source has an explicit map from article slugs to loaders. Each loader dynamically imports the corresponding body file. The archive uses compact metadata, while a detail route asks for the body matching its address. That differs from directly importing every complete article into the entry module.

Dividing the files does not make the whole first screen light by itself. Shared UI, large images, interactive tools and libraries can create other costs. If a detail page still includes home features, that also deserves a separate inspection. I keep the result of body separation distinct from a conclusion about the performance of the entire website.

I check for titles without usable bodies

Separation introduces new failure cases. A post can appear in the index without a registered loader, its body slug can differ from the metadata, or a withdrawn post can remain in related links. A clean-looking archive is incomplete if its links do not lead to usable content.

The current check visited every published entry, confirmed its loader, loaded its body, compared the slug and checked for sections. It also compared the number of independent body chunks with the published index and confirmed that an unknown slug returns null. This check did not measure runtime browser requests or search-engine exposure.

1. Does every published address have a registered body loader?
2. Does the loaded body identify the same slug as its metadata?
3. Does the body contain the required content structure?
4. Are unpublished entries excluded from public and related lists?
5. Does the build keep body chunks outside the entry’s eager dependencies?

I retain a publication boundary around the loader

The synthetic example below reduces the inspected structure to its core. It chooses a loader only for an entry in the published index and checks that the body matches. An unknown address and a loading failure are not turned into the same successful empty result. Surrounding UI is omitted so the conditions remain easy to transfer.

This index check is not security for private material. If a draft file enters a public static build, someone who knows its address may request it directly. Private manuscripts and internal evidence must be excluded from public outputs or stored behind authentication. Removing a menu item and restricting access to a file are separate checks.

// Synthetic example: metadata is small; bodies have explicit loaders.
const published = new Map([
  ['first-guide', { title: 'First guide', status: 'published' }],
  ['second-guide', { title: 'Second guide', status: 'published' }]
]);
const loaders = {
  'first-guide': () => import('./bodies/first-guide.js'),
  'second-guide': () => import('./bodies/second-guide.js')
};

export async function loadPublishedArticle(slug) {
  const metadata = published.get(slug);
  if (!metadata || metadata.status !== 'published') return null;
  const load = Object.hasOwn(loaders, slug) ? loaders[slug] : null;
  if (!load) throw new Error('Published article has no body loader');
  const module = await load();
  const body = module.default;
  if (!body || body.slug !== slug || !Array.isArray(body.sections)) {
    throw new Error('Article body does not match its metadata');
  }
  return { ...metadata, ...body };
}
// The route distinguishes null (not published) from a loading failure.
// The explicit map is not an authorization boundary for private files.

Loading and failure still need a reading flow

Fetching a body later creates a loading state. My design approach is to retain the title and context, explain that the body is being prepared, and provide retry and archive navigation after failure. A failed request should not resemble an intentionally empty article, leaving visitors unable to distinguish missing content from a connection problem.

Another concern appears when a visitor switches articles quickly. An earlier request can finish late and place the wrong body below the current heading. The UI should compare the current route and request sequence, or use the framework’s cleanup and cancellation behavior to ignore stale results. The small loader here handles data selection; it is not presented as a complete shared interface that has already solved those screen states.

I check discoverable documents alongside a lighter entry

A body appearing after JavaScript runs does not automatically establish that a useful document exists for discovery. The original work also has a separate static-document generation structure. Article titles, bodies, canonical addresses and sitemap entries need direct checks alongside file separation.

The current rerun covered the client build and body connections. It did not rerun the entire static-document pipeline or verify search registration. In a new project I would separately check direct entry to a detail address, refreshing that address, and removal of withdrawn content from public lists and search-related outputs. I would not claim that a ranking or search result has been achieved.

I describe the result in terms I can verify

The observed results here are matching metadata and bodies, independent build files and the absence of bodies from eager entry dependencies. They support a deliberate choice about which information to prepare first as publication expands. Perceived speed including network conditions, device capability, caches and image weight is a different measurement.

Before advertising a percentage improvement, I preserve the maintenance conditions. Register the metadata and body together, update their publication state together, and rerun the connection checks. If performance needs measurement later, compare first and repeat visits under the same device and network conditions. A growing publication needs more than separated files: it needs a way to keep their connections correct.