What an Authority Site Build Costs: The Four Cost Centers

Ask what an authority site costs and the answer usually comes back as a monthly retainer or a per-page rate. Neither one describes the shape of the spend. A build has four cost centers, they happen in a fixed order, and three of the four happen exactly once — which makes the sequence you buy in more consequential than the rate you negotiate.

This page prices that shape. It does not quote a build price: no source on our closed list publishes one, and our own record holds git-dated build velocity and committed audit ledgers rather than metered spend or a rate card [our data]. Where the arithmetic belongs, it is linked.

What are the four cost centers of an authority site build?

Four, in build order: niche research, the content contract, the publishing engine, and the content tranches. The first three are one-time work. Only the fourth grows with page count.

The order is the finding. Research belongs first because its job is to be able to say no, and it is the cheapest of the four. The contract belongs before page one for a reason our own ledger records: on our greenfield build, a site-wide fact audit checked 445 claims and corrected 40, and the corrections concentrated in pages written before the contract existed, while contract-governed pages audited clean [our data].

Why is the engine a one-time cost and content a linear one?

Because the engine is a set of rules and gates, and rules are not re-bought per page. Across our 3 production builds the same shape — one frontmatter block per page driving every downstream surface, plus build gates that refuse to ship a page breaking the contract — carried a full five-cluster content map in 2 days on the greenfield build and 67 reviewed pages in 2 days on the migration build [our data]. Page 200 then obeyed the same rules as page 2 at no additional engine cost.

Content does not behave that way, and only part of it compresses. The second page in a cluster reuses the first page's sources, and publish QA collapses toward zero once gates run mechanically. Claim verification does not compress: each statistic still has to be traced and each computed figure re-run, which is why per-page production cost is modeled by stage rather than by word count.

How many pages does a first phase actually ship?

As many as the architecture calls for, and our three builds landed in three different places for that reason. The greenfield build counted 167 content pages across five clusters at audit time. The migration build held 298 content files by day 14 (2026-08-19) against a roughly 365-URL architecture. The third build holds 106 content files against a 102-page architecture [our data].

Those are different numbers because the cluster maps were different, not because the budgets were. Page count is an output of library architecture — how many clusters, how deep each one goes, which questions actually have demand — so a proposal that opens with a page count and no architecture is quoting a volume rather than a build.

One thing these figures do not do is predict what any of it earns. Our register carries build velocity and audit ledgers deliberately, and no traffic or revenue figures at all [our data]. A page count is evidence about production, not about what an answer engine will do with the pages. Google's own guidance sets the bar at content that is helpful and reliable for the person reading it (Google, people-first content guidance) — a per-page property, which a total cannot demonstrate.

What does the infrastructure line actually cost?

Close to nothing, on the architecture we run. Our canonical stack is a static export served from a CDN's free tier, with the content layer held as MDX files in git rather than in a CMS; one of our three builds runs a paid server-feature tier so it can offer grounded site search. None of the three carries a CMS subscription [our data]. Where a database does appear in our fleet it sits behind a product feature — a lead pipeline, a market-data board — not behind the content pages.

We put no monthly figure on either line, because our record holds build velocity and audit ledgers rather than metered bills [our data]. An estimate here would be precision we did not measure, which is the failure this page exists to avoid.

That is a description of our stack, not a claim about anyone else's. A build with a CMS, a database, or per-request rendering has a real infrastructure line, and the honest comparison is architecture to architecture. What is worth noticing is how little the platform has to do: Google's Search Essentials describes what a site must satisfy to be crawled and indexed at all, and none of those requirements are things a subscription buys. An infrastructure line that dominates a content-library budget is usually paying for capabilities the library never uses.

What is the recurring cost that never goes away?

Review. Infrastructure stops being a decision once the stack is static; verification recurs for as long as the library exists. On our builds the freshness gates fail the build when a page's review date lapses — 182 days for money pages, 365 days for reference pages — so review is a build failure rather than a good intention [our data].

How large that line runs depends on claim density, not page count. In our own per-page labor model, which is an illustration rather than a metered figure, audit and refresh together are about 43% of a page's lifetime hours. The per-claim version of the same question — what verification costs when the unit is the claim rather than the page — is worked through at what a fact audit costs, against the same 445-claim, 40-correction ledger [our data].

What does getting the order wrong cost?

More than any single line item, because the wrong order is paid twice. The three one-time centers exist to make the fourth cheap and consistent, so buying content before the contract and the engine exist means paying for pages and then paying again to bring them into compliance. Our own audit is the receipt: 40 corrections in 445 claims, concentrated in the pre-contract pages [our data].

Two other rework items from the same record make the point at a smaller scale. A schema type shipped for editorial question-and-answer content had to be reverted after the fact. A naively built internal-link graph left 74 of 176 pages with zero inbound links while 3 pages collected 83 each, and had to be rebuilt with equity spreading [our data]. Neither was expensive on its own. Both were spend that produced nothing new.

Why does this page not quote a build price?

Because we cannot compute one honestly, and every alternative is worse. Our first-party record documents dated velocity, page counts and audit ledgers, and deliberately not spend or rates [our data]; no source on our closed list publishes authority-site build prices either. A figure here would be an estimate wearing the clothes of a measurement, which is the specific failure this library exists to avoid.

What you can compute is your own number, in three moves. Take the per-page labor model from what a fact-audited page costs, run it through your architecture's page count using the worked totals in the 100 to 200 page library budget, then add the one-time research, contract and engine work as separate lines. That produces a budget with your wage assumptions in it instead of ours, and it makes every quote you receive answerable to one question: which of the four cost centers does this price include, and at what depth?

Said against our own interest, since we sell builds: the cheapest good outcome here is a research pass that comes back no. That is the whole point of putting it first — it can end the project before the other three centers are funded, and a research line that cannot return no is onboarding with a research label on it. If you want the short version of that test before anyone quotes you anything, the fit check is it.