Most WordPress comment spam plugins work the same way: they intercept bot submissions, run a quick validation check, then silently block the junk. Clean dashboard, no moderation queue overflow, problem solved.
Except the logs don’t disappear. They accumulate in your database, often in custom tables the plugin created during activation. A site that publishes two posts a week might generate 40 rows of real comments per month—and 4,000 rows of blocked spam attempts that still get written to disk.
The performance cost sneaks up slowly. MySQL queries take an extra 100ms, then 200ms. Backups grow from 50MB to 800MB. Your host starts warning you about inode limits. And because the spam logs live in separate tables, you won’t notice them in your Posts or Comments admin screens.
What gets logged and where
Popular plugins like Akismet log every checked comment, whether it’s marked as spam, passed, or auto-deleted. That metadata includes IP address, user agent string, submitted content, referrer, and timestamp. Each log entry runs 1–3KB depending on comment length.
If your site receives 200 spam attempts per day—a conservative estimate for any public WordPress install older than six months—that’s 6,000 rows per month, or roughly 12MB of log data before indexing overhead.
Some plugins store logs in wp_commentmeta, which inflates core WordPress tables. Others create dedicated tables like wp_akismet_log or wp_antispam_data. A few write to flat files in /wp-content/uploads, which can break backup scripts that assume uploads only contain media.
The worst offenders don’t surface log size in their settings panels. You have to SSH in and run SELECT COUNT(*) queries or inspect table sizes via phpMyAdmin to know how much space the plugin has claimed.
When bloat starts breaking things
Database bloat doesn’t crash your site. It degrades it in ways that look like other problems.
Slow admin page loads get blamed on a bad theme. Backup timeouts get blamed on host resource limits. Jump-to-comment anchor links that take two seconds to resolve get blamed on browser caching.
The real bottleneck: MySQL has to scan larger indexes every time it touches the comments table, even if your query filters by post ID. If the spam log shares a table with legitimate comment metadata, every comment-related query pays the performance tax.
One operator I spoke with last month had 1.4 million rows in their Akismet log spanning four years. Their live site showed 800 published comments. The log table alone consumed 2.8GB—more than the rest of their WordPress database combined. Clearing it dropped full-page cache generation time from 11 seconds to under three.
Manual cleanup and plugin-level controls
Most comment spam plugins include a log retention setting buried two or three tabs deep. Akismet’s lives under Settings → Akismet Anti-Spam → Privacy. The default is often “Keep logs indefinitely” or a vague “Delete old entries automatically” that triggers annually.
Set retention to 30 or 60 days unless you’re actively investigating spam patterns or running forensic analysis. Logs older than eight weeks have near-zero diagnostic value—you’ve either already fixed the issue or decided to live with it.
For immediate cleanup, you can truncate plugin log tables directly via SQL. Example for Akismet:
TRUNCATE TABLE wp_akismet_log;
Back up your database first. Some plugins store legitimate config data in the same table as logs, though most separate the two. If you’re unsure, export the table schema and first 100 rows before running destructive queries.
After truncation, run OPTIMIZE TABLE wp_akismet_log; to reclaim disk space. MySQL marks deleted rows as free space but doesn’t shrink the table file until you explicitly optimise.
Better: switch to lightweight validation
If you’re not monetising comments and don’t rely on them for community interaction, turn off comments site-wide and uninstall the spam plugin entirely. You’ll shed the performance overhead and eliminate the log problem at the source.
If you need comments on select posts, use a JavaScript-based honeypot or time-delay check instead of a server-side plugin that logs every request. Tools like Cloudflare Turnstile or hCaptcha validate humans without writing to your database.
For high-traffic sites where moderation and spam filtering are non-negotiable, run your anti-spam checks in a separate microservice or worker process that doesn’t touch your WordPress database. Log to a dedicated logging service with automatic retention policies—Logtail, Papertrail, or even a self-hosted Loki instance—so old data expires without manual intervention.
What you should do this week: SSH into your WordPress install or open phpMyAdmin. Check table sizes for any plugin with “spam,” “akismet,” “antispam,” or “comment” in the name. If any table exceeds 100MB and you’re not actively debugging spam issues, truncate it and set retention to 30 days. Your backups will thank you.
Hit reply if you’ve found other plugins that hoard logs silently—we’ll cover the worst offenders in a future piece.