Treat the warning as a reason to inspect autoloaded data, not an instruction to delete it. Identify each large option, test supported changes in staging and preserve a database restore path.
The WordPress Site Health message about autoloaded options is a prompt to investigate configuration data. It is not permission to delete the largest database rows. Those rows may contain active theme settings, plugin configuration or information needed to keep a website working.
A useful fix identifies the owner and purpose of the data, confirms whether it needs to load automatically, and tests a supported change with a restore path. Begin with read-only evidence. The aim is less unnecessary work while preserving behavior, not merely making a warning disappear.
What autoloaded options are
WordPress stores many configuration settings as options. Some are loaded together so code that uses them does not need a separate lookup for each setting. That can be efficient for frequently needed data, but it also means unnecessary or oversized entries can become part of routine application work.
The WordPress 6.6 Options API change note explains changes to how newly saved options receive autoload values, while older yes and no values remain supported. Therefore, an old tutorial that counts only rows marked yes may not describe your site’s complete autoloaded collection.
The current wp_autoload_values_to_autoload reference lists yes, on, auto-on and auto as the core defaults that trigger autoloading, subject to its filter. Check your installed version and effective behavior rather than assuming every row outside yes is excluded.
Read the warning as a threshold, not a speed test
The current Site Health test uses a default threshold of 800,000 bytes, which can be filtered. Its warning is triggered when the calculated size is not below that limit. The displayed number and the default threshold do not identify the faulty plugin or quantify how many milliseconds a page is losing.
Record the exact message, option count and reported size. Also record your WordPress version, whether persistent object caching is active, and the symptom that led you to investigate. Is wp-admin slow, is an uncached page slow, or did you simply notice the message? Those are different starting points.
Do not raise the threshold merely to obtain a green status. That changes the reporting rule without establishing that the underlying data is appropriate. Likewise, reducing data below the threshold does not prove that every performance problem has been solved.
Prepare a restore path before any adjustment
The inventory can remain read-only, but eventual changes to options are database changes. Before attempting them, have a current backup that includes the relevant database and verify how to restore it. A screenshot of a settings page cannot recreate every option or serialized value.
Use a staging copy with the relevant plugin and theme versions when possible. Keep external email, payment and integration actions disabled in staging so a test does not contact real customers or create live transactions. Record the original setting through its supported management interface and retain the backup separately from the proposed change.
For a busy site, also decide how production rollback would avoid overwriting legitimate new orders, messages or edits. Restoring a whole database is not a trivial undo button on an active business. Prefer a narrowly supported settings change whose original value can be restored, with the backup as the wider recovery option.
Build a read-only inventory without exposing option values
An administrator needs names, sizes and ownership before deciding anything. Do not export every option value into a shared spreadsheet or support thread: settings can contain credentials or private integration details. An inventory can be useful without disclosing that content.
The wp_load_alloptions function returns the runtime collection, with caching and filters involved. The following PHP example is a diagnostic for an already loaded WordPress environment controlled by an authorized administrator. Run it privately in staging through your established maintenance tooling; do not create a public endpoint for it.
$sizes = array();
foreach ( wp_load_alloptions() as $name => $value ) {
$sizes[ $name ] = strlen( (string) $value );
}
arsort( $sizes );
foreach ( array_slice( $sizes, 0, 25, true ) as $name => $bytes ) {
echo $name . "\t" . $bytes . "\n";
}This reads the loaded collection and reports names with byte lengths; it does not delete or update settings. It is not a complete performance profile. If a database inventory differs from the runtime view, examine caching, filters and measurement definitions rather than immediately modifying rows to make the totals match.
Identify who owns each large entry
For the largest contributors, record the option name, approximate size, likely component, whether that component is active and what evidence supports the identification. A familiar prefix is a clue, not proof. Several plugins may use similar names, and a removed plugin’s data can still be relevant to a planned migration or recovery.
Check the component’s documentation, settings interface, current release notes and, where appropriate, its source code. Ask its support team whether the data is intentionally autoloaded and whether a supported cleanup or update exists. Share the name and size first; avoid sending the private value unless a justified, secure support process requires it.
Classify entries as active configuration, regenerable cache, verified obsolete data or unresolved. Keep unresolved rows intact. Deleting them to discover what breaks reverses the order of diagnosis and can make the failure harder to repair.
Separate three possible remedies
Updating the owning component may be the right answer when a maintained release changes an unnecessary autoload default or handles old data properly. Test that release against the site’s normal journeys rather than treating its changelog as proof of your result.
Changing whether an existing option autoloads can preserve the value while altering when it is retrieved. Whether that is supported and beneficial depends on the code using it. A setting needed on nearly every request may simply require an extra lookup after the change; it is not automatically an optimization.
Removing verified obsolete data is a different operation. Use the component’s supported uninstall or cleanup process when available, and understand whether it also removes unrelated settings or content. Absence from the active plugin list alone is not sufficient evidence that every similarly named option is disposable.
Test one supported change at a time
Choose one identified contributor in staging. Record the original state, apply the supported change and repeat the inventory. Then test behavior, not just the total size.
- Load the homepage and a representative uncached article.
- Sign in and open the affected plugin’s settings.
- Save a harmless test setting and reload it to confirm persistence.
- Test any affected forms or integrations using non-production destinations.
- Check scheduled tasks or background processes related to the component.
- Review the relevant logs for new errors without exposing sensitive values.
- Restore the original state and confirm the rollback works.
Include both a cold and warm application path if your environment supports that comparison. A full-page cache can hide the underlying work from an anonymous page view, while wp-admin still exercises it. Do not globally flush production caches simply to obtain a number; plan the measurement in staging or an approved maintenance window.
Measure the relevant outcome consistently
Use the same page, environment and cache condition before and after. Retain several observations instead of claiming a speed improvement from one unusually fast request. Record the autoloaded byte change separately from response-time observations.
Consider a fictional site with one large, regenerable cache option and several essential theme settings. If a supported plugin update stops autoloading the cache while all journeys still pass, that is a useful change. If disabling theme settings saves similar bytes but causes extra queries or inconsistent display, the smaller total is not a better result. These are decision examples, not benchmarks.
If the warning remains after a justified improvement, inspect the next verified contributor. There is no reason to change every option in one session. If performance remains poor, broaden the diagnosis to the actual slow operation rather than assuming autoload is the only cause.
Keep maintenance from becoming repeated cleanup
Document what changed, the owning component and the evidence that it was safe. A plugin may recreate data, so recheck after its scheduled processes and next update. If the same unnecessary collection repeatedly grows, work on its cause instead of scheduling blind deletion.
Leave unresolved settings in place until their purpose is known. Keep backups and staging useful, and avoid database cleaners that encourage size-based removal without ownership evidence. A trustworthy fix preserves the website’s behavior, produces a repeatable improvement where measurable, and can be reversed without guessing what the deleted row contained.
Sources and verification
Editorial review 2026-10-14. Source check dates are recorded separately. Notes describe what each source supports and its limits.
View sources
- WordPress Options API: disabling autoload for large optionsChecked WordPress 6.6 changed how newly saved options can receive autoload values while preserving older yes/no values.
Limits: Historical change note; current runtime behavior should be checked against the installed version. - wp_autoload_values_to_autoload referenceChecked Current core defaults include yes, on, auto-on and auto as autoload-triggering values, subject to the documented filter.
Limits: Hardcoding only autoload=yes misses other current values; site filters can narrow the effective set. - Site Health autoloaded options testChecked The current core test uses a filterable 800000-byte default threshold and reports critical when the calculated size is not below it.
Limits: A warning threshold is not a measured page-speed penalty or an instruction to remove specific settings. - wp_load_alloptions referenceChecked WordPress loads and caches the runtime autoloaded-options collection; runtime filters and caching affect what is observed.
Limits: A runtime snapshot and raw database inventory answer related but different diagnostic questions.