A hundred pages without a hundred templates

The request arrives as one line: a page for each service, a page for each project, a page for each city we deliver to. It sounds like twelve pages and it is actually a hundred, and by the time you notice, the copy has been pasted into a hand-made template thirty times. Somewhere around the fortieth page the site stops being content and becomes maintenance: a price changes and nine pages are wrong, a service is renamed and the menu, the footer and the sitemap disagree.

The fix is not more discipline. It is deciding, before the fiftieth page, what is structure and what is a record.

The page count is not the work

A hundred-page site is rarely a hundred designs. It is usually five to eight kinds of page with records behind them: a home page, an index, a detail page, a few fixed pages, a form.

The useful question is not "how many pages" but "how many kinds". If two pages differ only in their words, they are one template with two records. If they differ in which fields exist — a case study has screenshots, a service has a scope list — they are two kinds, and that is a decision worth making on purpose.

A site with a hundred templates has a hundred places a font size can be wrong. A site with six templates and a hundred records has one.

Content is data, not markup

The difference is where the words live. If the text sits inside the page's markup, only someone who can edit that markup can change the text. If it is a record with fields, anyone who can edit a small file can change it, and a machine can check it.

That is not a tooling preference. It is editorial, because the fields become the writing standard:

• a title, required, one per record;
• a description with a length limit, because it is also the search snippet;
• a date, in one format, so ordering is not a guess;
• a status, so a draft is invisible rather than hidden;
• references by identifier, so a link cannot point at a page that was renamed or never published.

Write the fields down first. They are the schema of the site, and cheaper to argue about on one page than after forty records exist.

The checking is what makes it worth doing: a validator reads every record at build time and refuses the site if one is incomplete — a missing description, a reference to a project that does not exist, a placeholder in a published page. The failure is loud and happens before deployment. On a hand-maintained site the same mistake is found by a customer, or never.

Routes are generated, never hand-listed

One route file per kind of page, parameterised by the record's identifier. The list comes from the same reader that validates the records.

The consequence matters more than it first appears: the detail pages, the index, the sitemap and the language alternates all derive from one list, so they cannot disagree about what exists. When the list is kept by hand, the classic failures appear — a page live but missing from the sitemap, a draft still linked from the index, a translation without an alternate link.

Adding a page then means adding a record and rebuilding, not copying a template. Copying is what produces drift, and every copy is a small fork of the truth.

What actually breaks at scale

None of the failures below appear at five pages. All of them appear by fifty.

Symptom	What caused it	Structural answer
Nine pages say the same thing slightly differently	Copy-paste instead of a field	One template, values in the record
A page is live but not in the sitemap	Two lists, both maintained by hand	Derive both from one reader
A section is missing from the mobile menu	Navigation written in three places	One navigation source, rendered everywhere
The English page contains a French paragraph	One language edited, the other forgotten	Both language fields required per record
Adding a page takes an afternoon	No route, no record, a new file each time	One route per kind, one record per page
The build slows down as content grows	Every page rendered on demand	Prerender the records; only changed ones rebuild
A rename breaks four links	References hardcoded in the body	References by identifier, resolved at render

The table has one theme: every row is a fact duplicated in two places. Scale does not create the problem; it makes the duplicates diverge.

The order the work goes in

The wrong order produces a template nobody can populate, or a schema that fits the first three records and not the next thirty.

1. Write the fields before the template. What does a record need to be publishable? Include what must be true, not what is convenient.
2. Build one real page from a record, not a sample. The first record should be the hardest you have.
3. Move the index and the sitemap onto the same source in one change. If they stay manual for a week, they drift for a week.
4. Add the second language as fields, not as a second site with its own structure. A second site is the drift problem with a bigger budget.
5. Only then add kinds. Each new kind is a new template and new fields, and should be justified by a difference in content, not taste.
6. Add the validator before page thirty. After thirty it is a migration.

The costs that are real

The bill arrives in places people do not expect.

A required field means editing every record. Adding one to a hundred records is a hundred edits unless it has a default on read. Decide which fields are genuinely mandatory, because each is a future migration.

A bad template multiplies. One mistake on one page is one mistake; the same mistake in the template is on every page of that kind. The first template deserves more care than the first page.

Someone has to be able to publish. Files in a repository are a fine store for a small site and a poor one for a marketing team of five. If the people writing the content cannot edit files, this pipeline is wrong and the honest answer is a content management system — chosen for the editor, not the framework.

Not every page should be a record. The about page exists once. Forcing it into a schema with a dozen empty fields is worse than a plain file: the emptiness looks like a policy.

Where this advice stops

If the site will never pass twenty pages, this is overhead. A handful of pages edited rarely are cheaper than a content model and always will be.

If the content is genuinely heterogeneous — a portfolio where each case study has its own shape — the model will fight you. The compromise is a template per layout family, and a tolerance for three kinds where the content really differs. Forcing everything into one schema produces fields named "extra section 2".

And the numbers quoted about builds like this — pages per day, seconds to deploy — do not transfer between teams, tools or languages. Measure your own pipeline before promising anything.

The claim worth keeping is smaller than it sounds: at a hundred pages, the thing you are maintaining is the model, and the pages are output. Spend the care there, early, while it is still one file and one argument.