Protect Email Address on Website from Spam: Plaintext Email Check

What is a plaintext email address on a web page?

A plaintext email address, or plain text email address, is one written as readable characters in the text of a page: a name, an at sign and a domain. This guide covers web pages, not plain text versus HTML email messages.

Addresses hide in the footer template, an author bio, the privacy policy, the title tag and code samples. There are three exposure levels:

• Visible text. The address is printed on the page, and our check fails it.
• Attribute only. The address sits in a mailto href, so our check passes it, though scrapers that read link targets still collect it.
• Not on the page. A contact form keeps the address on your server.

Retina image file names with a scale suffix after an at sign, and sample addresses on the domain reserved by RFC 2606, also look like addresses to the pattern, so this page describes both in words.

Why email harvesters scrape addresses from websites

Email address harvesting is automated. A spam bot or web scraper fetches pages, runs a pattern for a name, an at sign and a domain, and pulls the target out of every mailto link. Each hit joins a list that is reused for bulk mail and phishing. Once an address sits in a list it is very hard to remove, so the volume tends to grow.

Named staff on team pages attract phishing aimed at a person, not just bulk spam. Hiding an address cuts what simple scrapers collect, but not what a browser-like renderer sees, and role names such as info and sales get guessed anyway. Our check counts the same as every other line in the score, and it is usually the cheapest red mark to clear.

How SEO Site Checker tests for plaintext email addresses

Our crawler opens your URL in headless Chromium, waits for the load event (20 second limit) and reads the rendered DOM (Document Object Model) straight away. Text a script writes during load counts.

The pattern is far simpler than RFC 5322. Signed in users can open the list of matches, while other visitors see the count and a login prompt.

The exact rule: after the load event, the page text is searched with one email pattern, and any single match fails the line.

What counts as a hit

The count is per occurrence, so the same address in the header and the footer counts twice. Text nodes are joined without spaces, so a hit can carry letters from a neighboring word, such as Contact glued to the front.

What passes and what fails in our tests

We ran our actual check against about 28 test pages we built. These failed: visible text, a mailto link whose anchor text is the address, HTML entities, a script that writes the address during load, noscript copies, the title tag, and an address split by a span. A decode on load script modeled on Cloudflare failed in simulation, though not yet confirmed on a live site.

These passed: a mailto link with generic anchor text, an address only in an HTML attribute, name [at] domain [dot] com, click to reveal scripts, CSS tricks such as a data attribute value, JSON-LD only, and a script that adds the address on a timer after load. Timers up to 6 seconds all passed, since we read right after load.

Edge cases to know

• Capitals. An address in all capitals, or with a capitalized ending, usually escapes, because the pattern wants a lowercase ending. Capitals in the name still match, so mixed case alone is no protection.
• Scope. The check covers only the one URL you scan, so other pages, PDFs and images are never read.

Test my page free

How to see which email addresses your page exposes

1. Run the report. Run the free report, then expand the Plaintext Email list while signed in.
2. Search the page. Press Ctrl+F (Cmd+F on a Mac) for the at sign, then search the view source, which can differ.
3. Search Google. Look up each address in quotes to see whether it is already indexed.
4. Preview the fix. Paste your replacement into the Online HTML Viewer before it touches a live template, to see the link text, the form fields and the address after a click.
5. Check the templates. Footer partials, theme files and plugin output repeat sitewide, so one edit can clear many hits.

How to hide an email address on a website: five methods

To hide an email address from bots, pick from five methods, strongest first. Each says whether it clears our check and how much it slows scrapers, and Blocks 1 to 4 below hold the code. As a rule of thumb, pick a form first, add a generic mailto link only if people expect a click to open their mail app. The table below compares them.

Method 1: replace the address with a contact form

With no address on the page, the line passes and scrapers find nothing (Block 1). Validate every field on the server, add a honeypot field, and add a CAPTCHA such as reCAPTCHA only if abuse appears. Shopify and Wix ship a contact form built in.

Method 2: keep a mailto link with generic anchor text

The line goes green because the address sits in the href and not in the text (Block 2). Scrapers that read link targets still collect it, so use it only for an address you can afford to lose, such as a press alias.

Method 3: build the address in JavaScript when a visitor clicks

Store the parts in data attributes and join them on click, as in Block 3. This JavaScript email obfuscation passes and beats simple scrapers, but building the address at page load fails, and visitors without scripts need a form. Skip ROT13.

Method 4: write the address in words a human can decode

At and dot replacement, as in name [at] domain [dot] com, clears our check. Many harvesters know these patterns and people must retype it, so use it last.

Method 5: let your platform or CDN do it

The WordPress antispambot function turns an address into HTML entities, and the Cloudflare email address obfuscation docs describe a Scrape Shield setting that swaps addresses for encoded links. Both hide the address in the source, yet the browser decodes it into the text, so our check can still fail. A mailto link with generic anchor text should still pass behind Cloudflare, since the visible link text is unchanged, but run the report to confirm.

Cloudflare leaves the head, script, noscript, textarea and xmp elements alone, and email_off comment markers or a configuration rule switch it off for part of a page. Run the report again afterwards.

Email obfuscation examples you can copy

Every sample uses a placeholder or split parts, and the syntax follows mailto URI scheme RFC 6068.

Block 1 is a contact form. We hide the trap field by moving it off screen, not with type hidden or display none, because many bots skip inputs hidden that way. The aria-hidden wrapper keeps screen readers from announcing the trap field, and the server must validate and send the mail.

<style>.hp { position: absolute; left: -9999px; }</style>
<form method="post" action="/contact">
  <label for="reply_to">Your email</label>
  <input type="email" id="reply_to" name="reply_to" required>
  <label for="message">Message</label>
  <textarea id="message" name="message" required></textarea>
  <div class="hp" aria-hidden="true">
    <label for="website">Leave this empty</label>
    <input type="text" id="website" name="website" tabindex="-1" autocomplete="off">
  </div>
  <button type="submit">Send</button>
</form>

Block 2 keeps the address in the href with generic link text, which our check passes.

<a href="mailto:EMAIL_ADDRESS?subject=Website%20inquiry">Email our team</a>

Block 3 joins stored parts on click. The handler runs once, so the second click opens the mail app.

<a href="/contact" class="reveal" data-user="info" data-domain="example.com">Show email</a>
<script>
document.querySelector('.reveal').addEventListener('click', function (e) {
  e.preventDefault();
  var a = this.dataset.user + String.fromCharCode(64) + this.dataset.domain;
  this.href = 'mailto:' + a;
  this.textContent = a;
}, { once: true });
</script>

Block 4 is for WordPress themes, with antispambot() in the href only.

<?php $contact = get_option( 'admin_email' ); ?>
<a href="<?php echo esc_url( 'mailto:' . antispambot( $contact ) ); ?>">Email our team</a>

Printing the antispambot() result as link text would fail our check. If a script stores an address as Base64, the Base64 Encode Decode tool reveals it.

Which way of hiding an email address works best?

People who search how to protect email address on website from spam often confuse two questions, clearing the report line and stopping scrapers, so the table keeps them apart.

A form plus a mail filter beats any single trick, and passing our check is only the floor. To keep an address off spam lists, judge each method by what a scraper can still collect.

Where email as an image and CSS tricks fit

An address drawn as an image passes our check, but screen reader users get nothing, nobody can copy it, and the alt text must not hold the address. CSS email obfuscation, such as reversed text or content pulled from an attribute with attr(), also passes, because the DOM text is reversed or the address lives in a pseudo-element. Both break copy and paste and only fool scrapers that read text, not ones that run OCR on a screenshot.

Common mistakes when you protect an email address

A pass is not safe: a green line is not a security verdict, because the address can still sit in a mailto href, the page source, or JSON-LD as a schema.org email property on an Organization or ContactPoint. Inspect your markup with the Schema Markup Validator and the structured data guide.

Encoding with HTML entities does not turn the line green, because the browser decodes them before the text is read. A display none span hides nothing either, because hidden text is still text in the DOM.

robots.txt is not a shield: most harvesters ignore it. See the robots.txt guide.