How to stop pages going live without a description
A CMS lets a page with no meta description publish. A typed content schema fails the build instead. How that works, and what it costs your editors.
To stop pages going live with a missing description or broken content, the check has to be enforced by the system, not remembered by a reviewer. In a typical CMS a missing meta description is not an error, so the page publishes. With typed content collections, as in Astro, the build fails and there is nothing to deploy. The first thing to ask your supplier is which content rules the build enforces and which depend on someone remembering.
Here is how that worked on this site, and where it stops.
When a supplier says every page was checked before release, what usually backs it is memory and a review. In a content management system a page with no meta description publishes. A page with an empty FAQ section publishes. A page whose category was never set publishes, and lands wherever the theme puts an undefined value. None of these is an error, because nothing in the system treats them as errors. They are absences, and absences are silent.
The business cost is slow and cumulative: pages that look unfinished in search results and on the site, and no record of when it started. The largest practical difference in moving this site to a static build was not speed or security. It was that content acquired a schema, and the schema can refuse.
What was actually going on
Every content type here is declared with a validator. An article requires a title, a publication date, a topic from a fixed list and a description of at least 70 and at most 165 characters. A product carries more, because more depends on it: a status from a fixed set, at least three features each with a title and a body, at least three bullets, at least four FAQ entries, and a category term used to build the page title.
If any of that is wrong, the build stops. Not a warning in a log or a red dot in a dashboard. There is no artefact to deploy.
It caught something this week. An article about verification was given a description of 169 characters. The limit is 165, chosen because that is roughly where Google truncates. The build refused:
description: String must contain at most 165 character(s)
Four characters. In a CMS that page ships, the snippet is cut off mid-sentence in results, and nobody finds out unless they happen to look. Here it cost thirty seconds and could not reach production.
The constraints are where the editorial standard lives, because the type checks are table stakes. A minimum of four FAQ entries on a product means nobody ships a page with two lazy questions, and it is enforced by the build instead of by a reviewer remembering. Each of these is an editorial policy made executable, which a CMS cannot do: a required field there can be filled with a space.
What we changed
The moves were to put the schema in front of the content and to give each fact one home. The one that
has earned the most is small: product status is one of four fixed values, live, uat, in-build
or pre-launch. The page renders it, the platform index groups by it, and the homepage count of live
applications is derived from it. Before, that number was a word in a paragraph, and words in
paragraphs go stale silently. When longer product pages were written later, the instruction not to
describe an in-build product as though it were in production had something to check against.
What it did not fix
A schema checks shape, not truth. It can insist on at least four FAQ entries. It cannot tell you they are good ones.
It also has a cost. Authors must satisfy a validator, and the error names a file and a rule and offers no help. For an engineering team writing its own material that is fine. For a marketing team used to publishing without a build step it is friction, usually solved with a git-based editing interface, which is real work and should be budgeted. Schema changes are migrations too: adding a required field means every existing entry fails until it is filled in. That is correct behaviour and it is still an afternoon.
What to ask your own team or supplier
Put these to whoever builds or edits your site:
- Which rules about content or configuration are enforced by the build, and which only by someone remembering to check?
- What stops a page shipping without a description, a category or a status?
- Where a fact such as “how many products are live” appears in text, is it typed or derived?
- If you add a required field, how do existing entries get found and fixed?
Where this ends up
Moving a site off a content management system is the smallest version of the work we do as enterprise software modernisation, and it has the same shape as the large ones: the gain is not that the replacement runs faster, it is that it can refuse what the old system silently accepted.