Publishing 100+ Pages in a Week: What Broke and What Held

Content velocity is the most-marketed and least-documented claim in this niche, so here is a documented version: one build's git history, dated commits, page counts from its audit ledger, and the specific things that broke at speed [our data]. No traffic numbers appear on this page — the git history proves velocity and integrity, and those are the only claims it can prove.

What was in place before the sprint started?

The slow part: a content contract, build gates, and the platform — all landed with or before the first pages. The frontmatter contract is the piece that makes the rest possible: one YAML block per page feeds the answer box, key takeaways, FAQ and article schema, sitemaps, RSS, and the freshness gate, so dropping an MDX file in the right folder is the entire publish operation [our data].

That ordering is the finding, stated up front. Nothing about the writing week was heroic; the contract made every page mechanical. The system that resulted is documented as the authority engine.

How many pages actually shipped, and when?

From the greenfield insurance build's git log [our data]:

"Shipped" here means live in production, not sitting in a branch: the day-1 git history includes production redeploy commits confirming the site was serving while the map completed [our data]. Counting drafts as velocity is the usual sleight of hand in content-speed claims, so the distinction is worth stating.

The pattern repeated on our second build — a migration onto a live-traffic domain — which shipped roughly 67 reviewed pages in its first 2 days and held 298 content files at day 14 [our data]. Same contract, same gates, different vertical and country.

What broke at that speed?

The connective tissue, not the writing [our data]. Three failures, in order of expense:

The internal-link graph collapsed silently. The first related-links implementation picked siblings naively (alphabetically), which left 74 of 176 pages with zero inbound internal links while 3 pages collected 83 links each. (176 is the route total at link-fix time; the day-1 audit's 167 counts content pages — the two denominators are different counts taken at different moments.) Nothing looked wrong on any individual page — the defect only existed at graph level.

A schema choice shipped wrong at scale. QAPage markup went out on editorial Q&A pages and had to be reverted to Article: Google's structured-data documentation scopes QAPage to forum-style pages where users can submit answers (Google, structured data). One wrong default, multiplied by every page that inherited it.

Pre-contract pages carried errors. The site-wide audit checked 445 claims and corrected 40 — including a statutory figure published as "roughly $10,000" where the regulation says $12,997. The corrections concentrated in pages written before the content contract existed; contract-governed pages audited clean. The full three-build accounting is in what fact-auditing 400+ pages catches.

The second build added a fourth class: render-layer defects. Source-level gates passed while ordered lists rendered as run-on paragraphs, literal asterisks showed on 35 pages, and 58 meta descriptions ran over length [our data].

What did the failures change?

Each one became infrastructure [our data]. The orphan collapse produced a related-links graph with deliberate equity spreading, built and verified at graph level from day one on every subsequent build. The QAPage incident produced fixed schema defaults — Article plus FAQPage for editorial Q&A — decided in the contract before any page ships. The audit findings put the content contract permanently upstream of page one.

The render defects produced an output gate: every page is built and checked as HTML in CI, so the thing readers and crawlers receive is the thing that gets validated. And one more velocity-specific rule from the second build: canonical stances on contested questions are written down before parallel writers start, because that build's fleet answered one question 3 different ways across 4 pages before the review caught it.

What is the generalizable rule?

Velocity comes from the contract, not typing speed. Both builds hit their maps in 2 days because one frontmatter block drives every downstream surface and the gates enforce it mechanically — the slow work happens once, before page one, and its cost is priced honestly in what a fact-audited page costs. Google's quality bar is about whether content is helpful, reliable, and people-first (Google's guidance) — cadence appears nowhere in it, and in our record cadence was not what generated errors.

Against our own interest, since fast builds are what we sell: a 100-page week is not a product worth buying on its own. Without the contract, the graph checks, and the audit, high velocity just ships failure modes at the same speed — 74 orphans and a schema revert are what our own sprint produced before the gates caught up [our data]. Buy the system or build it first; the page count is a byproduct, and what the pages must do once live is the subject of the operator's guide.