The Contact Anchor Comes in Two Shapes: 51 of Our 74 Protection Links Carry a Hex Fragment and 23 Carry None
I work on OnePassApps, and this is our own site, so I measured it myself: plain HTTPS, signed out, no browser and no JavaScript, on 10 November 2026. I read the sitemap once and then fetched each of its 56 URLs once.
I work on OnePassApps, and this is our own site, so I measured it myself: plain HTTPS, signed out, no browser and no JavaScript, on 10 November 2026. I read the sitemap once and then fetched each of its 56 URLs once.
One hidden address, 74 anchors, two shapes
Across those 56 documents there are 74 anchors pointing at Cloudflare's email-protection rewrite, /cdn-cgi/l/email-protection. They are not all built the same way. 51 of the 74 carry a hex fragment in the href, and on those the __cf_email__ class and the data-cfemail attribute sit on a span inside the anchor. 23 of the 74 carry no fragment at all, and on those the same two things sit on the anchor element itself.
The 23 are exactly the guide fleet
The 23 anchors with no fragment live on 23 pages, and those 23 pages are exactly the guide fleet: the guides index and the 22 guide pages. The other 33 pages - the home page, /voting, /plans, /terms, the seven studios and the 22 app pages - hold the anchors that do carry a fragment. The two shapes split the same way the guide fleet and the app fleet have split in every other layer we have measured.
One address, several encodings
Decode the hex and it is the same address every time. Cloudflare's scheme is simple: the first byte is an XOR key and the rest of the string is the address XORed with it. Run that over every hex string in the fleet - the href fragments and the data-cfemail values alike - and all of them come back as the same one address. The guide anchors carry only the attribute, with no href fragment alongside it, so the address reaches the browser by one route on the guide fleet and by two on the rest of the site.
What a reader sees is the same in both shapes
All 74 anchors render the same visible text, in 1 distinct variant across the fleet. The difference between the two shapes is in the markup, not in what a visitor reads.
The structured data names the address in plain text
All 56 pages carry one JSON-LD block, 56 blocks across the fleet, and in all 56 of them a ContactPoint node names the address in plain text, with contactType customer support. So the address the markup hides is named in the clear in the structured data of every page.
An earlier post counted these anchors on an earlier build
An earlier post on this account covered the 74 anchors and the visible text. That was a different build - the hashed file names our pages preload have changed since - so I re-measured the same layer today rather than repeat a number that might have moved. The split of the 74 into two shapes is what today's build does.
What I did not test: one build, one day, plain HTTPS from one machine, signed out, and a reading of the HTML the server sent. Nothing here says what a browser does with either shape once the page loads, and I did not open any of these pages in a browser.
I work on OnePassApps, so this is our own site and our own pages, measured today. The apps are here:
The earlier post on this layer: https://dev.to/onepassapps/the-anchor-layer-of-apponepassappscom-1058-links-162-link-texts-and-one-footer-on-all-56-pages-8i6
Originally published by Dev.to WebDev. Aggregated on AIWithGhost for educational purposes — full credit and traffic to the original publisher.