What a custom WordPress theme is, and when you need one

A theme decides what your pages are made of. A custom one means that decision was made for your site rather than for a marketplace of ten thousand sites, and it is the difference between a site that does what you need and a site you spend two years working around.

There are three ways to build one, and the honest answer is that the right choice depends on who edits the site afterwards.

Block theme, classic theme, page builder

A block theme is, in WordPress’s own words, “a theme that uses blocks for all parts of a site”: navigation, header, content and footer. It is edited in the Site Editor, and its styling runs through a single file called theme.json, which the Theme Handbook calls “a foundational piece of block theming.”

theme.json is where colours, type scale, spacing and layout widths are declared once. WordPress turns those declarations into CSS custom properties with a predictable naming scheme, --wp--preset--color--brand and so on, which is exactly the seam where a brand’s design tokens meet a website. The current format is version 3, introduced in WordPress 6.6, and older versions keep working.

A classic theme is built from PHP templates and functions.php. It is the older approach, and WordPress documents the trade-off in one sentence: “Classic themes do not work with the Site Editor.” The Customizer is likewise unavailable in block themes unless a plugin brings it back.

A page builder is a plugin that replaces both. This is the one to understand before choosing it, and the accurate version of the objection is narrower than the one you usually read.

What page-builder lock-in means in practice

The common claim is that removing a page builder fills your posts with shortcodes. For Elementor, the most widely used of them, that is not true, and repeating it would be unfair.

What is true comes from Elementor’s own developer documentation. It “stores the page data and layout in a JSON format as WordPress post metadata,” saved as “a private custom field which is not visible in the WordPress dashboard,” and its frontend “is responsible for parsing the page data to create the page layout.”

Read that carefully, because it is the whole argument. Your design does not live in WordPress’s content field. It lives in a private custom field, in a format only Elementor can render. Your words survive. Your layout is portable only to another installation of the same plugin.

That is a reasonable engineering choice, and for a site somebody edits weekly without a developer it may be the right one. It is also a commitment, better made knowingly in week one than discovered in year three.

Which we build, and why it is not always the same

Two sites, two different answers.

Bonatar, a machinery safety practice in Belgium, got a custom block theme with theme.json v3. The site runs in Dutch, French and English, and every element that appears on every page (navigation, the call to action, the mark, the language switcher, the SEO head) is generated in one place, so a change lands in all three languages at once. Localised URL paths, language detection and hreflang are built into the theme: no multilingual plugin, no per-language duplicate of the template, nothing extra to license.

A swim school in North Jutland got a classic PHP theme instead, and the case study says why plainly: the design is four fixed layouts, and block templates would have added an editing surface nobody asked for plus a second place for the markup to live.

The structural decision there is worth stealing regardless of which approach you choose. Two body templates render four pages, each against a language copy table. One template per language is precisely how a copy fix lands in Danish and silently misses English.

The principle: pick the approach that matches who edits the site. A block theme buys editing freedom, and charges for it in surface area. A classic theme buys exactness, and charges for it in flexibility. Anyone who recommends the same one for every client is selling their habit.

What a custom theme should include

• One place for anything repeated. Navigation, footer, calls to action and metadata generated by a single function, not pasted into each template.
• Design tokens, not hardcoded hex. The colours in the theme are the colours in the brand guide, read from the same source.
• No asset hardcoding. WordPress is explicit that you “should never manually hard code” <link> and <script> tags; stylesheets and scripts are enqueued, fonts declared in theme.json.
• The head owned by the theme. Meta description, canonical, Open Graph and structured data generated rather than typed per page.
• A version number that moves, so you can tell what is deployed.

Who should not buy one

• You need a site next week for under a thousand. Buy a good theme from a marketplace and spend the money on photography.
• Your site is a shop with standard requirements. WooCommerce with a well-maintained theme will beat a bespoke one on cost and on how long it keeps working.
• Nobody at your company will ever touch it. Then the editing surface is irrelevant and almost any approach works. Choose on price.

What it costs

A website from this studio starts at $2,997, and the configurator gives you the exact figure for your build rather than a range.

The theme itself is a line in it: WordPress + a custom theme built from your tokens, $900. Pages are $150 each, a second language $200 on top of its share of the pages, and ownership transfer and admin handover $100, ticked by default. I have not found another page on this topic that prints the price of the theme as a separate figure, which is odd, because it is the first thing anyone wants to know.

---

Next: Who owns your website · What a website actually costs · price your own build