Blog

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

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