“Hand-coded” appears on a lot of developer websites, including this one. It sounds credible without necessarily meaning anything specific, and it is easy to say without being asked to explain it. This post explains what hand-coded actually means in the context of a WordPress theme, what it does not mean, and why the distinction matters when you are choosing who to work with.
What hand-coded actually means
A hand-coded WordPress theme is one written directly in PHP, HTML, CSS, and JavaScript by the developer. Every template file, every function, every style rule was typed out by a person rather than generated by a tool.
That means:
No visual builder in the stack. Elementor, Divi, WPBakery, and Beaver Builder are all tools that generate code from a visual interface. The code they produce is real code, but neither the developer nor the client wrote it. A hand-coded build has none of this in the stack.
No third-party theme framework as the foundation. Some developers build on top of commercial base themes like Genesis or OceanWP, customising them rather than starting from scratch. This is not hand-coded in the meaningful sense, even if the developer writes additional CSS on top of it.
No generated markup. Page builders in particular produce large quantities of HTML that no human would write. A hand-coded theme produces only the markup the page actually needs.
What it does mean in concrete terms: a functions.php file written for this specific site, not adapted from another product; CSS written to specification, not overriding a framework’s defaults; template files that reflect the actual structure of the site, not a generic template with chunks disabled; and ACF used to create flexible content management, not a builder used to create the visual layout.
What hand-coded does not mean
This is the part that sometimes gets lost when the term is used as a marketing claim.
It does not mean writing from memory
No developer writes entirely from memory. Documentation is used constantly. Stack Overflow, the WordPress developer handbook, MDN, GitHub issues. The distinction is not between a developer who references documentation and one who does not. It is between code generated by a tool and code written deliberately by a person who understands what it does.
It does not mean avoiding all libraries
A hand-coded theme may use small, well-maintained JavaScript libraries where they are appropriate. It might use a CSS reset, a utility function, or a package installed via npm. None of this disqualifies a build from being hand-coded. What matters is that the structural decisions, the template architecture, the styling approach, and the output HTML were all authored by the developer.
It does not mean unnecessarily complex
Good hand-coded themes are often simpler than their page builder equivalents. A page builder site for a four-page brochure site might generate 15,000 lines of CSS. A hand-coded equivalent might use 800. Simplicity is a feature, not an accident.
Why the performance difference is real and measurable
Page builders output substantially more HTML and CSS than a hand-coded theme serving the same design. This is not a marginal difference.
A page builder wraps content in multiple nested container divs. It loads CSS for every widget in the builder’s library, whether or not those widgets appear on the page. It often loads JavaScript that executes on page load regardless of whether any interactive element requires it.
This additional weight directly affects Core Web Vitals: Largest Contentful Paint takes longer because there is more to parse and render; Total Blocking Time increases because builder scripts execute during page load; Cumulative Layout Shift can occur while the builder calculates column positions in JavaScript.
Core Web Vitals are a Google ranking signal. A hand-coded theme starts with a structural performance advantage that a page builder site has to work against, often requiring additional optimisation plugins to partially compensate for overhead the hand-coded build never introduced. I covered this in more detail in the post on why I do not use page builders, if you want the fuller picture on what that overhead actually looks like.
Why the maintainability difference matters over time
Code you wrote is code you understand. More importantly, it is code another developer can understand.
A hand-coded WordPress theme has a predictable structure: template files, a stylesheet, a functions file, and ACF field groups if content management is involved. A developer picking up the project for the first time can read through those files and understand exactly what is happening, why each decision was made, and how to extend the site without breaking anything.
A page builder site stores layout information in the database in a proprietary serialised format. The visible HTML is generated at render time by the builder. Another developer inheriting this site has to reverse-engineer the builder’s logic before they can do anything. In practice, developers often prefer to rebuild rather than maintain a page builder site they did not build themselves.
This matters not just for handoffs but for ongoing development. Adding a new section, modifying a template, debugging an interaction: all of these are faster and lower-risk on a codebase that was written to be read.
What to ask to verify it
Claiming to build hand-coded sites costs nothing. Demonstrating it does.
The simplest way to verify whether a developer’s work is genuinely hand-coded is to ask to see the code. Not a screenshot of the admin, not a Lighthouse score, but the actual template files and stylesheet. Legitimate developers who build hand-coded themes will say yes, either by sharing a private repo, sending a zip of a sanitised project, or walking through it on a call.
A few things to look for in the output:
The stylesheet should have a clear structure and comments that suggest human authorship, not generated class names and utility-first frameworks used in ways that do not match the design.
The HTML source of a live page should be clean and minimal. Run it through W3C’s markup validator. Open the source and read a section. If every paragraph is wrapped in four nested divs with generated class names like elementor-widget-container, that is page builder output.
The template files should follow WordPress’s template hierarchy: page.php, single.php, archive.php, and so on, with logic that makes sense for the specific site.
If a developer declines to share code, or becomes evasive when asked, that is information.
If you want a WordPress site that performs well now and stays maintainable for years, the approach I use for every build starts from hand-coded foundations. For a closer look at why page builders specifically create the problems this post outlines, the post on why I do not use page builders covers the full picture.
Frequently asked questions
What is a hand-coded WordPress theme?
A hand-coded WordPress theme is one built directly in PHP, HTML, CSS, and JavaScript by the developer, without using a visual page builder to generate the code or a commercial theme framework as the foundation. Every template file and style rule is written deliberately rather than produced by a tool.
Is hand-coded WordPress faster than Elementor or Divi?
Consistently, yes. Page builders generate significantly more HTML, CSS, and JavaScript than a hand-coded equivalent needs to produce. That additional weight affects Core Web Vitals, specifically Largest Contentful Paint and Total Blocking Time. A hand-coded theme outputs only what the page requires, which means faster loading by default.
Does hand-coded mean more expensive?
Usually, yes, because it takes longer to build. A hand-coded theme cannot be assembled from visual blocks in an afternoon. The cost reflects the time required to write a theme that is specific to the project. Over the life of the site, the cost of maintenance and the absence of a required rebuild at three or four years often makes the hand-coded build the more economical choice.
Can I update a hand-coded WordPress site myself?
Yes, if content management is built correctly. A hand-coded theme paired with ACF gives editors structured fields for updating text, images, and content, without access to the underlying template. The design is protected and the content is manageable. This is how every site I build is structured.
What is the difference between hand-coded and custom WordPress?
Custom WordPress typically means a site built for a specific client rather than using an off-the-shelf theme. Hand-coded specifies how that custom site was built, meaning without a page builder generating the code. A custom site can still be built with Elementor. A hand-coded site cannot.