wp_options Table Cleanup
Export the database, then measure how much data WordPress autoloads from wp_options on every request. If it is large, delete only expired transients and settings left by plugins you have removed, one row at a time. Never delete siteurl, home, active_plugins, template, stylesheet, cron or the user-roles row.
For WordPress site owners and developers whose dashboard or pages slowed down as plugins came and went.
knowledge
- Read time
- 5 min
- Sections
- 5
- Updated
- 14 Nov 2026
- Written by
- WebJi® team
Last editorial update: 14 November 2026.
What does the wp_options table store?
wp_options holds one row per named setting — site URL, active plugins, theme, cron schedule, transients and every plugin’s settings — and WordPress loads all rows marked for autoload on every request. A bloated autoload set therefore slows every page, even pages that never use the plugin that created the rows.
| Value | Loaded on every request? |
|---|---|
yes (legacy), on, auto, auto-on | Yes |
no (legacy), off, auto-off | No — read only when code asks for that option |
The usual sources of bloat are expired transients (timed cache rows) and settings left behind by plugins you deleted. WordPress 6.6 and later also warn in Tools → Site Health when autoloaded options exceed about 800 KB, which is a quick way to see whether cleanup is worth doing at all.
Which wp_options rows must you never delete?
Never delete siteurl, home, active_plugins, template, stylesheet, cron or the user-roles row; removing them breaks the address, plugins, theme, schedules or admin access. Take a full database export before touching any row.
| option_name | Purpose | If deleted |
|---|---|---|
siteurl, home | The site’s addresses | Redirect loops or a broken site URL |
active_plugins | Which plugins are on | Every plugin switches off |
template, stylesheet | Active parent and child theme | Blank or default front end |
cron | Scheduled tasks | Scheduled posts and updates stop |
wp_user_roles | Roles and capabilities | Administrators lose access |
The roles row follows your table prefix: with a shop_ prefix it is shop_user_roles inside shop_options.
How do you measure autoload bloat in phpMyAdmin?
Open phpMyAdmin from cPanel, select the WordPress database and run two SELECT queries: one for the total autoloaded size and one listing the twenty largest rows. Replace wp_ with the prefix shown in the table list.
-- total size of autoloaded options
SELECT ROUND(SUM(LENGTH(option_value))/1024, 1) AS autoload_kb, COUNT(*) AS row_count
FROM wp_options
WHERE autoload IN ('yes','on','auto','auto-on');
-- the 20 heaviest autoloaded rows
SELECT option_name, autoload, ROUND(LENGTH(option_value)/1024, 1) AS kb
FROM wp_options
WHERE autoload IN ('yes','on','auto','auto-on')
ORDER BY LENGTH(option_value) DESC
LIMIT 20;If the total is well under 800 KB, cleanup will not noticeably speed the site; look at caching instead. The cPanel MySQL database guide shows how to open phpMyAdmin.
How do you delete expired transients safely?
Delete only transients whose timeout has passed, removing each value row together with its matching _transient_timeout_ row. WordPress rebuilds any transient it still needs on the next request.
-- 1. preview expired timeouts
SELECT option_name, FROM_UNIXTIME(option_value) AS expired_at
FROM wp_options
WHERE option_name LIKE '\_transient\_timeout\_%'
AND option_value < UNIX_TIMESTAMP()
LIMIT 50;
-- 2. delete each expired value row and its timeout row
DELETE a, b
FROM wp_options a
INNER JOIN wp_options b
ON b.option_name = CONCAT('_transient_timeout_', SUBSTRING(a.option_name, 12))
WHERE a.option_name LIKE '\_transient\_%'
AND a.option_name NOT LIKE '\_transient\_timeout\_%'
AND b.option_value < UNIX_TIMESTAMP();SUBSTRING(…, 12) strips the 11-character _transient_ prefix to find the key. For network transients, use _site_transient_, _site_transient_timeout_ and position 17. Rerun the size query and load the homepage afterwards. Never run a delete that matches every name containing “transient”.
How do you remove options left by deleted plugins?
Take one heavy option_name at a time, confirm it belongs to a plugin whose folder is gone from wp-content/plugins, then delete that single row and reload the site. Deleting several names in one statement makes a mistake impossible to trace.
- Export the database from phpMyAdmin → Export and confirm the file downloaded.
- Search the codebase for the name (for example with File Manager search or
grep -r "option_name_here" wp-content). - If no installed plugin or theme uses it, run
DELETE FROM wp_options WHERE option_name = 'exact_name' LIMIT 1; - Open the homepage and wp-admin. If either shows an error, import the export and stop.
Page builders and SEO plugins are common sources of large leftovers. Afterwards, clear the WordPress cache so cached pages reflect the change.
How do you clean wp_options with WP-CLI?
From the folder containing wp-config.php, wp transient delete --expired clears expired transients, and wp option list shows the autoload total and the largest rows. Confirm you are on the right site first with wp option get home.
wp db export before-options-cleanup.sql
wp option list --autoload=on --format=total_bytes
wp transient delete --expired
wp option list --autoload=on --fields=option_name,size_bytes | sort -n -k 2 | tail -20
wp option delete exact_option_nameOn multisite, each site has its own options table; select a site with --url=, and use wp transient delete --expired --network only for network transients.
When is wp_options not the reason your site is slow?
If autoloaded data is already small, the slowdown lies elsewhere: page caching, slow plugins, uncached database queries or the hosting plan’s CPU limits. Further deletes will not help.
After a large delete, phpMyAdmin may show “overhead” on the table; repairing and optimising the MySQL database reclaims it. A persistent object cache stops repeated option queries; see Redis object cache for WordPress. For a hands-off fix, WebJi® WordPress speed optimisation covers database, caching and plugin audits.
Frequently asked questions
Why is my wp_options table so large on disk?
Expired transients and leftover plugin settings are the usual cause. The file can stay large after rows are deleted until the table is optimised. Speed depends on the autoloaded total, not the file size, so check that figure before cleaning.
Can I just switch autoload off for a large option instead of deleting it?
Yes, if a plugin still uses the option but does not need it on every page. Set its autoload value to off and test the pages that plugin controls. If the plugin later re-saves the option with autoload on, the change will be undone.
Are database cleanup plugins safe?
Reputable ones are, if you use them with care. Choose one that shows rows before deleting, limit it to expired transients and clearly orphaned data, and decline any “delete all options” or “delete all transients” task. Keep a database export either way.
How often should I clean the wp_options table?
Check Site Health monthly and clean only when it flags autoloaded options or after removing large plugins. Sites with a working WP-Cron delete expired transients automatically, so frequent manual cleanup is rarely needed; if cron is unreliable, see replacing wp-cron with a real cron job.
Last editorial update: 15 November 2026.
Ready to get started with WebJi®?
Join 12,000+ businesses across India and overseas. INR pricing, 18% GST shown before payment and 24/7 email support in Hindi and English — average first reply under 60 minutes.