Stopping Spamblog Registration in WordPress MultiUser

Comment Spammers Burn In Hell...I’ve been running a copy of WordPress MultiUser for over a year now. Comment spam hasn’t been much of a problem, thanks to Akismet, but if I leave site registration open (so students and faculty can create new accounts and blogs), the evil spammers find it and start sending their bots en masse.

I tried a few plugins, with varying levels of success. There’s an interesting one that attempts to limit registrations to a specific country, but it falsely reported some valid users as not being in Canada. Captchas work, but also block some valid users (and the signup captcha plugin I’d been using is possibly abandoned).

So, I did some quick googling, and came across the page on the WordPress Codex about using .htaccess files to stop comment spam. I made some modifications to the technique, and am now running it on with apparent success. The apache logs show the bot attacks are still in full force, but not a single one has gotten through in order to register. And valid users have been able to get through. That’s pretty promising.

Here’s the technique – just drop a modified version of this into your .htaccess file for your WPMU server:

RewriteEngine On
RewriteCond %{REQUEST_URI} .wp-signup\.php*
RewriteCond %{HTTP_REFERER} !.** [OR]
RewriteCond %{HTTP_USER_AGENT} ^$
RewriteRule (.*) [R=301,L]

I put that block above the WPSuperCache block in my .htaccess file.

Modify the part that says “” to be whatever your WPMU server is (you may need to do more if you run multiple domains…), and modify the part to point to wherever you want to send suspected evil spammers. I send them here.

What it does is detect any POST requests (submitting a form) for wp-signup.php, that haven’t been sent from a web page on the WPMU site or have an empty user agent string (identifying the software making the request), and sends them to a page that apologizes for any false positives (and provides a contact to get around it for valid users that somehow got sent there) and scolds evil spammers for being evil spammers.

The beauty of it is that it doesn’t require anything from WordPress. No plugins. No mu-plugins. No hacking core files. Nothing. Apache steps in and kicks spammers out before they get in at all.

57 thoughts on “Stopping Spamblog Registration in WordPress MultiUser”

  1. Wouldn’t it be more fun to send them to a page that puts their bot into some kind of endless loop. I guess they would have that figured out too.Is the the file you are editing the Apache file or the WPMU .htaccess file?

    1. the endless loop would be interesting… Bad Behavior redirects people to so they show up in their server logs…

      this is the .htaccess file in the root of the wpmu install – but it could just as easily go into the apache config file if .htaccess editing isn’t possible.

  2. Thanks for this. It’s actually a decent solution. There is one thing you have to watch out for: Folks linking directly to your signup page from outside your site. We see folks give links as “You can sign up for a blog here” and then give the link directly to it. Since those are coming from outside the domain, that may cause issues. Maybe a workaround for that, and I haven’t looked at it, it to create some sort of landing page before hitting the form or embedding the signup form within a main blog page.

    1. good point – but this is a WPMU install for use on a university campus, and I just tell people to go to the front of the site and follow the link. I’m ok with the risk of borking direct links to the signup page – there shouldn’t be any in my case. Hopefully…

      1. Good catch, Donncha! Of course the POST request must have a referrer. There shouldn’t be much worry about valid requests being turfed, then. Spambots, begone!

        1. It really depends. I’ve seen tracking software that does some weird stuff with POSTS and GETS.

          One of my clients pointed out that instead of putting a domain in there as a referrer, it should be an IP address. If you use a domain, Apache has to do a lookup which takes time and increases load. If you’re using domain mapping, which you may not be on a college campus, it gets around that issue. I’m assuming that there would be a method of putting multiple IP addresses in there if you have a mu install spread out.

          Also a suggestion not to send the spammer to some site like That may get you in trouble legally as they may see you as the abuser.

  3. Just reporting back: It will be a week tomorrow since I tried D’Arcy’s technique. I run 4 Mu sites …. to date 3 sploggers have gotten thru …. I’m wondering if these are live humans – slave labor – locked in a cell, pounding away at a keyboard. I’ve seen one of the “names” before….

    1. yeah. I still get the occasional spammer getting through – but they’re having to do it manually, and FAR fewer are getting through as a result.

  4. Over the last few days I have seen some registrations that I figure had to be real humans manually spamming. I had a Jim Kirk and a John Caparulo (Fictional/Celeb names, but no trailing numbers) … and what I found interesting was each one had chosen a different theme for the blog … not the default theme … I almost hesitate to delete them.

    Almost. But then all the email domains seem to point back here:

  5. And if wpmu is on a subdomain I modify like RewriteCond %{HTTP_REFERER} !.** [OR] ?

  6. …put that block above the WPSuperCache block…

    Sounds great, thank you! One question: If not running SuperCache, where in .htaccess should this go? Before or after uploads? Does it matter? Thanks again.

  7. it shouldn’t matter much – just drop it directly above the SuperCache section, under everything else, and you should be fine.

  8. Hi, I just saw, that you implemented Buddypress. I was just wondering, if your technique works with BP, too? I am not a programmer, so can you please tell me if I still should use the RewriteCond %{REQUEST_URI} .wp-signup\.php*
    because I have deleted the signup.php and use only the buddypress register.php file.
    Thanks for your advise, experience!
    Sunny greetings from Switzerland,

    1. ah, yes! this would have to be modified to handle the Buddypress /register url – I’m not sure exactly what that would take, but it may be slightly more complicated because the exact filename of the register page is hidden behind a prettified URL (so a simple tweak to the .htaccess line to catch %{REQUEST_URI}.register* would catch all URLs across the site that end in “register” – there could be Pages on sites that do that…

      1. Ok, thanks. How do you do it on your BP-Site? Would that be bad, if it would catch all those register-pages?

        1. While I have managed to defeat spambot signups, unfortunately, I was getting so many of the live human spammers that I finally disabled self registration on all my Mu sites. Now if someone wants a blog, they must contact me. Which kind of muddles the purpose of creating a social network. Sigh.

          I have to admit, some of the human spammers were going above and beyond the call of duty. They picked out particular themes (instead the default) and added images to their spam blog posts. 🙂

          P S Here’s a link to a post on WPMUtotorials about adapting for BuddyPress.

  9. thanks for this tutorial. I wonder, though, if this hack can be applicable to a regular (not Mu) WordPress site? I’m planning for a project to be a regular WordPress with open registration.

  10. Hi and Thanks for the info! These spammers are a real pain in the arse! I tried just about every other fix that I was able to find….lo and behold the little bot blasters still get through. I just added your htaccess fix…..let’s see the little buggers get past this! Any type of bottleneck will be better then the current wide open no can stop them action I’m getting right now 🙂

    Will report back in a few days!

    Thanks again!

  11. Hmmmm….4 new signups in the last few hours. Maybe I have the code in the wrong place? Here is what my htaccess file looks like:


    AddType application/x-httpd-php5 .php
    RewriteEngine On
    RewriteBase /

    RewriteEngine On
    RewriteCond %{REQUEST_METHOD} POST
    RewriteCond %{REQUEST_URI} .wp-signup\.php*
    RewriteCond %{HTTP_REFERER} !.** [OR]
    RewriteCond %{HTTP_USER_AGENT} ^$
    RewriteRule (.*) [R=301,L]

    #uploaded files
    RewriteRule ^(.*/)?files/$ index.php [L]
    RewriteCond %{REQUEST_URI} !.*wp-content/plugins.*
    RewriteRule ^(.*/)?files/(.*) wp-content/blogs.php?file=$2 [L]

    # add a trailing slash to /wp-admin
    RewriteCond %{REQUEST_URI} ^.*/wp-admin$
    RewriteRule ^(.+)$ $1/ [R=301,L]

    RewriteCond %{REQUEST_FILENAME} -f [OR]
    RewriteCond %{REQUEST_FILENAME} -d
    RewriteRule . – [L]
    RewriteRule ^([_0-9a-zA-Z-]+/)?(wp-.*) $2 [L]
    RewriteRule ^([_0-9a-zA-Z-]+/)?(.*\.php)$ $2 [L]
    RewriteRule . index.php [L]

    SecFilterEngine Off
    SecFilterScanPOST Off


    Any suggestions?


    1. this won’t stop manual spamming by actual humans – you might be surprised at how many spammers employ farms of real people to bypass the automated defences, rather than writing better software.

  12. Thanks for this solution – we were getting upto 20 a day, I will let you know how we get on now it’s implemented 🙂

    Again, thanks a lot


  13. I was having this same problem on my WPMU and have disabled all registrations until they email me (same as Cheryl – above).

    I think one of the ways to minimise this is to have a double opt in registration, where they have to go to their email and activate their link. Is there such a plugin for this? Or is there a hack that can be used for WPMU?


    1. The anti-spammer in me has a need to point out what you describe Armand is called “confirmed opt in.” “Double opt in” was a term created by spammers in an attempt to download confirming email registrations as being wasteful and annoying to endusers.


      Confirmed opt in is I believe what WPMu operates with. Clicking on a link in an email to confirm the registration is required. Unless I missed an upgrade in there somewhere that removed this. (Hope not…)

    2. WPMU does have confirmed opt-in – you probably don’t want to add any more layers of email/confirmation to the process, as any friction makes people less likely to jump through hoops.

  14. I’ve added this to my htaccess file, will report soon to let people know if it has worked. I do get a lot of spam signups, I hope this will at least slow things.

  15. UPDATE: I’ve had this solution in place now for a few months, and it had been working great, until recently. In the past week or so we have been getting dozens of splog registrations daily. It’s hard to believe by humans… :-\

    Nearly all are from the fullname#### ilk. Can anyone suggest what might be added to these rules to ban signups for any username ending in a four-digit number? Is this even possible? I would be willing to do this on our site, and just add an explanation/disclaimer to our “if spam” redirect.

    Thanks again.

    1. Yeah. I’ve been getting a LOT of FullnameYYYY users creating accounts and blogs lately. They don’t seem to do much more than create the default site – I’m not sure if their l337 skript kiddy tools bork on something, or if they’re planning to come back and crap up the place later.

      1. Thanks for the reply, I was just wondering there’s any “easy” way to ban all usernames ending in #### … ?

        True, most just create the blog, But I have noticed some change the theme, and I did miss one that eventually posted. Our users keep asking what’s up with the stretchmarkcream blogs!

  16. Sorry to say, I disabled self-registration on all my sites. (Thanks for that, spammers 🙁 )

    I mostly use my sites to create my own blog/sites anyway.

    If anyone wants on board they will have to ask me, and if I know who they are, I’ll set them up as a user on the backend. It’s a labor intensive solution, but no more intensive then deleting spamblogs every day.

  17. For those disabling self registration – don’t, that’s just letting the spammers win!
    Splogs are a pain, but if you’re getting enough to really bother you, you might want to consider the ‘Moderate New Blogs’ plugin – – at least then real users can still sign up and get their blog, whilst you can get rid of the splogs before they’re ever viewed.

    Also worth renaming your wp-signup.php file and you might want to consider some smaller tweaks like removing the ‘powered by wordpress’ test in the footer of your theme. Little stuff, but every little helps

  18. Unfortunately, I have had to disable registrations on my site too and added a note that if they want to register they have to email instead, to the point that I’ve also neglected adding any updates on it.

    I might try that little nifty trick from Michael and might actually use the hack suggested in this article.

  19. I managed to fix my spam problem pretty easily. I checked the access logs and all the splogs were created with “curl” in the user-agent. This is easy to block in the htaccess:
    SetEnvIfNoCase User-Agent “^curl” blog_spammer
    order allow,deny
    deny from env=blog_spammer
    allow from all

    I’m sure I’ll have to modify this in the future when they work out a way around it, but for now I’ve gone from 20 or so splogs per day to zero.

    1. I’d been using a different rule to redirect curlers to a spank page, but just switched to use your simpler deny rule. Thanks for the nudge to update that.

  20. Thanks for the tip! I just implemented it on my BuddyPress site as per Cheryl Johnson’s modifications, hope this is a little more successful than the various CAPTCHAs, filters, hashcashes, etc. I’ve installed. Presently, I have something like 8 antispam plugins on my site and none of them do the trick…

    Also, on an unrelated note: Go Dinos! 🙂

    1. it’s certainly not bulletproof. actually, I’m not even sure if it works anymore. the bots seem to have adapted. I use reCaptcha as well, and am still getting up to a dozen splogs created per night. It’s definitely better than it was before, but some are still sneaking through. The only consolation is that they must be manually entered, so the sploggers are wasting their time, too. The funny part is, they always forget to change the blog/site privacy setting for their sites, so they all block Google from seeing their new sites anyway. Sigh…

  21. Pingback: Spam / Splog Wars

Comments are closed.