Author: onetwothreeadmin

If you’ve ever typed a keyword into the WordPress media library search bar and watched it return nothing—despite knowing you meticulously added alt text to that exact image three months ago—you’re not imagining things. WordPress media library search doesn’t index alt text by default. It only searches file names, titles, captions, and descriptions.

For solo operators managing a growing library of stock photos, screenshots, and custom graphics, this is more than an annoyance. It’s a workflow tax that compounds every time you need to reuse an image.

What the media library search actually indexes

Out of the box, WordPress media search queries four fields: the attachment post title (usually derived from the file name), the caption, the description, and the file name itself. Alt text lives in a separate post meta field (_wp_attachment_image_alt) and is deliberately excluded from the default search query.

This decision dates back to WordPress core architecture. Alt text was added later than the other fields, and backwards compatibility concerns kept it out of the search scope. The result: you can have 400 images with perfect alt text and zero ability to surface them by searching for the words you wrote.

If you’re running a content site where images get reused across posts—product screenshots, annotated charts, author headshots—this creates two problems. First, you waste time scrolling or re-uploading duplicates. Second, you’re less likely to maintain good alt text hygiene if the system doesn’t reward you for it.

Why this matters for accessibility and SEO

Alt text isn’t just for screen readers. It’s also the fallback when images fail to load, and it contributes to image SEO. If your workflow separates “alt text for accessibility” from “searchable metadata,” you’re maintaining two systems where one should suffice.

Many operators add keywords to the image title or caption purely to make search work, then duplicate the same text in alt text for compliance. That’s redundant labor. Worse, it encourages bad alt text—cramming keywords instead of describing the image meaningfully.

A better system would let you search by alt text and trust that the field serves both accessibility and discoverability. WordPress doesn’t do this natively, but you can fix it.

How to make alt text searchable

The cleanest solution is a small function added to your theme’s functions.php or a custom plugin. This snippet hooks into the media library query and includes alt text in the search scope:

function extend_media_search_alt_text( $where, $query ) {
  global $wpdb;
  if ( $query->is_search() && isset( $query->query_vars['post_type'] ) && $query->query_vars['post_type'] === 'attachment' ) {
    $search_term = $wpdb->esc_like( $query->query_vars['s'] );
    $where .= $wpdb->prepare( " OR ( $wpdb->postmeta.meta_key = '_wp_attachment_image_alt' AND $wpdb->postmeta.meta_value LIKE %s )", '%' . $search_term . '%' );
  }
  return $where;
}
add_filter( 'posts_where', 'extend_media_search_alt_text', 10, 2 );

This tells WordPress to join the postmeta table and include alt text when searching attachments. Once active, typing “pricing chart” into the media library will return any image with that phrase in the alt text—even if the file name is IMG_3487.png.

If you’re not comfortable editing PHP, a handful of plugins handle this. Search & Filter and Enhanced Media Library both extend media search, though they add other features you may not need. The function above is lighter and does one thing well.

When to use file names instead

There’s one case where skipping alt text search makes sense: if you’re using a digital asset management system or a headless CMS that treats WordPress as a media CDN. In those workflows, images often arrive with machine-generated alt text or none at all, and file naming conventions carry the metadata load.

But for most solo operators and small teams publishing directly in WordPress, alt text is where the human-readable description lives. Making it searchable closes the loop.

Once you’ve added the function, spend ten minutes backfilling alt text on your most-reused images—screenshots, logos, charts. The next time you need that “customer dashboard screenshot with annotations,” you’ll type six words instead of scrolling through 200 uploads.

Want more WordPress infrastructure fixes like this? Reply and tell us which core behavior wastes your time—we’ll cover it in a future issue.

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.