Content collections: how a static site handles hundreds of pages
Five pages are easy; five hundred articles need structure. How content collections organise, validate and publish at scale, without a database.
The short answer
A static site with five pages is a handful of files. A static site with five hundred articles, in nine topics, with search, related links, feeds and structured data, needs a system, and content collections are that system. A collection is a folder of content files, each with a block of structured fields, title, date, topics, summary, and a body of text. A schema defines what those fields must contain, and every file is checked against it when the site is built. The build then turns the collection into pages, listing pages, a search index, feeds and structured data, all as plain files. Nothing runs when a visitor arrives. This knowledge base is built exactly this way.
What a collection gives you
| Need | How a collection handles it |
|---|---|
| Consistency across hundreds of pages | One schema; every file must satisfy it or the build stops |
| Listing pages, topics, related articles | Generated from the fields at build time |
| Search | An index built from the pages, served as static files, queried in the browser |
| Feeds, sitemaps, structured data | Generated from the same fields, always in sync with the content |
| Versioning and review | Files live in the repository; every change is a reviewed commit |
| Speed | Finished pages on a network; per-page speed does not depend on how many pages exist |
| Security | No database, no admin panel on the public site |
From a file to a page
- An author writes a file: fields at the top, text below, in a plain format an editor or an interface produces.
- The build reads every file in the collection and validates each against the schema.
- Templates render one page per file, plus listing pages per topic and an index.
- Derived outputs are generated: search index, sitemap, feeds, structured data for search engines and AI systems.
- Everything is deployed as static files to the network, cached at the edge.
- A change to one file triggers a rebuild that checks everything again and publishes the result.
Scale, in practice
Two things stay constant as a collection grows from ten files to a thousand: the speed of each page for a visitor, because every page is a finished file, and the guarantee that every page satisfies the schema, because every build checks every file. What grows is build time, which is measured in minutes and happens on a build server, not in front of a visitor. For a knowledge base, a catalogue or a large documentation site, that trade is exactly right.
What this means for you
If your site will have many pages of written content, articles, guides, locations, products described in text, content collections are how a static site handles it without a database. You get consistency enforced by a schema, listings and search generated for free, versioned changes, fast pages regardless of scale and nothing running on a server. It is the structure underneath what you are reading now.
Frequently asked questions
Is a folder of files really better than a database for content?
For content that is written and read, rather than transactional, yes, in most respects: every change is versioned and reviewable, the schema is enforced, there is no database to secure or back up, and the build produces plain files that are fast and cheap to serve. Databases are for data that changes per visitor or per second; articles are not that.
How do non-technical editors add content?
Through an editing interface that writes the files and commits them, or through a headless content system that the build reads from. Either way the editor sees a form with the schema's fields and a text editor; the files and the build are behind the scenes. The preview link shows the result before it goes live.
What happens if an editor fills in a field wrongly?
The build fails with a message naming the file and the field, and nothing is published until it is fixed. That is the feature: a date typed as text, a description too long for search results or a field the schema does not know is caught before any visitor sees it.
Sources
- Astro documentation: Content collections (accessed 2026-09-11)