Your WordPress database index is missing—or bloated
The server hums in a data centre three time zones away, and somewhere in row forty-seven a disk spins through two million rows because nobody told it where to look. Your page takes four seconds to render, and the visitor is already gone.
Your WordPress database is scanning two million rows to find twelve posts
Missing indexes force MySQL to check every row in a table, turning fast queries into multi-second waits.
Every WordPress query—posts, comments, user meta—relies on indexes to locate data quickly. When an index is missing or fragmented, MySQL falls back to a full table scan: reading every row sequentially until it finds what it needs. On a site with fifty thousand comments or a hundred thousand postmeta rows, that scan costs you seconds per page load.
The problem compounds when plugins add custom post types or meta fields without building the indexes WordPress assumes exist. A query that should touch twelve rows touches two million. Hosting providers see the CPU spike, throttle your account, and send a vague email about “resource usage”. The real culprit is invisible unless you know how to check query execution plans.
Most operators discover index problems only after a traffic spike breaks their site. Query Monitor will show you slow queries, but it won’t tell you which table is missing the index or whether rebuilding a bloated one will help. You need to read the EXPLAIN output MySQL generates for every query—and most WordPress dashboards hide that data behind three layers of interface.
TACTIC
Cache plugins purge at different speeds—and timing matters
WP Rocket, W3 Total Cache, and LiteSpeed Cache all claim instant purge, but their clearing mechanisms work differently. WP Rocket flushes object cache and page cache simultaneously; W3 Total Cache queues purge actions and processes them on the next cron tick; LiteSpeed communicates directly with the server layer and skips PHP entirely. If you publish a correction or update a product price, the version your readers see depends on which plugin you installed and whether it finished purging before the next request arrived.
FROM THE ARCHIVE
Admin roles expose subscriber emails and unpublished drafts
WordPress Editor and Author roles grant access to more than published content. Editors can view the full subscriber export if you’re running a membership plugin, read every unpublished draft across the site, and adjust settings in most SEO and analytics plugins. Authors see fewer screens but still access custom post types and taxonomies that may contain pricing data, roadmap notes, or internal documentation. If you hand someone the Editor role to help with a launch, you’ve also handed them your subscriber list and every draft scheduled for next quarter.
WORTH READING
Mailchimp segments take ninety minutes to update after a rule change
Mailchimp’s segment filters don’t recalculate instantly. When you adjust a condition—change a tag, update a purchase threshold, or add a date range—the platform queues the re-evaluation and processes it in batches. Depending on list size and server load, the new audience count can take up to ninety minutes to appear. If you’re launching a time-sensitive campaign and relying on a segment you just edited, the send may go to yesterday’s audience—or fail silently because the count hasn’t refreshed yet.
Know someone who would like this? Forward today’s email — every operator we reach is one closer to running an online business with a little less friction.