We wanted a deploy check that was worth something. The one we had asked whether the site returned 200, which is a green light that does not illuminate the thing you changed: a deploy that never reached the edge and an edge serving a stale copy both answer 200 cheerfully. So we tried the obvious stronger test — fetch the page through the public internet, compare it byte-for-byte to the file on disk.
Every page "diverged".
That is the interesting part, because it was not a bug and it was not noise. The edge is rewriting the bytes, and it is doing it in a small, closed, fully enumerable set of ways. If you serve anything to a machine reader — docs, OpenAPI specs, llms.txt, agent instructions — this is worth knowing precisely, because one of those rewrites makes your text unreadable to exactly the clients you are writing it for.
We diffed served body against on-disk file across a spread of pages — HTML, plain text, XML, JSON. Four transformations, no others:
window.__CF$cv$params before </body>, and a module tag for the site's own .webmcp/bridge.js in the head. These are constant: +583 bytes, every page, every time. An 80,209-byte file serves as 80,792. A 12,584-byte file serves as 13,167.Non-HTML is untouched. robots.txt, sitemap.xml, an extensionless .well-known JSON document: byte-identical, zero injection. The rewriting is specific to HTML, which makes sense — it is aimed at browsers.
A bare address in your HTML — anywhere, in prose or inside a <code> block — comes out the other side as this:
<a href="/cdn-cgi/l/email-protection" class="__cf_email__"
data-cfemail="89f9fbe0ffe8eaf0c9e4e0e7e0e8bbe8a7fce2">[email protected]</a>A browser runs the injected decode script and renders the real address. Everything else sees the literal string [email protected].
So if your documentation tells an agent to contact you at an address, the agent does not receive that address. It receives a placeholder that looks like a redaction. The page renders perfectly in every browser you will test it in, which is why this survives review — the readers who are broken are the ones who do not run JavaScript.
There is a second shape, for a link rather than prose. A mailto: anchor is rewritten into a protection link wrapping a span:
<a href="/cdn-cgi/l/email-protection#f8888a918e999b81..."><span
class="__cf_email__" data-cfemail="3d4d4f544b5c5e44...">[email protected]</span></a>Two shapes, and if you only notice one you will misread a page. We know because we only noticed one at first, and the page carrying both shapes reported as a 241-byte unexplained divergence — a false alarm we then spent time chasing. The mailto: form has to be matched first, since it is the more specific pattern; a rule written for the bare form stops at the inner </span> and leaves the outer tag mangled.
The obfuscated payload is not a hash. It is XOR: the first byte of data-cfemail is a key, and every following byte is the plaintext XORed with it. Six lines will undo it:
def decode_cf_email(hexstr):
raw = bytes.fromhex(hexstr)
key = raw[0]
return "".join(chr(b ^ key) for b in raw[1:])
# "89f9fbe0ffe8eaf0c9e4e0e7e0e8bbe8a7fce2" -> "[email protected]"This matters more than it looks. The tempting move is to strip the obfuscated anchor and compare what is left. Do not. Stripping deletes content that still exists on disk — the real address — so the remainder can never match, and you have built a check that fails forever for a reason you have already decided to ignore. Decoding restores the text you actually wrote, which means the comparison stays exact and the decoder itself stays falsifiable: if the decoding is wrong, the address will not equal the one in the file, and the check goes red. A transform you merely tolerate is a blind spot. A transform you invert is still a test.
With the four rewrites undone, served and on-disk content match byte-for-byte — 11 of 11 pages, including the email-bearing one. That gives a deploy check that can actually fail. It catches a deploy that never reached the edge, and it catches an edge holding a stale copy, neither of which a status code can see.
Two design notes, both learned the hard way:
== operator works; it proves nothing about the pipeline. Ours runs one control end-to-end — real fetch, real remote read, real normalization — against a deliberately mismatched real pair, and a second against external truth: a decoded address that has to appear in the published file. Without that pair, a predicate that answers "no" to everything passes every negative control you own.curl, no JavaScript. Grep for __cf_email__ and /cdn-cgi/. If either appears, a machine reader is getting placeholders.The general lesson is not about any one CDN. It is that the artifact you authored and the artifact your reader receives are two different things, and the gap between them is invisible to every check that stops at the transport layer. If your product is read by machines, that gap is your product.