Classic theme to block theme without a big-bang relaunch

Many established WordPress sites still run on classic themes or page builders. Moving to a block theme brings faster pages and an editing experience that’s built into WordPress, but nobody wants to freeze their site for months while it’s rebuilt. The good news is you don’t have to. WordPress lets a site move to blocks in stages, and visitors never need to see the seams.

Why move at all

Speed. Page builders add a lot of CSS and JavaScript to every page. Block themes load styles per block, so a page only carries what it actually uses.
Longevity. The block editor is where WordPress is heading. Classic themes and many page builders get less attention every year, and a site tied to one builder is tied to that vendor’s roadmap and pricing.
Consistency. A theme.json file acts as the design system. Colors, fonts, font sizes and spacing are defined once and offered to editors as presets, so pages stay on brand without anyone memorizing hex codes.
Editing in one place. Headers, footers and templates become editable in the Site Editor (Appearance, then Editor), instead of living in PHP files only a developer can change.

None of this is a reason to panic. A healthy classic theme will keep working for a long time. The case for moving is strongest when you are already planning work: a redesign, a performance push, or replacing a page builder you’re unhappy with.

Start with an audit

Before any code changes, we take stock. This step is what makes a staged move possible, because it tells you what depends on what.

Templates in use. List the template files the theme has and which ones actually render pages. Many classic themes carry templates nothing uses.
Content by editor. Count posts and pages built with the classic editor, with blocks, and with a page builder. A quick query on post content and post meta usually shows the split.
Shortcodes. Search content for every shortcode tag and note which plugin owns it.
Widgets, menus and sidebars. Note where each one appears.
Custom fields. Note which templates print values from custom fields, such as an event date or a staff title.
Traffic. Pull your top pages from analytics so you know which ones to convert first and which can wait.

We also crawl the site at this point and save the results (URLs, titles, meta descriptions, canonical tags, headings). That baseline is what we compare against after each stage to make sure nothing SEO-related slipped.

A staged approach

Build the design system first. Add a theme.json to the existing classic theme with your current colors, fonts and spacing. Classic themes can use theme.json too, so new blocks immediately match the site and editors get the right palette, with no visible change for visitors.
Lock down the editor while you’re there. In theme.json, turning off custom colors and custom font sizes keeps editors on the presets you just defined. This alone cuts down on one-off styling.
Rebuild templates one type at a time. Start with something low-risk, like blog posts. Then move to pages, then archives, then the home page. Develop the block templates and template parts (header, footer) in the new theme on a staging site, comparing each against the live version.
Convert content gradually. Old pages can keep their classic content while new pages use blocks. WordPress handles both: classic content shows up inside a Classic block, and its toolbar offers “Convert to blocks” when you’re ready. Convert pages when they need an edit anyway, rather than all at once.
Replace builder pages last. Page-builder layouts are the slowest to convert, because they don’t map neatly to blocks. Do the most visited pages first and leave archived ones for later.
Switch themes on staging, then live. Once templates cover every content type, activate the block theme on staging, run the crawl again, compare it to your baseline, and then switch production.
Remove the old theme code once nothing depends on it, including leftover builder plugins and their stored settings.

Depending on the site, there’s often a hybrid period where a classic theme adopts theme.json and some block-based pieces before the full switch. That’s fine. What matters is that every stage ships on its own and leaves the site in a working state. It also means a site that publishes every week never needs a content freeze.

Watch out for

Shortcodes from old plugins. The Shortcode block still renders them, so nothing breaks on day one, but each one is a dependency on that plugin. Replace them with blocks or patterns over time.
Page-builder leftovers. Some builders store layouts as shortcodes in post content. Deactivate the builder and those pages can fill with raw bracketed code. Never deactivate a builder until every page using it has been rebuilt or checked.
Widgets and sidebars, which become template parts or blocks in the template. Widget-only plugins may need a replacement.
Custom fields used in templates. These may need a small custom block, or the Block Bindings API, which lets core blocks display post meta without custom code for simpler cases.
Menus. Classic menus can be imported into the Navigation block, but check the result, especially mega menus and any menu items added by plugins.
Tracking. Make sure your tag manager snippet, consent banner and any inline scripts are carried into the new header template. This is easy to miss and expensive to discover a month later.

What it looks like to visitors

Ideally, nothing at all, until the day you choose to refresh the design. The structure changes underneath while the site keeps running and ranking. URLs stay the same, titles and meta stay the same, and pages tend to get lighter as builder assets drop away.

As for effort, a small brochure site with clean classic content can move in a few weeks. A large site with years of page-builder content takes longer, but the staged approach spreads that work out instead of stacking it into one risky launch.

When to bring us in

If your site is small and mostly classic-editor content, a capable in-house developer can follow the steps above. Where we help most is with page-builder conversions, custom fields and plugins that need block replacements, and sites where downtime or lost rankings aren’t an option. Our custom Gutenberg theme work covers the whole path, from design system to final cleanup. If you’d like an honest read on how big your migration really is, let us know.