The difference between block and classic WordPress themes becomes clear when you change something outside a post. Both can support the block editor for writing pages. Changing a shared header, a site-wide colour, or navigation, however, takes you through different controls. Those differences matter when choosing a theme for an existing site.
Start with templates
A classic theme defines page structure mainly through PHP templates. Its developer decides what editors can change through the Customizer, menu and widget screens, or theme settings. A block theme defines templates as block markup and exposes them in the Site Editor. The WordPress Block Editor Handbook explains both template formats. A classic theme can still support block content and some block settings.
Seeing blocks in a post therefore does not mean you can edit its header as blocks. In a classic theme, the post editor controls content within a template whose surrounding layout may remain in theme files. In a block theme, the Site Editor can expose templates and shared template parts, including headers and footers. WordPress’s block theme documentation explains this wider editing scope.
Before saving a change, identify its scope. Editing a heading in one post differs from changing a post template. Editing a shared header can affect several kinds of page. Preview the routes that use the part you changed, including a typical post and any special page layout.
Start by finding which template the page uses. A homepage, a single post, and an archive may each have their own layout. If the change belongs on one page, edit that page or choose an appropriate template for it. If it belongs on every post, change the shared post template instead. In the Site Editor, check whether a header or footer is a shared template part before rearranging it. In a classic theme, ask whether the relevant layout is controlled by a template file or an editor-facing theme setting. This small check prevents a local request from becoming an unintended site-wide change.
Changing a header and navigation
Suppose the logo needs more room and a new page belongs in the main navigation. With a classic theme, first check its available controls. The logo may be in the Customizer, while a menu screen or Customizer panel may manage links. A widget area might supply another header element. Moving the logo beside a button could require a template or stylesheet change if the theme offers no suitable control.
With a block theme, open Appearance → Editor and find the header template part. Select its blocks to adjust the logo, spacing, or arrangement. Edit links through the Navigation block or the editor's Navigation area. The Site Editor guide describes template parts, navigation, and the save review that identifies affected parts.
In either case, inspect the rendered header. A different template may use a different header. Test a long menu label and a narrow screen, then follow the links. A tidy editor view does not establish that the mobile menu opens, closes, and stays readable. After switching themes, check visible links and their order: a classic theme's menu location does not guarantee the same presentation in a block theme.
Changing a site-wide style
For a heading colour change in a classic theme, look for a control in the Customizer or theme settings. Some themes expose a heading colour; others offer only a general palette. If the control is absent, the change may need CSS or a theme file edit. Check existing custom CSS before adding an override.
In a block theme, open Styles in the Site Editor and look for colours or settings for the Heading block. A change there can apply across the site; styling one selected heading affects that instance. Review several real pages, especially headings in dark headers, coloured sections, and plugin output. A general colour rule may not suit every context.
A theme's theme.json file can define starting settings and styles, including palettes, typography, and available block controls. Its presence alone does not identify a block theme: the WordPress Theme Handbook says it works with classic themes too. Check the controls on the actual site rather than inferring the editing workflow from one file.
Check how the proposed colour interacts with links, buttons, and backgrounds rather than reviewing an isolated heading. On a classic theme, a CSS rule aimed at all headings can override colours that individual pages need. In a block theme, a global style can have the same broad effect. Keep a short record of the original setting and the pages checked, so another editor can understand the change and reverse it if a missed layout becomes unreadable.
Widgets and the Customizer
Classic themes often define widget areas such as a sidebar or footer. Editors place content in those areas, while the theme decides where they appear. In a block theme, comparable layout work happens in templates and template parts. Find the part that renders the area and check its output; an old widget does not automatically become an equivalent block.
The Customizer is generally unavailable with a block theme unless a theme or plugin activates it. Most layout and style work moves to the Site Editor, although a plugin may still expose a Customizer control. For a site with existing settings, note where each important control lives before replacing the theme.
Switching an existing site
A theme switch changes presentation and editing controls; it does not convert old templates. Posts and pages remain available, but the replacement supplies its own layouts. A classic theme's PHP header, page templates, widget areas, and menu locations do not turn into matching block templates. The Learn WordPress switching tutorial recommends checking visual changes, theme-specific features, menus, widgets, and plugins before switching a live site.
Inventory the parts that could be affected: pages with special templates, each navigation area, widget-dependent content, custom CSS, shortcodes, and theme-specific features. Include representative posts and pages as well as the homepage. On a staging copy, activate the proposed theme and mark each item as present, needing rebuilding, or no longer required. Compare rendered pages with the originals after rebuilding shared parts.
Check plugins by task, not merely by whether they remain active. A form, listing, or shortcode may still exist but no longer appear in its previous position. Submit a test form where appropriate, inspect custom content, and follow a visitor action to its visible result. Keep a restorable backup before changing the public site.
Make the comparison at more than one screen width. Inspect a long article, an archive with several entries, and any page whose layout differs from the default. Check heading order, navigation labels, sidebars, and footer content as well as appearance. If a feature is missing, record whether it came from the old theme, a widget, a plugin, or custom code before rebuilding it. That distinction tells you what must be recreated and what might simply need a new placement. Repeat the same checks after the replacement is configured; a successful activation is only the start of the review.
Choosing the editing model
- Editors often rearrange shared layouts: trial a block theme. Confirm they can distinguish a page edit from a template or template-part edit and review the affected routes.
- Editors mainly publish posts: a classic theme may already provide all necessary controls. Try the actual publishing tasks and document how occasional structural changes are made.
- The site depends on PHP overrides, widget placements, or theme-specific features: assess those dependencies on staging before choosing a replacement.
- The team wants block settings without rebuilding templates: check what the current classic theme supports, including its block controls and theme.json settings.
A useful trial is to change a header, adjust a global heading style, update navigation, and inspect a plugin-dependent page. Record where each change was made, what else it affected, and how the rendered result behaved. That evidence shows what editors will actually manage after a switch.