You changed a setting, saved, and the site is worse. The permalinks broke, the theme lost its header, the shop shows prices in the wrong currency, or the front page is suddenly the blog. The instinct is to look for an Undo button, and there is none: WordPress cannot undo WordPress settings changes on its own, because it never stored the previous value. This guide is the four fixes that work, from the quickest to the most thorough, plus the two cases where a wrong setting locks you out of the admin before you can fix anything.
Why you cannot undo WordPress settings out of the box
Every setting lives in the wp_options table as one row: a name and a current value. When you click Save, update_option() overwrites the value. There is no revision row, no timestamp and no author — a fact the settings history guide goes into in detail. Post content gets a revision on every save; settings get nothing. So to undo WordPress settings changes you need the old value from somewhere else, or something that recorded it as it changed.
| Fix | Needs | Time | Risk |
|---|---|---|---|
| 1. The plugin’s own reset | Nothing | 1 minute | Resets more than the one setting |
| 2. WP-CLI with a value you know | SSH and the old value | 2 minutes | Typos in serialized data |
| 3. One row out of a backup | A backup from before the change | 15–30 minutes | Restoring the whole backup by mistake |
| 4. A plugin that recorded the change | It was installed before the change | 10 seconds | Protected options need care |
Fix 1: undo WordPress settings with the plugin’s own reset
Before touching the database, look at the screen where the setting lives. Most plugins with more than a handful of options have a reset: “Restore defaults”, “Reset section”, a per-field arrow back to the default, or a Tools tab with “Reset settings”. Elementor, WooCommerce, the big SEO plugins and most form builders all have one somewhere.
Its limitation is scope, and it is why a reset is rarely the way to undo WordPress settings you had tuned. A reset puts a section back to the plugin’s defaults, not to your values from yesterday. If the section held ten settings you had tuned and one you broke, a reset costs you the nine. It is the right first move when the plugin was on its defaults anyway, and the wrong one when it was not.
Core settings have a variant of this. WordPress falls back to a built-in default when an option is missing, so deleting the row is a reset:
Delete an option and let WordPress fall back to its default
# Reading settings: posts per page defaults to 10 when the row is gone
wp option delete posts_per_page
wp option get posts_per_page
# → 10The same works for many plugin options that read with get_option( 'name', $default ). It does not work for options the plugin expects to exist, so take a copy first: wp option get name > name.txt, then delete.
Fix 2: undo WordPress settings with WP-CLI
If you know the old value — from a screenshot, an email, a colleague’s memory, a staging site — WP-CLI is the fastest way to undo WordPress settings: it writes the value back in one line and does not care which plugin owns the option:
Write a known value back
# A plain value
wp option update blogdescription "Web design and WordPress engineering"
# Find the option first when you only know the plugin
wp option list --search='woocommerce_*' --fields=option_name | grep -i currency
wp option update woocommerce_currency USDArray options are where people hurt themselves. A setting like elementor_settings or a theme’s options is one serialized array; the setting you want to undo is one key inside it. Do not paste the whole array back with one value edited. Patch the key:
Change one key inside an array option
# See the structure
wp option get my_theme_options --format=json
# Put one key back; the rest of the array is untouched
wp option patch update my_theme_options container_width 1200
# Nested keys are a path
wp option patch update my_theme_options header sticky 1This is the cleanest way to undo WordPress settings changes when you have the value, and it is safe on serialized data because wp option patch unserializes, edits and re-serializes for you. On hosts that have disabled proc_open, every wp option command still works — it is only wp db that breaks there.
Never edit a serialized value in a text editor or phpMyAdmin. s:5:"width" means a five-character string follows. Change the text without changing the number and the whole option fails to unserialize; get_option() returns false, and the plugin acts as though it had never been configured. The symptom is a plugin that “forgot” every setting, not just the one you touched.
Fix 3: undo WordPress settings from a backup, one row at a time
When nobody knows the old value, the backup does, and it is the only way to undo WordPress settings that were changed before anything was recording. The mistake is restoring the whole backup: that rolls back every post, order, comment and form entry since it ran, to recover one setting. Restore it somewhere harmless instead and take the one value:
Lift one option out of a backup
# 1. Load the backup's SQL into a scratch database, never the live one
mysql --defaults-file=~/.my.cnf scratch_db < backup-2026-09-15.sql
# 2. Read the value as it was
mysql --defaults-file=~/.my.cnf scratch_db -N -e \
"SELECT option_value FROM wp_options WHERE option_name='my_theme_options'" > old.txt
# 3. Write it back to live — as a raw serialized string, so pass it exactly
wp option update my_theme_options "$(cat old.txt)"
# 4. Check it reads as an array, not false
wp option get my_theme_options --format=json | head -c 200Step four is the one that catches a copy-paste error, and it is worth running every time you undo WordPress settings this way. If it prints false or an empty string, the value was mangled in transit; run the query again and redirect straight to the file rather than pasting through a terminal.
If you do not have SSH, the same three steps work in phpMyAdmin: import the backup into a second database your host lets you create, browse wp_options, copy the value, and paste it into the live row. It is slower and it is where the serialized-data trap bites hardest, so copy the entire cell and change nothing.
Whether a backup exists at all, and whether it is from before the change, is the real question. Backups done right covers the schedule; the six checks for a backup plugin covers whether yours would actually restore.
Fix 4: undo WordPress settings in one click with a plugin that recorded them
The three fixes above all reconstruct the old value after the fact, which is why each takes minutes. The fourth way to undo WordPress settings takes seconds: Settings Undo, a free plugin we built for this, hooks the moment any option is added, changed or deleted and stores the value before and after, with the user, the time, the plugin or theme that wrote it and the screen it came from. Every entry has an Undo button; every save that touched several options has an Undo all.
What one entry looks like
September 16, 2026, 4:42 am usm4nzz@gmail.com WordPress Settings › Reading
posts_per_page updated 10 → 12 [Diff] [Undo]Because it works at the options layer, it does not need to know about the plugin that owns the setting. Elementor, RankMath, WooCommerce, the Customizer and the core Settings screens all appear in the same timeline. Array options get a key-by-key diff, so you undo WordPress settings changes knowing exactly which of the forty keys moved. The undo itself is recorded, so if you undo the wrong thing, that is one more click.
Its one requirement is the obvious one: it has to have been installed before the change. That is the case for the next mistake, not this one. The plugin page has the download, screenshots and the list of what it deliberately ignores.
Undo WordPress settings on the screens people break most
The same handful of core settings account for most of the “undo WordPress settings” requests we get. Each one is a single option with a plain value, which means fix 2 is one line. The table gives the screen, the option name and the value that is usually right.
| Screen | Symptom | Option | Usual fix |
|---|---|---|---|
| Settings › Reading | Site vanished from Google after a redesign | blog_public | wp option update blog_public 1 |
| Settings › Reading | Home page shows the blog, or the wrong page | show_on_front, page_on_front | wp option update show_on_front page then the page id |
| Settings › Permalinks | Every post is a 404 | permalink_structure | wp option update permalink_structure "/%postname%/" then wp rewrite flush |
| Settings › General | Spam registrations overnight | users_can_register | wp option update users_can_register 0 |
| Settings › General | Scheduled posts publish at the wrong hour | timezone_string | wp option update timezone_string "Asia/Karachi" |
| Settings › General | Admin in the wrong language | WPLANG | wp option update WPLANG "" for English |
| Settings › Discussion | Comments open on everything, or closed on everything | default_comment_status | wp option update default_comment_status closed |
The first row is the expensive one. “Discourage search engines from indexing this site” gets ticked on a staging copy and travels to production with the migration, and the site quietly drops out of results over the following weeks. If you undo WordPress settings for nothing else, check that one after every launch: it is the top item in why a site is not showing on Google.
Two of these rows need a follow-up after the value is back. A permalink change is not complete until the rewrite rules are rebuilt, and the front-page change needs a valid page id or the home page renders blank. Neither is obvious from the option itself, which is one more reason a recorded history beats reconstruction: when you undo WordPress settings from a timeline entry, the surrounding writes from the same save are right there beside it.
Two settings that lock you out before you can undo them
Most wrong settings are annoying to undo. Two take the admin away with them, and for those the fix has to work without the dashboard.
The site URL pair: siteurl and home
Change the WordPress Address or Site Address in Settings › General to a wrong value — a typo, http instead of https, the staging domain — and every admin link now points somewhere else. You cannot undo WordPress settings from a screen you cannot reach. Override them from wp-config.php instead:
Override the URLs without touching the database
# wp-config.php, above "That's all, stop editing"
define( 'WP_HOME', 'https://example.com' );
define( 'WP_SITEURL', 'https://example.com' );These constants win over the database values, and the admin comes back on the next request. Then fix the stored values properly and remove the constants, or leave them in: a hard-coded URL is a reasonable thing for a production site to have.
Or fix the stored values directly
wp option update siteurl https://example.com
wp option update home https://example.comThe active-plugins list
A plugin that fatals on activation, or a restored active_plugins value that references a folder that no longer exists, can take the whole site down with it. Deactivate from outside the dashboard:
Deactivate plugins without the admin
# All of them, then re-enable one at a time
wp plugin deactivate --all
# Or just the suspect, by renaming its folder over SFTP
mv wp-content/plugins/broken-plugin wp-content/plugins/broken-plugin.offOne thing to know before you undo WordPress settings here: writing an old active_plugins list back does not run each plugin’s activation or deactivation routine. Tables are not created, cron events are not scheduled, rewrite rules are not flushed. For anything beyond a simple on/off, activate the plugin properly from the Plugins screen once you are back in. The locked-out guide covers the other eight ways back into an admin you cannot reach.
Where undoing WordPress settings goes wrong
| Mistake | What happens | Do instead |
|---|---|---|
| Restoring a full backup for one setting | A day of orders and posts gone | Scratch database, one row (fix 3) |
| Editing serialized data by hand | The option reads as false; the plugin forgets everything | wp option patch, or a plugin that handles it |
| Resetting a whole section to undo one field | Nine tuned settings lost to fix one | Reset only when the section was on defaults |
| Fixing a cached symptom | The setting is right; the page is still wrong | Purge the cache after the undo — Elementor especially |
Writing siteurl with a trailing slash or wrong scheme | Redirect loops, mixed content | No trailing slash; match the scheme the certificate serves |
| Undoing after a plugin update changed the schema | The old value no longer fits the new plugin | Check the plugin’s changelog first; prefer its own migration |
The cache row is the one that wastes the most time when you undo WordPress settings. You undo WordPress settings correctly, reload, and see the old behaviour, because a page cache or an object cache is still serving the previous state. Purge before concluding the fix did not work.
After any settings undo
wp cache flush
# plus your page cache — LiteSpeed shown, others have their own command
wp litespeed-purge allSet up the two-minute fix before you need it
Every way to undo WordPress settings in this guide except the fourth is reconstruction: finding a value that WordPress threw away. Fix four is ten seconds because the value was kept. The difference is entirely whether something was recording before the mistake, which is a decision for a quiet Tuesday, not for the moment the site breaks.
Two things belong on that Tuesday. A backup schedule you have tested a restore from, so fix three is always available. And a record of settings changes, so that fix four is too. Neither costs money. Both belong in the monthly maintenance checklist, next to updating safely — and if you would rather someone else kept that list, that is what a maintenance plan is.
Questions about how to undo WordPress settings
Is there an undo button in WordPress settings?
No. Undo exists inside the post editor for content, and revisions exist for posts and pages. Settings screens overwrite the stored value with no history, so to undo WordPress settings changes you need the old value from a backup, from memory, or from a plugin that recorded it.
Can I undo a change in the Customizer?
Partly. The Customizer keeps a changeset while you are editing and you can discard it before publishing. Once published, the values are written to the theme’s options and the changeset is gone, so the same four fixes apply. Some themes keep their own export/import of Customizer settings, which is a manual snapshot by another name.
What if I do not know which option the setting is stored in?
Search the table by the plugin’s prefix: wp option list --search='pluginname_*'. If that finds nothing, the plugin may keep settings in its own table, which none of the option-level fixes reach — only a backup does. A settings-history plugin shows the option name on every entry, which answers the question for next time.
Will undoing a setting break something else?
Occasionally. Some options depend on each other — a permalink structure and the compiled rewrite rules, a currency and its stored format. Undo the setting, then trigger whatever regenerates the dependent value: for permalinks, wp rewrite flush or a visit to Settings › Permalinks; for caches, a purge.
Can I undo WordPress settings that a plugin changed on install?
Only with a record of what it wrote. A plugin can add or change dozens of options on activation and leave them on uninstall; nothing in core tells you which ones. A settings-history plugin that was running at the time shows every option the install touched as one change set, with Undo all beside it. Without that, fix 3 and a backup from before the install are the only route.
Does a settings-history plugin slow the site?
Not measurably. It runs only when an option actually changes, which on most sites is a few times a day, and never on the front end for visitors. It ignores transients, cron and cache keys, which are the writes that happen constantly.
Can I undo WordPress settings on a multisite network?
Per site, yes, with all four fixes. Network-wide options live in a different table (wp_sitemeta) and use update_site_option(); the WP-CLI equivalent is wp site option. Settings Undo does not yet cover network options; that is on its roadmap.
Should I keep WP_HOME and WP_SITEURL in wp-config permanently?
On a production site with one fixed address, yes: it removes a whole class of accidents, and the General settings fields become read-only, which is a feature. On a site that moves between domains regularly, leave them out so the database values can be changed by the migration tool.
