PageDigest v1 Release Candidate
A one-file change-detection protocol for public websites is ready for adopter feedback.
PageDigest v1 is now in release-candidate status.
The shortest version: PageDigest is a one-file change-detection protocol for public websites. A publisher serves a manifest at /.well-known/pagedigest.json; stateful consumers fetch that manifest, compare it with their cache, and skip page fetches for URLs that provably have not changed.
For a 10,000-page site that changes 20 pages in a week, a consumer can make one manifest request plus 20 page fetches instead of 10,000 per-URL checks.
That is the whole coordination move.
Why this exists
Publishers and crawlers are often arguing about the same waste from opposite sides.
The publisher sees the same automated clients fetching the same pages again and again. The crawler sees increasingly hostile bot defenses and still needs to know what changed. Both sides would prefer not to waste bandwidth. They just do not have a small, auditable coordination surface.
PageDigest is that surface:
{
"version": 1,
"generated": "2026-07-04T00:00:00Z",
"site_rev": 18294,
"entries": {
"/": { "rev": 47 },
"/blog/hello-world": {
"rev": 4,
"digest": "sha256:..."
}
}
}
site_rev is the fast path. If it did not move, the consumer can stop after one request. Per-URL rev values tell the consumer what changed when it did move. Optional digest values let consumers spot-audit publisher claims instead of taking the manifest on faith forever.
What ships in the RC
The v1 release candidate includes:
- a stable wire format with
site_rev, per-URLrev, optionaldigest, and optionalmodifiedfields - digest audit guidance for consumers that want to verify publisher claims
- optional
PageDigest-Staterequest headers so cooperative consumers can make manifest observations visible in ordinary publisher logs - reference publisher and consumer implementations
- distribution through GitHub Releases, Cargo,
npx, PyPI, and an Astro integration - production dogfood on pagedigest.org and a measured producer case study for dotrepo.org
Install paths:
npx pagedigest ./site-dist
cargo install pagedigest
python -m pip install pagedigest
npm install @pagedigest/astro
What would help before v1.0
The useful feedback now is practical adoption feedback.
I am especially interested in:
- publisher integration reports from static-site generators, custom build systems, CMS exports, and CDN or edge deployments
- consumer integration reports from crawlers, caches, monitors, archive systems, agents, and search/indexing pipelines
- real cases where URL keys, redirects, digest audits, deployment races, or partial coverage semantics are surprising
The project has a public v1 RC feedback issue. The canonical announcement lives on pagedigest.org, and the implementation lives in the pagedigest repository.
The main remaining v1.0 dependency outside the repo is registry review for the well-known URI and link relation requests. The v1 field semantics are expected to remain stable through final v1.0.
Related Project
The work this piece is connected to