Modern web architecture in the age of AI.

A website project can start with a conversation about what members need and end up in a debate about which framework has a future. Nobody wants to invest in a platform that might fall behind, especially with AI changing what developers can build. That’s what makes the word “modern” so persuasive in those conversations.

When developers call a platform modern, they often mean a headless CMS such as Payload or Sanity, or a website built with Next.js. The comparison often starts from an outdated picture of how WordPress and Drupal are built and operated today.

A modern website should be fast, accessible, secure, rewarding to use, and an excellent place to publish. Those qualities come from design, implementation, infrastructure, and working practices. Treating headless as the next generation confuses a different architecture with a more advanced one. As AI helps developers build sophisticated features across platforms, that distinction deserves more scrutiny.

Modern isn’t a platform.

Most organizations want something fairly reasonable from their website. Visitors should find what they need, understand it, and be able to act on it. The people managing the site should be able to publish useful content, respond to changing priorities, and improve the experience without turning every request into a development project.

Those expectations can lead to quite sophisticated work. An accessible resource library, a useful search experience, or a campaign page that connects properly with your CRM all require care. But none of them tells you, on its own, which content management system you should use.

Platform names can start doing the work of a proper comparison: WordPress sounds established, React sounds modern, and headless sounds like room to grow. A list of technologies then stands in for an explanation of how the website will work.

WordPress and Payload are content management systems. React is an interface library; Next.js is a framework for applications built with React. Headless separates content management from presentation. Composable assembles capabilities from separate services. The terms describe different parts of a solution and can overlap: Payload itself is built on Next.js.¹

Those labels tell you how a website is put together, but there’s still room for a good or bad implementation. A headless site can be beautifully engineered or frustratingly slow, just as a WordPress site can be easy to maintain or weighed down by years of poor decisions.

AI gives developers more help with integrations, interfaces, unfamiliar code, and repetitive work. Sophisticated features are becoming practical on more platforms. They remain different, but “we need a modern stack to build this” deserves a specific explanation.

The useful question is what the proposed architecture will make better for your organization, and what it will ask of you in return.

Headless is a bit of a letdown.

Let’s be honest: headless architecture has been something of a letdown.

For much of the past decade, headless was presented as the future: faster websites, flexibility, better developer tools, and content free to travel between websites, applications, and services. Plenty of platforms were built around that promise.²

The message reached well beyond the CMS vendors themselves. In the world of WordPress, WP Engine launched Atlas under the banner “the future of headless WordPress.” Pantheon developed decoupled tools and starter kits for WordPress and Drupal using frameworks such as Next.js and Gatsby. Frontity, a React framework created specifically for decoupled WordPress, was acquired by Automattic in 2021. Headless had real momentum because the promise was appealing.³

Give developers freedom to build the front end with the tools they prefer. Store content independently so it can be used wherever it is needed. Let separate applications develop on their own schedules. For organizations with several digital products, that separation can be genuinely useful.

The argument expanded beyond those uses. Separating presentation from content became an upgrade in itself, apparently the sensible destination for any ambitious website.

And that is where the hype fell flat. Headless does solve certain engineering problems, but it doesn’t solve many of the problems most marketing and communications teams have with their websites.

A communications manager still needs to preview a page, rearrange a campaign, and publish on time. Visitors need useful, accessible pages. An executive director needs affordable operation and improvement. Moving content through an API does not make those tasks easier on its own.

The separation can create work an integrated CMS already handles: previews, connecting edits to finished pages, coordinating releases, and keeping caches current. Developers gain front-end control, while the organization pays for the publishing experience around it.

This is the letdown: an architectural choice acquired a reputation for being an upgrade before its benefits to the organization had been demonstrated. Headless found real uses, but it never became a convincing default for the ordinary organization website.

Meanwhile, WordPress kept evolving. Its editor became more capable. Hosting and deployment practices improved. Developers gained better tools for building custom experiences. The comparison that made headless look inevitable often depended on WordPress standing still, and it did not. Not even close.

Now AI is making sophisticated development more accessible across established platforms, too. A team can spend its effort improving an already capable publishing system instead of assuming that progress requires replacing it. That changes the calculation again.

Headless can still be the right architecture. But “being headless” deserves far less weight than the publishing experience, flexibility, cost, support, and day-to-day usefulness of the finished website. Those are the qualities an organization will actually live with.

WordPress’ evolution is impressive.

If your impression of WordPress comes from a decade-old site, a frustrating page builder, or plugins nobody understood, take another look. Those experiences are real, but they do not describe what a carefully built WordPress website can offer today.

Modern WordPress supports a visual block editor, reusable design patterns, custom content types, APIs, and interactive components. Developers can build a tailored theme around an organization’s design system, define how content is organized, and connect the site to external services. WordPress can also provide content to a separate front end when that arrangement serves a purpose.⁴

PHP has evolved, too.

PHP, the language behind WordPress, has evolved too. PHP 8 introduced union types, named arguments, attributes, and more concise ways to express common tasks. Modern PHP helps developers organize code, describe expected data, and catch mistakes.⁵

You do not need to recognize those terms to understand their significance. PHP is actively developed and supports well-organized, tested application code. Writing in it does not oblige anyone to work as though it were 2005.

PHP runs on the server, generating responses such as the HTML a browser displays. JavaScript can run on servers through Node.js, too. Next.js can render on the server and send selected interactive components to the browser. The comparison is more nuanced than server language versus browser language.⁶

PHP also remains widely used. W3Techs identifies it on roughly seven in ten websites whose server-side programming language it can detect. That is a measure of websites in its survey, rather than a share of all internet activity, but it gives some perspective on claims that PHP has been left behind.⁷

Good engineering matters more than the language label.

A secure, reliable WordPress site is entirely achievable. It depends on sensible access controls, timely updates, reviewed code, backups, monitoring, and a manageable set of dependencies. WordPress’s own hardening guidance covers these responsibilities in detail.⁸

Headless changes where some risks sit. A public front end may be isolated from the CMS, which can be useful. The CMS, APIs, authentication, build process, and software packages still need to be secured and maintained. A smaller plugin directory or a newer language does not settle that work for you.⁹

The same principle applies to speed and accessibility. Sending less unnecessary code, serving appropriately sized images, using good caching, and building interfaces properly matter across platforms. A fast demo or a framework logo cannot substitute for checking the pages people will actually use.

Gutenberg makes publishing easier.

The publishing experience is one of the strongest reasons to choose WordPress, and it deserves more attention than it usually gets in an architecture discussion.

Gutenberg, the WordPress block editor, turns text, images, calls to action, and resource lists into reusable page elements. With a well-built theme, they reflect the organization’s design, so editors can work visually without inventing layouts each time.¹⁰

Consider a communications team preparing a new program launch. They need a landing page, supporting resources, a quote from a partner, a registration link, and a prominent notice on a related page. Much of that work should be routine publishing. It should not require a developer to wire together a new page every time.

In a carefully designed WordPress editor, the team can start with an appropriate page pattern, add the content, choose from the components the project provides, and review the result. The design work has already happened. The team can concentrate on the message.

Freedom to publish, with the design protected.

Giving editors control does not mean handing them an unrestricted design tool. WordPress supports curated blocks, reusable patterns, and controls that restrict which elements people can move or change. Content-only editing can let someone revise the message while keeping the surrounding design intact.¹¹

That gives the communications team freedom to publish within a consistent design and lets developers save their time for components that need custom behaviour.

The quality of this experience depends on the implementation. An editor crowded with overlapping plugins and poorly named blocks can be just as frustrating as any other badly designed system. We favour a deliberate set of native blocks and patterns, useful defaults, and controls that match the work people need to do.

Staff who know WordPress bring useful familiarity. Documentation, training, and potential support providers are widely available. A custom implementation still needs a proper handover, but it starts from a shared foundation.

Ask to build a representative page in the actual editor, change its layout, preview it, and publish it. Find out which steps need custom development or another product. Let the people who will publish try their own work.

Modern infrastructure changes the comparison.

One of the easiest ways to make WordPress look outdated is to compare an inexpensive, poorly maintained WordPress installation with a carefully engineered Payload or other headless implementation. The difference may be dramatic, but it tells you very little about what caused it.

Payload’s own “Payload vs. WordPress” page is a useful example. It invites readers to “leave yesterday’s technology in the past” and contrasts Payload’s modern, purpose-built platform with a version of WordPress defined by plugins, outdated PHP, and a cluttered dashboard. That is effective product marketing. It is not a fair architectural comparison.¹²

Compare credible implementations: current PHP, a purpose-built WordPress theme and block system, managed infrastructure, tested releases, and curated dependencies beside equally careful Payload engineering. Then assess which approach creates more value for the organization.

Traditional WordPress: one application handles the website.

In a conventional WordPress setup, editors manage content in WordPress, and WordPress uses the theme to generate the pages visitors see. Content lives in the database, uploaded media lives in file storage, and the application brings those pieces together.

The arrangement is direct: one application understands the content and its presentation. Publishing and previewing stay together, with fewer connections for developers to maintain.

A basic installation might sit on a single hosting account with updates made directly to the live site. That is a choice about how the site is operated. It is not a requirement of WordPress, and it is a poor basis for judging every website built with it.

Modern WordPress: one publishing system, with modern deployment.

In a setup such as the one we build around Pantheon, WordPress still manages content and produces the website. The development process around it is more disciplined. Code is tracked in version control, reviewed, checked, and moved through development and testing environments before it reaches the live site.

CI/CD means continuous integration and continuous delivery or deployment. It gives changes a repeatable route through automated checks and appropriate human review. Marketing teams benefit from safer releases without needing to manage the mechanics.

Content publishing remains a separate activity. Editors work on the live content, while developers test code changes elsewhere. Pantheon’s workflow moves code towards Live and brings copies of live content back to development and testing. A routine code release should not replace the production database with an older testing copy.¹³

A content delivery network, or CDN, can serve cached responses from locations closer to visitors, reducing the work the application has to do for eligible requests. Pantheon provides a Global CDN as part of its platform. Caching still needs to be configured around the website’s behaviour, particularly for private or personalized content.¹⁴

The important point is that WordPress can have a mature development and delivery process while retaining an integrated publishing experience. Git, automated checks, separate environments, caching, and repeatable releases are available without replacing the CMS.

Headless: content management and presentation are separated.

In a headless arrangement, the CMS provides content to a separate presentation layer. That layer might be a Next.js website, a mobile application, or several different products. Developers decide how each one retrieves content and turns it into an experience.

WordPress can also use version control, CI/CD, managed hosting, caching, APIs, and separate environments. Both approaches need decisions about previews, authentication, releases, and failure. Headless changes the arrangement, while many operating responsibilities remain familiar.

The main difference is who connects presentation to publishing. Headless usually needs that connection built and maintained within the application; WordPress supplies more of it within the CMS. Added architectural freedom comes with additional cost and responsibility.

Speed comes from the whole implementation.

Both headless and WordPress can produce very fast websites. In either case, speed depends on how pages are rendered, what is cached, how much work reaches the browser, and the quality of the assets and code.

A framework does not make a heavy page lightweight. A CDN does not fix an inaccessible form. A modern hosting provider does not decide whether a visitor can find the information they came for.

Compare representative pages under comparable conditions. Look at real visitor measurements where they are available, including Core Web Vitals, which assess loading, responsiveness, and visual stability. Then look beyond the score to the actual experience: search, navigation, forms, accessibility, and how the website behaves when something goes wrong.¹⁵

The real cost is what it takes to keep improving.

The build price is the beginning. Hosting, maintenance, support, training, integrations, and future changes add cost through invoices, staff time, and improvements the team cannot afford to make.

This is where a good publishing system earns its place. If a communications team can build the next campaign from existing components, the organization avoids paying someone to reproduce work the website should already support. If changing a page requires a specialist, a small request can acquire a briefing, estimate, scheduling delay, review, and invoice.

WordPress can give content-heavy websites an economic advantage because much of the publishing machinery exists already. More budget can go into content, design, accessibility, and distinctive features, with a broad supplier community available for support.

That advantage needs care. Cheap hosting, excessive plugins, and hurried development can make WordPress expensive to operate. Headless can be economical when its separation solves a real problem or suits an established team. Compare the continuing responsibilities of credible implementations.

A proposal should make those responsibilities visible. Who maintains the front end? Who maintains the CMS? What happens when an integration changes? Which editor features are included, and which require additional development or licensing? How much can the communications team accomplish within the system it is buying?

AI can reduce some implementation work, but it does not remove ownership. Generated code still needs to be understood, reviewed, tested, and maintained. Research into AI-assisted development continues to show that the results depend heavily on the task, the team, and the surrounding workflow.¹⁶

For an organization buying a website, the relevant saving is the cost of delivering and maintaining useful improvements. A developer producing more code is only helpful if that code makes the website better without creating a larger maintenance burden.

Owning the code should give you choices.

Vendor lock-in is often discussed as though it begins and ends with the software licence. In practice, an organization can own its source code and still find itself dependent on the only supplier who understands it.

That dependence can come from a proprietary service, an unusual combination of tools, undocumented deployment steps, or a custom content model that is difficult to move. It can also come from ordinary things: the agency owns the hosting account, nobody else has the repository, or the handover never happened.

Open-source software provides a useful starting point. WordPress and Payload are both open source, so this is not a distinction that automatically favours one of them. The more revealing questions concern the complete solution and how easily another capable team could take responsibility for it.¹⁷

WordPress has established conventions, public documentation, hosting options, and a large support community. Following those conventions generally makes handover easier than relying on an unfamiliar layer of custom machinery.¹⁸

There are limits to that advantage. A proprietary page builder can create its own migration problem. A deeply customized plugin can become a single point of dependence. A WordPress site built on a managed platform may still require work to move its deployment and caching arrangements elsewhere.

Headless can introduce similar dependencies through the CMS, front-end framework, hosting services, preview tools, and integrations. Even when the application can be self-hosted, operating it well may require knowledge of details such as coordinating caches across multiple instances.¹⁹

Keep account and code ownership explicit. Expect documentation and a usable handover, and ask what changing supplier or host would involve. Those answers reveal how easily the organization could maintain or move the complete website.

Can your website keep up?

Communications teams have more channels, higher expectations, and less time to reach an audience. AI helps develop concepts and prepare work, but a website that turns every useful change into a development request can still hold everything back.

This is where velocity becomes a useful way to think about a platform. Can your team take an idea, turn it into something useful, publish it, learn from the response, and improve it while the opportunity is still there?

That depends on more than development speed. Content has to be written, reviewed, and published, and some changes need design or code. Every unnecessary handoff adds time. A website has real velocity when the team can make ordinary improvements while they still matter.²⁰

The time between an idea and a useful result.

Imagine your team spots a gap in a service explanation. The content is ready, the design system provides what is needed, and an editor is available. A capable CMS lets them respond while the problem is fresh.

If assembling those existing patterns requires a new front-end component and scheduled release, the organization has acquired a costly dependency. Engineering review earns its place when the behaviour itself is new.

These small differences accumulate. A team that can act on what it learns has more opportunities to improve its work. A team that has to justify a development request for every adjustment will naturally leave some useful ideas undone.

A well-built Gutenberg setup helps a team make those everyday changes independently. Developers build the capabilities and set the limits up front, so editors can keep improving the website and call in developers when a change needs their expertise.

AI should shorten the path to publishing.

AI can help a development team prototype a component, explore an integration, or work through a difficult implementation. On WordPress, that work can become a reusable block or feature that the communications team then uses without further developer involvement.

The value carries forward whenever staff reuse the capability. A resource filter, campaign pattern, or notice component can support many changes, reducing the stream of small development requests.

AI-generated drafts still need accuracy checks, editorial decisions, and accessibility review. The platform should help the team complete that work and publish, rather than leave more ideas waiting.

Velocity does not mean abandoning review. It means giving each kind of change an appropriate path. A correction to an opening-hours notice should be simple. A change to authentication deserves engineering review. A good website makes those differences manageable rather than sending every request through the same expensive process.

Ask where staff lose time: ordinary publishing, developer handoffs, release queues, or corrections after publication. Those answers show whether the platform helps them keep up without requiring an elaborate measurement system.

When headless earns its place.

Headless earns its place when an organization supplies content to websites, mobile applications, and other products with separate release schedules, or has an application team building experiences that behave more like software than published pages.

In those circumstances, an API-first CMS and a framework such as Next.js can fit the work well. A platform such as Payload gives developers considerable control over content models, access rules, and application behaviour. Teams that need that control may reasonably accept the additional integration and operating responsibilities.

Be specific about the requirement. Sharing articles on social media is different from supplying independently developed applications. Custom search, interactive tools, and CRM integrations do not automatically require replacing WordPress, which has APIs for wider application architectures.²¹

Drupal deserves the same fair treatment. Its content modelling and editorial workflow tools can suit organizations with demanding requirements. That is a reason to examine those capabilities against the work, rather than treating its reputation as evidence that it must be a better choice for every complex organization.²²

Enterprise requirements belong in the comparison too. Permissions, sign-on, approval workflows, auditability, and recovery need concrete answers in any proposed solution. Some are provided by the CMS, some by additional software, and some by the hosting and operating arrangements. An architecture diagram cannot establish that those requirements have been met.

A defensible headless decision identifies the requirement the separation solves, demonstrates publishing, and accounts for ongoing cost. Looking more modern is a weaker justification.

Build for the work ahead.

The most revealing platform comparison is a demonstration of the work your organization expects to do.

Give each proposed solution the same task. Ask the team to create a campaign page, update a resource, preview a change, handle an approval, and explain how it reaches the live site. Look at what happens when the request goes beyond the original template. Include the people who will publish the content and the people who will maintain the system.

Then compare the experience, the responsibilities, and the cost. How much freedom does the organization get? Where will it need specialist help? What has been built already, and what is still a promise? What would it take for another supplier to support the website a few years from now?

We build WordPress around native blocks, reusable patterns, purpose-built features, curated plugins, and tested releases. The aim is to support the organization’s ambitions while keeping everyday publishing practical.

There is room for sophisticated engineering in that approach. It belongs in the places where it produces something useful: a better search, a dependable integration, a faster page, an accessible interaction, or an editor that gives a communications team more control.

AI is widening what development teams can accomplish. WordPress benefits from that progress alongside other platforms, while bringing a mature publishing system, a large community, and an established support ecosystem to the project.

A platform earns its place by helping an organization do better work. As the possibilities expand, the experience of using and improving the website is where modern technology should prove itself.