Review Tools > Site Health and record the reported issue. Back up the database and measure a representative uncached request. The number of options is less informative than their combined size and what they contain. Do not assume every row in the options table is autoloaded.

1. Use an appropriate diagnostic tool or a reviewed WP-CLI options report to identify large autoloaded entries without publishing their values.
2. Map each candidate to the plugin, theme or custom code that owns it.
3. Check whether the owner is still installed, active or required by a pending integration.
4. Look for a supported cleanup or migration procedure from that developer.
5. Test the smallest justified change on staging and compare both performance and functionality.

Run this read-only query only after confirming the selected WordPress database and exact site options table. Replace wp_options if the prefix differs. On Multisite, choose the specific subsite table deliberately; a WP-CLI --url flag does not rewrite raw SQL table names.

SELECT option_name,
       LENGTH(option_value) AS value_bytes,
       autoload
FROM wp_options
WHERE autoload IN ('yes', 'on', 'auto-on', 'auto')
ORDER BY value_bytes DESC
LIMIT 20;

This uses the core default autoload values, which filters can narrow. It lists names and stored sizes without displaying the option contents. Identify each option’s owner and supported cleanup process; a large licence or payment setting is not automatically obsolete.

Expected result: The review finds the largest candidates without deleting data or exposing stored secrets. Any later supported change is tested on staging and compared with both application behaviour and the original performance warning.

No. Some settings are needed on most requests, and changing them indiscriminately can replace one efficient load with many individual database reads. Modern WordPress also uses more than the historical yes/no autoload values. Avoid copying old SQL recipes that assume a single representation or bypass WordPress cache invalidation.

Only after its purpose and consumers are understood and a recovery copy exists. An inactive plugin may still have valuable configuration that will be needed when reactivated. Prefer its documented uninstall or cleanup process, and retain evidence of any manual removal. Do not delete payment, licence or security settings solely because they are large.

Use supported WordPress APIs or a maintained tool for any approved autoload change so related caches remain consistent. Test administration, scheduled jobs and the feature that owned the setting. Recheck the measured request and Site Health after relevant caches refresh. If the data quickly grows again, address the plugin behaviour producing it instead of scheduling repeated blind deletion. Share option names and sizes with support as needed, while keeping stored secrets and customer data private.

• Identifying the active WordPress database and table prefix
• Measuring WordPress performance before changing settings
• Checking WordPress canonical URLs after migration
• Checking a WordPress backup before relying on it

• WordPress: Optimization
• WordPress: WP Set Option Autoload Values
• WordPress: List
• WordPress documentation

• WordPress autoload values
• WP-CLI SQL query scope