Overview

An overview is the landing page a reader reaches first in a product area: it answers "what is this, and where do I start?" in one paragraph, then routes onward. The tone is accessible, welcoming, conversational, and outspoken.

Use an overview as the single landing page for a product or major product area, the page its sidebar section opens on. It is not:

• A concept page. Move architecture and tradeoffs to a concept page and link to them. An overview orients rather than explains.
• A bare table of contents. A list of links with no orientation only duplicates the sidebar.
• A marketing page. The reader has already clicked into the docs.

For the full comparison, refer to Content types. For a live example, refer to the Argo Smart Routing overview.

• Title: the name of the product, product group, or content area, as a noun. Do not append "documentation", use a gerund phrase, or use "Introduction".
• Description: name the Cloudflare product and what it does for whom in one sentence, then state the plans it is available on.

Use the Nimbus overview recipe to generate this page. Your coding agent pulls the full page skeleton and self-review checklist, then adapts them to your product:

npx @cloudflare/nimbus-docs add content-overview

yarn @cloudflare/nimbus-docs add content-overview

pnpm @cloudflare/nimbus-docs add content-overview

Adapt the frontmatter the recipe emits to Cloudflare's schema: set pcx_content_type and products instead of the generic fields the recipe emits, such as type.

• Cards are the signature components: this is the one type where cards are the body content, because routing is the body. Keep card text to a name plus one line, because a card that explains is a concept paragraph in a box. In the Markdown twin cards flatten to link-plus-description lists, so write the one-liners so they work in both forms.
• Link lists beat cards when the grid forces padded copy, or when a group genuinely must run past the roughly five-link cap, because prose lists scan better at volume.
• What does not fit: Steps (nothing is performed here), code blocks (nothing is looked up, though inline code in the orientation line is fine), and accordions (an overview with hidden content is hiding its own map).

pcx_content_type: overview
products:
  - product-a
  - product-b
  - product-c

For more details, refer to pcx_content_type.

Every product or major product area must have an overview, so the answer to a weak one is always to strengthen it, never to remove it. If a page reads like a bare table of contents, add the orientation that says what the area is and where to start. Do not delete it and let the sidebar stand in.

The only page you hide is a structural group node: a folder that exists purely to group its children in the sidebar and was never a content page. You cannot delete a folder's index.mdx without a build error, so hide the placeholder and redirect readers past it by setting group.hideIndex to true:

---
title: Placeholder
sidebar:
  group:
    hideIndex: true
---

• Self-contained orientation. Write the opening paragraph so it stays accurate in isolation, because it is what an agent quotes when asked what the product is. Do not lean on the title or a later section to complete its meaning.
• Literal availability. State availability with literal plan, region, or release-stage names rather than a paraphrase.
• Load-bearing links. Use real, current routes, because a stale route here strands a reader at the front door.