WordPress Theme Switching: What Survives And What Doesn't

WordPress theme switches are presented as straightforward operations: activate the new theme, the content stays, the design changes. The reality is more nuanced. Specific things survive the switch; specific things don't. Understanding the distinction before switching prevents painful surprises.

The pattern that produces clean theme switches involves an audit before the switch and a recovery plan for what gets lost. Sites that switch themes without this discipline often discover problems for weeks after the change.

What survives the theme switch

Post and page content. Stored in wp_posts, not affected by theme. All articles, pages, and custom post type content remain.

Custom field data. Stored in wp_postmeta, not affected by theme. ACF fields, Meta Box fields, custom field values all persist.

Media library. Stored in wp_posts (as attachments) and on disk. Images, documents, media files remain accessible.

Users and permissions. Stored in wp_users and wp_usermeta, not affected by theme.

Settings configured through WordPress Settings menu. Stored in wp_options. General settings, reading settings, writing settings persist.

Plugin settings (mostly). Most plugin settings are stored in wp_options or plugin-specific tables. They survive theme changes.

Categories, tags, and other taxonomies. Stored in the term tables, not affected by theme.

What doesn't survive the theme switch

Customizer settings. Most customizer values are theme-specific. The new theme doesn't read the old theme's customizer values. Colors, fonts, header layout, footer layout all reset to the new theme's defaults.

Widget assignments. Widgets in sidebars are assigned to specific sidebar IDs. The new theme may not have the same sidebars; widgets get assigned to "Inactive Widgets" and have to be manually re-added to the new theme's sidebar areas.

Menu locations. The old theme had menu locations like "Primary Menu" and "Footer Menu". The new theme has its own menu locations. The menus themselves persist, but their assignments to display locations get cleared.

Theme-specific custom content. Some themes store content in theme-specific places (theme options pages, custom database tables, theme-specific custom post types). This content doesn't transfer.

Theme-specific shortcodes. If the old theme defined shortcodes like [previous-theme-button], those shortcodes don't work in the new theme. Content using them renders the literal shortcode text.

Header and footer customizations. Most themes provide their own header and footer; the customizations to the old theme's header/footer don't carry over to the new theme.

What partially survives

Page layouts built with the old theme's tools. If the old theme had a custom page builder or layout engine, those layouts might render incorrectly in the new theme. The content is there but the visual structure depends on the old theme's CSS/JS.

Custom post type displays. The post types themselves persist, but their display templates depend on the new theme. If the new theme doesn't have templates for the custom post types, they may fall back to default layouts.

Featured image displays. The featured images are stored as post meta, but their display (sizing, positioning) depends on theme templates. The new theme may handle them differently.

The pre-switch audit

Before switching themes, document the current state:

1. Customizer settings: screenshot all customizer sections. Note custom colors, fonts, layout choices.

2. Widget configurations: screenshot each widget area showing assigned widgets and their settings.

3. Menu assignments: note which menu is assigned to which menu location.

4. Theme options pages: if the old theme has its own options page, screenshot or export all settings.

5. Custom CSS: copy any custom CSS from the Customizer's Additional CSS section.

6. Shortcodes in use: search content for theme-specific shortcodes that might break.

7. Page builder content: identify pages built with the old theme's page builder or layout engine.

The audit takes 30-60 minutes for a typical site. It produces a recovery plan that's invaluable when the new theme is active and things don't look right.

The staging discipline

Never switch themes directly on production. The pattern:

1. Create a staging copy of the production site (most quality hosts include one-click staging).

2. Activate the new theme on staging.

3. Reconfigure all theme-specific settings on staging.

4. Walk through the entire site on staging, verifying that every page renders correctly.

5. Identify everything that doesn't work and fix it on staging.

6. Once staging is fully functional, deploy to production.

The staging discipline catches issues before they affect real users. A theme switch done directly on production can leave the site broken for hours while problems get identified and resolved.

The plugin compatibility check

Some plugins integrate tightly with specific themes. Examples:

Page builders that depend on specific theme integrations.

WooCommerce themes with custom checkout layouts that depend on theme support.

Membership plugins that have theme-specific styling.

SEO plugins that depend on theme-specific schema integration.

Before switching, check that each plugin works with the new theme. The plugin's documentation usually lists supported themes; the plugin's support might confirm compatibility.

The performance comparison

Theme switches sometimes change page performance significantly. The new theme might be heavier or lighter than the old one. Test performance before and after on representative pages.

If the new theme is heavier, you may need to disable or replace features that affect performance most: bundled animation libraries, heavy slider scripts, complex layout engines.

The performance impact compounds with content. A theme that adds 100KB of CSS per page affects every page across the site.

The case where switching is worth it

The current theme is being abandoned by its developer. Continuing to use an unmaintained theme accumulates security and compatibility risk.

The current theme is genuinely outgrowing the site's needs. The site has expanded to needs the theme doesn't support, and customizing the theme to fit costs more than switching.

The current theme has serious performance issues that can't be addressed within the theme's structure.

The site is being redesigned anyway. Switching themes during a redesign is appropriate because the redesign work absorbs the switch overhead.

The case where switching isn't worth it

The current theme works adequately but you saw a prettier demo for another theme. The switch cost is real; the benefit of "looks better" is subjective.

The site has heavy investment in theme-specific customizations. The switch loses those customizations; recreating them costs significant time.

The team isn't ready to handle the switch logistics. Switching themes mid-quarter while many other things are happening multiplies the friction.

The honest framing

Theme switches are real projects, not configuration changes. Treating them as projects (with planning, staging, verification, rollback plan) produces better outcomes than treating them as quick switches.

The investment that pays off: planning the switch like any other site change. Audit before, stage, verify, then commit. The discipline prevents extended periods of broken UI that frustrate users and damage trust.

For sites where the current theme works, the default should be to keep it. For sites where the current theme genuinely doesn't fit anymore, the switch should be planned carefully rather than executed impulsively.