Every site we look at that has run a contact form for a couple of years hides the same thing in the admin: an entries table with thousands of rows, almost none worth keeping. Spam that slipped past the filter, test submissions from the day the form was built, quote requests from 2019 long since closed. Nobody clears them out because deleting a page at a time is miserable work, so the pile grows. Here is how to clear it properly, including the two mistakes (orphaned meta rows and abandoned uploads) that make a cleanup look successful while the database stays fat.<\/p>\n
Almost every form plugin that stores submissions keeps them forever by default. That is a sensible choice: silently deleting a customer’s data would be a far worse bug than storing too much. The effect is that “store submissions” is a switch you flip once and nothing ever removes anything after. No retention setting, no cap, no warning at ten thousand rows.<\/p>\n
Spam accelerates it, because most plugins flag a submission as spam rather than discarding it, so you can review false positives. And entries are wider than people expect: a ten field form typically stores one parent row plus one child row per value, so a single entry can be a dozen rows across two tables.<\/p>\n
Does that slow the site down? Usually not the front end. What it slows is the entries screen, exports, backups, and staging clones. It also quietly increases your exposure, because every old submission is personal data you still hold, which is why a compliance checklist<\/a> is worth a read before deciding what to keep.<\/p>\n We will say this once and move on. There is no undo. Form plugins generally do not put deleted entries in a trash the way WordPress does for posts. Some have a trash state, plenty do not, and those that do empty it on a schedule you did not set. Realise later that you removed six real leads along with the spam, and only a backup brings them back.<\/p>\n Take a full database backup, not a “the host does nightly snapshots” assumption. Restoring a nightly snapshot rolls back orders and comments and everything else since, which is why a targeted dump right before the cleanup is worth two minutes. Then export: a CSV of what you are about to remove costs almost nothing and turns a scary irreversible operation into a boring one. Our walkthrough on storing and exporting form entries<\/a> covers the formats and the multi-value gotchas.<\/p>\n Every major form plugin has a bulk action on the entries list: tick the header checkbox, choose Delete, apply. For a few hundred entries it is the right tool.<\/p>\n The limit catches people out because nothing announces it. That header checkbox selects the entries on the current page, not the ones matching your filter. If the screen shows 20 rows and you have 8,000 entries, you are about to delete 20. The usual workaround is Screen Options, where you raise the per page count, and that has its own ceiling: push it too high and the request times out partway through, so you do not know what got removed. A few hundred per pass is the honest limit on shared hosting. Some plugins offer a separate “delete all entries for this form” button, safer because it batches server side.<\/p>\n The habit that scales is to narrow the list first, then delete what is left.<\/p>\n Sometimes the admin screen will not get you there: 60,000 rows, no date filter, a site you need clean today. SQL through phpMyAdmin, Adminer or WP-CLI is legitimate here, and it is also where cleanups go wrong. Everything below is illustrative. Table and column names vary by plugin and version, and your prefix may not be Rule one: never start with DELETE. Start with a count, so you know the size of what you are destroying.<\/p>\n If the number looks right, sample the rows before committing. If it is wildly off, you picked the wrong date column, or it holds a Unix timestamp.<\/p>\n Rule two, the expensive one: entries typically live in a parent table plus a child meta table. Delete only the parent and the child rows stay behind forever, orphaned, pointing at an id that no longer exists. They never appear in any admin screen, so the cleanup looks like it worked while the database barely shrinks. Children first, then parents:<\/p>\n Rule three: some plugins store each entry as a custom post type instead, so the parent is a row in Rule four: chunk it. One DELETE touching 100,000 rows can lock the table long enough to take the site down. Add A manual purge is a one time event you will not repeat, and in eighteen months you will be reading this article again. The durable answer is deletion on a schedule, driven by a written retention rule.<\/p>\n The rule need not be elaborate. Spam deleted after 7 days, general enquiries after 12 months, anything tied to an order kept as long as finance requires. Write it as a sentence, put it in your privacy policy, then configure the site to enforce it. Writing it first is what makes the deletion defensible, and what a data subject request gets measured against. Our post on GDPR and WordPress forms<\/a> goes deeper on retention.<\/p>\nBack up first, and make it a database backup<\/h2>\n
Built-in bulk actions, and where they run out<\/h2>\n
Delete by filter, not by “select all”<\/h3>\n
\n
The direct SQL route<\/h2>\n
wp_<\/code>. Confirm the real names and timestamp column first, and do not copy these queries blind.<\/p>\nSELECT COUNT(*) FROM wp_yourplugin_entries\nWHERE created_at < DATE_SUB(NOW(), INTERVAL 24 MONTH);<\/code><\/pre>\n-- 1. children, matched through the parent\nDELETE m FROM wp_yourplugin_entry_meta m\nINNER JOIN wp_yourplugin_entries e ON e.id = m.entry_id\nWHERE e.created_at < DATE_SUB(NOW(), INTERVAL 24 MONTH);\n\n-- 2. then the parents\nDELETE FROM wp_yourplugin_entries\nWHERE created_at < DATE_SUB(NOW(), INTERVAL 24 MONTH);<\/code><\/pre>\nwp_posts<\/code> and the values are rows in wp_postmeta<\/code>. Deleting from wp_posts<\/code> by hand leaves orphaned wp_postmeta<\/code> rows, and on a busy form that is where the real bloat lives. Prefer wp post delete --force<\/code> via WP-CLI there, which cleans the meta up for you.<\/p>\nLIMIT 1000<\/code>, repeat until zero rows are affected, then OPTIMIZE TABLE to reclaim the disk space.<\/p>\nThe real fix is scheduled deletion<\/h2>\n