WordPress Site Design: Builder, Parent Theme or Code

Your website has two layers, and where each one is stored decides how much freedom you keep.

The platform question comes first, and it is a genuine fork. Hosted builders such as Wix, Squarespace and Shopify win when nobody wants to run software and the platform already does the job, Shopify plainly so on commerce. A bespoke or headless stack, an Astro front end on Sanity for instance, wins when the thing you are building is closer to an application than to a set of pages. Neither is a lesser choice, and neither is a fallback from WordPress. WordPress covers a wider range than either, which is why it fits so many situations, though every situation carries considerations that can point somewhere else.

Choosing between those three is where this series starts, in Website Platform Choice: Builder, WordPress or Custom, and WordPress vs Shopify vs Wix vs Squarespace, Compared already sets the four platforms side by side. Everything here assumes the question has been asked and the answer was WordPress.

A WordPress design can then live in one of three places. A page builder plugin holds the design and the content together, storing your pages in its own format. A vendor parent theme holds the design and leaves the content in WordPress’s own blocks. A custom theme holds the design in code written for your site, and leaves the content in those same blocks.

What separates them is custody rather than quality, and it turns on one property: whether your content layer stays in portable core blocks. Leave a builder and your pages have to be rebuilt. Leave either theme and you redesign around content that survives the change.

Every Website Has Two Layers, and the Split Decides How Much Freedom You Keep

Your content layer is the words, the images and the pages. Your design layer is the layout, styling and templates that decide how those pages look when a browser or a crawler asks for them. The two feel like one thing while you are editing, which is why the split gets missed, and missing it is how a build decision ends up being made on the wrong grounds.

WordPress keeps them apart by design. Content is stored in the database as post content, and how WordPress stores content types has been documented and stable for years. The theme is a separate thing that reads that content and decides what it looks like.

The editor you type into is where the split becomes visible. The block editor ships inside WordPress itself rather than as a plugin you install, and the release FAQ from WordPress’s co-founder records the point at which it moved into core. A block written in the core editor therefore belongs to WordPress, not to whatever is styling it this year.

That ownership is worth something because of how many sites are in this position. WordPress’s share of the web and the current CMS market share both put it far ahead of anything else, so the three-way choice gets made constantly, usually without anyone naming it. The first of the three names itself the moment you install it.

Option One: a Page Builder Holds Your Design and Your Content Together

A page builder is a plugin that replaces the editing experience and renders your pages itself. Elementor, Divi and Beaver Builder are common examples.

The design lives inside the plugin, as modules and settings. The content lives there too, saved in the builder’s own format rather than as core blocks. That is the whole of the trade.

What you get is genuine: a visual canvas, drag and drop layout, no template file to touch. Plenty of sites are better off with exactly that, and the situations where it is the right call are specific enough to name outright.

What you carry is a rendering layer sitting between your content and the browser. Page weight is the general web’s problem rather than any one tool’s, and the measured page weight and performance across the web is the picture every build is measured against. Because the Core Web Vitals thresholds are published, this is a cost you can put a number on rather than argue about, and Core Web Vitals Explained for Non-Engineers covers reading those numbers without an engineering background.

The number you get back describes your build, not builders in general. A well-kept builder site can pass thresholds a neglected custom one fails. What a builder cannot change is where your content sits, and that is exactly what the second option moves.

Option Two: a Vendor Parent Theme Holds the Design and Leaves Your Content Alone

A vendor parent theme is a complete theme built by someone else, installed on your site, running on the core editor. Astra, Kadence and GeneratePress sit in this category.

The design lives in the theme, controlled through an options panel and often a starter template. The content stays in core blocks, on the far side of the line from a page builder.

Three ways exist to customise that design layer, and beginner guides usually stop after the first two.

• Theme settings. You change colours, fonts, spacing and layout through the theme’s own controls. Nothing breaks on update, and you are limited to what the vendor chose to expose.
• A child theme carrying CSS. A small theme inherits the parent and overrides styling only. Your changes survive vendor updates because they sit in a file the vendor never touches.
• A coded child theme. The same inheritance, carrying real template files and functions. This is where a vendor theme stops being a product you configure and becomes a base you build on.

The ceiling here is a design one rather than a technical one. Usability research on template-driven pages is worth reading before you treat a template as a shortcut with no cost: a template helps when your content fits the shape it assumes, and works against you when it does not. Sites that look alike do so because a starter template chose their hierarchy before anyone wrote a word, and hierarchy is the part a reader feels first.

Diagnosis

Open any page on your site in the editor and look at what it is made of. Named WordPress blocks (paragraph, heading, image, columns, group) mean your content layer is portable and will survive a change of design. The design tool’s own widgets mean content and design are held together, and neither moves without the other.

How much that ceiling costs you depends on how far your site needs to sit from the shape the vendor drew. When the gap is wide enough, the design stops being something you configure.

Option Three: a Custom Theme Puts the Design in Code Written for Your Site

A custom theme is written for one site and runs on the core editor. The design lives in template files and stylesheets, and the content stays exactly where it was in option two, in core blocks.

The difference from a vendor theme is fit rather than capability. Nothing is inherited that you did not ask for, and nothing is shaped around a settings panel that has to serve thousands of installations at once. The tradeoff is that fit has to be built, and then kept.

What keeps it maintainable is the platform more than the developer. WordPress’s developer documentation on backward compatibility describes how the project treats the interfaces themes are written against, and that discipline is why code written for your site survives core updates instead of needing a yearly rewrite. What the platform will not do is write the code or answer the support ticket. A person does that, and if no person will, this is the wrong option.

The 2026 version of that objection is whether a model changes the arithmetic. Step 2 of this journey, AI Built WordPress Themes: Four Decisions You Own, takes it on directly: the code got faster, and the decisions around it did not.

The Invariant: Whether Your Content Stays in Portable Core Blocks

Option one sits on one side of a line, and options two and three sit on the other. Your content either stays in portable core blocks or it does not, and that single property is what sets the price of every decision you make afterwards.

The question to ask	Page builder plugin	Vendor parent theme on the core editor	Custom theme on the core editor
Where does the design live?	Inside the builder plugin, which assembles your layout from its own modules each time a page is requested.	Inside a vendor’s theme, whose options panel and templates control layout and styling.	Inside template files written for your site, which render the layout directly.
Where does the content live?	Inside the builder’s own storage format, which only that builder can read back reliably.	Inside WordPress’s own blocks, which the core editor reads whether or not that theme is active.	Inside those same core blocks, read by the core editor independently of the theme.
What do you install to get the design?	A plugin, plus whichever add-on packs the design you want depends on.	A theme, usually with a starter template and the plugins that template expects.	Nothing from a marketplace, because the theme is written for this site and ships with it.
What does leaving cost you?	A rebuild, because the pages must be recreated once the builder stops rendering them.	A redesign, because the content survives the swap and only the styling is rebuilt.	A redesign, on identical terms, because the theme was never holding the content.

The editor check tells you which row you are in, and it takes less time than reading a feature comparison. A feature comparison also measures the things that change with every release rather than the one thing that does not.

Search engines care about the output rather than the tooling. Google’s own description of crawling and indexing is written at the level of the page served, not the plugin that served it, so portability is a business question rather than a ranking one. What the page emits is what affects rankings, and Technical SEO for Founders: What to Fix First covers that layer.

Portability earns its keep for a second reason that has nothing to do with vendors. A content layer held in core blocks is one you can fill quickly, including with a model drafting first passes under supervision, because those blocks are a format anything can write into. Step 7, AI Website Copy: Which Sentences to Keep and Cut, covers what goes in that brief.

Insight

Where your content is stored decides what changing direction costs you later. Step two of eighteen asks whether a model can now write the theme.

Book a free diagnosis if you want a second opinion on which of the three places your own site is in.

Where a Page Builder Is Genuinely the Right Call

A builder is the correct answer in five recognisable situations.

The situation you are actually in	Why the builder is the right answer there
Your site is small and is not going to grow much.	The rebuild cost never arrives, because there is nothing large enough to rebuild. Portability is insurance on a library you have no plan to build.
Speed to launch is the real constraint, not the ten-year plan.	Assembling a page from ready-made parts is faster than writing templates, and a site earning attention today beats a better one still being drawn.
Nobody is going to maintain a custom codebase after launch.	A large vendor with a support team and automatic updates beats code that will sit untouched. Unmaintained bespoke code ages worse than maintained shared code.
The person editing the site wants to move things around themselves.	Drag and drop is a real capability, not a compromise. When layout freedom for a non-technical editor is the point of the site, that freedom is precisely the thing you are buying.
Your team already knows one ecosystem and the person who maintains it is staying.	Continuity of the person keeping the site alive beats portability nobody will use. A tool your maintainer knows gets updated. One they do not know gets abandoned.

How many sites run on hosted builders shows this is a mainstream, well-supported way to run a website.

If two or more of those rows describe you, the honest recommendation is a builder, and the rest of this journey still applies to your site. That recommendation costs me work, which is the point at which I should say what my work is.

My Interest in This, Stated Plainly

I build custom themes for a living, so option three is the one I sell. That is a commercial interest in the decision you are making, and you should weigh what I have written accordingly.

The editor check is a test you run yourself, on your own site, and it returns the same answer whoever is asking. Hold me to the rest of it. Step 18, Thirteen Questions to Ask a Web Vendor Before Signing, puts thirteen questions to any web vendor before you commit, and they are aimed at me as squarely as at anyone else.

The same instinct turns up at the far end of a build. Step 17, AI SEO Services: Six Flex Points and Who Decides, asks who is accountable for output a machine produced. Custody and supervision are one question asked twice.

Eighteen Steps Sit Between a New Site and a Cited One

Eighteen articles run in one order, from the build decision to the point where answer engines quote you, or you hand the whole thing to someone else.

The stage, and the positions it covers	What you leave that stage knowing
DECIDE, positions 1 to 4, this article among them.	Which of the three places your design lives in, whether a model can write the theme now, what site structure your build already chose on your behalf, and what changing direction would cost.
WRITE, positions 5 to 10.	Which pages your structure calls for, the order that earns attention fastest, and how to brief a model well enough that its first draft is worth editing.
BE FOUND, position 11.	How to edit a drafted page so it answers the query someone typed rather than the topic it sits near, which is the edit a generated first pass usually needs.
BE CITED, positions 12 to 17.	What evidence, schema and human supervision answer engines reward, so that being found turns into being quoted by name.
OR HIRE IT OUT, position 18.	Thirteen questions to ask any web vendor before you commit, and what a good answer to each one sounds like.

Two stages have foundations worth reading out of order. SEO for Startups: What to Do in the First 90 Days sits under BE FOUND, and Answer Engine Optimization: What AEO Actually Is sits under BE CITED.

Step 2 is the one to read next. AI Built WordPress Themes: Four Decisions You Own takes up the question left hanging here, which is whether the third option still costs what it used to.

Frequently Asked Questions

What is a block editor in WordPress?

WordPress’s block editor is the editing screen that ships inside WordPress itself, not a plugin you install. It saves each paragraph, heading, image and list as a named block in the post content. Because those blocks belong to WordPress rather than to a theme or a plugin, they stay readable when either one changes.

What are the differences between the WordPress Classic editor and the Block editor?

The real difference is how a page is stored, not how it looks while you type. Classic saved one field of free-form HTML. The block editor saves an ordered sequence of named blocks with their settings attached. That storage change is why block content can be moved, restyled and re-rendered without being retyped.

What is the difference between a parent theme and a child theme in WordPress?

A parent theme is the complete theme supplying templates and styling. A child theme inherits all of it and overrides only what you change, so vendor updates never erase your work. Child themes range from a few lines of CSS to fully coded templates and functions, and that coded version is the one beginner guides skip.

What are the key differences between a website builder and a custom website?

The useful difference is where each layer is stored. A builder holds your design and your content together in its own format, so leaving means recreating the pages. A custom build holds the design in code and leaves the content in WordPress blocks, so leaving means restyling content that survives the change intact.

Do I need a theme for WordPress?

Yes. WordPress will not render a front end without an active theme, so every WordPress site has one, including every site run through a page builder. Keep the two questions separate: the theme decides what renders your templates, and the builder decides where your content is stored.

Which is better for building a website, WordPress or a website builder?

Neither is better in the abstract, and the question one level up is more useful: who is holding your content, and what would leaving cost? Hosted builders trade content portability for speed and vendor support, which suits a small or short-lived site. WordPress with core blocks keeps that content layer portable.

Continue Reading:

Previously in this series

• Website Platform Choice: Builder, WordPress or Custom, the platform choice that sits one level above this one, and the maintenance question that settled it.

Next in this series

• AI Built WordPress Themes: Four Decisions You Own, whether a model can now produce option three quickly, and which build decisions it still will not make for you.

From the library

• WordPress vs Shopify vs Wix vs Squarespace, Compared, for the platform decision that sits one level above this one.
• Technical SEO for Founders: What to Fix First, for what the page you serve has to get right regardless of which of the three places built it.
• Core Web Vitals Explained for Non-Engineers, for reading your own performance numbers instead of inheriting an opinion about them.
• SEO for Startups: What to Do in the First 90 Days, the foundation under the BE FOUND stage of this journey.
• Answer Engine Optimization: What AEO Actually Is, the foundation under the BE CITED stage.

Explore TDM Insights Categories

• SEO
• AEO
• Content
• Case Notes