A customer sent us a support message that turned out to be the most common WordPress question nobody writes a good answer to. They had followed a tutorial that said to open Appearance and click Customize. There was no Customize link. They assumed their install was broken. It was not: they had activated a block theme, and WordPress had quietly removed the menu item.
WordPress now has four separate places where a theme’s appearance can be changed, and which ones exist on your site depends on which kind of theme you activated. Nothing tells you this. The fix is not a longer tutorial, it is knowing which route you are on before you start.
First, Find Out Which Kind of Theme You Have
Everything below depends on this one answer, and it takes about five seconds to get.
Open your WordPress dashboard and look at the Appearance menu. If you see an Editor item, you are running a block theme. If you see Customize instead, you are running a classic theme. If you somehow see both, a plugin has re-registered the Customizer on top of a block theme, and the Editor is still the one you want.
That single menu item decides which of the four customisation surfaces you get, which of them will survive a theme update, and whether the tutorial you are following applies to you at all.
Block themes are no longer a fringe choice. On 4 September 2026 the WordPress.org directory listed 8,562 themes in total, of which 1,802 were block themes built for the Site Editor. If you install something popular and current, the block theme route is now the likelier one.
Also Read: What Is a WordPress Block Theme? explains what changed under the hood and why the two theme types behave so differently.
Route One: Block Themes Use the Site Editor
If you have a block theme, go to Appearance then Editor. WordPress defines the Site Editor as the experience that lets you directly edit and navigate between templates, template parts and styling options in one place. In practice it is the only surface you need for the large majority of visual changes.
The two areas worth learning first are Styles and Templates. Styles controls the site-wide design system: colour palette, typography, spacing and the default appearance of each block type. Templates controls structure: what a single post looks like, what an archive looks like, and the reusable header and footer that WordPress calls template parts.
The important habit is to make changes in Styles rather than on individual blocks. Setting your heading colour once in Styles applies it everywhere and keeps applying it to content you have not written yet. Setting it on one heading styles one heading, and you will be repeating yourself for the life of the site.
- Site-wide look: Editor, then Styles.
- Page and post structure: Editor, then Templates.
- Header and footer: Editor, then Patterns, then Template Parts.
- One-off tweak on a single page: edit that page directly, not the template.
Route Two: Classic Themes Still Use the Customizer
If your Appearance menu shows Customize, you are on a classic theme and the Customizer is your primary surface. It is not deprecated and it is not going away for the themes that rely on it. It gives you a live preview pane, a set of panels supplied partly by WordPress and partly by your theme, and a publish button that applies everything at once.
What the Customizer offers varies enormously between classic themes, because most of its panels are registered by the theme itself. This is why two tutorials for two different classic themes can describe completely different options and both be correct.
One panel is worth knowing about regardless of theme: Additional CSS. It is a safe place for small style overrides because it lives in the database rather than in theme files, which means a theme update cannot overwrite it. We come back to that below.
Where the Customizer Went, and Why
For the customer who thought their site was broken, this is the actual answer. WordPress removes the Customizer from the Appearance menu when a block theme is active, because block themes are meant to be customised in the Site Editor instead.
There is one exception, and it explains the confusing cases. If any active plugin registers a callback on the customize_register action, WordPress puts the Customize menu item back so that plugin’s settings remain reachable. That is why a block theme site can still show a Customizer, usually with only one or two panels in it, and why the same block theme can look different on two sites.
So if you are on a block theme and the Customizer appears, treat it as a plugin’s settings screen rather than as your theme’s control panel. Your theme’s controls are in the Editor.
Style Variations: The One-Click Restyle Most People Miss
This is the highest-value feature in the Site Editor and the one most people never open. Style variations are alternative versions of a theme’s design configuration that ship with the theme. The official documentation describes them as skins for your theme.
You find them under Editor, then Styles, then the Styles sub-screen, where they appear as a grid of previews. Clicking one restyles the entire site, colours and typography together, without touching a single block. If your theme ships six variations, you have six coherent designs available immediately, each designed by whoever built the theme rather than assembled by you.
There is one consequence worth understanding before you commit. When you select a variation, that configuration is copied into your site’s database as a user customisation. It stops tracking the theme from that point, so later changes the theme author makes to that variation will not reach you unless you switch variations again. That is a reasonable trade, but it should be a decision rather than a surprise.
Also Read: Web Design Trends 2026 shows what a modern design system built on these controls actually looks like in Gutenberg.
What theme.json Already Decided for You
Behind the Site Editor sits a single file called theme.json. You do not need to edit it, but understanding what it does explains most of the moments where the editor seems to be fighting you.
The WordPress documentation calls it a foundational piece of block theming, covering everything from configuring colours to defining default typography to applying front-end styles. It is where the theme declares its palette, its font sizes, its spacing scale and which controls it wants to expose to you at all.
This is the answer to two frequent complaints. If a colour picker only offers eight colours, the theme declared eight colours in theme.json. If a control you saw in a tutorial is missing, the theme turned that setting off. Neither is a bug, and neither is fixed by hunting through the interface. It is fixed by choosing a theme with a broader configuration, or by overriding it deliberately.
When You Actually Do Need Code
Some changes genuinely fall outside the visual controls. When that happens, the question is where to put the code so that a theme update does not erase it. There are three options and they are not equivalent.
- Additional CSS in the Customizer, or a custom CSS field if your theme or a plugin provides one. Stored in the database, survives theme updates, correct for small visual overrides. Start here.
- A child theme. A separate theme that inherits from the parent, so your edits live in files the parent update will not touch. Correct when you are changing templates or adding functions, and heavier than most people need for a colour change.
- Editing the theme’s own files. The next update overwrites your work. Avoid this.
The distinction people get wrong is the second one. A child theme is the right tool for template and function changes and the wrong tool for twenty lines of CSS, where it adds a maintenance burden for no benefit.
Also Read: WordPress Code Snippets Plugin vs Child Theme compares the child theme route against a code snippets plugin for anything involving PHP rather than CSS.
What Survives a Theme Update
This is the part worth keeping. Every customisation you make lands in one of two places, and only one of them is safe.
- Survives: Site Editor changes to Styles and Templates, selected style variations, Customizer settings, Additional CSS, and anything in a child theme. All of these live in the database or in a separate theme.
- Does not survive: anything you typed directly into the parent theme’s files.
The one genuine risk is not updates but theme switching. Site Editor customisations are stored against the active theme, so changing themes leaves them behind. They are not deleted, and reactivating the old theme brings them back, but the new theme starts from its own defaults. Plan a theme switch as a rebuild rather than a swap.
If you are choosing a theme now with all of this in mind, the practical filter is how much the theme exposes through theme.json and how many style variations it ships, because those two things determine how far you can go before you need any code at all.
Suggested Reading
- The WordPress Site Editor: A Complete Guide to Full Site Editing
- What Is a WordPress Block Theme?
- WordPress Block Themes vs Classic Themes: 6 Key Differences
- How to Choose a WordPress Theme: 10 Key Factors
- How to Use Variable Fonts in WordPress
