How To Protect Email Addresses On Your WordPress Site

It may be old and and it’s definitely uncool but email is still a significant communication channel and that means it still garners the attention of the spammers.

The first step in email anti-spam is not to handover the email address but often there’s a requirement, especially for organizations, to publish an email address on their WordPress site.

In this Weekend WordPress Project, we’ll look at how to make the scraping of email addresses from your site as difficult as possible.

Email encoding is quick, easy and effective
Email encoding is quick, easy and effective

Before we start, it’s important to appreciate that there is no failsafe method of protecting an email address or indeed any content. What we are trying to do here is raise the degree of difficulty just enough to foil the majority of bots.

The other key consideration is that the horse has probably already bolted for any email addresses that have been on your site for any length of time. That said, adding the protecting to your website will not do any harm.

So, how do you deter the majority of bots?

The bots work by scanning the source code of your site, looking for email addresses and following links to other pages. Email addresses are fairly easy to pick out due to their formatting and their use of the “mailto” URL scheme.

There are various techniques for making harvesting of these links difficult but the most successful and the most usability-friendly approach is to encode the email address.

Whilst browsers will decode the address and it will display and behave exactly as normal, most bots don’t decode nor do search for an encoded @ – they don’t have to as there are enough websites that publish email addresses in plain text.

Installing The Email Address Encoder Plugin

Email Address Encoder promo image
Simple email address obfuscation that won’t impact on usability

All that’s required to encode the email addresses is to install the Email Address Encoder plugin, one of the best documented plugins, incidentally, in the WordPress plugin repository.

The plugin uses a variety of filters to encode email addresses on the fly as WordPress puts a page together including those found in posts, pages, widgets, comments and excerpts.

So, for example, whilst the browser shows this:

Screenshot of two email address that appear normal despite being encoded
For humans, everything looks like normal

What the bot sees is very different:

Notice also how the email address in the content itself has also been encoded.

This technique won’t guarantee that email addresses on your site won’t get scraped but it will certainly prevent most of the scraper bots from plying their trade whilst maintaining usability.

Well worth the five minutes to install the plugin.

Comments (13)

  1. Chris,

    Thanks for writing this article, which is exactly what I needed today. For several days I’ve been fretting about finding the best plugin for hiding e-mails on a new web site I’m working on, and now I can feel confident that I’ve found it.

    So are so many different methods out there, and I just wasn’t sure which one might really do the job and not be difficult to work with…and your article has given the answer.

    • Dan, many of the techniques mentioned in that article, including the top-rated writing the email backwards, have serious issues when it comes to accessibility.

      They also are much more difficult to implement automatically.

      So, whilst I take your point that encoding is not the most effective method, it is a quick and easy solution that can be applied automatically (and therefore retrospectively), maintains accessibility and is considerably better than displaying emails in plain text.

  2. Yes, they are awful for accessibility but stop the spammers. You have to pick one or the other. I’ve only found them hard to implement automatically when I have to account for email addresses appearing in forms, which is another problem. There really is no silver bullet solution other than not putting email addresses in web pages.

      • I have seen a great deal of sites that only have contact forms. It seems to be the way to go for a lot of home based businesses. However, I know for myself, I don’t tend to feel a sense of trust toward businesses that don’t publish their contact details (including email). It just seems dodgy. Logically, especially because I am in the industry, I KNOW why they do it, but psychologically, I can’t deny the feelings/thoughts it creates as a result. And if they come up in me, someone who understands the reason behind it, oh, they’re coming up in spades with people that do NOT understand the reason behind the lack of contact details. ;)

        From a marketing perspective, trust is the number one goal in our websites. Increased trust with your audience will result in increased sales. So, for me, from my marketing brain, even though there is a technical reason for leaving out the emails, it’s no good if doing so will sabotage the whole point of our sites. :)

      • interesting, when i had set it up in the past, I couldn’t find that, but now as I’m reading the wp.org page on it, I see that… hmmmm… lol Thanks, I guess I need to dig in more with the settings.

      • ah, ok, I just went in there, and I realise that I knew that it can do that, but I chose not to, because: “Notice: be carefull with this option when using email addresses on form fields, please check the FAQ for more info.”

        I didn’t want to have to designate certain page ids, etc. Too much hassle for a pro-bono site (for my sons’ school’s PAC). BUT, when I read the FAQ, there is a shortcode to do it. But, to be honest, it’s just easier for me to put everything into a mailto: link. ;)

        • Forms are the Achilles’ heel of EEB. After thinking about this again here, I made a similar comment (within a superlative review) on its page in the plugin directory, suggesting that an easy fix would be to skip forms automatically or just let the user designate pages for the plugin to skip. The developer replied and said he has this issue high on his list for a future release, but it may be a few weeks off since he’s refactoring the whole thing right now.

Participate