What this approach means

Page template and custom field builds are the older, more controlled way to build serious WordPress sites. Instead of giving editors a visual layout system, the developer creates templates and the editor fills in defined fields for headlines, images, buttons, repeaters, related content, and other structured pieces.

This approach can produce clean, consistent pages, especially when content follows a repeatable structure. It also puts a lot of power in the hands of the build team and much less in the hands of the editor.

Why teams used this approach

Before the block editor matured, this was often the safest way to give clients editable content without letting every page turn into a design project. The template handled layout. The fields handled content. Editors could update what they were allowed to update, and the design stayed protected.

That structure is still useful in the right place. It can make sense for content that should always follow the same pattern, such as locations, team members, case studies, products, resources, or directory-style records.

Where ACF usually fits

Many template-led WordPress builds use Advanced Custom Fields or a similar custom field system. ACF can be useful, and plenty of strong sites have been built with it. The problem is not custom fields by themselves. The problem is using fields as the default answer for every editing need.

Some sites go even further and create full custom ACF block systems. That can work, but it can also become clunky fast. Editors end up managing content through panels, repeaters, tabs, hidden conditionals, and settings that are hard to understand without knowing how the developer imagined the page.

What editors gain

• Layouts stay consistent because the template controls the page structure.
• Editors have fewer design decisions to make.
• Repeatable content can be easier to organize when it has a clear data model.
• The front end can stay polished even when different people update the content.
• Developers can tightly control how information is displayed across the site.

What editors lose

The tradeoff is flexibility. Editors often cannot see the finished layout while they work. They enter content into fields, preview the page, go back to adjust, preview again, and hope the available fields match what the page actually needs.

That can make simple changes feel harder than they should. Adding a new section, changing the order of content, adjusting a call to action, or creating a slightly different landing page may require developer work because the template did not anticipate it.

Why it can feel too locked down

The main strength of this approach is also its weakness. It protects the design by limiting choices, but it can limit too much. Editors may be able to update the words and images, but not shape the page in a way that matches the real communication need.

For modern business sites, that can be frustrating. Teams need to publish service pages, campaign pages, resource pages, landing pages, and updates without turning every content change into a development request.

There are better ways to work now

The block editor changed the decision. Many things that used to require custom fields can now be handled with core blocks, custom blocks, patterns, template parts, locked layouts, and theme settings. Editors can work closer to the final page while the site still protects the design system.

That does not mean custom fields are obsolete. It means they should be used more carefully. Fields are best for real structured data, not for rebuilding visual page layout through a long admin form.

Where this approach still makes sense

• Repeatable content types with a consistent structure.
• Data that needs to be queried, filtered, reused, exported, or integrated with other systems.
• Pages where editors should not be making layout decisions.
• Directories, profiles, locations, case studies, resources, events, or product-like content.
• High-control areas where design consistency matters more than page-level flexibility.

Where it is usually the wrong fit

• Marketing pages that need flexible sections and changing campaign content.
• Service pages where each page may need a different story or layout.
• Teams that want to preview and refine content visually before publishing.
• Sites where every small layout change becomes a developer ticket.
• Builds that use custom fields to imitate blocks instead of using blocks directly.

Decision snapshot

Choose this approach when…	Be careful when…
The content is structured, repeatable, and should display consistently.	The site needs flexible marketing pages or campaign layouts.
Editors should manage data, not design.	Editors need to see and shape the page before publishing.
The information needs to be reused, queried, filtered, or integrated.	Custom fields are being used to recreate a page builder.
The layout should rarely change after launch.	Every new content need requires another field group or template change.

Questions to ask before choosing templates and fields

• Is this content truly structured data, or is it page layout?
• Will editors need to change the order, emphasis, or layout of sections over time?
• Can the editor understand the page while working, or only after previewing?
• Are fields being used because they are the best model, or because the build process is stuck in an older workflow?
• Would blocks, patterns, or custom blocks give the same control with a better editing experience?

Best fit

Page template and custom field builds are best when the site needs structured, repeatable content with strong layout control. They are less ideal when editors need to build, test, and improve pages visually over time.

This approach still has a place, but it should no longer be the default for every custom WordPress build. Use fields for real structure. Use templates where consistency matters. Use blocks and patterns where editors need visual control. The best modern WordPress sites do not lock everything down just because they can.