What should a content operations ledger record so you can measure anything later?

A content operations ledger should record, for every change, the page URL, the date, what changed, how the page was chosen, the pages you left alone and any other edits nearby. With a saved copy of the daily Search Console data, those rows let you compare the change later with pages left untouched.

• Search Console keeps the last 16 months of data (Google, Analytics Help, read 30 October 2026).
• Penlid's free did-it-work tool reads one change per line, as a page URL, a date written YYYY-MM-DD and an optional note, up to 50 changes (Penlid, did-it-work tool, read 30 October 2026).
• When Penlid changes a page it records the change and freezes a pool of up to 30 untouched pages, and leaves out and counts any of those pages changed from 56 days before the change to 28 days after it (Penlid, methodology, read 30 October 2026).
• In Penlid's simulated tests, unchanged pages whose last 28 days sat at least one standard deviation below their own average were called "improved" 5.50% to 9.20% of the time, against at most 3.10% for pages picked another way (Penlid, methodology, read 30 October 2026).

What is a content operations ledger?

A content operations ledger, as we define it rather than as an industry standard, is a dated record of your page changes, of the pages left alone around each one, and of where the measurement data is kept. Two kinds of fact belong in it: decisions nobody else writes down, and data that expires.

Timing alone cannot settle whether a change worked: Google's guidance on measuring the impact of page changes says it can be difficult to tell whether a change caused an improvement, because periodic changes in user sentiment, news events or improvements to a competing site can also contribute to changes in performance. Penlid's methodology asks instead whether the page did better than the untouched pages predicted; our reasoning is that answering that later takes records made at the time. Our free did-it-work tool runs that comparison in your browser.

Which fields should every ledger row have?

Every row needs eight fields: the page URL, the date, what changed, who made it, how the page was chosen, the pages left alone, other edits nearby and the data copy.

The first three fields are the ones the did-it-work tool reads, separated by commas or tabs, so a column pasted from a spreadsheet works; its date must be YYYY-MM-DD alone.

Why freeze the list of pages you left alone?

The untouched pages are what a changed page is later measured against, and Penlid's methodology says the one fact that cannot be rebuilt afterwards is which pages you left alone. When Penlid changes a page it records the change and, at that moment, freezes a pool of up to 30 untouched pages, ranked by how close they were in traffic and in trend, with a modest bonus for sharing the first URL path segment. Only the best eight are used, and with fewer than three untouched pages left the result is "not measurable" rather than a number. Our reasoning: save the list itself, not a rule for rebuilding it, because pages are added, merged and redirected.

Penlid's methodology is blunt about edits: We only know about changes we were told about. A comparison page someone edited outside Penlid looks untouched to it, and a few such pages can move the comparison. Penlid leaves out and counts any comparison page changed from 56 days before the change to 28 days after it, and the free tool does the same for pages you list, so list every change, not only the one you want measured. Our reasoning: the ledger should be the one place everybody's edits go, template updates and migrations included, both of which Google's custom annotations announcement names.

Why record how each page was chosen?

How a page was chosen changes how its result should be read, because a page picked for having declined is likely to improve on its own. Penlid's methodology calls refreshing declining pages the largest remaining source of false "improved" results, one it cannot remove; the effect is regression to the mean.

Drift is how far pages wander apart on their own. Pages not picked that way were called "improved" at most 3.10% of the time. If you did pick on decline, Penlid advises reading an "improved" as at least as good as the pages left alone, possibly with some recovery that was coming anyway. When a result matters, the methodology says what reduces the problem is to choose which pages to change without looking at how they were trending: every page in a set, or alternate pages (see how to choose pages to change without bias). If you must work from decline, see which pages to refresh first, and note the rule either way.

Which Search Console facts belong in the ledger?

Record where your copy of the daily data is kept, the date you exported it and the time zone of its days, because Search Console itself keeps only the last 16 months.

The did-it-work tool prefers day-by-day rows with a Date and a Page column. The interface export stops at 1,000 rows (see the export row limit), so a page-by-day history comes from the API or one of the routes the content decay check lists. A bulk data export can keep a running copy, but Google's setup page sends you to the API or the reports for data from before it began, and its table guidelines say a missed day is retried for about a week, after which Search Console stops trying to save it, so check for gaps.

Chart annotations are no substitute for a ledger: a note holds up to 120 characters, a property up to 200 notes, and notes older than 500 days are deleted automatically.

What should you add when AI drafted the change?

Record the exact model ID and the date the draft was made. Anthropic's documentation says a Claude model ID identifies a pinned version of the model, which an alias does not. It also says the infrastructure around a model can change, which can produce minor differences in behavior; our reading is that the date matters as well as the ID. See also what a human should approve and fact-checking AI-written content.