“Dynamic website” covers three entirely different things, and the distinction determines scope, cost, and legal requirements. Content generated from a database is WordPress’s default behaviour and needs nothing added. Interactivity, meaning responses without a page reload, is a front-end layer. Personalisation, meaning different content for different visitors, is the most expensive of the three and the only one that carries GDPR implications and a direct conflict with your caching layer. Before you start, establish which one you mean.
Three meanings of “dynamic”
1. Content generated from a database
This is what WordPress does by default. Every page is assembled at request time from data held in the database. Posts, product listings, category archives, filtered results. In this sense every WordPress site is already dynamic and nothing needs adding.
The work here is data modelling rather than adding features. Custom post types, taxonomies, and custom fields let you build a property catalogue, a knowledge base, or a location list that editorial staff populate once and the site displays in several places.
2. Interactivity
Elements that respond to user action without reloading the page: result filtering, type-ahead search, load-more buttons, calculators, multi-step forms, product configurators.
This is a front-end layer talking to the server through the REST API. It does not change the data model and does not touch personal data, provided it does not record user behaviour.
3. Personalisation
Different content for different visitors: recommendations based on browsing history, material tied to subscription level, messaging based on location.
This layer differs from the other two in kind, not in degree. It requires processing data about user behaviour, which brings legal basis and consent into scope. On top of that sits a technical problem described below, one that planning often skips.
Personalisation against caching: a conflict to settle up front
WordPress performance rests on full-page caching. The server renders a view once and serves the finished file to subsequent visitors. That mechanism is what lets a site absorb traffic.
Personalisation breaks the premise. If content has to differ per visitor, you cannot serve everyone the same file. The more personalisation, the less caching, and the less caching, the weaker your Core Web Vitals and the higher your infrastructure cost.
There are three ways out of the conflict:
- Fragment caching. The page is cached and only selected fragments are personalised, fetched after the view renders. The most commonly used approach and usually sufficient.
- Edge personalisation. The CDN layer substitutes content variants without hitting the application server. Scalable, but it needs infrastructure that supports it.
- Deliberately doing less. Confining personalisation to the logged-in area, where caching does not apply anyway, and keeping the rest of the site fully cached.
Settle this before implementation. Adding personalisation to a site optimised around full-page caching usually means rebuilding the performance layer, not installing a plugin.
Personalisation and GDPR
Behaviour-based personalisation is processing of personal data. It needs a legal basis, and in practice consent where it relies on cookies or similar technologies.
The design consequence matters: the site has to work sensibly for someone who has not given consent. Personalisation is therefore a layer on top of a working baseline, not the foundation of the user experience. Implementations built the other way round have to be unpicked later.
Personalisation based on data the user has deliberately provided, such as a chosen language, industry, or subscription level, is considerably simpler legally than profiling from observed behaviour.
The data layer: custom post types and fields
Every one of the three scenarios rests on the data model.
Register custom post types in a custom plugin, not in the theme’s functions.php. A type registered in the theme disappears from the admin when the theme changes, leaving the data in the database with no way to edit it.
php
function wlc_register_property_post_type() {
register_post_type( 'property', array(
'labels' => array(
'name' => __( 'Properties', 'wlc' ),
'singular_name' => __( 'Property', 'wlc' ),
),
'public' => true,
'has_archive' => true,
'show_in_rest' => true,
'supports' => array( 'title', 'editor', 'thumbnail' ),
'menu_icon' => 'dashicons-building',
) );
}
add_action( 'init', 'wlc_register_property_post_type' );The show_in_rest parameter matters here. Without it the post type is unavailable through the REST API, so it cannot be used in the block editor or in the interactive layer.
Custom fields extend the data model with information WordPress does not hold by default. Advanced Custom Fields is the most widely used tool in this area, alongside Meta Box and custom implementations.
When outputting data in a template, every value needs escaping before it reaches the page:
php
<div class="property-details">
<p>Price: <?php echo esc_html( get_field( 'price' ) ); ?></p>
<p>Location: <?php echo esc_html( get_field( 'location' ) ); ?></p>
<p>Area: <?php echo esc_html( get_field( 'area' ) ); ?> m²</p>
</div>esc_html() is not optional. A person fills that field in, and anything entered by a person reaches the page escaped. No exceptions.
In block themes, part of this work moves into the editor. The Query Loop block renders content listings without code, and the block bindings mechanism connects block attributes to custom fields. On simpler listings that is usually the better route than a PHP template, because editorial staff can adjust the layout themselves.
Tooling: fewer is better
The market offers dozens of plugins for dynamic content. Approach it with some reserve, because plugin sprawl is the most common source of trouble on larger sites, more common than any limitation of the platform.
A set that covers most projects:
- Data layer: custom post types registered in code, plus one custom fields tool.
- Presentation: the Query Loop block and block patterns, with a theme template for more complex views.
- Forms: one solution with conditional logic, not three.
- Filtering and search: on large datasets, a dedicated search engine such as Algolia, because the default WordPress mechanism does not use full-text indexes.
- Logged-in areas: one access management solution.
It is worth thinking twice about building the dynamic layer on a visual page builder. A builder gives you a fast start, but stores layouts in its own format, which ties the site to one tool and complicates any later change. On projects planned to run for years, a custom block library and design system is the better foundation.
Performance on a dynamic site
A site generating content on every request runs more database queries than a static one, so performance needs deliberate decisions.
Caching layer:
- full-page caching for non-personalised content
- fragment caching for personalised areas
- object caching on Redis or Memcached, storing database query results
- a considered invalidation strategy, so that editing one post does not clear the whole cache
Database:
- indexes on columns used in filtering queries
- query monitoring to catch inefficient operations
- regular cleanup of revisions and transients
Code:
- pagination instead of loading a whole list
- lazy loading for elements below the fold
- REST API requests limited to the fields actually needed
Infrastructure:
- a current PHP version
- hosting tuned for WordPress with headroom
- a CDN for static assets
What to watch for
Start from a need, not a capability. Personalisation implemented without a defined goal raises cost and does not move conversion. Establish what should improve and how you will measure it.
Plan the fallback. A dynamic element that fails to load cannot leave a blank space on the page. The baseline version has to be complete.
Check the SEO impact. Content fetched by script does not always reach the index. Important content should be present in the server response, not appended in the browser.
Do not overload pages. Several independent dynamic elements on one page means several parallel requests and a visible hit to Core Web Vitals.
Design for mobile from the start. Interactions designed for a cursor rarely work well under a thumb, and most traffic arrives from phones.
Plan for maintenance. A dynamic layer means more dependencies, so more things can break after an update. A staging environment stops being optional.
In summary
The answer to the title question depends on which of the three meanings you have in mind. Content from a database is data modelling work. Interactivity is a front-end and REST API layer. Personalisation is an architectural decision with consequences for performance and GDPR compliance.
The most common mistake is implementing the third scenario when the first was needed. A well-ordered data model and well-designed listings solve most of what gets described as “we want a dynamic site”, without the costs personalisation brings.
FAQ: dynamic website in WordPress
Is every WordPress site dynamic?
In the sense of content generated from a database, yes, by default. Personalisation and interactivity are separate layers that have to be built.
Does personalisation hurt performance?
It limits full-page caching, which is noticeable under traffic. The answer is fragment caching or personalisation at the CDN layer.
Does personalisation require user consent?
Where it relies on observed behaviour and cookies, usually yes. Personalisation based on data the user deliberately provided is simpler legally.
Do I need a visual page builder for dynamic content?
No. The Query Loop block and block bindings cover most listings. A builder starts faster but stores layouts in its own format, tying the site to one tool.eeds. Plan for ongoing optimization and feature enhancement as part of your website strategy to continuously improve user experiences and business outcomes.
