Stopping WordPress Comment Spam

Why spam finds WordPress

Why spam finds WordPress so reliably: scale and default openness. WordPress powers a huge share of the web, and its comment system is enabled by default on posts — a standardised, findable target. Bots locate it by crawling for wp-comments-post.php and the comment form's field names, then submit at machine speed: templated praise, spun text, links in author names and bodies.

The economics: a vanishing success rate still pays when submission is free and automated. What spam wants is published links. What it costs you is moderation time, database bloat — tens of thousands of stored comments slow queries and backups — and, if moderation lapses, a site that looks abandoned. The fix is the layer stack below, not any single setting.

Layer 1: Akismet and comment settings

Layer one is Akismet plus strict comment settings — the foundation. Akismet screens every incoming comment against its cloud intelligence, auto-trashing obvious spam and holding questionable ones; personal blogs select the free name-your-price tier, commercial sites need a paid plan (verify current terms at akismet.com).

Under Settings > Discussion: require manual approval for every comment — or at minimum first-time commenters; hold comments with links for moderation. And turn off trackbacks and pingbacks, legacy notification channels most sites no longer benefit from. These settings convert spam from publishable to moderated, which changes its economics completely.

Layer 2: anti-spam plugins and honeypots

On anti-spam plugins (Antispam Bee), the honest summary is that defaults matter more than brand names — a well-set budget plan outranks a mis-tuned premium one. WebJi® documents its defaults openly and adjusts them per ticket when workloads need it.

Layer 3: manual approval and blacklists

How this plays out with comment settings (approval, registration): settings that look cosmetic usually decide page speed and uptime under real traffic. The defaults WebJi® ships are tuned for Indian network conditions, and support can review your setup on request.

Bulk-deleting spam

How this plays out with honeypot fields: settings that look cosmetic usually decide page speed and uptime under real traffic. The defaults WebJi® ships are tuned for Indian network conditions, and support can review your setup on request.

Disabling comments by page type or site-wide

Disabling comments is the legitimate nuclear option — and honest assessment comes first: do comments serve this site? Business brochure sites, service pages and product catalogs gain nothing from comments and pay spam's tax regardless.

Per-page: every post editor carries a Discussion panel (enable via Options if hidden) with 'Allow comments' unchecked — pages default to off, posts to on. Site-wide: Settings > Discussion unchecks 'Allow people to submit comments on new posts' for future posts; existing posts need a bulk quick-edit sweep. Middle paths: auto-close comments after 30 days, or require registration. 'Should we have comments?' is a content strategy question — spam management starts with it.

Do spam comments hurt SEO?

Published spam hurts: pages bristling with pharmaceutical links read as neglect to crawlers, user-trust metrics compound it, and Google's guidance for decades has been to moderate or disable unmanaged comments. Stored-but-unpublished spam does not directly harm rankings — search engines never see it — but the bloat tax is real: database size, backup weight, query overhead.

The link-economy footnote: comment links are nofollowed by default, so the SEO spammers chase is largely worthless — the harm is to you, not the gain to them. Bottom line: moderate what publishes, keep the library lean, disable where comments serve nothing — and put the recovered attention into content, the thing that actually ranks. If spam has become a security problem, WebJi®'s WordPress security service handles cleanup, and the full security checklist continues from there.