The Most Customisable Theme Is Usually the Hardest to Leave
Every setting a theme adds is a setting stored in that theme's own options, and lost the day you switch. Option count is a measure of lock-in as much as of flexibility.
"Most customisable" almost always means "hardest to leave". Every option a theme adds is a value stored in that theme's own settings, meaningful to nothing else. A theme with two hundred controls has given you two hundred pieces of configuration that evaporate the day you switch.
That is the trade nobody puts on the sales page, and it is the whole of this decision.
Three kinds of customisation, and what happens to each
| Kind | Where it is stored | Survives a theme switch |
|---|---|---|
| Theme options and Customiser settings | Theme mods, keyed to that theme | No |
| Content — blocks in the post | The post itself | Yes |
| Content — page-builder layouts | Post meta, in the builder's format | Only while that builder stays |
| Global styles in a block theme | Database, keyed to the theme | No, but exportable |
| Child theme templates and CSS | Your own files | Depends on what it targets |
The pattern is clear once it is laid out. Configuration dies. Content lives. Code lives if you wrote it against your own markup rather than the parent theme's class names.
So the practical question is not "how much can I change" but "how much of what I change am I going to lose". A theme that pushes design decisions down into content and up into standard tokens is more customisable in the sense that matters, even if its options panel is a single screen.
Why option count is a bad proxy for flexibility
Options are frozen decisions. Someone at the vendor decided that you can set the header height but not the header structure, that there are five blog layouts but not a sixth. You can customise precisely what was anticipated, and nothing else.
The costs are real and compound:
- Output bloat. Options panels usually render as inline CSS in the head, a block of rules generated from every setting whether it differs from the default or not.
- Diagnosis becomes archaeology. When a heading is the wrong size, the cause could be a global setting, a per-post override, a builder value or a stylesheet. Four places to check instead of one.
- Update fragility. Vendors restructure their options between major versions, and settings quietly stop applying.
- Nothing is documented for the next person. A site configured entirely in a proprietary panel cannot be handed over except by clicking through it.
A theme with a tight, well-chosen set of controls and clean templates is more workable at year three than one that promised unlimited possibilities at week one.
What actually makes a theme customisable
- Predictable, semantic markup. If you can write
.entry-content h2and have it hold, you can restyle anything. If the theme emits generated class names, you cannot. - Low specificity. No
!importanton typography, no long selector chains you have to out-rank. A theme that fights your CSS is not flexible, whatever its feature list says. - Design tokens rather than per-element settings. Colours, type scale and spacing defined once in
theme.jsonand referenced everywhere beats a colour picker per section. - Template parts and hooks you can override in a child theme without copying the whole file.
- Editor parity. What the editor shows is what the front end renders. Where these diverge, every layout change becomes trial and error.
Block themes genuinely changed the answer
With a block theme, the header, footer and templates are editable as blocks and stored in the database rather than in a settings panel. Global styles sit on top of the theme's theme.json defaults.
Two honest caveats. Those user changes are still keyed to the theme, so switching does not carry them across — but they can be exported as files, which no options panel offers. And the ceiling is lower: precise, art-directed layouts are harder here than in a mature builder.
If you want the maximum portable version of this, building your own block theme turns your customisation into files you own outright.
Custom CSS is the most portable customisation there is
A stylesheet targeting your own block class names and content selectors will keep working across themes, updates and rebuilds. It is the one layer nobody can take away from you. Keep it in a child theme or a code plugin rather than a theme's own CSS box — see adding custom CSS — because the theme's box goes when the theme does.
How to choose
Take the design you want and the theme you are considering, and estimate how much of the default you would have to override. If the answer is "most of it", no amount of options will rescue that pairing — you have picked the wrong starting point, and every setting you touch is another thing to rebuild later.
Pick the theme closest to your intended design with the smallest settings surface, put everything you can into content and tokens, and read how to change a WordPress theme before you commit — knowing what a switch costs is the fastest way to see which customisations are worth making. The mechanics of each layer are covered in customising a WordPress theme.
Frequently asked
- No. Theme options, including the ones set in the Customiser, are stored per theme and have no equivalent in the next one. Only content and your own CSS or child-theme code have any chance of surviving.
- It gives finer visual control over individual pages, at the cost of storing that layout in a format only that builder can read. A block theme gives less pixel-level control and produces markup that any future theme can still render.
- If your stylesheet is mostly overriding the theme rather than adding to it, you picked the wrong theme. Fighting a theme's defaults with specificity works until the next update changes the selectors underneath you.