WordPress 6.7 fixed (some of) the autoload problem.

The Options API in WordPress underwent a meaningful architectural shift across the 6.6 (July 2024) and 6.7 (November 2024) releases. Core now actively manages the autoload column instead of trusting plugins to do the right thing: new autoload values, a default size threshold, explicit declarations across every core option. For sites carrying years of accumulated wp_options bloat, this is the most consequential core-level fix in recent memory. It's also incomplete. The 2023 audit queries will silently miss half the modern autoload picture, and the cleanup work the original advice prescribed is still the work.

The Options API in WordPress underwent a meaningful architectural shift across the 6.6 (July 2024) and 6.7 (November 2024) releases. Core now actively manages the autoload column instead of trusting plugins to do the right thing — new autoload values, a default size threshold, explicit declarations across every core option. For sites carrying years of accumulated wp_options bloat, the problem described in autoloaded options: the silent WordPress performance killer, this is the most consequential core-level fix in recent memory. It’s also incomplete. The audit queries from 2023 will silently miss half the modern autoload picture. Here’s what’s different now, and what hasn’t changed.

What 6.6 and 6.7 actually changed.

Three things landed in core that matter:

1. New autoload values. The column historically took two values, 'yes' and 'no'. As of 6.6, the column also accepts 'on', 'off', 'auto', 'auto-on', and 'auto-off'. The new values let WordPress (and plugins) express intent more clearly:

• 'on' — explicitly requested to autoload
• 'off' — explicitly requested not to autoload
• 'auto' — defer to WordPress’s default heuristic (currently autoloads; behavior may change)
• 'auto-on' — heuristic decided yes, autoload
• 'auto-off' — heuristic decided no, don’t autoload

The old 'yes' and 'no' values are preserved for backward compatibility and treated equivalently to 'on' and 'off'. No data migration is being run, which means a real-world wp_options table now contains a mix of old and new values depending on when each option was first written and whether the plugin that wrote it has been updated.

2. A size threshold with a default. WordPress 6.6 added a filter, wp_max_autoloaded_option_size, with a default of 150 KB. Any newly-added option larger than that threshold is automatically set to not autoload — regardless of what the plugin asked for. The intent is to prevent the exact failure mode responsible for most autoload bloat: a plugin caches a large API response or accumulating debug log into a single option, autoloads it because that’s the default, and then ships it on every request from then on.

This is the biggest single change. Plugins that would have produced a multi-megabyte autoloaded option in 2023 now have that option silently quarantined by core in 2025. The architectural failure mode is partially closed.

3. Explicit declarations across all of core. WordPress 6.7 went through core’s own options and made every single one explicitly state its autoload preference instead of relying on defaults. Some options that had previously autoloaded “by accident” no longer do. The total autoload payload from a clean WordPress install is meaningfully smaller post-6.7 than pre-6.6.

What this means for the audit queries.

The SQL queries that worked in 2023 are now incomplete. WHERE autoload = 'yes' on a 2025 wp_options table will silently miss every option stored with the new values — which includes anything WordPress core or a 6.6-aware plugin has written in the last two years. The table will look artificially healthy because half the autoloaded data is invisible to the query.

The correct audit query for modern WordPress:

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

The corresponding total-size query:

SELECT
    ROUND(SUM(LENGTH(option_value))/1024/1024, 2) AS autoload_mb
FROM wp_options
WHERE autoload IN ('yes', 'on', 'auto', 'auto-on');

This matches the values WordPress core itself considers autoload-triggering via the new wp_autoload_values_to_autoload() helper introduced in 6.6. If a future WordPress version adds more values, the canonical way to stay current is to call that function from PHP rather than hard-coding the IN list.

What’s still your problem.

Core’s changes mitigate the future but don’t clean up the past. The work that’s still on the site owner:

• Legacy bloat from pre-6.6 plugins. The 150 KB threshold only applies to newly added options. Every multi-megabyte autoloaded entry that was already in the database when the site upgraded to 6.6 is still there, still autoloading, still costing time-to-first-byte on every request. The cleanup work the original article described is still the work.
• Plugins that ignore the new conventions. Plugins built before 6.6 and not updated since will continue to call add_option() with explicit $autoload parameters set the old way. Core honors what they ask for. The result is a mixed environment: some options autoload sensibly, some still bloat the table.
• Plugins that bypass add_option() entirely. Anything writing directly to wp_options via SQL (it happens) skips the size threshold check completely. The bloat path is still open for poorly-written code.
• Options just under the threshold. The 150 KB default catches the egregious cases. It doesn’t catch the long tail of 50–100 KB options that aren’t individually catastrophic but add up. A site can have a perfectly compliant autoload table that still totals 8 MB across 100 options.
• Options the user manually flipped to autoload. Some admin UIs let users mark options as autoloaded. Those choices stick. The threshold doesn’t override explicit user intent.
• The wp_options table itself. Even non-autoloaded options bloat the table, which still affects database query performance, backup size, and replication overhead. Cleanup of unused options matters even when they’re not autoloading.

The remediation pattern, updated.

The pattern from 2023 still works, with one syntactic change: when flipping an option to non-autoloading, the modern value is 'off' rather than 'no'. The old 'no' still works for backward compatibility, but new code should write 'off' for consistency with the rest of the database:

UPDATE wp_options
SET autoload = 'off'
WHERE option_name = 'the_bloated_option_name';

The full remediation flow is unchanged from the original article: audit with the (now-corrected) query, identify the bloat candidates (anything matching %_transient_%, %_cache, abandoned plugin prefixes, debug logs stored as options), flip to 'off' instead of deleting outright, monitor for breakage, then delete the truly unused ones once safe.

The bigger architectural takeaway.

The 6.6/6.7 work is part of a broader pattern in modern WordPress core: less trusting of plugin behavior, more willing to enforce sensible defaults at the framework level, more attention to the operational characteristics of long-lived sites. The autoload overhaul is the clearest example so far, but it’s not the only one — the same instinct shows up in the script-loader changes, the speculative loading API, and the renewed attention to persistent object cache support.

For sites running on serious managed hosting, much of this gets handled in the background — the host monitors total autoload size, applies the cleanup quarterly, keeps options hygiene as part of routine maintenance. For sites that aren’t, the audit is still a one-query, one-evening project that delivers measurable performance improvement on the first run. See the original autoload article for the underlying mechanics and historical context, or legacy modernization for what this looks like as part of broader platform cleanup work.

Catching and fixing issues like this is part of a Technical SEO engagement: the unglamorous engineering underneath search performance.