Quick answer: A WordPress page template is a PHP file in your theme that defines an alternate layout for Pages. Authors pick it in the editor under Template. Use templates for repeatable layouts (full width, landing page, contact sidebar) without installing a heavy builder for every variation. Understand the template hierarchy so you know when a custom page template is the right lever versus a custom post type or a builder section.
Themes ship with at least one default page look. Business sites usually need more: a stripped landing page, a wide marketing layout, a docs-style sidebar. Page templates are the classic WordPress answer.
How page templates work
In a classic PHP theme you add a file such as template-landing.php with a header comment:
<?php
/**
* Template Name: Landing - No Sidebar
*/
WordPress lists “Landing – No Sidebar” in the Page attributes / Template panel. When that page loads, WordPress uses your file instead of page.php.
Block-based full site editing is emerging, but in August 2019 most business sites still run classic themes with PHP templates. This article focuses on that reality.
Common template types worth having
- Default page: title, content, maybe a sidebar
- Full width: no sidebar, for storytelling pages
- Landing page: minimal header/footer chrome, strong CTA
- Contact: form emphasis, map, details
- Legal: narrow readable column for privacy and terms
Keep the list short. Ten barely different templates confuse editors.
Templates vs page builders
Builders (Elementor, Divi, and similar) let marketers arrange sections visually. Page templates lock structure in code for speed and consistency. Many sites use both: templates for global rules, builders for one-off campaigns. Be explicit. See Divi vs Elementor when choosing a builder, and custom theme vs premium when the theme itself is the question.
Templates vs the Customizer
The Customizer changes theme options and site identity. It does not replace per-page structural templates. Use Customizer for colors and menus; use templates for layout skeletons.
Creating or extending templates safely
- Use a child theme so updates do not wipe your files.
- Copy
page.phpas a starting point rather than inventing markup from nothing. - Keep
get_header()andget_footer()unless you intentionally build a chrome-free landing template. - Escape output. Follow WordPress coding standards.
- Test menus, forms and SEO plugins on the new template.
Editor experience tips
Name templates in plain language editors understand: “Full width (no sidebar)” beats tpl-fw-v2. Document when to use each on an internal wiki. Remove obsolete templates so the dropdown stays honest.
In Gutenberg, the template selector still matters for classic themes. Confirm your template works with blocks and with any classic content you still have (Gutenberg editor, Classic Editor plugin).
SEO and templates
Templates should expose one H1, readable content, and unique titles via Yoast or similar. A landing template that hides the title visually should still keep a sensible H1 in the HTML for accessibility and clarity. Avoid thin doorway templates that only exist to chase keywords.
Performance
Each template should load only the CSS/JS it needs. Landing templates are a common place where teams dump every marketing script. Be deliberate; see third-party scripts.
When to use a custom post type instead
If you are really building a catalog of case studies or team members, a CPT with single-case-study.php is cleaner than misusing Pages with twenty templates. Pages + templates shine for a handful of structural variants, not for large collections of structured items.
Accessibility in templates
Skip links, landmark roles and heading order belong in the template shell, not only in page content. A full-width landing template still needs keyboard-reachable menus if any chrome remains. Test once per template with keyboard only.
Migration from builder-only pages
If every page is a builder canvas, introducing PHP templates for a few key layouts can improve performance and consistency. Start with legal pages and a simple contact layout. Leave complex campaign pages in the builder until you have a pattern library.
Naming collisions
Do not reuse template file names across parent and child themes carelessly. Prefer unique file names in the child theme. Document which template file maps to which admin label so deploy reviews are easier.
SEO plugin compatibility
Confirm Yoast or your SEO plugin still outputs titles and canonicals on custom templates. Occasionally a template omits wp_head by mistake. Include that in QA.
Landing page template details
A good landing template often removes global nav distractions, keeps a simple logo that links home, and stacks a hero, proof, details and a repeated CTA. Put scripts for ads and analytics in deliberately; do not inherit every header script from the blog layout if you can help it. Forms should be native or carefully embedded. Test spam protection on the landing template specifically.
Assigning templates in bulk
When migrating, you may need to assign templates to many pages. wp-cli or a careful bulk edit plugin helps. Preview a sample in each language or market if you run multilingual.
Page templates and caching
Full-page cache plugins sometimes need URL or cookie rules per template if a landing page shows personalized offers. Document cache exceptions next to the template name in your runbook.
Homepages and front page displays
Your static front page uses the selected page’s template too. People forget and wonder why the home looks like a generic page. Set the front page deliberately under Settings → Reading and assign the intended template.
Internationalization
If strings appear in templates, wrap them for translation. Template names in the header comment are admin-facing; keep them clear for the language your editors use. Related: translation-ready themes.
Example workflow for a new template
Create a child theme file with Template Name, build markup with the title and content tags, enqueue narrow CSS only on that template via is_page_template, create a draft page, assign the template, add real content, QA responsive layouts and forms, then document the template in your editor handbook.
Conditional widgets and sidebars
If a template removes the sidebar, unregister or hide sidebar widget areas in that context so editors do not wonder why their widgets vanished. Clarity in the admin prevents support noise.
FAQ
Can posts use page templates?
The classic Template Name header is for Pages. Posts use the hierarchy (single.php, single-{post-type}.php). Some plugins extend template selection more broadly.
Do I need a plugin to add templates?
No. Theme PHP files are enough. Plugins can register templates too if you package them that way.
Will switching templates delete content?
No. Content stays in the database. Layout chrome changes. Shortcodes that assumed a sidebar may look odd; preview first.
Are page templates the same as block patterns?
No. Patterns are reusable block layouts inside content. Templates wrap the whole page shell in classic themes.
Pick a few layouts and name them clearly
Page templates give you controlled variety without turning every page into a one-off. Start with full width and landing, document them, and keep the dropdown short. If you need help structuring a WordPress theme for marketing pages that convert, see Turn visitors into customers.
