Attic — Safe Database Cleanup (Undo-Friendly)

Install Attic, go to Tools → Attic and run a scan. The autoload findings list every large autoloaded option by size, with the plugin it belongs to and whether that plugin is still installed. Quarantine the ones left behind by plugins you've deleted. Your autoload size drops right away, and anything you remove can be restored for 30 days.

If your autoloaded options are large, yes: WordPress loads them on every page request, so shrinking them cuts work on every page. Orphaned tables and meta mostly cost disk space and backup size rather than page speed. Attic shows sizes up front so you can see what's worth removing.

Only if the plugin that created them is really gone and nothing on your site still reads them. Some plugins share tables, and some keep data you'd want back if you reinstall. That's why Attic never drops a table straight away: it renames it to wp_attic_quarantined_*, so your site behaves as if it were deleted. If nothing breaks during the purge window, it's removed for good. If something does break, restore it in one click.

The scan is read-only. Nothing changes until you take an explicit, confirmed action. Core options like siteurl, active_plugins and cron can never be flagged, and neither can anything on your own protected list or the attic_protected_options filter.

Tools → Attic → Quarantine. Every action creates a batch; restore a whole batch in one click. Batches auto-purge after 30 days (configurable).

For most rules, high confidence requires the owning plugin to be absent from disk (or the option to be size-flagged and unread), and zero literal and zero prefix references anywhere in your code. Dynamic option names never literal-match, so even a weak signal keeps a finding at "review". If your filesystem could not be read, everything is marked unverified rather than guessed at. Two rules are exceptions, because a code search cannot tell you anything useful about them: an expired transient and a meta row whose parent is gone are facts about your database, not guesses about your code. Those are reported as high confidence on their own evidence.

Yes — when Redis/Memcached is active, transients never touch the options table, and Attic says so instead of showing a meaningless clean bill of health.

Yes. Single-site, subdirectory multisite, and subdomain multisite installs all work. Network-wide fleet scanning is available via the network admin dashboard.

Attic works with all WordPress plugins — it's a read-only cleanup tool that doesn't touch plugin data unless you explicitly quarantine it. The attribution map helps identify which plugin owns which database entries, but the scan works regardless of whether a plugin is in the map. Plugins with known prefixes in the attribution map get named attribution, and the "leftovers from a deleted plugin" rule relies on the map to know which prefixes belonged to which plugin. Data belonging to a plugin that is not in the map is still found by the other rules — an oversized autoloaded option, an orphaned table or a dead cron event is detected either way. It just shows its owner as "unknown". You can add your own entries with the attic_prefix_map_entries filter.

No. Attic quarantines data (renames tables, copies options), never deletes. You can restore anything from Quarantine within the purge window (default 30 days, configurable).

Attic correctly detects network-active plugins and never flags their data as orphaned, even if they're deactivated on individual sites.