Blog

You rewrote the shipping page on Tuesday and only noticed today that a heading is missing. Or a plugin updated at lunchtime and the cart is now an empty column on mobile. In both cases you want an undo button, and WordPress doesn’t have one for the whole site.

What it has is a set of separate recovery tools. Each one covers one part of the site and has its own limit. The skill is matching the tool to the place where the change is stored, then using the smallest tool that can reach it. Picking the wrong one is how a typo turns into a lost week of orders. A full restore is the last step on that ladder, and our guide to restoring a WordPress site from backup covers it in detail.

Which undo tool fits the change you made?

Find the row that matches what changed. The last column shows what that tool can’t reach, which is usually the reason an undo fails.

Check the cache and save the broken state first

Before undoing anything, make sure the problem is real. WordPress.org’s FAQ on changes that seem to do nothing lists browser caching, server-side caching and caching plugins as common reasons a page looks wrong when the site is fine. Do a hard reload first. Then clear your caching plugin or builder cache, then your host’s cache and any CDN.

If the problem is still there, take a backup of the site as it is now, even though it’s broken. That copy lets you undo your undo. It also holds any orders, comments or form entries that came in since your last good backup. You may need to copy them back later.

How to undo an edit you haven’t saved yet

Use the Undo arrow in the editor’s top toolbar, or press Ctrl+Z on Windows. Each press steps back one action in the current editing session. Redo, next to it, steps forward again.

Undo only covers the current session. Once you save or publish, use revisions instead. One quirk confuses people: after you undo every change, the Save button can stay active. If you want to throw away a whole session of experiments, close the tab or reload without saving.

How to restore a saved post or page from revisions

WordPress records a revision every time you save a draft or publish an update. Restoring one replaces the content of that single post or page and leaves the rest of the site alone. For content mistakes, it’s the safest undo there is.

1. Open the post or page in the block editor.
2. Open the Settings sidebar, select the Post or Page tab, and click Revisions. If you don’t see it, the item may only have been saved once, or revisions are switched off.
3. Drag the slider to the last good version and check its date and time. The good and bad versions are often one step apart.
4. Read the comparison. Anything added on purpose after that version, such as a corrected price or a colleague’s paragraph, will be lost if you restore past it.
5. Click Restore This Revision. The version you replaced stays in the history, so you can undo this step too.
6. View the live page in a private window and check links, forms and the SEO title before you move on.

Know the limits before you rely on this. WordPress’s revisions documentation says core tracks the title, author, content and excerpt. It doesn’t track menus, widgets, site settings or most plugin data. People testing SEO changes on r/Wordpress warn that revisions don’t always restore SEO plugin fields or page builder data cleanly. Revisions are unlimited by default, but the WP_POST_REVISIONS constant in wp-config.php can limit or turn them off. A host or plugin may have set it without telling you.

Autosaves are separate. WordPress keeps one per user per post, each new one replaces the last, and an autosave never overwrites published content. To get a reliable restore point, save by hand before a big edit.

How to get back a page you deleted

Go to Posts or Pages, open the Trash view at the top of the list, hover over the item and click Restore. Restored items may come back as drafts, so check the status and publish again if needed.

Trash only holds items for a limited time before deleting them for good, and the window depends on your setup. Once an item is gone from Trash, you need a backup made before you deleted it. Restore that backup to a staging copy and copy the page across, rather than rolling the whole site back for one page.

Why reinstalling a block theme doesn’t undo design changes

Block themes save your Site Editor changes in the database, not in the theme files. In a wordpress.org support thread, a user deleted and reinstalled the theme and found their customizations still there. Clearing the template’s customizations is what removed them.

Go to Appearance → Editor. For site-wide colours, fonts and spacing, open Styles and use its revision history to compare and restore an earlier version, or reset it. For a template or template part, open it, then use the three-dot menu to reset it to the theme’s version. Menu labels have changed between WordPress versions, so look for “Reset” or “Clear customizations”.

Be careful with what you reset. A template controls every page that uses it, and resetting it removes all of its customizations, including the ones you wanted to keep. Global styles affect the whole site. If you edit a classic theme’s files directly instead, a theme update can overwrite those edits. Learn WordPress’s advice is to use a child theme, and our guide to updating a WordPress theme safely covers the checks to run before an update.

How to undo a plugin or theme update

Find the component that’s causing the problem before you roll anything back. WordPress.org’s plugin documentation suggests checking the plugin’s support forum or deactivating plugins one at a time. If you updated five plugins and rolled all five back, you still wouldn’t know which one broke the site.

Once you know which plugin it is, the free WP Rollback plugin from the WordPress.org directory can install an earlier version. Go to Plugins → Installed Plugins, click Rollback under the plugin, choose a version and confirm. For premium plugins, download the earlier version from your account with the vendor and upload it.

Rollback only replaces files. WP Rollback’s own FAQ says a downgrade doesn’t reverse database changes a newer version made, and that older versions can be missing security fixes. If the update changed how the plugin stores its data, the old code is now running against new data and can stay broken. The changelog is the best clue. Look for words like “migration”, “database update” or a major version jump. In that case, restoring the pre-update backup is the real undo.

WordPress core won’t do this for you. Since 6.3, core automatically puts the previous version back only when a manual plugin or theme update fails to install. Make WordPress Core’s announcement says it doesn’t keep the old version once an update succeeds. An update that installs cleanly and then breaks the site stays installed.

If you can’t reach the dashboard

When the site shows “There has been a critical error on this website,” check the admin email inbox for WordPress’s recovery link first. If that doesn’t work, connect by SFTP or your host’s file manager and rename the plugin’s folder inside wp-content/plugins. WordPress deactivates a plugin it can’t find. Renaming the whole plugins folder also works, but it turns off every plugin at once. Our guide to fixing a WordPress fatal error walks through reading debug.log to find the cause.

When a backup restore is the right undo, and what it erases

Use a backup when the damage covers both files and data, or when you can’t find the cause and the narrower tools have failed. WordPress’s backup handbook says a complete backup needs both the files and the database. A database-only backup doesn’t bring back themes, plugins or uploads.

The cost is everything that happened after the backup’s timestamp. One r/Wordpress poster restored a five-month-old backup to fix a problem. It wiped theme changes, a slider, an infographic and their stock counts. Kinsta’s documentation makes the same point about staging: pushing a whole staging database to live replaces the live database. That loses orders, comments, form entries and users created since the copy was made.

To keep the damage small, choose the newest backup taken before the problem, not just the newest backup. Restore it to staging first if your host allows, and compare it with live. If your host offers selective restore, restore only the files or only the database, whichever actually needs it. Our article on backups that actually restore covers setting this up before you need it.

On a WooCommerce store, protect orders first

WooCommerce’s update guide recommends a current backup, testing on staging, and keeping checkout out of use while you restore or troubleshoot. Rolling back a plugin’s files doesn’t delete orders, but a database restore can. Practitioners on r/woocommerce export orders and customers before a restore and re-import them afterwards. They add that the right method depends on whether High-Performance Order Storage is enabled.

Subscriptions add a money risk. WooCommerce’s Subscriptions documentation warns that restoring a backup can remove orders, customer details, payment tokens and subscriptions from the gap between the backup and the restore. Renewals may then run again and charge customers twice, unless you fix the renewal schedule. If you need to refund anyone afterwards, WooCommerce’s refund docs are clear: changing an order’s status to Refunded doesn’t return the money. The refund has to go through the payment gateway.

How to tell the undo actually worked

The error going away isn’t the finish line. Log out, open the page in a private window, and check whatever the change touched: the form submits, the cart adds an item, the menu opens on a phone. A restored page can bring back an old form, an outdated offer or missing image alt text you had already fixed. Then save the post or take a fresh backup, so the repaired state becomes your next restore point.

When to stop and get help

Stop undoing and start diagnosing when:

• a critical error survives a plugin rollback
• the files are back but the data is still wrong
• a restore would erase live orders
• a fix removes the error but breaks something else

At that point you’re fixing a bug, not reversing a change. Collect the error message, the time it started and what changed just before, then take it to the plugin’s support forum or your developer. If you’d rather not do it yourself, SiteSelf handles finding and fixing WordPress errors on request. It needs hosting (SSH) access for code and file work, says what it is about to change and whether that can be undone, then fetches the page and reports what it changed and what it checked.

Frequently asked questions

Go to Settings → General in your WordPress dashboard, type the new name into Site Title, click Save Changes, then load your homepage in a private window. That works on every WordPress install, whatever the theme. If the new name appears in the header and the browser tab, you’re finished.

If it doesn’t appear, the save almost certainly worked. The word “title” covers several separate things on a WordPress site, and each one is set in a different place. Most of this guide is about finding the one that is actually wrong.

Which title are you actually trying to change?

Start by finding where the wrong name is showing, because that tells you which control sets it. The site title is one setting. The header, the browser tab and Google can each show something different.

If you wanted to change one page’s headline, or hide it, you need the page editor, not this setting. Our guide on hiding page titles in WordPress explains the difference between the Title block and the Site Title block.

How to change the site title in Settings → General

This is the main route, and every other route saves to the same value. WordPress stores that value as the blogname option. WordPress.org’s Settings General documentation says themes commonly show it in the layout and the browser title bar, and that WordPress uses it to identify the site in feeds.

1. Log in with an Administrator account. Other roles can’t save core settings.
2. Open Settings → General.
3. Copy the current Site Title into a note. A setting has no revision history, so that note is how you undo the change.
4. Type the new name in Site Title, with the exact spelling and capitalisation of the brand.
5. Leave Tagline alone unless you mean to change it too. It’s a separate field for a short description, and many themes print it under the name.
6. Click Save Changes at the bottom of the screen.
7. Open the homepage in a private window and check the header and the browser tab.

The WordPress Address and Site Address fields are on the same screen. Don’t touch them. They set the site’s URL, and getting them wrong can lock you out of your own dashboard. Renaming the site doesn’t change your domain, permalinks or URLs.

How to change it in a block theme’s Site Editor

Block themes such as Twenty Twenty-Four and Twenty Twenty-Five give you two more routes, and both save back to Settings → General. WordPress.org’s Site Title block documentation says that editing the block and saving the template changes the name everywhere it appears.

1. Go to Appearance → Editor.
2. Open the Identity section and edit Site Title there. Or open the header template part and click the Site Title block on the canvas.
3. Type the new name.
4. Click Save. Until you save the template, nothing changes on the live site.
5. Go back to Settings → General to confirm the field shows the new name.

WordPress.org’s Site Editor Identity documentation says the Identity section only exists when a block theme is active. If your Appearance menu has no Editor item, you have a classic theme. Use the next section.

Two blocks look the same as the Site Title block on the canvas but behave differently. A Heading block with the name typed into it is just static text. Editing it changes the header but not the site title, and changing the site title won’t update it. A Title block shows the current page’s title, and editing it renames that page only. If your header ignores your changes, click the text and check the block name in the toolbar.

How to change it in a classic theme’s Customizer

Classic themes usually show the same fields under Appearance → Customize → Site Identity, with a live preview next to them. Edit Site Title, then click Publish. Changing the preview alone saves nothing.

The same panel has a Display Site Title and Tagline checkbox, which most themes include. If the name is saved correctly but missing from the header, that box is probably unticked, or the theme is showing a logo instead. The reverse also happens. One WooCommerce shop owner on Reddit found a large, unwanted site-title link above their menu and removed it from Site Identity. For header layout changes that go beyond the name, see our guide to modifying a WordPress header.

Page builders such as Elementor and Divi often build the header in their own editor. In that case the header shows whatever the builder template contains, so edit it there.

Why the old name still shows after you save

Work through these checks in order. Each one rules out a layer, and the order keeps you from clearing caches over and over when the cause is something else.

1. Confirm the saved value

Reload Settings → General. If the field still shows the old name, the save failed. Skip to “When to stop and get help” below. If the field shows the new name, the setting is fine and something further along is showing the old one.

2. An SEO plugin is writing the browser tab title

The text in the browser tab comes from the HTML <title>. On most sites an SEO plugin writes it. In Yoast SEO, the Website name field under Yoast SEO → Settings → Site basics overrides the WordPress setting in Yoast’s output. The homepage also has its own SEO title. Yoast’s homepage guide says to edit it under Settings → Content types → Homepage when the homepage lists your latest posts, or in that page’s own Yoast search appearance settings when you use a static homepage. Rank Math, AIOSEO and SEOPress have similar settings in their own menus.

Check that only one plugin is writing titles. In one wordpress.org support thread, a site kept its old title after the setting was changed. Clearing WP Fastest Cache didn’t help. The cause was several plugins with title settings that clashed.

3. The page has two titles, or none

Open the page, press Ctrl+U (Cmd+Option+U on a Mac) to view the source, and search for <title. There should be exactly one result. Yoast’s troubleshooting page for SEO titles lists a missing or duplicated <title> as a source-code problem. Older themes that don’t support WordPress’s title-tag feature can print their own title from header.php.

Yoast has a Force rewrite titles option for those themes, but warns it may considerably slow the site. It also warns that theme updates overwrite edits made directly to theme files. A hard-coded header belongs in a child theme, and that is usually work for a developer.

4. A cache is serving the old page

If a private window shows the new name, only your own browser was out of date. If it doesn’t, clear the caches in this order: your caching plugin, then your host’s cache, then your CDN. Clearing the browser cache doesn’t clear the server’s copy. WordPress.org notes that managed hosts often cache pages even when no caching plugin is installed. Our article on pages that won’t update covers each layer and how to clear it.

5. Google still shows the old name

Google doesn’t read your title setting. It builds title links and site names from your pages. Google’s title link documentation says it creates them automatically, may rewrite titles it considers outdated or unclear, and that recrawling and reprocessing can take a few days to a few weeks. For the site name, Google recommends WebSite structured data with name and url on the homepage. Google still makes the final choice. Yoast and other SEO plugins usually output this markup from their site name field.

Once the live page is correct, request indexing in Search Console’s URL Inspection tool and wait. In one wordpress.org thread, a site owner spent hours resetting and rebuilding before learning that re-indexing was all the site needed. Reddit users report waits of 10 days or more. One still saw no change three weeks after adding site-name markup. If Google shows leftover demo text from an imported template, check the Tagline and the homepage’s SEO title before you resubmit.

Usually the hard part of this job is the diagnosis, not typing the name. If you’d rather send the new name in chat and have it changed, checked on the live page and reported back, that is one of the routine website edits SiteSelf handles. A settings change like this needs only the SiteSelf Connector plugin.

Changing the title from WP-CLI or the REST API

If you have SSH access, WP-CLI’s option command reads and writes the setting directly. Read the old value first so you can put it back.

wp option get blogname
wp option update blogname "Acme Dental"
wp option update blogdescription "Family dentistry in Leeds"

blogdescription is the tagline. On a Multisite network, each site has its own title, so point the command at the right site with --url=. Run without it, the command changes the main site. Our explainer on multi site websites covers how networks keep each site’s settings apart.

The REST API settings endpoint calls the same values title and description. An authenticated POST to /wp-json/wp/v2/settings with a new title changes the name, and you can use an application password as the credential. Whichever route you use, a success response only proves the value was saved. Load the live page afterwards to confirm visitors see the new name.

When to stop and get help

Hand it to your host or a developer if any of these apply:

• The setting won’t save. The usual causes are a host firewall rule returning a 403, a conflict with a plugin or theme, or a leftover object-cache.php or advanced-cache.php file in wp-content. Ask your host to check its firewall logs before you start disabling plugins.
• The title is hard-coded in the theme. Editing header.php on a live site without a child theme risks breaking the layout, and the next theme update will undo your edit.
• The name changed and nobody changed it. That can be a sign the site has been hacked, especially if Google shows a name you never used. Read our guide on what to do when WordPress is hacked before you just rename it back.

Frequently asked questions

HTTP Archive’s 2025 Web Almanac found that 45% of WordPress sites passed all three Core Web Vitals on mobile, and 53% had a good Largest Contentful Paint. So most WordPress sites are still slow on phones. The usual reaction is to install another speed plugin. In support threads, that is the most common way people make a site slower or break it.

The method that works is boring. Measure the page that is slow, find out where the time goes, make one change and test again. A speed setting that breaks a menu, a form or checkout is a bug, not an improvement. Stacked optimization features are also a common reason WordPress plugins stop working.

What do you need before you start?

You need an administrator login, access to your hosting dashboard (that is where server cache, PHP version and CDN settings usually live) and a recent backup you know you can restore. If your host offers a staging copy, test the risky steps there first.

You also need three free tools: PageSpeed Insights, your browser’s developer tools (the Network tab), and the Query Monitor plugin, which shows slow database queries and outside HTTP calls. Most image and plugin work happens in the WordPress admin. Changing caching rules, PHP or theme files needs hosting access.

Step 1. Measure the page that matters, on mobile

Test the page that earns money or leads, such as a product page, a service page or the booking form. The homepage alone doesn’t tell you enough. Run it through PageSpeed Insights on the mobile setting.

A single run is noise. The WordPress Performance Team’s measurement best practices recommend taking several measurements with the same setup. Run the test at least three times and use the middle result. Write down LCP, INP, CLS, TTFB, total page weight and the LCP element (the image or text block the test flags).

The thresholds come from Google’s Core Web Vitals documentation. Google also says that meeting them doesn’t guarantee better rankings. Aim for real visitors’ numbers (the field data at the top of the report). The lab score is there to help you diagnose.

Step 2. Work out whether the server or the page is slow

TTFB tells you which half of the problem you have. If the first byte takes a long time, the browser is waiting for WordPress to build the page. Compressing a stylesheet won’t help with that. If TTFB is fast but LCP is slow, the page itself is too heavy.

If a theme or plugin is the suspect, isolate it. WooCommerce’s slow site troubleshooting guide suggests switching to a default theme for a while and turning extensions off one at a time. Do that on staging, not on the live site.

Step 3. Fix server response with hosting, PHP and one page cache

Start by finding out what your host already caches. Many hosts run their own server or edge cache, and some won’t let you add a caching plugin. Kinsta’s technical FAQ says it doesn’t allow them. A second page cache on top of the host’s cache causes conflicts and old pages that won’t go away.

Page caching matters when TTFB is the problem. In SpinupWP’s 2023 lab test, uncached WordPress handled 42 requests per second. With WP Rocket, WP Super Cache or W3 Total Cache it handled 213 to 253, and with Nginx FastCGI Cache it handled 287. That was one setup measuring server capacity, not what a visitor feels. If your host doesn’t cache, add one plugin that suits your server, for example LiteSpeed Cache on a LiteSpeed server.

Then check that the cache is actually working. Open the page in a private window, reload it, and look at the response headers in the Network tab for a cache “HIT” from your plugin or host. An installed cache that never hits does nothing.

Next, check PHP. Go to Tools > Site Health > Info > Server. WordPress’s requirements page recommends PHP 8.3 or newer. Check that your theme and plugins support it, then switch PHP in your host’s dashboard. On stores and membership sites, which can’t serve every page from cache, a persistent object cache such as Redis can reduce repeated database work if your host supports it.

If TTFB is still high while the cache is hitting, or you see 502, 503 or 504 errors, the server is running out of capacity or a request is too slow. Our guide to the 504 error on WordPress explains how to read the logs. Only upgrade hosting once you have measured that the server is the bottleneck. A pricier plan doesn’t fix a heavy plugin.

Step 4. Make pages lighter, starting with images

The usual image problem is size, not number. A 4,000 by 3,000 pixel camera photo shown 800 pixels wide makes every visitor download pixels nobody sees. A large Media Library doesn’t slow a page. Only the images on that page count.

1. In the Network tab, filter by images and sort by size. Fix the largest files first.
2. Resize to the width the theme displays, compress, and use WebP or AVIF where your setup supports them. WordPress then serves smaller copies to small screens through srcset.
3. Lazy-load images below the fold. Never lazy-load the hero image. Load it straight away and give it fetchpriority="high". Lazy-loading the LCP image delays the one thing the test measures.
4. Give every image a width and height so the browser can save space for it. This keeps CLS down.

Our guide to optimizing pictures in WordPress covers formats, bulk tools and how WordPress decides which images to lazy-load.

Step 5. Remove scripts and plugins you can’t justify

Plugin count is a poor guide. One badly built plugin can do more damage than twenty small ones. Use Query Monitor and the Network tab to see what each plugin loads and which queries it runs. Then delete any plugin nobody can explain, especially abandoned ones. That is cheaper than faster hosting, and every deleted plugin is one less thing to keep patched.

Third-party scripts such as chat widgets, trackers and ad code are often the heaviest items on the page. Removing one can be a business decision, so ask whoever owns it before you cut it.

Front-end optimization features (minify, combine, delay JavaScript, remove unused CSS) break things more often than anything else in this list. Turn them on one at a time. WP Rocket’s documentation says to turn off Combine JavaScript files when Delay JavaScript Execution is on. If a feature breaks a script, exclude only that script. After each change, open the mobile menu, submit a form and press the main button with the keyboard as well as by tapping.

If a heavy theme or page builder is the cause, replacing it is a redesign, not a quick fix. A builder your team edits every week can be worth its overhead. In that case, turn off the builder features you don’t use.

Step 6. On WooCommerce, protect checkout first

A faster store that can’t take payment is broken. WooCommerce’s checkout spinner documentation says to keep Cart, Checkout and My Account out of page and edge caching, and to make sure AJAX and Store API requests are never served from cache. If they are, customers see the wrong cart, a spinner that never stops, or wrong shipping rates.

After every change, purge every cache layer and place a full test order using your payment provider’s test mode. Add a product, change the quantity, apply a coupon and check the shipping and tax totals. Turning off cart fragments can speed pages up, but it can also stop the header cart from updating, so test that on staging first.

Step 7. Test the same way again, then keep or undo

Retest the same page with the same settings and the same number of runs, and compare it with your baseline. Keep a change only if it improved the metric you aimed at and nothing broke. Otherwise undo it before you try the next one. Write each change down in one line, because three weeks later nobody remembers which setting broke the contact form.

If a change doesn’t show up, an old copy is being served from somewhere. Purge the plugin cache, the host cache, the CDN and then the browser, in that order. Our guide to a page that isn’t updating explains how to tell which layer answered. Field data in Search Console takes weeks to catch up, so judge field results over time.

What if it’s still slow, or only the admin is slow?

A slow wp-admin is a different problem. Common causes are a bloated wp_options table, very large numbers of posts or custom fields, no object cache, old PHP, host limits and outgoing calls that time out. WooCommerce’s wp_options and site speed guide points out that autoloaded options load on almost every page. Check what is autoloaded before you delete anything, because removing rows blind can wipe settings a plugin still needs.

Stop and get help if checkout breaks and you can’t trace why, if you’re unsure what a database table belongs to, or if a script conflict goes beyond what the plugin settings can fix. If you’d rather hand the work over, SiteSelf’s speed optimization work starts from your slow page URL in chat. The agent makes the change on your site using hosting (SSH) access and reports what it changed and what it checked. Speed also drifts as content and plugins change, so a website care plan should name who retests and when.

Frequently asked questions

Your hosting dashboard probably says backups are on. That sounds fine until something breaks and you have to answer three questions: what does the copy contain, where is it stored, and has anyone ever restored it? Most failed recoveries had a backup. The backup just had a problem nobody found until the day it was needed.

This guide covers making a backup you can actually use: what it has to include, three ways to make one, how often to run it, where to keep it and how to prove it works. If you already have a backup and need to use it, our guide on restoring a WordPress site from backup covers that side.

Why a WordPress backup is always two things

A full backup is the database plus the files, taken at the same moment. Leave out either half and you can’t rebuild the site.

The database stores posts, pages, comments, users, settings and most plugin data. On a store, it also holds products, orders and customers. The files are WordPress core, your theme, your plugins, the wp-content/uploads folder with every image you have uploaded, and wp-config.php. WordPress’s Advanced Administration Handbook on backups warns that downloading the WordPress folder does not include the database, because the database is stored separately. The handbook’s order is to back up the database first and then the files, and to restore the files first and then the database.

The common mix-up is Tools > Export. That screen produces an XML file of your posts and pages. It contains no theme, no plugins and no settings. WooCommerce’s backup documentation says a store’s data lives in two places, the wp-content folder and the database, and that the XML export does not include orders, products or settings. Use the export to move content around, not as a backup.

Treat every archive as sensitive. wp-config.php holds your database password and security keys, and a store’s database dump holds customer names and addresses.

Which backup method suits your site

There are three ways to do it, and many sites use two of them together.

• Host backups. You don’t have to set anything up, and you can usually restore with one click or a support ticket. Ask your host what the backups include, how long they are kept and where they are stored. They often sit in the same account as the live site.
• A backup plugin. You choose the schedule and send copies to storage you own, such as Google Drive, Dropbox or S3. It is one more piece of software to keep updated, and it can fail when the server runs out of memory, time or disk space. Our explainer on what a backup plugin does and where it fails covers the failure modes.
• A manual backup. You export the database and copy the files yourself. You get full control and no plugin limits, but it takes more skill, and nothing happens unless someone remembers to do it. It works best as a one-off copy before a risky change.

For an owner without a web team, a sensible default is to keep the host’s backups as one layer and add a plugin that sends copies off-site. Plugin choice matters less than people think. Practitioners on Reddit and wordpress.org disagree about which plugin is most reliable, and the same plugin works for one person and fails for another depending on the server. Pick one plugin, not two, and check that it works.

How to make a manual backup

You need your hosting control panel login, SFTP or file manager access, and access to phpMyAdmin or SSH. Check the database name in wp-config.php (the DB_NAME line) before you start, because exporting a staging database by mistake is easy to do.

1. Pause writes if they matter. On a store or a busy membership site, pick a quiet hour. Orders that arrive while you copy can end up in one half of the backup but not the other.
2. Export the database. In phpMyAdmin, select the database named in wp-config.php, open the Export tab and export all tables as SQL. Name the file with the site and the date and time.
3. Copy the files. Using SFTP or the host’s file manager, download the whole WordPress folder, including wp-content and wp-config.php. Turn on hidden files so you also get .htaccess. Check that the transfer finished and didn’t just stop partway.
4. Write down the environment. Note the WordPress, PHP and database versions. Restoring an old backup onto a newer PHP version is a known way for restores to fail.
5. Move the copy off the server. Put the SQL file and the file archive together in storage outside your hosting account, encrypted if it holds customer data.

With SSH access, the same backup is two commands, run from the WordPress folder:

wp db export ~/backup-$(date +%F).sql
tar -czf ~/files-$(date +%F).tar.gz .

Then copy both files somewhere other than that server. Before you rely on the backup, open the SQL file and check that the tables you expect are there, including the plugin tables, and that the archive size makes sense for your site.

How to set up a plugin backup that you can trust

Installing the plugin is the easy part. What makes it work is the setup and a habit of checking it.

• Include everything. Back up the database, plugins, themes, uploads and other wp-content folders. Leaving out uploads makes the archive smaller, but the backup is no longer complete.
• Set a remote destination. A copy that stays in the plugin’s folder on your server is not off-site.
• Turn on email reports. Then actually read them.
• Read the log after the first run. In a 2026 wordpress.org thread, an UpdraftPlus user’s log showed errors and no database archive, yet the run ended as succeeded and no failure email was sent. Other people in the thread questioned the cause. Either way, the status label was not enough to go on.
• Check the remote storage directly. In another thread, a remote upload failed, the local copies kept building up, and the server filled until the site went down. Open the Drive or S3 folder now and then and check that new files keep arriving.

How often should you back up?

Back up often enough that you never lose more work than you could stand to lose. WordPress’s handbook suggests weekly backups for small sites with little activity and daily backups for busy ones. Neither is a rule. A brochure site edited once a month is fine with weekly backups. A blog publishing every day needs daily backups. A store taking orders all day needs database backups more often than daily, and Reddit commenters suggest every few hours.

Files usually change less than the database, so a common pattern is to back up the database daily and the files weekly. Separately from the schedule, take a fresh backup before every plugin, theme or core update, before a migration and before any developer starts work on the site.

Where should backup copies live?

Keep at least one copy outside your hosting account, in storage only you control. A backup in the same account as the site goes down with it: if the account is suspended, if someone steals the login, or if the host has an outage, you lose both. Practitioners call this a “3-2-1 style” setup: the live site, the host’s backup and one independent copy.

Keep enough old copies to go back past a problem you didn’t spot right away. A hack often starts days before anyone sees it, and the newest backup may already include it. Our guide on what to do when your site is hacked explains why to restore only a backup you know is clean, and only after the way in has been closed.

How do you know the backup will actually restore?

Restore it somewhere that isn’t the live site. A host staging copy or a local install with LocalWP both work. Do it once now and then on a regular schedule. Some practitioners do it monthly. Restore the files, import the database, then check the pages, images, forms and logins, and count posts or products against the live site. A homepage that loads can still hide missing tables.

A staging copy is a working site and can do real things. The Make WordPress Hosting handbook on staging warns that a clone can be indexed as duplicate content, can send emails to customers, and can run scheduled tasks that call payment or subscription services. Put a password on the copy, stop or catch outgoing email, switch payments to sandbox mode and turn off cron. If you push from staging back to live, check Settings > Reading on the live site afterwards. WordPress’s Reading settings documentation explains that “Discourage search engines” adds a noindex tag, so if that setting comes across from staging, search engines get the same instruction for your live site.

What is different on a WooCommerce store?

Restoring an older database takes the whole store back to that moment, and every order placed since then disappears. One store owner on r/woocommerce rolled back to fix a payments problem and lost several days of orders. Restoring the site doesn’t bring back the business records. You would have to match up the missing orders against your payment provider by hand.

When an update breaks something, roll back the one plugin or theme that caused it and leave the database as it is. Use a partial restore if your tool offers one. Test updates on staging before they reach checkout. Never push a staging database over a live store, because the Make WordPress Hosting handbook notes that this overwrites orders, comments and users created since the copy was made.

When to stop and get help

Stop and ask for help if a restore freezes partway through, if a backup is too big for your host’s upload limit, if the site shows “There has been a critical error on this website” after a restore, or if you suspect the backup itself is infected. Running the same browser restore again rarely works unless something has changed, such as higher PHP limits or more free disk space. If a former developer or host ran the site, ask them for a backup before you rebuild anything. They often have one.

If a backup before every update is the step you keep skipping, SiteSelf can take on routine WordPress updates and maintenance on request through chat. Before each change it says what is about to change and whether it can be undone. You still need your own off-site backup. A WordPress care plan should say who is responsible for that.

Frequently asked questions