One keyword per page, checked at build time.
Every page owns exactly one search query, declared in its source and collision-checked when the site is built. No two pages on the site ever compete for the same searcher.
Two pages, one query. Both lose.
A site with no rule about queries grows two pages that answer the same question. Nobody planned it. One was written in the spring, one in the autumn by someone who did not search first. Each is half as good as the page that would have existed if the effort had gone into one.
A search engine has to pick between them, and it picks inconsistently. Links split across the pair. Neither ranks as well as one would have. The site has paid twice for a page and received less than one.
The usual remedy is an audit, run once a year by whoever remembers. The playbook’s remedy is a rule the build runs every time.
One question, one page. The build keeps the count.
Declare it, then let the build collide it.
Every page declares its query
The query is written into the page’s source, next to its title, as the one search phrase the page exists to answer. It is emitted into the page as metadata, so it can be read back from the output rather than trusted from the source.
The build collects every query
After the pages are rendered, a check reads the metadata from each one and builds the list. A page with no query fails, unless it is a page that is deliberately not indexed, such as a conversion page or a legal page, and is registered as such.
Two pages on one query fail
If the list contains the same query twice, the build stops and names both pages. Someone has to decide which page owns the query, and the other page either takes a different intent or goes.
The rule cuts both ways. Never two pages on one query, and never two queries on one page. A page that tries to answer two questions answers neither well; the build cannot catch that one, but the discipline of writing one phrase into the source makes it hard to pretend otherwise.
Intent decides the page. The build enforces the decision.
Every page on ownthecode.dev declares one query. This page owns “one keyword per page”. The stack page owns “astro for client websites”. If a second page declared either, the build would fail and print both file names.
The rule also forces a sharper question than which keywords the site wants: what does the searcher mean? “Webflow alternative for client sites” and “webflow export code” look related. They are different intents. The first person is shopping for a replacement and belongs on the stack page. The second is trying to leave and belongs on the Webflow escape page. Two pages, two queries, no collision, and each searcher meets the page written for them.
Every indexable page at launch declares one query, where the gate can read it. When the next page is written, the first thing the build will ask is which query it owns.
No two pages compete. Not by policy. By build.
The page has its query. Now it has to be true.
Silos decide where a page lives; the query rule decides what it is for. The next system, write, then verify, is about whether what the page says can be sourced. The playbook runs all six together.
Read the sharpest chapter first. It costs an email.
We’ll send the build-gate chapter in full: the checks, the code, and the reasoning. Read it. If it doesn’t change how you think about shipping client sites, you’ve lost ten minutes and kept a working release gate.
That did not send. Check the address and try again.