There’s a moment every WordPress developer knows well. A client leans over, points at the screen, and says: “Could you make this page look different from the others?”
It seems like a small ask. But if you’re relying on a single page.php file to handle every page on the site, the answer can quickly become complicated.
WordPress page templates exist precisely to solve this problem. They’ve been a core part of theme development for years, and the underlying principle hasn’t changed: different pages can carry entirely different layouts, all within the same theme.
What has changed is how you implement that idea — and understanding both approaches is increasingly valuable as the WordPress ecosystem evolves.
How classic page templates work
In a classic PHP-based theme, every page defaults to the page.php template. That file controls the layout, including where the sidebar sits, how wide the content area is, and what elements appear around your post content.
When every page shares that single file, your design flexibility hits a ceiling fast.
The solution is to create a separate template file for pages that need a distinct layout.
Say a client wants their bio page to run full-width, without a sidebar. You create a new file — call it bio.php — and copy the contents of page.php into it. Then you remove the sidebar call and manually expand the content div to fill the full container width.
The critical step is pasting the necessary code at the top of that new file, before the header call:
<?php /* Template Name: Bio */ ?>That single comment is what tells WordPress this file is a page template and what to call it in the admin. Save the file, upload it to your theme folder, and WordPress picks it up automatically.
Assigning the template in the WordPress admin
Once the file is in place, assigning it to a page takes seconds. Open the page you want to use it on — either create a new one or edit an existing page — and look for the Page Attributes panel in the right-hand sidebar. You’ll find a “Template” dropdown there. Select your template from the list and save.
That’s the full workflow for classic themes. One file, one comment, one dropdown selection. The page now renders with its own layout while every other page continues using the default page.php.
The use cases multiply quickly once you understand the mechanism. A landing page without a header or footer. A product showcase with a custom grid layout. A contact page stripped of all sidebars and distractions.
Any page that needs to behave differently from the rest of your site is a candidate for its own template.
Where this fits in the modern WordPress landscape
WordPress has undergone a significant architectural shift with the introduction of Full Site Editing (FSE) and block themes, which became a stable part of the platform from WordPress 5.9 onward.
Block themes replace PHP template files with HTML-based templates managed entirely inside the Site Editor. There’s no page.php, no manual file uploads, and no template comment at the top of a PHP file.
In a block theme, you create custom page templates visually. Navigate to Appearance > Editor, open the Templates section, and add a new template.
You build the layout using blocks — removing the sidebar, adjusting column widths, rearranging elements — and save.
WordPress stores the template and makes it available to assign to any page, exactly as before, but without touching a single file.
The end result for the user is identical. The bio page gets its full-width layout. The landing page loses its navigation. But the path to get there is now entirely visual and code-free for those using modern block themes.
Which approach should you use?
The answer depends on what kind of theme you’re working with.
Classic themes — including most of the major commercial themes built before FSE became mainstream — still rely on PHP templates, and the original technique remains completely valid.
If you’re customising or building a classic theme, creating a custom-template.php file and pasting the necessary code at the top is still the correct approach.
Block themes shift that workflow into the editor. Themes like Twenty Twenty-Five — WordPress’s current default — are built entirely on this system. If you’re starting a new project or advising a client who wants a modern, code-light setup, a block theme with the Site Editor is worth understanding.
What’s worth noting is that the underlying logic is the same in both cases. You’re telling WordPress: this particular page should use a different set of layout rules than everything else.
Whether that instruction lives in a PHP comment or a visual template editor is a matter of implementation, not principle.
Common mistakes to avoid
The most frequent error with classic templates is forgetting the template name comment entirely. Without it, WordPress has no way to recognise the file as a selectable template, and it won’t appear in the admin dropdown. If your new template isn’t showing up, that’s the first place to check.
Another common issue is creating a template file but editing the wrong copy. If you’re working locally and syncing to a server, make sure you’re uploading the updated file to the correct theme folder. It sounds obvious, but it’s an easy mistake when you’re managing multiple environments.
For block themes, the pitfall tends to be the opposite: over-relying on the visual editor and not understanding what’s actually being stored. Block theme templates are saved as HTML files in the /templates directory. Knowing that structure matters when you’re version-controlling a project or handing a theme off to another developer.
A flexible tool worth mastering
Page templates are one of those WordPress features that seem minor until you realise how often you need them. Once you’ve used them on a few projects, they become a standard part of how you think about site architecture.
The classic PHP approach remains relevant and widely used. The block theme approach is where WordPress is heading. Learning both gives you the range to work confidently across the full spectrum of WordPress projects — whether you’re maintaining a legacy site or building something from scratch on the latest platform standards.
The request will keep coming. “Could you make this page look different?” Now the answer is always yes.
