Blog

Most hosts and plugins can copy a WordPress site to a staging URL in a few minutes. The problems come afterwards. Anyone who finds the copy can open it. It still holds your live payment keys and email settings. And pushing it back to live can erase every order, comment and sign-up that came in while you were testing.

This guide covers the three ways to create the copy, the four things to lock down before you test on it, and how to deploy back without overwriting live data. Before you start, take a fresh backup of the live site and make sure you can actually restore that WordPress backup. Staging is for testing. It doesn’t replace a backup.

Which staging method fits your site

Use your host’s tool if your plan has one. If it doesn’t, or the tool fails on your site, use a plugin. Build a copy by hand when you need full control or nothing else works. That order comes up again and again in practitioner threads, and it also matches how much can go wrong with each method.

How to create the staging copy

With your host’s staging tool

Look in the hosting dashboard for “Staging”, “Environments” or “Clone”. On Kinsta, for example, you go to Sites, open the live environment and choose Create new environment, then pick the clone option. Most hosts put the copy on its own subdomain and connect it to a separate database for you, so this is the quickest route.

If the tool fails on one site but works on others, try a plugin instead of running the same clone again. Repeating a clone without changing anything usually fails the same way.

With a staging plugin

With WP STAGING’s free version, go to WP Staging, then Staging Sites, then Create New Staging Site. Give it a name and start the clone. The copy lives in a subfolder of your domain, such as /development. By default its tables sit in your existing database under a separate prefix.

That shared database keeps the copy separate in software, but not physically. Subdomain clones, a separate database and pushing to live are Pro features. Long-time users say this kind of plugin works best on small, clean sites, and that large sites sometimes need a manual search-replace after the clone.

By hand

1. Create a subdomain such as staging.example.com in your hosting panel.
2. Copy the WordPress files into the subdomain’s folder, including all of wp-content.
3. Export the live database. Create a new, empty database with its own user, and import the export into it. Don’t reuse the production database credentials.
4. Edit the staging wp-config.php so it points at the new database and labels the environment:

   define( 'DB_NAME', 'example_staging' );
   define( 'DB_USER', 'staging_user' );
   define( 'WP_ENVIRONMENT_TYPE', 'staging' );

5. Replace the live URL with the staging URL using a tool that understands serialized data. Run it once with --dry-run to preview the changes, then run it again without that flag to apply them:

   wp search-replace 'https://example.com' 'https://staging.example.com' --skip-columns=guid --dry-run

6. Password-protect the subdomain before anyone else logs in.

Step 5 is where most hand-built copies break. WordPress stores some settings as serialized PHP, and the stored value includes each string’s length. If you swap a URL in phpMyAdmin, the length no longer matches and widgets or options stop loading. WordPress’s migration handbook also says to leave the guid column alone. If those IDs change, feed readers can show old posts as new.

Lock the copy down before you test anything

A fresh clone is a working copy of your live site. It can do anything live can do: send email, charge cards and fire webhooks. Make these four changes before anyone uses it.

Put a password in front of it. WordPress’s own documentation says that Settings → Reading → “Discourage search engines from indexing this site” asks search engines not to index the site. It doesn’t stop anyone from visiting it. Real access control means server-level password protection (basic auth), which shows a login prompt before WordPress even loads. Our guide to adding password protection to a site covers the options. Don’t also disallow the copy in robots.txt. Google’s documentation says a crawler blocked by robots.txt can’t read a noindex tag, and the blocked URL can still show up in search results.

Switch payments to sandbox. Set every payment gateway to test or sandbox mode. WooCommerce’s documentation says test orders can trigger order emails and appear in analytics like real orders, and that other integrations may not be able to tell them apart from real ones.

Stop outgoing mail and integrations. Turn off outgoing email on the copy. If you send mail through an SMTP provider’s API, remove or change the API key there too, because some plugins that block WordPress mail don’t stop mail sent through the provider. Check webhooks to fulfillment, accounting and CRM tools. In one wordpress.org support thread, a copied database still had live API and webhook access.

Handle WooCommerce Subscriptions. Subscriptions decides it’s on a staging site by comparing the current URL with the URL it stored when it was first activated. So activate it on live before you clone, then check the mode under WooCommerce → Status. In staging mode it skips payments and subscription emails, but scheduled renewals and events still run. Make sure the live site answers on only one URL. If it works on both www and non-www, Subscriptions can mistake the live site for staging.

Setting WP_ENVIRONMENT_TYPE to staging helps too, but only as a label. WordPress recognizes local, development, staging and production, and plugins can read the value. That tells everyone which site they’re looking at. It doesn’t stop a plugin that ignores the label from sending mail.

What a working staging copy looks like

Open the homepage, a post, a product page and the login screen. Every page should load on the staging address, with the same theme, plugins and content as live. Click the main menu and two links inside page content. If any of them opens the live domain, the search-replace missed something.

On a store, place one order in sandbox mode and take it through to the thank-you page. Then check the live order list. It should not have gained an order. Your inbox should get the test email only if you redirected mail to yourself. No customer address should receive it.

Then test the actual change. Do one thing at a time, in this order: core, then theme, then plugins. That way, when something breaks, you know which change caused it. For store updates, WooCommerce’s update guide lists what to check: product pages, cart, checkout, payments, shipping, taxes, order emails and any extensions you rely on.

When the clone fails: the usual causes

The clone stalls partway or times out. The site is too big for the PHP execution time limit, or a large table such as orders or analytics logs is slowing it down. Ask your host to raise the limit, or lower the plugin’s batch size. You can leave out log tables, but don’t leave out anything your test needs.

A memory error. In one wordpress.org support thread, a clone failed because WordPress’s own memory limit was 40 MB even though PHP allowed 256 MB. Adding define( 'WP_MEMORY_LIMIT', '256M' ); to wp-config.php raises WordPress’s limit.

The copy redirects to live, or every page except the homepage returns 404. Check the siteurl and home values in the copy’s options table. Then go to Settings → Permalinks and click Save Changes. Next, look at .htaccess or the Nginx config, then at caching, SSL, redirect and security plugins.

A blank page or “critical error” after a clone that reported success. Turn on debug logging and read wp-content/debug.log. It usually names a theme or plugin file. Make sure the copy runs the same PHP version as live before you start deactivating plugins.

The plugin can’t use a separate database. WP STAGING can’t create the database itself. Create it first, and give its user the CREATE, INSERT and ALTER privileges.

How to move tested changes to live without losing orders

A full database push replaces data. It doesn’t merge it. Kinsta’s push documentation warns that a full push can lose purchases, comments, new content, sign-ups and forum posts added since you made the staging copy. On r/woocommerce, one store owner reported duplicated and reset order numbers after pushing from host staging. WordPress has no built-in way to merge two databases that have both changed, so the safe approach is to pick the method that fits the kind of change.

A files-only push has its own limit. Kinsta notes that pushing files doesn’t create a new plugin’s database tables, and dashboard settings are usually stored in the database. Avoid the opposite mistake too: don’t push the whole database just to carry over one setting.

If you push database tables to a store, first find out where the store keeps its orders. Stores using High-Performance Order Storage keep orders in their own wc_orders tables. Older stores keep them in wp_posts and wp_postmeta, mixed in with your pages. If you can’t name every table a push will overwrite, don’t run it.

For updates, the test-then-repeat approach is the simplest safe option on a busy site, because it never touches the live database. If you would rather hand the update cycle off, the plugin updates and maintenance page explains how SiteSelf reviews, applies and checks updates on request.

Four checks on the live site after a deploy

1. Search visibility. Open Settings → Reading on live and make sure “Discourage search engines” is unticked. That setting is stored in the database, so a push can bring it over from staging and leave production hidden from search.
2. Protections. Kinsta says .htpasswd files and some bot-protection settings don’t transfer in a push. Check that live still has the protections it had before.
3. Money paths. Make sure the gateways are back in live mode on production. Run through checkout up to the payment step, and confirm today’s orders are still in the order list.
4. Links and redirects. Click the menu, a few in-content links and any redirects you rely on. None should point at the staging address.

Once the work ships, delete the staging copy or lock it away. An unmaintained clone of your site is another login page for attackers to find, and it falls further out of date every week. If something did go wrong, restore the backup you took before the deploy instead of editing live tables under pressure. Our guide to restoring WordPress from backup covers that.

Frequently asked questions

You publish a new Services page and go looking for the screen that puts it in the header. Maybe you find Menus, drag the page in, save, and the header stays the same. Maybe Appearance has no Menus item at all, just something called Editor. Neither means WordPress is broken. Your site uses one of two menu systems, and most menu problems come from editing in one system while the site displays the other.

The fix is to find out which system your theme uses, edit the menu there, and then confirm that the saved menu is the one visitors actually get. If you’re adding a page for the first time, our guide to adding pages in WordPress covers that part. This article starts once the page exists.

Which screen edits your menu depends on your theme

Open the Appearance menu in the dashboard. If it has Editor but no Menus, you have a block theme, such as Twenty Twenty-Four. If it has Menus and usually Customize, you have a classic or hybrid theme. WordPress.org’s Menus screen documentation says 5.9 was the last version that showed that screen on every site by default. From 6.0 on, block themes manage navigation through the Navigation block. Some classic and hybrid themes, and some plugins, still bring the old screen back, so trust what your own dashboard shows over any tutorial.

Before you change anything, write down three things: the theme name, its type, and the screen you’re using. If the result looks wrong later, that note tells you where to look first.

How to edit a menu on a classic theme

You need an Administrator account, or any role with the edit_theme_options capability. By default, Editors can’t change menus.

1. Go to Appearance > Menus. Pick the menu from “Select a menu to edit” and click Select. Sites often have several menus, so check the name. Editing the existing menu keeps its location, so the header stays filled while you work.
2. Show any hidden panels. Click Screen Options at the top right. Some panels, such as Tags, are hidden by default. Turn on Link Target there too if you’ll need “open in new tab”.
3. Add items. From Pages, Posts, Custom Links or Categories on the left, tick what you want and click Add to Menu.
4. Reorder and nest. Drag items up or down. To make a dropdown, drag an item slightly to the right under its parent until it’s labelled “sub item”. Our guide to building a drop-down menu covers the details.
5. Assign the location. Under Menu Settings, tick the Display location your theme uses: Primary, Header or whatever your theme calls it. This is the step people miss most often.
6. Click Save Menu. This screen doesn’t save automatically. If you leave the page, your changes are lost.
7. Check the live site in a private window. This screen has no preview. The Customizer route has one, if you’d rather see the change before it goes live.

Renaming, removing and new-tab links

To change the text visitors see without renaming the page, click the arrow on the item and edit Navigation Label. The page title stays the same. Remove in the same panel takes the item out of the menu and leaves the page alone. Once Link Target is turned on in Screen Options, each item gets an “Open link in a new tab” checkbox.

When a page exists, choose it from the Pages panel instead of pasting its address as a Custom Link. WordPress.com’s support docs point out that a pasted address never changes, so it leads to a 404 if the page’s URL changes later. A menu item picked from the Pages panel stays tied to the page.

How to edit a menu on a block theme

WordPress.org’s Site Editor navigation docs list every menu in one place, but they also make a point people miss: creating or editing a menu there doesn’t put it on the site. A Navigation block inside a template part has to use it.

1. Go to Appearance > Editor > Navigation and select the menu.
2. Edit the items. Add a page, post or custom link with the + button. Open List View to drag items and nest them into submenus. Nested items are much easier to select there than on the canvas.
3. Rename or retarget a link by selecting it. You can edit the label text directly, and the link settings have an “Open in new tab” toggle.
4. Save. The menu is now stored, but it may not be displayed yet.
5. Check where it’s placed. Open Patterns or Template Parts, then Header (wording differs a little between versions). Select the Navigation block and confirm in the block settings that it uses the menu you just edited. Save the header.
6. Set mobile behaviour. In the same block settings, Overlay Menu set to Off shows the full menu at every screen size with no hamburger icon. Mobile folds it behind a hamburger icon on small screens.
7. Check other templates. A homepage or landing template can contain its own Navigation block that points to a different menu.

Why new pages stopped appearing in the menu

A new Navigation block often starts as a Page List, which adds every published page automatically. The Navigation block documentation explains that clicking Edit on it converts it into individual Page Link blocks. You can then remove or reorder single items, but newly published pages stop showing up on their own. That’s expected behaviour. From then on, add new pages to the menu yourself.

Adding WooCommerce product categories

WooCommerce’s documentation describes two routes. On a classic theme, turn on Product categories in Screen Options, and a Product Categories panel appears beside Pages. On a block theme, add a block inside the Navigation editor and search for Product Category Link.

Your category tree doesn’t come with them. One store owner on r/woocommerce found that parent and child categories went into the menu as one flat list. The fix was to drag each subcategory under its parent by hand.

Why a saved menu doesn’t show on the site

A menu that saved correctly but looks unchanged is usually not broken. Somewhere between the editor and the visitor, the site is showing something else. Check in this order and stop when you find the cause:

1. Wrong editor. You edited in Menus while a block theme’s Navigation block draws the header, or the other way round.
2. Not placed. On a classic theme, no Display location is ticked. On a block theme, the header has no Navigation block, or its block points to another menu.
3. A different template. If the menu changed everywhere except the homepage, open that template under Appearance > Editor > Templates, select its Navigation block, choose the shared menu and save.
4. A separate mobile menu. A mobile-menu plugin can show its own menu. In one wordpress.org thread, phones kept showing an old menu until the plugin was set to use the same WordPress menu as the desktop header.
5. Cache. Clear the caching plugin first, then the host or CDN cache, then the browser. In another wordpress.org case, clearing the plugin and browser caches wasn’t enough, and only the host clearing its own server cache fixed it.
6. A stale link. If one item leads to a 404, it’s probably a pasted address for a page whose slug changed. Remove it and add the page again from the list.

Open the page in a private window before you edit anything again. If it looks right there, the problem is cache and the menu is fine. Making the same edit over and over just makes it harder to tell what happened. If the page still looks old after every cache is cleared, our guide on a WordPress page not updating goes through the next layers.

Check it like a visitor before calling it done

The editor canvas shows roughly what the site looks like. It isn’t a phone. Open the published site on a real phone, open every submenu, and tap every link you changed.

Then put the mouse down. The W3C’s menus tutorial says fly-out menus must work with a keyboard as well as a mouse, shouldn’t disappear the moment the pointer leaves them, and need touch targets large enough to tap. Tab from the top of the page and watch for a visible focus outline. Open a submenu with Enter or Space, and close the mobile overlay with Escape.

Before a large reorganisation, take a screenshot of the item list. Page and post revisions don’t bring back menus, as our guide to undoing changes in WordPress explains. Without a record, an undo means rebuilding the menu from memory.

When to stop and get help

Label changes, reordering and adding a link are safe jobs to do yourself. Stop when the problem stops being about the menu:

• The Menus screen loads blank or shows PHP warnings such as “Cannot modify header information”. That points to a conflict in a theme or plugin. Isolate it on a staging copy, not by switching off plugins on the live site.
• Saving returns a 404 or “Bad Request”. On large menus, a server security rule can reject the save request. Your host can check its logs and relax the rule for the save, then turn it back on afterwards.
• Opening Menus causes “There has been a critical error on this website.”
• Your account can’t see the menu screens at all. Ask an administrator to check that your role has edit_theme_options.
• The header is built in a page builder, or the change means rebuilding a template rather than a list of links.

If you’d rather describe the change than click through it, SiteSelf makes menu edits like these on the live site through chat. It connects through the SiteSelf Connector plugin, fetches the changed page to check it, and reports what changed, which is how it handles everyday website edits.

Frequently asked questions

A 70% bounce rate on a blog post and a 70% bounce rate on a paid landing page are different problems. On the blog post, readers may have found their answer and left happy. On the landing page, you are probably paying for clicks from people who leave right away. So before you compress an image or install another plugin, work out which of those you’re looking at.

The steps below work in order. First check what the number measures. Then find the pages where it matters, fix the cause your data points to, and confirm the result against what the page is supposed to do. That last step usually means conversions, which our guide to measuring landing page conversion rate covers in more detail.

What GA4 actually counts as a bounce

In Google Analytics 4, bounce rate is the share of sessions that were not engaged. Google’s Analytics Help page on engagement rate and bounce rate says a session counts as engaged if it lasts longer than 10 seconds, records a key event, or has at least two page or screen views. A bounce is a session that does none of the three.

This is a different measure from the old Universal Analytics one, which counted any single-page visit as a bounce. If you compare today’s figure with a blog post from 2019 or an industry benchmark, you may be comparing two different metrics.

Look at the last row. A visitor who got exactly what they came for still counts as a bounce unless a key event fires. Marking any event as a key event also makes the session engaged. You can lower the number without changing anything about the visit, and that is not a fix.

Why your bounce rate suddenly jumped or dropped

If the rate moved sharply overnight, check your tracking before you look at visitor behaviour. Real behaviour rarely changes that fast. A tracking setup changes the moment someone clicks save.

The WordPress.org support forums have plenty of examples. In one Complianz support thread, a site owner saw bounce rate go from an average of 25% to about 80% over a similar 30-day period, after plugin updates and a rerun of the consent setup wizard. Other owners report the opposite: bounce falling from around 60% to under 10% the day they installed a plugin that sends extra events. Neither case proves a cause. Both tell you where to look first.

Check these, starting with the most recent change:

• A new or reconfigured cookie consent plugin. It changes which sessions get tracked at all.
• An analytics or marketing plugin that sends scroll, timer or click events.
• A second copy of the GA4 tag, added by a theme, a plugin or Google Tag Manager.
• A new redirect that sends visitors through an extra URL before the real page.
• A spike from one referrer or country, which often means bot traffic.

Find the pages worth fixing first

A site-wide average mixes your guides, your product pages and your contact page into one number, and that number points at nothing. Start where visitors enter the site.

1. In GA4, open Reports, then Engagement, then Landing page. If your property doesn’t show it, an admin can add it from the report Library.
2. Bounce rate isn’t always a default column. Use Customize report to add it next to engagement rate, average engagement time and key events.
3. Sort by sessions. A page with 40 visits and a 90% bounce rate is noise. A page with 4,000 visits and 65% is worth your week.
4. Add Session source/medium as a secondary dimension, then compare by device. A page can be fine on desktop and fail completely on mobile visits from paid social.
5. Use at least four weeks of data, and write down the starting numbers for each page you pick.

Now ask what each page is for. A how-to article that answers the question on its first screen can bounce heavily and still do its job. A service page fed by paid ads, or a product page, is supposed to lead somewhere. A high bounce rate on those pages is the one worth fixing.

Fix the cause your data points to

The pattern in your data narrows down the cause. Very short mobile sessions point to slow loading or a broken layout. Visits from one ad campaign that leave without scrolling point to a promise the page doesn’t keep. A spike on one template after an update points to a conflict.

Make the page match what brought the visitor

Message mismatch is a common cause, and it’s the one no speed plugin can fix. A typical example on Reddit’s small-business forum: a gardening business sends its Google Ads traffic to the homepage, sees bounce above 80%, and gets one booking. The ad promised hedge trimming. The homepage talked about the company.

Give each ad group or offer its own page. Make its headline repeat what the ad said, and answer the visitor’s questions in the order they would ask them. A page headed “Emergency plumber in Leeds, same-day callouts” with a tap-to-call button keeps visitors that “Welcome to our services” loses. If the gap only appears for one campaign, the fix may be the campaign’s targeting rather than the page.

Put the answer on the first screen

Within a few seconds, visitors should be able to see what you do, roughly what it costs, and what to do next. A good test: time someone who has never seen the site. On articles, put the answer first and the background after it. On product pages, show the price and whether it’s in stock. On lead pages, show the form or the button above the fold, with no slider or second offer competing for attention.

Speed up the slow pages, without breaking them

Speed and bounce rate move together, but the gap in the best data is smaller than most guides suggest. Contentsquare’s 2025 Digital Experience Benchmarks covered 90 billion sessions on 6,000 sites. Pages with poor Largest Contentful Paint had a 53% bounce rate, against 49% for pages with good LCP. That is a correlation across the whole web, using the one-page definition of a bounce. Treat a slow page as a real cause, but don’t expect a fixed percentage back.

Use field data from PageSpeed Insights and look at mobile on its own. Google’s web.dev counts a page as good when LCP is 2.5 seconds or less, INP is 200 milliseconds or less and CLS is 0.1 or less, measured at the 75th percentile of real visits.

On WordPress the usual causes are a hero image several megabytes in size, plugins nobody uses any more, a heavy theme or page builder, cheap shared hosting, and third-party scripts such as chat widgets. Our guide to speeding up a WP site without breaking it goes through each one. The rules that keep speed work from causing new bounces:

• Back up the site first, or work on a staging copy.
• Check what caching your host already does before you add a plugin. Two caching layers can conflict.
• On WooCommerce, keep Cart, My Account and Checkout out of the page cache. WooCommerce’s developer docs list all three.
• Don’t lazy-load the hero image. It is usually the LCP element, so delaying it makes the page feel slower.
• Turn on minification, JavaScript delay and unused-CSS removal one option at a time, and test menus, forms and checkout after each one.
• If the layout breaks with WP Rocket, add ?nowprocket to the end of the URL. WP Rocket’s troubleshooting guide uses that to show whether its optimizations are the cause.
• Run speed tests more than once. The first request after a cache purge is uncached and slower.

If you’d rather not do this work yourself, SiteSelf can fix slow WordPress pages for you from chat, using hosting access, and report what it changed and checked.

Test it on a real phone

A fast page with a menu that won’t close loses visitors just as quickly as a slow one. On a real phone, open and close the menu, submit each form with a deliberate mistake in it, and watch the first screen while the page loads. Look for a cookie banner covering the call to action, or a chat widget pushing the headline down. Content should fit a 320-pixel-wide screen without scrolling sideways, which is the WCAG 2.2 reflow width. Pop-ups that show up before the visitor has read anything, or that are hard to close, cost more than they bring in. If they still earn their place, trigger them on exit intent instead. For layout problems, see making a mobile-friendly website.

Make sure the page loads at all

Broken pages almost never appear in bounce-rate case studies, yet they lose every visitor who reaches them. A 404 from an old link, a redirect loop after an SSL or CDN change, or the “There has been a critical error on this website” screen all show up as bounces. Check Tools, then Site Health, look at your 404s, and open your top landing pages while logged out. If a page throws errors, our guide to fixing WordPress issues without guessing covers how to track down the cause.

Give the visitor a next step

A visitor who isn’t ready to buy still needs somewhere to go. Inside an article, link to the related service or the next question, a few paragraphs in. End with one specific action, such as “Get a quote for your postcode”. Commenters in WordPress forums are skeptical that a sidebar of related posts helps much. Links inside the text get clicked more because they appear right where the visitor has the next question.

How to tell whether the fix worked

Change one thing per page and note the date. Wait until the page has had enough sessions that one quiet day can’t swing the figure, then compare it with that page’s own baseline, split by the same source and device. If you changed the headline, the images and the caching in the same week, you won’t know which change did anything.

Then check the number that matters for that page. If bounce rate drops and calls, leads or orders don’t move, nothing improved for the business. If a new tracking event lowered the bounce rate, nothing improved for visitors either.

Stop and get help if the site shows a critical error, checkout stops working after you changed caching, or you can’t tell whether a plugin or the theme is causing the problem. WooCommerce’s own advice is to test for conflicts on staging, switching to a default theme and reactivating plugins one at a time. On a live store, that is not something to try during business hours.

Frequently asked questions

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