Copy the site, switch the theme on the copy, and walk the pages that are not the homepage. That is the whole method, and the reason it needs writing down is that the advice everybody gives instead, use Live Preview, does not work for block themes.
WordPress has no live preview for an inactive block theme. If you are moving from a classic theme to a block theme, which is the switch most sites are making now, the single most-recommended technique in every ranking guide is unavailable to you.
Why Live Preview is the wrong tool now
Live Preview is the Customizer with a different theme loaded. Block themes do not use the Customizer. Activating one removes Customize, Menus and Widgets from the Appearance sidebar and replaces them with the Site Editor.
So there is no Customizer to borrow, and there is currently no way to preview or customize an inactive block theme. You find out what the theme looks like on your content by activating it.
That is fine on a copy. It is not fine on the site people are reading.
Live Preview is still useful for classic to classic. Even then it only renders the front end, so it cannot show you anything that broke in wp-admin.
What actually changes when you switch
The content is safe. Posts, pages, menus, media and widget content all survive a theme switch, and every guide says so correctly.
What moves is everything that was scoped to the old theme, and that is where the work is.
Customizer settings. WordPress stores them in wp_options under theme_mods_<theme-slug>, one slot per theme. Activate a different theme and it reads a different slot, so your colors, logo and layout options look deleted. They are not deleted. They are in the old theme's row, which is also why switching back restores them and switching to a child theme does not.
Widgets. Different themes register different sidebars. Any widget in a sidebar the new theme does not have goes to the Inactive Widgets box at Appearance, Widgets, still holding its content, assigned to nothing. On a block theme that screen is gone entirely unless a classic widget block is in play.
Menu locations. The menus themselves survive. The assignment does not, because primary in one theme and header-nav in another are different registered locations. The front end renders no navigation, or falls back to a page list, and it looks like the menu was destroyed.
Shortcodes and theme features. Any shortcode the old theme registered stops being defined the moment it is deactivated. The shortcode text then renders literally in the middle of your posts. Learn WordPress puts it plainly: moving to a block theme means CSS modifications and theme exclusive features disappear, including custom page templates.
Custom page templates. A page assigned to template-fullwidth.php keeps that value in _wp_page_template after the switch. If the new theme has no such file, the page silently falls back to the default template, and a full-width landing page comes back with a sidebar.
The list of pages to actually open
The mistake is checking the homepage and calling it done. The homepage is usually the page the new theme was designed against.
Open these, in this order, on the copy:
- A single post with an embed, a gallery and a shortcode in it.
- An archive: a category, a tag, and the author archive.
- Search results, including a search that returns nothing.
- The 404 page. Type a URL that does not exist.
- A page using a custom template, if you had any.
- The comment form on a post that has comments.
- Every page that a page builder made.
- Checkout and My Account, if this site sells anything.
Then do the same set logged out, in a private window. A theme can render an admin bar offset that only exists when you are logged in, and half of the layout complaints after a launch come from that.
The admin side is the half nobody tests
If the switch is classic to block, your editorial workflow changes on the same day the design does.
Someone who edits the site every day loses the Menus screen, loses the Widgets screen, and gains the Site Editor. Menus become a Navigation block edited inside a template. That is a training problem, and it is better discovered by you on a copy than by your editor at 9am on Monday.
Open Appearance and see what is actually there. Then try the one job the person editing this site does most often, whatever that is, and time it.
Do it on a real copy, not an approximation
A fresh WordPress with the new theme tells you the theme works. It tells you nothing about whether it works on your content, and your content is the entire risk.
The failures above are all content-shaped. A shortcode leaking as text needs the post that contains the shortcode. A page template falling back needs the page that used it. An inactive widget needs the sidebar the old theme registered.
Clone the live site into a sandbox and switch the theme there. The copy has the real posts, the real menus, the real theme_mods_ rows and the real plugin set.
Two things worth doing on the copy before you touch the theme:
wp option get theme_mods_twentytwentyone --format=json
wp theme list
Keep that first output. It is the record of what the old theme was configured to look like, and you will want it when you are rebuilding the same settings in the Site Editor. You can run both over SSH into the sandbox, or from the CLI.
If the switch goes badly on the copy, reset the sandbox to a clean install or clone again. Neither costs you anything, which is the point of testing somewhere disposable.
Testing two candidate themes at once
Theme selection is usually a choice between two or three, and switching back and forth on one install is where settings get mangled.
Clone once, save that as a Template, then launch a sandbox per candidate. Each one starts from the same content, and you can put the two front ends side by side in two browser windows rather than from memory.
This is also how to hand the decision to someone else. A URL to a working site is a better review request than a screenshot.
What a sandbox will not tell you
Be honest about the limits, because a clean test that misses the real failure is worse than no test.
- Performance under real traffic. A sandbox is not your production host. Theme render time will differ, and a CDN, a page cache and an object cache are not in the loop.
- Anything your host adds. A server-level cache, a WAF rule, an image optimiser or a host-installed must-use plugin is not in the copy.
- SEO impact. A theme change alters headings, schema and internal linking. A sandbox shows you the markup, not what happens to your rankings.
- Third-party services keyed to your domain. Analytics, ad code and anything with a licensed domain will behave differently or not at all.
- Email. A cloned site carries your real user table. Do not let it send.
And one thing a sandbox is genuinely the wrong tool for: the actual cutover. When you are ready to go live, do the switch on your live site in a low-traffic window with a current backup, not by pushing the sandbox over the top of production. The sandbox is for finding out what you will have to fix, and for building the list of fixes in advance.
The short version
Copy the site. Switch the theme on the copy. Open the archive, the 404, the search page, a page-builder page and a post with a shortcode in it, logged in and logged out. Save theme_mods_<old-theme> before you start.
Then decide, with a list of what breaks in your hand, whether the switch takes an hour or a weekend. That number is the thing you actually wanted to know.
