Email obfuscation: 792 of 1,061 home pages gave an AI crawler no address, and on 24 the address was in the bytes

Does email obfuscation hide your email address from AI crawlers?

Start with the vendor's own description, because the feature says plainly what it is for. Cloudflare's documentation for email address obfuscation, which carries a last updated date of 3 August 2026, states that with it on "email addresses on your web page will be hidden from bots, while keeping them visible to humans". It describes the mechanism in the same place: Cloudflare rewrites the address in the HTML, and "Cloudflare injects a small decode script (email-decode.min.js) into the page using the defer attribute". The page also states that "Cloudflare enables email address obfuscation automatically when you sign up", so this is not a box somebody has to go and tick.

What arrives on the wire is worth reading once, because it answers the question before any measurement does. On groundcover.com the footer contained a span with the class name __cf_email__, a data-cfemail attribute holding 44 hexadecimal characters, and, as its visible text, the words email protected inside square brackets. A client that runs the decode script replaces that text with the address. An AI crawler that runs no scripts extracts the words email protected and nothing else. 19 of the 1,061 pages carried that literal placeholder in their visible text, 36 times in total, which means the obfuscation is legible as an artefact: if a page shows the words email protected in square brackets where an address should be, you are looking at the crawler's view of it.

Whether any given AI crawler runs the script is not something this corpus can answer, and the honest position is on the record already: Lantad's measurement of what nine operators say about rendering JavaScript found two of nine willing to state it either way, and the corpus run on how much prose JavaScript actually supplies put the figure at 7.6 percent. What can be settled is what Lantad's own pipeline does, which is checkable rather than asserted. The extractor in core/src/facts.ts reads an email address from exactly three carriers: a mailto link in the markup, a schema.org email property inside JSON-LD, and a run of text in the prose that matches an address. An encoded hexadecimal attribute is none of those. Running the shipped extractFacts over all 27 obfuscated pages on 9 November 2026 returned zero email facts on 24 of them, and the three exceptions all had the address declared separately in their structured data.

What 1,061 home pages published for a crawler to read

The obfuscated pages are the sharp case, and they are 27 out of 1,061. The duller and much larger finding is that most of these home pages had no address to hide. 792 of the 1,061 yielded no email address through any carrier, and the three carriers are not interchangeable: 137 pages carried a mailto link, 122 declared a schema.org email property, and 38 had an address sitting in the prose. Only 47 pages carried more than one address at all. Across the whole set the extractor returned 344 email facts resolving to 342 distinct addresses, which is roughly one address for every three pages measured.

The carrier a page chooses decides who can read it, and the split is clean enough to be useful. 117 pages had a mailto link and nothing else, which a person can click and a machine can parse out of the href. 102 had the address only in a JSON-LD block, where schema.org's email property is defined with the one word description "Email address." and is listed on ContactPoint, Organization and Person, the last of which this blog measured in how many sites name a human at all. Those 102 pages are the mirror image of the obfuscated ones: the address is machine readable and never shown to a reader, which is a reasonable thing to do on purpose and is worth knowing you have done. 24 pages had the address only in prose, with no link and no markup around it, which is the carrier the last section of this post shows is the easiest of the three to fool.

Of the 342 distinct addresses, 181 had a role style local part, led by 56 at info, 29 at support, 22 at hello, 13 at sales and 12 at contact. 17 pages published a free mail address, mostly small local businesses: theheatbureau@gmail.com on heatbureau.com, westendrehab@hotmail.com on etobicokerehab.com, animalclinic408@gmail.com on iowacityanimalclinic.com. 60 pages carried an address whose domain is not the site's own, which covers group companies, outsourced support and, in a handful of cases, the agency that built the site. None of this moves an AI visibility grade by itself, because an email address is one fact among the price, phone, address, hours, FAQ and table rows the extractor weighs, and it is separate again from entity confidence, and the fuller picture of that is in the corpus run on which facts never reach the HTML a crawler receives.

The 27 pages that encoded the address instead

356 of the 1,061 pages arrived with a cf-ray response header, meaning they were served through Cloudflare, and all 27 of the obfuscated pages were among them. So this is 27 of 356, not 27 of the whole corpus, and the other 329 Cloudflare sites had the setting off or had no address on the page to rewrite. The 27 carried 89 encoded payloads between them, split across data-cfemail attributes on spans and hexadecimal fragments appended to a /cdn-cgi/l/email-protection href, and all 27 also referenced the decode script the documentation names.

The payloads are recoverable, and saying so is more honest than implying the address is gone. Lantad decoded each one by treating the first byte as a key and taking the exclusive or of every following byte against it, then tested the result against an address pattern. 26 of the 27 pages produced at least one syntactically valid address and 38 distinct addresses came out in total. nami.org carried eleven encoded hrefs that all decode to helpline@nami.org, sitting in a sentence that offers a phone number as a plain tel link and the email only as the word "email". standardbank.co.za carried nine payloads decoding to information@standardbank.co.za, complaint.resolutioncentre@standardbank.co.za and a whistleblowing line at tip-offs.com. diabetes.org gave askada@diabetes.org, psychiatry.org gave apa@psych.org, cshl.edu gave info@cshl.edu, maroc.ma gave contact@maroc.ma, nzz.ch gave leserbriefe@nzz.ch and seha.ae gave care@seha.ae.

Two of the decodes are more interesting than the addresses. uacvoice.org encoded two addresses, contact@uacvoice.org and contact@uaccstage.wpengine.com, the second naming a staging host that the obfuscation has carried into production unchanged. tobira.ai encoded three, hello@tobira.ai alongside anna@example.com and yourcompany@tobira.ai, so a template's placeholder addresses were obfuscated with the same care as the real one. The single page whose payload was not an address, swissre.com, is the clearest evidence of how mechanical the feature is: the href was a share button whose mailto carried no recipient at all, and the encoded string decodes to a query fragment beginning "?subject=Swiss%20Re%20Group". The rewrite does not know what it is encoding, which is exactly what you would expect of something enabled automatically at signup. This is the same class of problem this blog has measured in text that reaches the browser and not the extractor and in words sitting behind a hidden marker, and in text that ships in HTML comments and reaches no reader, with one difference worth stating: here the hiding is the advertised purpose.

The sites that spelled the address out by hand

Cloudflare's setting is the industrial version of a much older habit, and the corpus still carries the handmade kind. A conservative pattern looking for a local part followed by a bracketed or spaced "at" and then a bracketed or spaced "dot" matched five of the 1,061 pages, and three of those five were the site's own contact address written so that no pattern can lift it.

Lund University puts its switchboard number in a tel link and then its address as a span containing "lu", the text " [at] ", a nested span holding "lu", another holding " [dot] ", and "se", with the whole thing repeated in brackets afterwards as "lu[at]lu[dot]se". The Reserve Bank of India writes "Contact us on helpdoc[at]rbi[dot]org[dot]in" in its footer, beside a line giving the date the website was last updated. The Indian Council of Medical Research writes "Email: icmrhqds[at]sansad[dot]nic[dot]in" in a block that otherwise gives a full postal address and two phone numbers in plain text. In every one of the three cases the phone number and the street address went out unprotected and only the email was defended, which tells you what the people who did it were actually afraid of, and spam is a reasonable thing to be afraid of.

The other two matches are the reason this count is a floor rather than a census. maxbone.com matched on "aamirafridi(at)gmail(dot)com", which is the author credit inside the banner of a jQuery marquee plugin the page loads, and tum.de matched on "info(at)in2code(dot)de", which is a content management vendor's banner drawn in ASCII art. Neither is the site's contact address, and both show that a pattern search finds the construction rather than the intent. Handmade obfuscation also has far more forms than one pattern covers, from images of addresses through to character by character markup, so sites doing this are certainly undercounted. What all of it has in common is the thing worth taking away: the address never reaches a reader that does not reassemble it, which is the same position the contact details measurement found for telephone numbers that are clickable on the page and absent from the markup, and the same holds for opening hours a machine could read.

Which kinds of site publish an address at all

The corpus is stratified, which makes the next cut the most useful one in the measurement. Both seed files split their hostnames into named strata, ten by the platform a site is built on and eight by what the site is for, and the share of home pages carrying a readable address runs from 66.7 percent to 4.3 percent across them. 36 of 54 Wix and Squarespace pages carried one, 18 of 29 Framer pages and 26 of 42 Webflow pages. At the other end, 4 of 94 finance sites, 5 of 84 government sites, 2 of 31 documentation sites, 10 of 98 education sites and 11 of 94 healthcare sites did.

The ordering is almost the reverse of what an answer engine is likely to be asked. A question about how to reach a bank, a ministry, a university or a hospital is exactly the sort a person now puts to an assistant rather than to a search box, and those are the four strata least likely to have put a machine readable address on the page. The small business end of the corpus, where the site was built in a hosted builder and the whole purpose of the home page is to get someone to make contact, publishes the address without being asked. This is not a technology finding. All of these platforms can emit a mailto link and a JSON-LD block; the builders simply default to doing it because the people using them want to be contacted, and a large institution routes contact through a form, a portal or a help centre on another path.

That last point is the honest qualification on the 792, and it needs stating before the number travels. A government site with no address on its home page has almost certainly got one two clicks away, and routing enquiries through a form rather than an inbox is a defensible choice for an organisation handling volume. What the measurement says is narrower and still worth something: on the one page an answer engine is most likely to have fetched, there was nothing to read. The same pattern turned up in the corpus runs on whether a pricing page puts a price in the markup and on how few home pages carry a postal address, and the published study is where the corpus figures are kept.

What this means for a page you own

The practical part is short. If you are behind Cloudflare and you want an address to reach a client that runs no JavaScript, declare it in a place the obfuscation does not touch: a schema.org email property inside your JSON-LD survives, which is why the three obfuscated pages that still produced an address did so. The alternative is to turn the setting off, and the documentation linked above says where. Either way the choice is now an informed one rather than a default, which is the only thing this measurement really buys you. If you want to see the view directly rather than reason about it, what GPTBot sees returns the raw fetch for a URL and the AI crawler reference lists the tokens doing the fetching.

The second point cuts the other way, and it belongs in a post that argues from measurement. Obfuscation works. It was built to stop address harvesting, harvesting is a real cost, and nothing here says the sites running it made a mistake. The cost is simply not the one the setting was weighed against: it was switched on when scraping meant spam, and the client it now also blocks is the one deciding whether to name you in an answer. A site that routes contact through a form has made the same trade deliberately. A site that has had the box ticked since signup has not made a trade at all, and 24 pages in this corpus are in that position.

The third is a caution about the method, because the weakest number in this post is the 38. Reading addresses out of prose finds things that are not contact details. outseta.com yielded sales@yourcompany.com and customer@acme.com from a product screenshot rendered as live HTML, userloop.io yielded you@email.com from a styled mockup of a form field, blindpay.com yielded juanperez@gmail.com from an API code sample printed on the page, and matsusentinel.com and tucsonspotlight.org both yielded jamie@example.com, apparently from one shared newsletter template. That is six addresses on five pages that are not contact details, and an answer engine reading the same prose has no better way of telling them apart. If your home page shows a product mockup containing a fake address, that string is a candidate for your contact details as far as anything reading the text is concerned.

What this run did not do is the usual list, and it matters more than usual here. No AI crawler was observed: Lantad reads sites rather than server logs, so nothing in this post says whether OpenAI, Anthropic, Google or Perplexity run the decode script or what they do with an address once they have it, and the platform notes collect only what those vendors publish. Each page was fetched once, with redirects followed and no JavaScript executed, so an address a script would have written in is absent from the reading, which can undercount and cannot overcount. Only the home page of each host was read, so a contact page one click away is outside the measurement entirely, and that is the single biggest reason the 792 is not a claim that these organisations are unreachable. The corpus is a stratified sampling frame for crawlability rather than a census of the web, so the stratum shares show direction and not rates. The methodology page describes the pipeline, the crawler policy describes how these hostnames were asked, and prose parity is where the thing that actually decides most scores is defined.