Open the admin on a six-page marketing site and wait.
Not a crash. Nothing dramatic. Just that sticky pause where WordPress feels heavier than a site with a homepage, some service pages, a contact form, and a blog has any right to feel.
Then you look at the stack.
Elementor. A form plugin. An SEO plugin. Maybe a popup tool. A collection of add-ons somebody installed three years ago because one widget looked useful.
And all of it exists to run what is basically a brochure with a lead form.
That architecture made more sense a few years ago. In 2026, there is another reason to question it.
AI agents are starting to operate WordPress, not just write copy for it.
WordPress itself is moving in that direction. WordPress 7.0 introduced a provider-agnostic AI Client and a Connectors system for AI providers. The Abilities API gives plugins a standardized way to describe actions that software can discover and execute. The official WordPress MCP Adapter can expose those abilities to MCP-compatible AI tools. WordPress 7.1 has continued expanding that foundation.
That changes how we should think about building a simple business website.
The question is no longer just:
Can a person edit this page visually?
It is also
Can software understand the page well enough to change it without breaking it?
For a large class of WordPress sites, that pushes the architecture strongly toward blocks.
First, "block theme" and "block content" are not exactly the same thing
This distinction matters.
A full WordPress block theme stores its templates as blocks and uses the Site Editor for headers, footers, templates, styles, and page structure.
But a classic or hybrid theme can also use the WordPress block editor for page content. WordPress explicitly supports block content and theme.json features in classic themes too.
So the real architectural principle is slightly broader than the headline:
Keep the content in a structured, WordPress-readable format instead of burying the site inside a proprietary page-builder document.
A native block theme is usually the cleanest way to do that on a new marketing site. It is not the only way.
That distinction becomes important when we get to GeneratePress and Kadence.
Not every WordPress site is the same job
People talk about a “WordPress website” as if that describes one type of system.
It doesn’t.
A marketing site is mostly editorial content owned by the business. Home. Services. About. Locations. FAQ. Case studies. Contact. The conversion is usually a form submission or phone call.
Plumbing and HVAC company sites fit here. So do most law firm, accounting, consulting, manufacturing, healthcare-adjacent, and professional-service websites.
A blog-heavy marketing site has the same basic architecture with a more active publishing operation. Writers publish regularly. Increasingly, AI systems may help draft, optimize, update, repurpose, or maintain that content.
Then the requirements change:
- E-commerce sites need products, inventory, checkout, tax, shipping, payment processing, and order management.
- Portals and web applications need authentication, permissions, dashboards, files, workflows, and business logic.
- Directories and marketplaces need structured records, filtering, search, ranking logic, reviews, paid placement, and sometimes messaging.
- Community sites need user-generated content, moderation, spam protection, profiles, permissions, and interaction.
Those are software systems.
A plumbing company homepage is not.
If the site is basically brochure plus content plus lead capture, stop borrowing architecture from the application crowd.
Why page builders create a different problem for AI
Page builders became popular for a good reason.
They gave non-developers visual control.
Elementor, Divi, and similar systems let someone drag a card here, move a heading there, resize a column, and see what the finished page would look like.
That solved a real problem.
But it introduced another layer between WordPress and the content.
Elementor, for example, stores page layout and configuration as JSON inside WordPress post metadata. Elementor’s own developer documentation describes its JSON structure and how saved page data lives in wp_postmeta.
There is nothing inherently wrong with JSON.
The issue is who understands that JSON.
Elementor understands it.
A generic WordPress tool does not necessarily understand that an object buried inside that document represents the service card in column two, which contains a heading that should change without disturbing the surrounding layout.
Core WordPress blocks give an AI system a cleaner target.
A heading is a block. A paragraph is a block. A button is a block. A table is made of blocks and attributes. The relationships are visible.
GravityKit’s Block MCP is a good example of why this matters. It exposes a WordPress page as a structured block tree so an AI agent can modify an individual block instead of reading and rewriting the entire page as one piece of HTML.
Want to change one heading?
Change the heading block.
Want to insert another paragraph into a section?
Insert it into that group.
Want to move a CTA?
Move that block.
That is much closer to how we want an agent operating a production website.
Elementor is not standing still
This is where the 2026 version of this argument needs more nuance.
It would be wrong to say, “AI cannot edit Elementor.”
Elementor already has Angie, its agentic AI system for WordPress. Elementor is also building an Elementor-specific MCP that its roadmap says will let tools such as Claude and Codex create and edit Elementor pages. As of early September 2026, Elementor lists that MCP with a September ETA.
That matters.
Vendor-specific AI can make a proprietary document format much easier for agents to operate.
But it doesn’t eliminate the architecture question.
It changes it.
Do you want your site’s AI editability to depend on WordPress’s native content model and an open interface, or do you want it to depend on Elementor plus Elementor’s interpretation layer?
For some companies, Elementor’s answer will be perfectly reasonable.
For a new six-page service-business website, we would still rather remove the dependency.
Performance is part of the argument, but don't oversimplify it
It is tempting to say:
“Elementor stores JSON, therefore Elementor makes WordPress slow.”
That is too simplistic.
Hosting quality matters. PHP configuration matters. Database health matters. Plugin count matters. Poorly written plugins matter. Caching matters. Images matter.
You need profiling to know why a specific installation is slow.
But architecture still affects the baseline.
A page builder adds its own editor, data model, styling system, assets, widgets, and compatibility layer. A native block setup can start considerably simpler.
That does not guarantee a fast site.
It gives you fewer moving parts to make slow.
And fewer moving parts matter even more when humans and AI agents will both be maintaining the system.
What we would use for a new marketing site in 2026
For a new brochure-style or content-heavy business website, the default should be block-first.
Theme: Twenty Twenty-Five remains the latest released WordPress default theme. There is no Twenty Twenty-Six. WordPress is working on Twenty Twenty-Seven for a later release. Twenty Twenty-Five is a full block theme with Site Editing, style variations, and more than 70 patterns, including services, testimonials, contact sections, calls to action, and full landing pages. Its current version was updated alongside WordPress 7.0 on May 20, 2026.
Pages: Build the hero, service sections, proof, FAQs, locations, calls to action, and footer using blocks and reusable patterns. Do not install another page builder “just in case.”
Forms: Use one form system. WPForms or Gravity Forms are reasonable options. If submissions need to reach GoHighLevel or another CRM, use the appropriate supported integration, automation layer, API, or webhook. Gravity Forms, for example, supports outbound webhooks to external APIs.
SEO: Pick one SEO system such as Yoast or Rank Math. Running multiple SEO plugins to solve the same problem usually creates more conflicts than capability.
Hosting: Do not expect a block theme to rescue bad hosting. A cheap overloaded server can make a clean WordPress installation feel terrible.
Then add AI deliberately.
The AI layer should stay boring
This is where people are going to overbuild.
A business does not need twelve AI plugins because WordPress suddenly supports AI.
For this class of site, the stack can remain relatively small.
- Run a current WordPress release. WordPress 7.1 is current as of this writing. The core AI architecture arrived with 7.0, including the AI Client and Connectors screen. WordPress provides featured connectors for Anthropic, Google, and OpenAI, while the actual provider implementations remain plugins rather than AI models being bundled directly into core.
- Use the official MCP Adapter when the workflow calls for WordPress Abilities. It is an official WordPress package, but it is installed separately rather than being part of core. It turns registered WordPress Abilities into tools, resources, and prompts that MCP clients can use.
- Use a block-aware interface for structural page editing. Block MCP is one current example. The point is not loyalty to one plugin. The point is letting the agent edit the structure instead of blindly rewriting post_content.
- Add in-dashboard AI only when there is a reason for it. Tools such as ClassifAI and AI Engine can handle tasks such as drafting, rewriting, titles, excerpts, images, and other AI-assisted workflows. They are optional layers, not prerequisites for an AI-ready WordPress architecture.
And keep HTTPS enabled. Once a system stores provider credentials or allows remote software to write to the website, encrypted transport is basic production hygiene, not an optimization.
The missing piece is permissions
This is one of the biggest holes in most “AI-ready WordPress” discussions.
Giving an AI agent access to a website is not the same as giving it permission to do everything.
Do not hand an agent unrestricted administrator access simply because MCP makes the connection possible.
The architecture should include restricted credentials, WordPress capabilities, revisions, backups, logging, and a way to revoke access quickly. Use staging for major structural changes when appropriate.
Block MCP’s newer setup, for example, can use a dedicated limited account rather than the site’s main administrator account. The WordPress MCP Adapter also supports permission controls around exposed abilities.
This is exactly how businesses should think about AI agents elsewhere too.
Give the system the tools required for the job.
Not the keys to the building.
What about GeneratePress and Kadence?
The original recommendation still works, but the terminology needed correction.
GeneratePress and Kadence can both support block-based workflows, but neither should simply be called a native WordPress full block theme.
GeneratePress explicitly says it has not adopted the core Full Site Editing block-theme model. Instead, GeneratePress plus GenerateBlocks provides its own block-based theme-building approach. Kadence documentation likewise says Kadence does not currently provide a full FSE theme.
That does not automatically disqualify them.
If page content remains structured as WordPress blocks and you avoid a proprietary canvas such as Elementor for every marketing page, they can still fit an AI-friendly architecture.
So this is not a brand loyalty test.
The test is the content model.
Should existing Elementor sites be rebuilt?
This is where absolutism gets expensive.
New marketing website?
Block-first.
The decision is easy.
Existing Elementor site with four or five simple brochure pages?</strong
A rebuild can be relatively manageable. An experienced WordPress developer may be able to recreate a straightforward site in a day or two, depending on the design, responsive behavior, forms, tracking, templates, and integrations.
Treat that as a rough migration range, not a promise.
If the client already hates how the WordPress admin feels, or the company wants agents updating service content regularly, the economics can make sense.
Existing Elementor site that has become a directory, membership system, vendor index, or mini-application?
Do not start by ripping out the builder.
Move the actual data into the right architecture first.
Custom post types. Structured fields. Taxonomies. Database-backed application logic where necessary.
Leave the sales pages alone temporarily if that reduces migration risk.
A hybrid architecture can be messy, but sometimes messy for one quarter is smarter than trying to rebuild the entire company website in one shot.
The ugly case: 80 Elementor landing pages
There is no universal answer here.
Suppose a business used Elementor almost like a CMS and built 80 campaign pages.
Rebuilding all of them has a real cost.
Leaving all of them inside a proprietary document system also has a cost.
The deciding factor is how the business intends to operate those pages.
If they barely change, the migration may not deserve priority.
If the plan is to let an agent update prices, offers, proof, service areas, headings, CTAs, and campaign messaging every week, the architecture becomes much more important.
Those 80 pages are no longer just web pages.
They are operational inventory.
And automation gets expensive when every item in that inventory requires a vendor-specific editing path.
Who this recommendation is not for
If you are building a dealer network where vendors pay for placement, users filter thousands of listings, dealers log in, buyers message sellers, and ranking rules determine visibility, you are not really choosing a WordPress theme.
You are designing an application.
A block theme can still handle the public marketing shell.
The directory itself needs a proper data model, permissions, querying, ranking, and application logic.
Do not ask the Site Editor to become a marketplace.
The same applies to serious portals, communities, complex membership systems, and custom operational software.
And if your design team absolutely requires Elementor because that is the only environment they know how to use, acknowledge that constraint.
That is a staffing and workflow decision.
It is not proof that the architecture itself is better.
The test we keep coming back to
For a new marketing site, ask one simple question:
Can an AI agent change the headline on the services page without pretending to be a human clicking through a visual builder?
Then ask the human version:
If the AI gets it wrong, can someone open core WordPress, see the structure, edit it, review the revision, and fix it without depending on a proprietary editing canvas?
And make sure you can revoke the agent’s access when you need to.
If the answer is yes, the architecture is doing its job.
If the answer is no, think carefully about what you are locking the business into.
Page builders solved the editing problem of the last decade.
AI agents are creating a different editing problem for the next one.
For a simple marketing website, there is little reason to make that problem harder than it needs to be.
