Short answer: a theme update replaces the theme's files. Anything you changed inside those files (style.css, functions.php, template files) is destroyed, and it is not recoverable from the database. Anything stored in the database survives: your posts and pages, menus, widgets, Customizer settings, and the template and style changes you made in the Site Editor on a block theme. The permanent fix is a child theme, made before you customize. If you have already updated and lost work, skip to the recovery section, because what you do in the next ten minutes decides how much comes back.
What survives an update and what does not
This table is the whole subject. Everything else is detail.
| What you changed | Where it is stored | Survives a theme update? |
|---|---|---|
| Posts, pages, media, categories | Database | Yes |
| Menus and widgets | Database | Yes |
| Appearance > Customize settings (colors, logo, layout options) | Database, as theme modifications keyed to that theme | Yes |
| Customizer > Additional CSS | Database, as a separate record tied to that theme | Yes |
| Site Editor templates and template parts (block themes) | Database, as their own records | Yes |
| Global Styles from the Site Editor (block themes) | Database, keyed to that theme | Yes |
| Theme options set in the theme's own settings panel | Usually database, occasionally files | Usually yes, check the theme's documentation |
| Edits to style.css, functions.php or any template file in the parent theme | The theme folder on the server | No. Overwritten. |
| Custom template files you added to the parent theme folder | The theme folder | No. Deleted. |
| Images or fonts you uploaded into the theme folder | The theme folder | No. Deleted. |
The rule underneath it: updating a theme replaces the theme's folder. It does not merge your changes, because it has no way to know which lines were yours.
Before you update anything
Take a full backup of files and database, and confirm you can restore it. A backup you have never restored is a belief about a file. On a theme update the practical version of this is: know where the backup is, know that it contains both halves, and know the restore procedure and roughly how long it takes.
Do it on a staging copy first if you have one. Most managed hosts offer one-click staging in the control panel. If your host does not offer staging, the honest fallback is a maintenance window: pick an hour when traffic is lowest, confirm the restore path first, and have the backup downloaded to your own computer before you click. Testing an update on a copy of your site first covers making a copy properly.
Take screenshots of your Customizer panels and your theme options screens. Two minutes, and it is the cheapest insurance in this article. Settings are far easier to re-enter than to reconstruct from memory.
Copy your Additional CSS into a text file. It lives in the database and it will survive, but it is one text box and it costs nothing to hold a copy outside the site.
Do not edit core WordPress files at any point. Nothing here requires it, and those edits are erased by the next core update regardless.
The real answer: a child theme
A child theme is a small folder that sits alongside the parent and says "use everything from that theme, except these files". Your changes live in the child. Updating the parent replaces the parent's folder and leaves the child untouched.
At minimum a child theme is a folder containing a style.css whose header declares the parent theme as its template, plus a functions.php if you have PHP customizations. Many theme authors ship a ready-made child theme on their own site, and using theirs is preferable to building your own, because it will already be wired the way that theme expects.
Two things a child theme does not do, both of which surprise people:
- A child theme is a separate theme as far as WordPress is concerned. That has consequences, in the next section.
- A child theme does not protect you from the parent changing its own markup. If the parent restructures a template your child overrides, your override can go stale silently and keep rendering old markup. Overriding fewer files is safer than overriding more.
If you are not going to build a child theme, the next best option is to put CSS-only changes in Appearance > Customize > Additional CSS, and PHP-only changes in a code-snippets plugin rather than functions.php. Both store in the database. Neither is touched by a theme update. Neither is as clean as a child theme, and both are far better than editing theme files.
Do not use the built-in theme file editor (the Appearance screen that lets you edit theme files from inside the admin). It writes directly into the theme folder, which is the exact thing an update overwrites, and a PHP mistake there can take the site offline immediately.
The trap: activating a child theme appears to erase all your settings
This is the failure that catches people doing the right thing, and most guides on this topic do not mention it.
Customizer settings are stored per theme. So are Additional CSS and, on block themes, Global Styles. When you activate a child theme, WordPress correctly treats it as a different theme, looks for that theme's settings, finds none, and shows you a site with the theme's defaults. Your logo, colors, and layout choices all appear to have vanished.
They have not. They are still stored against the parent theme, which is why switching back restores everything instantly. But if you activate the child theme, panic, and start re-configuring at speed, you can spend an evening rebuilding something that was never lost.
The safe sequence:
- On staging, or during a quiet window, screenshot every Customizer panel and copy the Additional CSS to a text file first.
- Activate the child theme. Expect the site to look wrong. This is normal and it is not damage.
- Re-enter the settings from your screenshots, and paste the Additional CSS back in.
- Compare against the live site before switching the live site over.
Settings can also be moved between themes programmatically, since they are ordinary database records, but that is a database change, and a database change without a tested restore behind it is not something to attempt on a site you cannot afford to lose. If you go that route, the reversal is restoring the database backup you took first, so take it first. Re-entering settings by hand from screenshots has no such downside, and for most sites it is twenty minutes.
Block themes and full site editing
If your theme is a block theme, the Site Editor changes the picture in your favor. Templates, template parts and Global Styles that you edit there are saved as database records, not as files in the theme folder. Updating the theme does not overwrite them.
The trade-off is the mirror image: because your version is stored separately, an updated theme's improved templates will not reach the pages you have already customized. The Site Editor marks customized templates and offers to clear the customization and return to the theme's own version, which is how you take the theme's update after the fact. That reset is a one-way action for that template, so decide before clicking, not after.
Where these screens live changed in the WordPress 7.0 admin redesign. The WordPress 7 admin walkthrough covers the new layout, and the WordPress 7.x guide for site owners covers what the release changed overall.
Recovery: you already updated and the design reverted
Work in this order, and change nothing else until you have been through it.
- Stop and take a backup of the current broken state. Recovery attempts can make things worse, and you want a way back to where you are now.
- Establish what actually changed. Is the design gone, or is the theme showing its defaults? If your Customizer settings are still listed under Appearance > Customize, nothing in the database was lost and you are looking at a file-level problem.
- Check whether the theme reverted to a parent or a default theme. Under Appearance > Themes, confirm which theme is active. An update that fails partway can leave a different theme active.
- Retrieve your file edits from the backup, not from the site. If your changes were in the theme folder, the only copy is in a backup taken before the update. Open the backup, find the old theme folder, and read your changes out of
style.cssandfunctions.php. - Do not paste them back into the updated parent theme. That reproduces the original problem and you will lose them again next time. Create a child theme and put them there.
- If there is no pre-update backup, file-level customizations are gone. What remains is everything in the database, which is usually more than people fear: content, menus, widgets, Customizer settings, Additional CSS.
If the site is not loading at all rather than merely looking wrong, that is a different problem with a different order of operations. Rolling back a WordPress update covers getting back to a working state first, before any of the above.
The honest limitation
A child theme protects your work from updates. It does not make your work permanent. Themes get rewritten, block themes and classic themes structure everything differently, and a heavily overridden child theme can become its own maintenance burden. If you find yourself overriding a dozen parent templates, the question worth asking is whether this is still the right theme, not how to defend the overrides.
Run the pre-update checklist before each theme update, and the next one is uneventful.
FAQ
Will updating my WordPress theme delete my customizations?
It deletes anything you changed inside the theme's files. It does not touch content, menus, widgets, Customizer settings, or Site Editor changes on a block theme, because those live in the database.
Why did my site lose its design when I activated a child theme?
Customizer settings, Additional CSS and Global Styles are stored per theme. A newly activated child theme has none yet, so you see the theme's defaults. Switching back to the parent shows the settings are still there.
Where does Appearance > Customize actually save my settings?
In the database, as theme modifications keyed to the active theme. That is why they persist through updates and why they do not follow you to a different theme.
Can I recover theme file edits after an update overwrote them?
Only from a backup taken before the update. There is no copy of overwritten theme files anywhere else on the site.
Do I need a child theme if I only change colors and fonts?
No. Color, font and layout choices made in the Customizer or the Site Editor are stored in the database and survive updates. A child theme is for changes to the theme's own files.
