Cloudflare hat sein Skript zur E-Mail-Verschleierung gefixt (vielleicht lag es an mir)

Was ist die E-Mail-Verschleierung von Cloudflare?

Cloudflares Email Address Obfuscation ist ein Scrape-Shield-Feature, das E-Mail-Adressen auf deinen Seiten vor E-Mail-Harvestern und Bots versteckt. Für menschliche Besucher bleiben sie normal sichtbar. Die Funktion ist in jeder Cloudflare-Zone standardmäßig aktiviert.

Zuletzt geprüft von Arjen Karel im April 2026

Update April 2026: Cloudflare hat das Problem behoben. Ein Product Manager bei Cloudflare hat mir auf LinkedIn geschrieben. Er hat diesen Artikel gelesen und das defer-Attribut zu email-decode.min.js hinzugefügt. Die offizielle Dokumentation von Cloudflare bestätigt es inzwischen: Das Skript blockiert das Rendering nicht mehr.

Defer ist ein Einzeiler. Dass das Attribut nicht von Anfang an da war, lag vermutlich daran: Cloudflare wollte sicherstellen, dass keine Websites kaputtgehen, die Adressen vor DOMContentLoaded decodiert erwarten. Jemand im Team hat sich die Arbeit gemacht. Das verdient Anerkennung.

Das Prinzip ist simpel. Der Edge-Proxy von Cloudflare scannt dein HTML nach allem, was wie eine E-Mail-Adresse aussieht. Er ersetzt jede Adresse durch einen XOR-codierten Hex-String und schleust ein kleines Skript namens email-decode.min.js ein, das die Adressen im Browser decodiert. Das Skript ist rund 1,2 KB groß, lädt inzwischen mit defer und entfernt sich nach der Ausführung selbst aus dem DOM.

Bis vor Kurzem lud dieses Skript weder mit async noch mit defer. Es blockierte das Rendering. Und das für ein Feature, das die meisten Besucher weder bemerken noch brauchen. Genau diesen Zustand hat dieser Artikel ursprünglich beschrieben – und genau deshalb hat Cloudflare nachgebessert.

.

Wie sich die E-Mail-Verschleierung von Cloudflare früher auf die Core Web Vitals auswirkte

.

Vor dem Defer-Fix wurde das Skript email-decode.min.js als render-blocking Ressource eingeschleust. Der Browser musste es herunterladen, parsen und ausführen, bevor er die Seite weiter rendern konnte. Das hatte drei Konsequenzen:

1. Es konkurrierte im kritischen Rendering-Zeitfenster um Netzwerk-Bandbreite und verzögerte den Largest Contentful Paint.
2. Es blockierte den Main Thread, was die Interaction to Next Paint in den Bereich „needs improvement“ schieben konnte.
3. Es löste bis zu fünf Lighthouse-Audit-Warnungen aus: eliminate render-blocking resources, avoid long main-thread tasks, reduce JavaScript execution time, avoid chaining critical requests und serve static assets with an efficient cache policy.

Dank defer lädt das Skript jetzt parallel zum HTML-Parsing herunter und läuft erst an, nachdem das Dokument geparst ist. Die Render-blocking-Warnung ist damit weg.

Was nach dem Fix bleibt

Der Main Thread muss nach wie vor 1,2 KB JavaScript parsen und ausführen. Auf dem Desktop ist das nichts. Auf einem Low-End-Android-Smartphone mit ausgelasteter CPU knabbert jeder kleine Main-Thread-Task an deinem INP-Budget. Wenn du ohnehin um die letzten 50 ms INP-Puffer kämpfst, ist dieses Skript ein weiterer Punkt in der Warteschlange.

Die größeren Probleme hat Cloudflare damit nicht behoben. Sie folgen weiter unten.

SEO-Nebenwirkungen

Cloudflare ersetzt E-Mail-Adressen durch Links, die auf /cdn-cgi/l/email-protection#[hex] verweisen. Für Crawler wie den Googlebot liefern diese URLs einen 404-Statuscode. Das Ergebnis: „Soft 404“-Fehler in der Google Search Console. SEO-Audit-Tools wie Ahrefs und Screaming Frog melden sie als defekte interne Links. Das erzeugt Rauschen, das echte Crawling-Probleme verdeckt. Nutzt du Cloudflare mit aktiver E-Mail-Verschleierung, prüfe deinen Indexierungsbericht in der Search Console auf diese Phantomfehler.

Ist die E-Mail-Verschleierung von Cloudflare überhaupt sicher?

Nicht wirklich. Cloudflare nutzt eine 1-Byte-XOR-Verschlüsselung, bei der der Schlüssel direkt im codierten String steckt. Jede von Cloudflare geschützte Website nutzt denselben Decodierungsmechanismus. Ein Spammer muss also nur einen einzigen Decoder schreiben, um die E-Mail-Adressen von all diesen Seiten abzugreifen.

Sicherheitsforscher haben gezeigt, dass sich die Codierung trivial umkehren lässt. Spencer Mortensens Verschleierungsstudie von 2026 testete 25 verschiedene Methoden mit Honeypot-E-Mail-Adressen gegen über 300 verschiedene Spammer. Selbst eine simple CSS-Methode mit display:none blockierte Harvester zu 100 %. Du brauchst kein mit defer geladenes JavaScript, um eine E-Mail-Adresse vor Bots zu verstecken.

Solltest du die Funktion trotzdem deaktivieren?

Wenn du keine E-Mail-Verschleierung brauchst – und die meisten Websites brauchen sie nicht –: Schalte sie ab. Das beseitigt die Soft-404-Crawling-Fehler und spart die letzten Millisekunden Arbeit auf dem Main Thread. So geht’s:

1. Melde dich im Cloudflare-Dashboard an.
2. Geh auf Security > Settings (oder Scrape Shield bei älteren Dashboard-Layouts).
3. Schalte Email Address Obfuscation auf OFF.

Das war’s schon. Das Skript verschwindet sofort. Die vollständige Konfiguration für maximale Performance findest du hier: die beste Cloudflare-Konfiguration zum Bestehen der Core Web Vitals.

Pro Seite mit Configuration Rules deaktivieren

Willst du die E-Mail-Verschleierung auf deiner Kontaktseite nutzen, aber nicht auf Landingpages mit viel Traffic, hilft eine Configuration Rule:

1. Geh auf Rules > Configuration Rules.
2. Erstelle eine neue Regel und gib ihr einen Namen (z. B. „Disable email obfuscation on landing pages“).
3. Lege die Filterkriterien fest (Hostname, URL-Pfad oder beides).
4. Füge die Einstellung Email Obfuscation hinzu und setze sie auf Off.
5. Klicke auf Deploy.

Du kannst einzelne E-Mail-Adressen in deinem HTML auch ausschließen, indem du sie mit Kommentaren umschließt: <!--email_off-->email@example.com<!--/email_off-->

Wenn du Verschleierung brauchst: Mach es selbst

Wenn du E-Mail-Adressen wirklich vor Bots verstecken willst, geht das deutlich besser – ganz ohne Skripte auszuliefern, bevor der Nutzer echtes Interesse zeigt. Der beste Ansatz: Häng einen IntersectionObserver ein und decodiere die E-Mail-Adresse just-in-time, sobald sie in den Viewport scrollt. Das ist dasselbe defer until needed-Muster, das ich für alles nutze – von YouTube-Embeds bis hin zu Google Maps.

Verschleierte E-Mail-Adresse erstellen

<a
 class="email-hidden"
 href="#"
 data-email="aW5mb0BleGFtcGxlLmNvbQ==">
 [email-hidden]
</a>

Häng den IntersectionObserver ein. Platziere diesen JavaScript-Code am Ende der Seite.

<script>
const emailtag = document.querySelector('.email-hidden');
let observer = new IntersectionObserver((entries) => {
  entries.map((entry) => {
    if (entry.isIntersecting) {
      let script = document.createElement('script');
      script.onload = function () {
        emaildecode(entry.target)
      };
      script.src = 'decode-email.js';
      document.head.appendChild(script);
    }
  });
}).observe(emailtag);
</script>

Lade das Skript decode-email.js hoch und ersetze die Decodierfunktion durch eine Library deiner Wahl.

const emaildecode = (e) => {
	let email = atob(e.dataset.email);
	e.href = 'mailto:'+email;
	e.innerHTML = email;
}

Ergebnis prüfen

<a href="mailto:info@example.com">info@example.com</a>

Die E-Mail-Adresse wird erst decodiert, wenn der Besucher sie in den Viewport scrollt. Null Einfluss auf den INP, keine Soft-404-Fehler für den Googlebot – und die Base64-Codierung ist nicht unsicherer als die XOR-Verschlüsselung von Cloudflare. Um die Verbesserung bei echten Besuchern zu messen, richte Real User Monitoring ein. Lighthouse-Scores sind gut fürs Debugging – aber Google nutzt Field Data von echten Nutzern für das Ranking.