Manual:Combating spam

Wikis are a common target for spammers wishing to promote products or web sites due to their open editing nature. MediaWiki offers a number of features designed to help block Wiki Spam

rel="nofollow"
Under the default configuration, MediaWiki adds rel="nofollow" to external links in wiki pages, to indicate that these are user-supplied, might contain spam, and should therefore not be used to influence page ranking algorithms. Popular search engines such as Google honour this attribute.

You can switch off this behaviour on a site-wide basis using the $wgNoFollowLinks configuration variable, e.g.



You can also configure a list of namespaces for which the rel="nofollow" attribute will not be set, using the $wgNoFollowNsExceptions configuration variable, e.g.



will switch this off for the main namespace.

Use of the rel="nofollow" attribute alone will not stop spammers attempting to add marketing to a page, but it will prevent them from benefiting through increased page ranks.

Spam blacklist
A popular extension for MediaWiki is the spam blacklist, which blocks edits that add blacklisted URLs to pages. The default blacklist used is the Wikimedia spam blacklist, and local blacklists (and whitelists) are also available.


 * Spam Blacklist extension
 * README

Captcha
One of the more common methods of weeding out automated submissions is to use a CAPTCHA. The ConfirmEdit extension for MediaWiki provides an extensible captcha framework which can be triggered on a number of events, including


 * all edits
 * edits adding new, unrecognized external links
 * user registration

The extension ships with a default test, but this is a reference implementation, and is not intended for production use. Wiki operators installing ConfirmEdit on a public wiki are advised to either Instructions on how to do this are supplied with the extension.
 * use the FancyCaptcha plugin, and generate a set of decent captcha images using the supplied Python script, or
 * use the ReCAPTCHA plugin.

It is important to note that captchas can block more than undesirable bots; if a script is unable to pass a captcha, then so is a screen reader, or other software or aid used by the blind or visually impaired. You should therefore consider the implications of such a barrier, and provide an alternative means for affected users to create accounts and contribute.


 * ConfirmEdit overview
 * ConfirmEdit extension
 * Extension:ReCAPTCHA

Edit filtering
MediaWiki provides a means to filter the text of edits in order to block undesirable additions, through the $wgSpamRegex configuration variable. You can use this to block additional snippets of text or markup associated with common spam attacks. For example:



will block edits which attempt to add hidden or overflowing elements, which is a common "trick" used in a lot of mass-edit attacks to attempt to hide the spam from viewers.

Restrict editing
In some cases, it is sufficient (and appropriate) to restrict editing pages to those users who have created an account. This restriction will halt a number of automated attacks. This approach can be coupled with, for example, requiring a captcha during account registration, as described above, or blocking usernames matching a certain regular expression using the Username Blacklist extension.


 * "Preventing access" overview
 * $wgGroupPermissions configuration

See also Anti-spam Features