
"Custom WordPress theme" is one of the most overloaded phrases in the agency world. It gets stamped on a $4,000 recolor of Astra and on a $60,000 enterprise build with equal confidence. The problem isn't that agencies are uniformly dishonest — it's that the word "custom" stopped having one clear meaning the moment WordPress shipped Full Site Editing. In 2026 you can produce a genuinely one-of-a-kind site without writing a single line of PHP, and you can also write ten thousand lines of code that still inherit half their behavior from a parent. So the useful question isn't "is it custom?" It's "which layer was customized, and who owns it afterward?"
Forget the old "child theme vs. starter vs. from-scratch" ladder for a moment. That ladder describes how much code exists, which used to be a good proxy for customization but no longer is. A more honest way to read a theme is by which of three independent layers actually carries the work.
This is typography, color, spacing, layout, and the arrangement of templates. Since FSE matured, this layer can be fully owned by the site without touching code at all. A designer working in the Site Editor can rebuild every template, define a global color palette and type scale in Global Styles, and assemble unique synced patterns — then export the result as a self-contained block theme. The output looks nothing like its starting point. By any reasonable visual standard, that is a custom design.
This is custom post types, custom blocks, query logic, integrations, REST endpoints, and anything in functions.php or a companion plugin. A site can have a wildly custom design and almost no custom code (pure FSE), or boring stock styling sitting on top of a large bespoke codebase (a membership platform, say). These two layers genuinely decoupled around the block-editor transition, and most "is this custom?" arguments are really two people pointing at different layers.
This is the one that actually shows up on your invoice later. Does the theme inherit updates from a third party, or does every WordPress core release become your problem? A child of GeneratePress gets security and compatibility fixes from its developer automatically. A from-scratch theme gets fixes from whoever you can still reach. Ownership is the layer agencies are least likely to talk about up front, and the one that costs the most over a five-year horizon.
With those layers in mind, here are the builds you'll actually encounter, including two the old taxonomy missed entirely.
theme.json, exported as a standalone theme. The design layer is fully owned, the code layer is essentially empty, and ownership is clean because there's no parent. This category did not meaningfully exist five years ago and is now common.theme.json for global styles while keeping functions.php and traditional templates. Increasingly the pragmatic middle ground, and a category the old child/starter/scratch model has no bucket for.You can usually classify a finished site in a few minutes without the agency's cooperation. Start at /wp-content/themes/ and read the slug.
If the slug is a recognizable product — astra, generatepress, kadence, oceanwp, twentytwentyfive — look for a sibling child directory like astra-child or {name}-custom. That pairing confirms a child build: the parent supplies nearly all behavior, the child overrides specific pieces.
Then determine classic vs. block, because that's the modern fault line. Crack open the theme folder and look for these signatures:
theme.json at the theme root, a /templates/ directory full of .html files, plus /parts/, /patterns/, and often a /styles/ folder holding alternative style variations.header.php, single.php, page.php), a substantial functions.php, and no root theme.json.theme.json — the giveaway that someone bolted modern global styles onto an older architecture.For starter detection, the old tells still hold. Read the style.css header: Underscores-based themes frequently leave the original _s Author URI pointing at automattic.com unless someone changed it. Sage shows itself through structure — an app/ directory and Composer dependencies (composer.json, a vendor/ folder). A Bedrock-based site moves WordPress into web/app/ rather than the usual wp-content/ layout. File count remains a crude but useful gauge: under about 20 files smells like a child theme, 50–200 like a starter build, and 100–500 for a complex from-scratch theme.
One caveat unique to the block era: a heavily rewritten theme.json on a child of Twenty Twenty-Five can represent real, valuable customization that the file-count heuristic completely misses — a 30-file theme can still be deeply bespoke at the design layer. Count files to spot a thin recolor, not to measure craft.
Each category buys you something and bills you for something else.
Child and hybrid themes are fast to ship and cheap to maintain because the parent absorbs WordPress compatibility work. The cost is a ceiling: if the parent drops a feature or makes a breaking change in a major release, your overrides can break with it, and you're at the mercy of someone else's roadmap.
FSE block themes give you a clean, parent-free design layer and travel well — global styles and patterns are portable, and you're aligned with where WordPress core is actually heading. The catch is that the block ecosystem still has rough edges, and some interactions that were trivial with PHP hooks require a custom block or a bit of plugin code to express.
Starter and from-scratch themes hand you total control and zero inherited surprises — and make every core update a manual review job. Underscores hasn't seen meaningful upstream maintenance from Automattic in years; sites built on it still run, but keeping pace with core is now your ongoing cost. That recurring maintenance is the line item most often missing from the initial bid.
A defensible answer: a theme is "custom" to the degree that a layer was meaningfully built rather than inherited — and you should always ask which layer. A pure FSE build with a hand-crafted theme.json is a custom design even with no code. A child theme with three hundred lines of CSS is a custom skin, not a custom theme, however it's sold. A starter or scratch build is custom code, and you're buying the maintenance obligation that comes with it.
For the small-business sites that get sold "custom themes," a child of a strong parent — or an exported FSE block theme — covers the large majority of real needs at a fraction of the price. The genuinely from-scratch cases usually know who they are because a hard constraint forced the decision. The expensive grey zone is the "custom theme" that's quietly a recolored Astra. None of this tells you what to build next, though: that depends on your timeline, your team's comfort with blocks versus PHP, and how much maintenance you're willing to own for the next five years. The category is where the conversation starts, not where it ends.
Site
Tools
We do not sell your email. We do not spam.
© 2026 RevealTheme. All rights reserved.