How often a page is read
The pages in your site’s inventory are read on a schedule:- Weekly. A page is read again 7 days after its last read.
- Daily while a suggestion is open. A page that one of your open suggestions targets is read about once a day, until 30 days after the suggestion was filed. Open means the suggestion has not been declined. At most 25 pages per workspace are on the daily read at once; when a new one would be the 26th, the watch that ends soonest goes back to weekly.
What a version records
Each version keeps the fields a person edits on purpose:
A page that answers with an error (a 404, say) is recorded too: the version is its status. A page we could not reach at all is not recorded, because there was no answer to keep.
Not captured is not absent
Versions taken before Attensira recorded a field cannot say what that field was. In a comparison, such a field is shown as not captured, never as removed, added or changed. The same goes for every field of a read that was not a 200: an error page has a status and nothing else to compare.What counts as a change
A read is compared with the current version of the page, not with the last read. A new version is recorded when:- any of the fields above other than the body differs (title, description, H1, H2, canonical, robots, social title and description, structured data types, structure);
- the status differs, for example 200 to 404; or
- the body text differs from the current version by more than noise: more than 3 bits of 64 in a similarity fingerprint taken over the title, the description and the first 1,500 words.
- Rotating tokens. Words containing a digit (dates, counters, “12 people viewing”, prices in a banner) and long hexadecimal strings (session ids, build hashes) are left out of the body comparison. A price that changes in the body text alone is therefore not a change; one that changes in the title is.
- Small body drift. A body edit too small to clear the threshold is the same version, seen again. Because every read is compared with the current version, several small edits that add up past the threshold are recorded as a change on the read that crosses it.
- Reordering. H1s, H2s and structured data types are compared as sets, so moving a subheading up the page is not a change.
- A better reader. When Attensira starts recording more about a page, the first read with the new reader is stored as a recapture. It is never treated as a change, and comparisons start from it.
Reverts
A change whose fields are the same as an earlier version’s, from the last 180 days, is a revert: the page went back. A page that returns to exactly the bytes it served before is matched to that earlier version too, so a revert is never lost. A revert is listed as its own page change. When it goes back on a change that is still being measured, that change’s outstanding re-reads are cancelled and the change is marked reverted, with the dates: “the change was reverted on the page between 2 Sep 2026 and 9 Sep 2026”. There is nothing left on the page to measure.When a change happened: the seen window
A read only tells us what the page says now. So a change is dated by two reads:- After: the last read that still saw the old version.
- By: the first read that saw the new one.
How a change is matched to a suggestion
A change is compared with the work items in this workspace that target the same page (its URL with or withoutwww or a trailing slash). Each suggestion names a field, such as the title or the meta description; a pull request may move any field, since the file it changes can render any part of the page.
A suggestion filed after the read that first saw the change cannot explain it: the page was already that way.
The strength of a match is shown with it, in three words: exact (our words, or our delivery, are on the page), close, and field (the field moved, to other words). Unattributed changes and reverts have none.
- Exact for a pull request or an article means the field’s new words, at least three of them, are in the file we wrote. A file is never on the page word for word.
- Timing. A suggestion filed inside the seen window may have come after the edit. Only an exact match is kept then, and the card adds: “We cannot tell whether this happened before or after our suggestion.”
- Declined suggestions still match. If you declined a suggestion and then made the change, it is still advice followed, and the card says when you declined it.
- Several matches. The strongest match wins, then a delivery of ours over advice, then the most recent suggestion. The others are kept as also matched.
- New pages. A page we had never read is filed only when it matches an article we drafted. A new page nothing explains is not a change.
- Advice that was never filed. A suggestion made only in a chat, never filed as a work item, cannot be matched.
The before and after
A change is measured on tracked prompts, picked in this order:- the matched suggestion’s own prompts;
- else the prompts of every suggestion that targets the page;
- else the prompts whose answers cited the page in the 28 days before the last read that still saw the old version, most cited first.
- Before: the 7 slot days ending the day before the last read that still saw the old version. The days of the seen window, when the change may or may not have been live, belong to neither side.
- After: the 7 slot days centred on the +N date.
One line for the page, decided once
Each re-read has its own verdict per prompt and engine, exactly as on Before and after. When the +30 re-read resolves, its answers are summed across every prompt and engine into one before and one after, the same significance test is run once on the sums, and the result is stored as the change’s pooled line. It is never recomputed when you look at it again.Sample-size floors
Below a floor the card shows the counts and no percentage: “Too early to say (n=108 before, n=112 after).”
The labels
Every change carries one of three labels:
Only moved gets the measurement sentence, and it puts the two rates side by side:
In the 7 days around 16 Sep 2026, this page’s 4 prompts were named in 31% of answers (n=112), against 12% (n=108) in the 7 days before it changed.
Why we never say “because”
A re-read shows that the numbers differ between two windows. It cannot rule out everything else that changed in the same weeks: a model update, a competitor’s new page, another edit on your site. So the change and the measurement are always two separate sentences, and no sentence about a page change uses “because”, “after we shipped”, “since we”, “thanks to”, “led to”, “drove”, “resulted in” or “as a result”. Every template is tested against that list. If two changes on one page fall in the same weeks, each is measured on its own, over the same answers. Neither can be separated from the other.Citations and AI-crawler fetches
The card also shows two descriptive counts. Neither carries a verdict.- Citations: how often answers to the change’s prompts cited the page in the re-read’s before and after windows, beside how many answers each window had.
- AI-crawler fetches: how often AI crawlers fetched the page in the days before the change and the same number of days since it was first seen (up to 7), with a split by provider since first seen. These need the AI traffic snippet. Without it the card says fetches are not counted. When the before window is older than the AI-traffic history held for your site, the before count is left out rather than shown as 0.
Where you see page changes
- Pages → Changes. Open a page in Pages and choose the Changes tab: every version we hold, when each change was first seen and what moved, reverts marked, and a field-by-field comparison of any two versions you pick.
- Work. One row per workspace, Page changes on your site, raised when a change is matched to something of ours and when a change’s pooled line is decided. Later events update the same row rather than adding rows. A change nobody suggested, or a revert, does not raise it when it is first seen. The evidence card also appears under the suggestion it matched.
- Mark shipped from the row. When our suggested words are on the page from a copy handoff nobody has marked shipped, the row offers Mark shipped, which opens the item where you confirm it. See Mark shipped.
- The morning brief. Up to three lines under “Changes we saw on your pages:”, moved first, for changes first seen or decided in the brief’s window (the day before; the week before on Monday). See Morning brief.
- Client reports. Up to ten changes matched to our work in the period, worded as the card words them. Unattributed changes stay on the card. See Client reports.
GET /v2/projects/{id}/pages/versions?url=, GET /v2/projects/{id}/pages/diff?url=&from=&to=, GET /v2/projects/{id}/page-changes (filters state = open, measured or reverted, attribution, cursor, limit up to 100) and GET /v2/projects/{id}/page-changes/{change_id}. These answer a signed-in session only; page changes are not on the REST API or the MCP server yet.
The agent’s page_changes tool
The agent has a free, read-only tool,page_changes, that compares two versions of one of your own pages field by field. With only url it compares the current version with the one it replaced; from and to take any two version ids from the list it returns, in either order. A field one version never read comes back as not_captured, with the reason, and the agent is told to say so rather than guess. The URL must be on your workspace’s own domain.
It sits in the agent’s Your own data tool group next to page_history, which lists a page’s versions one after another.