Switch themes from wp-admin → Appearance → Themes, and do it on a staging copy first, not live. If the new theme doesn't support the block editor cleanly, don't force it with a page builder plugin as your first move. Preview it, check your key templates, and only then activate on the real site.
Preview before you activate
WordPress lets you preview a theme against your actual content before switching. From Appearance → Themes, use the theme's preview option (or install it first if it's not already on the site, via Add New Theme or upload a zip). The preview loads your site's real content inside the new theme's templates, so you can catch obvious breakage, like a menu that disappears or a homepage layout that collapses, before any visitor sees it.
Preview is a start, not a guarantee. Some problems (broken shortcodes, missing widget areas, custom fields that don't map to the new theme's templates) only show up once you're actually browsing the live site with real traffic hitting it. That's what staging is for.
Do the actual switch on staging
Back up first. Take a backup before you touch anything, the same rule as any WordPress change (see Updating WordPress safely). Then work through it on a staging copy: Using WordPress staging covers creating the copy and the safe promote-to-live workflow.
On staging:
- Activate the new theme.
- Walk every template type: homepage, a blog post, an archive/category page, a static page, search results, and 404.
- Check navigation menus, widget areas, and footer content. Themes assign menus and widgets to their own named locations, and a new theme won't inherit the old theme's slots automatically. You'll likely need to reassign menus under
Appearance → Menusand re-add widgets underAppearance → Widgets(or the equivalent block-based template parts, depending on the theme). - If you sell anything, walk the cart and checkout flow. Theme CSS conflicts with WooCommerce templates are a common source of layout breakage that doesn't show up on a simple content page.
Once it looks right, promote staging to live. Keep the gap between your last live backup and the push short, since anything that changed on the live site in the meantime (new orders, new posts, new comments) isn't in the staging copy you're about to push over it.
Block editor first, page builder only if you need it
If your content was built with the core block editor (Gutenberg), most theme switches are low-risk: blocks render using the new theme's styles, and you're mostly checking spacing, colors, and typography rather than rebuilding pages. Stick with the block editor when you can. It's the path WordPress itself is designed around, and it doesn't tie your content to one theme's page-builder markup.
If your site is built with a page builder (Elementor, Divi, WPBakery), be aware the builder's layout data is often stored as builder-specific markup, not portable blocks. A new theme won't necessarily break that markup, but builder-generated CSS and a new theme's CSS can conflict, especially around container widths, typography defaults, and button styles. Test builder-heavy pages carefully on staging, and expect to spend time on manual style fixes rather than a clean swap.
Themes advertised as "block theme" or "full site editing" ready work best with pure block content. If you're moving toward one of those, converting page-builder content to core blocks first (a manual rebuild, not an automated one) will save you trouble on every future theme change, not just this one.
Child themes, if you're customizing
If you plan to edit the new theme's CSS or template files directly, use a child theme rather than editing the parent theme's files. A child theme inherits the parent's templates and styles but keeps your customizations in separate files, so a theme update doesn't wipe out your changes. Most reputable themes ship with a child theme or documented instructions for creating one. If you're only adjusting colors and fonts through the Site Editor's global styles (block themes) or the Customizer (classic themes), you don't need a child theme for that, those settings are stored in the database, not the theme files.
After you activate on live
Once the new theme is live, caching can mask problems or hide the fact that your changes took effect. Confirm the changes are actually visible (see How we make your site fast) before you declare victory. Then reload the live site in a private/incognito window to confirm what visitors actually see.
If the site looks broken immediately after activating, deactivating the theme from wp-admin → Appearance → Themes and switching back to the previous one (or a default theme, if admin access itself is broken) is the fastest way back to a working state while you figure out what went wrong. Keep that backup you took at the start handy as the real fallback if switching back through the admin doesn't fully undo the damage.
When to contact support
If the switch takes down the site in a way you can't undo through the admin, or you're not comfortable running the staging workflow yourself, open a ticket from the portal's Support section. It reaches a real person, and you can use the secure-share panel on the ticket to hand over credentials safely if they need to look at the account directly.