I'm having a nightmare with spam registrations! Can't seem to stop them.

We have changed the Profile Trigger Word to something completely random, and use Freemember to register members.

We have added the following Extensions:

  • Accessible Captcha
  • Hon-ee Pot Captcha
  • VZ Bad Behavior

All work for me when I answer the wrong question, or enter the honeypot field.

I emailed one of the spammers email addresses (which are just random character emails at aol, gmail, and others), and got a bounce back saying it did not exist. I thought human spammers may at least use working emails.

Does anyone know why spam registrations can still happen?

Using EE 2.7.3


  • 1
    Add a new member field that will be filled in with the current URL of the registration page to make sure you know exactly where the registrations are happening. Hide it on the form <input type="hidden" value="{current_url}" name="reg_url">. Let us know what you get. May 26, 2014 at 17:11
  • Also, does your trigger word change or is it permanently some random word? May 26, 2014 at 17:22
  • Thats a good idea about the registration url, added it and will monitor. The member trigger word is fixed, we manually set it so do not go in and change it often. Its very random, not guessable. May 26, 2014 at 19:56
  • There's a way to make your trigger word random and change regularly without having to do it manually each time. If that's your issue, I'll show you in an answer below. May 26, 2014 at 20:00
  • Have you tried Snaptcha? May 26, 2014 at 21:09

6 Answers 6


Spam is an uphill battle, any solution made by man to stop it can be broken by man to abuse it.

The unfortunate truth is that traditional spam solutions are very short term and don't scale.

What I have noticed, though, is that on sites where similar things happen quite often the registrations stem from a couple of the same IPs and blocking them from the server cuts off the head (for the time being).

Take a look through some of the recent registrations and see if the IPs are shared. If they are add this to your .htaccess file

order allow,deny
deny from
deny from
deny from
allow from all

and those IPs will be unable to even access the site.

Furthermore, consider using a service such as http://www.cloudflare.com/ - you route your site via their service (there are free and paid plans) and you can benefit from CDN and optimisation plus anti-spam. Basically if they notice spammers on one Cloudflare powered site, they can be blocked across the entire network. Many large sites use it, and is a proactive and communal way to try to catch spammers out.

  • Thanks, but the IP addresses of the spammers are recorded in EE and are nearly always different. Occasionally there are ones the same, but very rare. So blocking them wont stop spam as new ones come from new IPs. May 26, 2014 at 19:57
  • How about the CloudFlare option? Give that a try and let us know if you see a decrease.
    – Mutual
    May 27, 2014 at 7:32
  • I am not sure yet... I just think the methods I used should stop automated spam, so ideally would like to look into getting those to work first. There's a big issue with EE somewhere if people can by pass all these registration checks! I dont want to use Cloudflare for all EE sites we have, but get to the bottom of the issue. I've used Cloudflare on another EE site before and it caused issues so stopped it. May 27, 2014 at 9:00

If you are not using the EE native member templates, then instead of making the trigger word a random word (might be difficult to guess, but can theoretically still be hit by spammers), you can simply add a hash in front of the trigger word so the URL can't be accessed, like:


of if you are using a custom config file, you can do it like this:

$config['profile_trigger'] = '#member';

  • This is good. This works, I cant access it. I presume because its treated as a hash and not a segment. So impossible to call the profile trigger word. I tried it with a blank trigger word in the config, and it worked too (cant save it as blank in admin). Also, you can save the hashed trigger word in admin, no need to put it in the config file. Although this wont stop the spam using Freemember of course. May 29, 2014 at 9:01
  • Yes, it basically treats the "member" trigger now as an old school element ID link on your homepage. From our experience spam registrations on EE sites are almost always through the native registration forms and not your freemember forms. The honeypot should stop most automated registrations there. Did you manage to figure out the current url for the spam registrations that the other user suggested?
    – telliks
    May 30, 2014 at 14:29
  • I havent had any spam registrations since changing the trigger word and also changing the template name from member/register to member/join-now. Dont know which was the solution! May 30, 2014 at 19:31
  • Okay, looks like the spam then came through the native EE registration and not via freemember. Glad you got it sorted.
    – telliks
    Jun 2, 2014 at 4:54

There is no fool proof way of preventing spam. Captcha solutions are obtrusive to the user experience and not very effective, which is why they are not recommended as the only line of defence. Eric Lamb has written a good article entitled "Avoiding CAPTCHA With ExpressionEngine" in which he also presents the solutions he recommends.

As the developer of Snaptcha, I can recommend it to anyone getting spam registrations, and in High Security Mode it is very effective against spambots. Keep in mind though that human spammers are a different breed altogether!!


Here's what I've done to completely stop spam members from registering on my default EE member registration forms while still allowing those forms to be used without needing any add-ons.

  1. Make sure spam members are actually using the EE forms by adding a new member field that will be filled in with the current URL of the registration page. Hide it on the form <input type="hidden" value="{current_url}" name="reg_url">

  2. In config.php (or config.master.php for Focus Lab's config) add this: $config['profile_trigger'] = date('YmW'); - This makes the "member" segment of the profile URL a numeric value based on the Year, month, and Week. It will output like this -- 20140623 -- making the member URL for the week /20140623/register or /20140623/profile and so on.

  3. To be able to link this in your templates, here's how to match the weekly URL segment: {current_time format='%Y%m%W'}. I usually put this in a snippet and just call the snippet in my template. Say my snippet is {sn_member_dir_link}, my template link will be <a href="/{sn_member_dir_link}/profile">My Profile</a>.

Setting the profile_trigger as the week's date is better than a random number if you need to access those templates on the front-end. If you don't need to use the native EE profile templates, just do this in your config.php: $config['profile_trigger'] = rand(0,time());

  • 1
    How does one come up with such ingenious ideas :) Jun 3, 2014 at 19:29

We've not had any spam registrations since:

  1. Changing the registration template from /members/register to /members/join-now (not a spam prevention technique but may help prevent bots accessing known URLs)

  2. Implementing jpunk11's solution of making the member profile trigger word inaccessible

I cannot say which was the solution as we did both the same time! My guess is they were using the native registration form even though we created a very random string for the trigger word. Stephen Callender's idea of storing the URL in the member profile would answer this.


Have you tried using the Blacklist/Whitelist Module? It's helped me a LOT in the past and I would highly recommend it! It comes with ExpressionEngine and is located under Modules. All you need to do is to make sure that your .htaccess file is writable by the server and you can set it up. That might also help!

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.