Content Inventory and Template Map

Somebody proposes changing the product pages. A reasonable first question is how many there are.

The CMS says 4,000. The sitemap has 6,200. Search Console reports impressions for just over 11,000 URLs. The gap is pagination, sort parameters, a legacy template that three hundred pages still render through, and a few thousand variants nobody meant to publish. Every one of those numbers is correct about something, and none of them is the answer to the question.

The decision it encodes

What pages exist, what is each one for, and which of them share a template?

Not a catalog for its own sake. Nothing downstream can proceed without it: you cannot split a template you cannot enumerate, and you cannot rank a roadmap by traffic at stake without knowing which pages a change would reach.

Two different units, and you need both

This is the distinction the rest of the system rests on.

The template is the unit of change. It is the thing an engineer edits once and thereby alters thousands of pages: a title pattern, a schema block, an internal linking module.

The page is the unit of randomization. It is the finest thing you can leave alone while changing its neighbor, which makes it the only available control when the channel cannot be switched off.

A program that knows its templates but not its pages can ship changes and cannot measure them. One that knows its pages but not its templates can measure things nobody can act on.

What a row in the inventory carries

Field	What it decides
Canonical URL	Which of several addresses is the page. Without it the same content is counted many times and split into both arms at once.
Template	What a single change would reach. The unit of action.
Intent	What the searcher wanted. Two pages on one template can serve different questions and respond differently to the same edit.
Index state	Whether the page is in the index at all. A page that is not has no impressions or clicks of its own to move, whatever it does for the pages that link to it.
Traffic share	How concentrated the template is, which decides whether a split can ever detect anything.
Last changed	When this page last moved, so a readout can exclude pages that were altered for other reasons mid-test.

Measure the concentration

Organic traffic follows a power law almost everywhere. A template with 4,000 pages where forty of them carry half the sessions is not a 4,000-unit experiment. It behaves like a far smaller one, because the pages that move the total are few.

That number also tells you which templates are testable at all. A long-tail template with thousands of similar low-traffic pages is the best experimental surface a site has. A template of twelve category pages, three of which are the business, is not, and no amount of care in the design will change that.

• Listing pages
• Guide pages
• Category pages

Swipe sideways for the full chart

Show the data

Template	Pages	Pages for half the sessions	Top 10% hold	Effective pages	Detectable effect
Listing pages	4,000	241	61%	459	0.26 SD
Guide pages	400	23	63%	56	0.75 SD
Category pages	60	4	68%	10	1.77 SD

Index state is eligibility

The parallel with a lifecycle program is exact, including the order of operations. Eligibility is defined before assignment, and failures after assignment stay in the population.

Pages known to be ineligible before the split is drawn leave the eligible population: deliberate noindex pages, canonicalized duplicates, URLs with no stable outcome history. They have no impressions or clicks of their own for a change to move, and including them dilutes the estimate with units that could not respond. Pages that drop out after assignment, because they fell out of the index, went out of stock, or were recreated under a new address, stay in the arm they were assigned to, and the attrition is reported by arm. Dropping them is the same mistake as filtering an email test to people who opened.

The pages that fail eligibility are not a random subset: they skew toward thin, new, and low-traffic pages, which is the tail a split depends on. A template can look large in the CMS and be small once the eligible population is counted.

Maturity, honestly staged

Stage 1: every URL mapped to a template. No new capability, and it is the first time anyone can say what a proposed change would reach.

Stage 2: intent and index state attached. Eligibility becomes answerable, and a template stops being treated as one population when it serves several questions.

Stage 3: traffic concentration measured per template. Which templates are testable is a number rather than an argument.

Stage 4: canonicalization and parameters handled. Counts stop moving when somebody adds a filter, and a page cannot land in both arms of a split under two addresses.

Why the page count overstates the experiment Technical

A comparison between two halves of a template is powered by variation across pages, and a page contributes to that in proportion to how much traffic it carries. Formally, for pages with session shares wᵢ, the number of equally sized pages that would give the same precision is (Σwᵢ)² / Σwᵢ², which is Kish’s effective sample size.

A uniform template returns its page count exactly. A template where one page holds a fifth of the traffic and the rest tail off returns a fraction of it. It is a screen, not the power calculation. The precision of the readout also depends on day-to-day autocorrelation, on how volatile the individual pages are, on seasonality that differs across pages, on how the two arms tracked before launch, and on the estimator used, none of which the concentration formula sees. The practical consequences are two: stratify by traffic when splitting, so the large pages are balanced across arms rather than left to chance, and get the detectable effect from placebo splits, dividing the template’s own history into two random halves many times and running the planned estimator on each, which is what the commercial tooling does before it will quote a test duration.

Excluding the largest pages entirely is a legitimate move and has to be stated. It raises the effective count of what remains, and it changes the estimand to the effect on the tail, which is often not the effect anybody was asking about.

Context

Best suited for

Sites with enough pages that changes are made to templates rather than to individual pages, and where more than one team can publish.

Data requirements

• A crawl or CMS export giving the canonical URL and rendering template for every page
• Search Console or equivalent, joined on canonical URL rather than on the address that happened to be reported
• Sessions or impressions per page over a period long enough to measure concentration rather than a week of noise
• A record of when each page last changed, from the CMS or the deployment log

What changes by context

B2C ecommerce

Faceted navigation multiplies URLs without multiplying content, so canonicalization is the field that decides whether any count here is meaningful. Product pages also churn as stock changes, which makes the last-changed field load-bearing.

Marketplace

Listings are created by users, so the inventory changes faster than any crawl schedule and the tail is enormous. Templates are few and pages are millions, which is the best possible shape for splitting.

B2B SaaS

Few pages, high value each, and most traffic on a handful of them. Concentration is extreme enough that split testing is usually unavailable, and the route is a modeled counterfactual rather than a design.

Local / omnichannel

Location pages are a large, near-uniform template and the strongest testing surface on most such sites, since they share structure and differ mainly in geography.

When it breaks down

• Sites of a few dozen pages, where every page is its own template and there is nothing to split.
• Single-page applications that render everything client-side and expose no stable URL per view.
• Programs where the CMS is the only source of truth and nobody can reconcile it against what is indexed, so eligibility cannot be established.