I tested WordPress 7 recently, and honestly the AI changes are bigger than most people realise. The new centralized AI system could make AI plugins way cleaner long-term.
I’d still recommend testing on staging first if you use Elementor or WooCommerce heavily.
TL;DR: Small SEO agency, mostly templated local-business sites, moving off Elementor, and looking for the best long-term WordPress workflow using the block editor, patterns, block themes, theme.json, cloud pattern hubs, and possibly the new Capabilities API.
I’d love input from people who build a lot of client WordPress sites and have opinions about sustainable agency workflows.
I’m working with a small agency in a very niche local small-business SEO space. Most client sites have a lot in common: similar content types, similar lead-gen goals, similar local SEO requirements, and a lot of templated/repeatable page structures. There is also a fairly heavy content publishing component because the niche is competitive. Our team is small: usually 1–2 developers, an account manager, a writer, and a designer.
Right now Elementor is a major bottleneck for us, and we’re trying to think longer-term rather than just swapping one page builder for another. The goal is to create a WordPress development system that is efficient for a small team, supports templated/local SEO builds, lets non-developers work safely, and stays stable/maintainable for the next 5 years.
If you were starting from scratch today, what would your ideal workflow and stack look like?
A few things I’m especially interested in:
• Would you go all-in on the block editor / block themes / theme.json / patterns?
• Would you use a lightweight block library, mostly core blocks, or invest in custom blocks? I personally have a lot of experience with Kadence and seems like creating a cloud pattern hub for the reputable elements would be helpful here
• How would you handle templated page types for local SEO without creating a brittle mess?
• What would you standardize across all builds: starter theme, patterns, CPTs, custom fields, SEO tooling, forms, schema, analytics, etc.?
• How much would you rely on synced patterns versus custom block development?
• For a small team, what should writers/account managers be able to edit safely vs what should stay developer-controlled?
• If your goal was “stable for 5 years,” what would you explicitly avoid?
• Has anyone started factoring the new WordPress Abilities API / capabilities-style agent tooling into their long-term architecture, or is that still too early for real agency workflows?
I’m especially interested in answers from people who build lots of repeatable service-business or SEO-oriented sites, not just one-off custom brochure sites.
If you had to choose a practical, durable stack for this exact situation, what would it be and why?
I'm trying to build out an API for animal shelters based on wordpress custom post types and it's meta fields...
The front end will be based on node.js and tailwind css and react or something like that...
So that the backend can stay the same for every client but the frontend is interchangeable.
Any ideas or thoughts?
Hey everyone,
I was browsing around recently and noticed some marketing tactics by Multidots that felt pretty misleading, and I wanted to see if I'm the only one bothered by this.
First, they published a "Behind the Build" article for the White House website. If you just look at the layout and the way it’s framed, it reads exactly like one of their own case studies. The actual build was famously done by 10up. Yes, if you dig into the text, they eventually acknowledge it's not their work, but the whole page feels intentionally designed to mislead visitors into thinking they were behind it. Taking credit (even implied credit) for another agency's flagship project just feels incredibly sketchy.
Second, I noticed they are running and publishing the domain `sitecoretowordpress.com`. Aside from the aggressive marketing angle, isn’t having both "Sitecore" and "WordPress" directly in a top-level domain a blatant trademark violation for both brands? I thought the WP Foundation was explicitly strict about not using "WordPress" in domains like this.
Am I overthinking this, or are these kinds of shady tactics becoming more common? It just feels like a really bad look for the ecosystem.
I am curious what others in the agency space are actually doing here — not what the ideal workflow is, but what you are actually doing.
The options I have seen:
Option 1 — Update directly on production, check afterward. Most common. Fast. Works until it doesn't. One bad Friday afternoon of a client's e-commerce site going down is usually enough to change this approach.
Option 2 — Staging environment per site. The right approach. The overhead of maintaining staging for 20+ client sites is significant. Most managed hosts now include staging (Kinsta, WP Engine, Cloudways) but it is still manual work to clone, update, test, and push.
Option 3 — Update one plugin at a time, carefully. The "manual discipline" approach. Works reasonably well if you have fewer than 10 sites. Does not scale.
Option 4 — Batch updates by site importance. Update lower-risk sites first (simple brochure sites with no e-commerce), wait a few days to see if any issues emerge in the wild, then update higher-risk sites (WooCommerce, membership sites, anything with active transactions).
What is your actual approach? And how do you handle the client communication side when something does break despite your best precautions?
My website is in wordpress and having more than 1300+ blogs for this rendering on UI becomes very slow, I am thinking to use HeadLess CMS Wordpress and for frontend Next.js/React.js .
Anyone here who has convert his/her website like this?
What are the issue I can get in future related to SEO and other stuffs , if a admin/author post new blog how its going to render also as I know I am going to use Wordpress RestAPI if it fetches this much does it going to affect Server where my domain is hosted ?
I've been running a WordPress site for around 5 years. Recently, I've been working with AI to help build prototypes, which it is very adept at.
One of the things I'm seeing is a bit of a collision between highly maintainable WordPress blocks, and quick and beautiful AI-generated code that is by nature less maintainable. I'm finding more of my site is becoming custom HTML code to achieve the look I want.
I'm interested in this community's opinion on what ends up bridging the gap here. The speed at which one can create fast HTML/JavaScript based websites with AI is not something that will be lost on both new and experienced website builders, and yet WordPress still dominates internet web sites not only for its CMS but also its ability to build and maintain sites very easily.
I'm not an expert here, so I'd love to hear the up close view from the experienced crowd here.
I just woke up to find that I've lost the TEC website, its redirecting to somewhere else!! anyone faced the same issue?
Hi guys,
I’m currently auditing my infrastructure costs and planning to move 32 client sites. I'm torn between sticking with a giant like WPMUDEV or going with KloxStudios.
The price difference between the two is significant. I know WPMUDEV is the industry standard for "all-in-one" plugin ecosystems, but KloxStudios offers a bundle that seems to cover the essentials (especially their security tools) for a fraction of the price.
Has anyone here made the switch to Klox or used them for agency-level hosting? I need to know if their performance holds up or if this is a "get what you pay for" situation. I have to pull the trigger by Monday, so I'd appreciate any real-world experience regarding their uptime and plugin stability.
Cheers!
I've been a fan of the Blocksy theme myself, but I still find myself needing a blocks plugin to use on top of Gutenberg.
Kadence (theme + blocks plugin) had one of the better offerings than the competitors, especially in the free version. It's one of the more recommended tools for performance in this subreddit as well. GeneratePress, although lean and clean, is quite limited in terms of even the basic features.
Greenshift is a great option, but it takes an FSE approach, so I guess it's not exactly a drop-in replacement for Kadence.
Are there any other theme + blocks plugin combinations that you guys recommend for people trying to move away from Kadence, and what appears to be a highly incompetent company, Liquidweb?
WordPress 7.0 lost its headline feature yesterday. The infrastructure story underneath is more interesting, and it's already in production.
Yesterday Matt pulled RTC (real-time collaboration) from WordPress 7.0. RC4 ships May 14, final on May 20, RTC has no new target version.
Most of the coverage I've read frames this as "WordPress lost its headline feature." Which is true. But I think the more interesting question is the one nobody seems to be asking yet:
If RTC isn't the infrastructure shift in WordPress 7.0, what is?
The answer is hiding in plain sight. While everyone covered RTC for six months, WordPress quietly shipped a complete AI infrastructure stack across 6.9 and 7.0:
@wordpress/abilities and @wordpress/core-abilities packages. Auto-fetches server-registered abilities via REST. Explicitly described in the dev notes as "laying the groundwork for browser agents and WebMCP integration."That's not one API. That's a complete platform shift. WordPress 7.0 is the first version of WordPress that ships AI infrastructure as a first-class core concern, with the same architectural commitment that the REST API got in 4.7 or Gutenberg got in 5.0.
I've been building production infrastructure on top of this stack as a solo dev for the last five months. Wanted to share what I've learned, because I think a lot of the same engineering problems that pulled RTC are about to show up in AI-agent territory and this community is going to be the one that has to deal with them in the field.
In one sentence: the difference between "AI generates HTML you paste in" and "AI safely edits the right field in the right module on the right page builder, with the right validation, on a real client site."
Every page builder stores content completely differently:
post_content_fl_builder_data post metaAn "AI plugin" that writes HTML and hopes the renderer figures it out doesn't survive contact with real client sites. You need schema-aware adapters per builder. The Abilities API is the standard registration layer that makes this tractable across plugins. WP AI Client gives every plugin a uniform LLM surface. Connectors API solves credentials at the platform level. Without all three, every plugin reinvents the same wheel and the ecosystem fragments.
With all three in core, the ceiling lifts substantially. We're going to look back at 6.9 + 7.0 the same way we look at 4.7 (REST API) and 5.0 (Gutenberg).
This is the part I find genuinely interesting and want to hear pushback on.
The five concerns Matt cited for pulling RTC: surface area, race conditions, server load, memory efficiency, recurring fuzz-test failures. Read carefully, all five describe the same family of consistency bug. The database accepts a state both clients agree on. Neither client's local renderer can reconcile it. Persistence is honest. The render layer isn't.
Two cursors typing in the same paragraph. The system has to decide which edit wins, how to merge, how to surface what happened.
Now look at AI agents editing the same WordPress site. An LLM writes a payload. The plugin endpoint accepts it. The database updates. The response says success: true. The page renders blank or wrong because some flag, some cache, some template reference, some selector specificity got missed.
Different mechanism. Same family of bug. The success signal lies.
I spent two months hunting an Oxygen Classic empty-render bug for one customer. Eight releases. Every patch fixed something real and still produced the same blank page. The final fix was that Oxygen's CSS regenerator expects integer ct_id values. The writer was emitting string GUIDs. The lookup missed silently. CSS never regenerated. The page rendered without its styling. The API said success the whole time.
Same family of bug as the RTC concurrent-edit problem. Different surface. Same engineering question core is now wrestling with at the platform layer.
These are the lessons that cost me real time. Sharing them because I think the community is about to need them.
If your plugin exposes an ability that writes to a page, HEAD-fetch the preview URL after the write completes. Check the rendered output. If it doesn't reflect what you just wrote, surface partial_write: true with structured trace fields. Don't trust your own success responses.
This is non-negotiable. The AI agent calling your plugin does not have eyes on the page. It only has your response. If your response lies, the agent confidently tells the user "done" while their site is broken. Same shape of failure RTC ran into; same shape of failure every plugin shipping on the new AI stack will run into if it doesn't gate the write.
Full state snapshot of post_content plus post_meta plus builder-specific data plus ACF fields, captured immediately before any AI write touches the post. Restore in one click.
This is the foundational safety primitive for AI editing WordPress. Not a feature, not a "premium" thing. The minimum viable safety story. Builder support without snapshot is playing with fire on production sites.
The temptation is to build a generic AI editing plugin and hope it works across builders. It won't. Every page builder needs its own adapter that understands its specific data model, its specific render path, its specific cache invalidation requirements.
This is the part that takes time. There's no shortcut. The Abilities API gives you the registration layer; WP AI Client gives you the LLM-side abstraction; Connectors API gives you credentials. The per-builder intelligence is still the work, and it lives outside core.
The pattern Gutenberg followed for major features was: feature plugin first, extended community testing, then core inclusion. Full Site Editing went through this. Block Patterns. The Site Editor. RTC will probably follow the same path now.
I'd argue AI-agent infrastructure follows the same path, with the foundation already in core. The Abilities API + WP AI Client + Connectors API are the platform commitments. The per-plugin implementations and the cross-plugin patterns are going to mature in the field first, then stabilize, then probably show up as more opinionated core APIs in 7.2 or 7.3.
The agencies and freelancers in this subreddit are going to be the ones who run that maturation. You're going to hit the silent-fail bugs. You're going to find the cache-invalidation gotchas. You're going to discover which builders need which adapter shapes. You're going to figure out which workflows actually want WP AI Client's abstraction layer and which want raw MCP. The work happens in the field, not in core.
I'd love to hear from anyone who's already touching the new AI stack on real client sites. Abilities API, WP AI Client, Connectors API, all three? What are you running into?
I build Respira for WordPress, an independent AI infrastructure layer for WordPress. Five months solo from Brașov, Romania. We support 12 page builders. Our biggest release shipped yesterday, same day RTC pulled from 7.0 (genuinely a coincidence).
Public live telemetry: 752 connected sites, 3.4M lines of code shipped through customer projects since March, 42K MCP events, zero API errors this week. The dashboard at respira.press/live updates every sixty seconds and is the place to verify any number I just cited.
Free Lite version is in the WordPress.org submission queue. Should land in a few weeks.
I'm in the comments for the rest of the day. Happy to go deep on:
If you want the longer write-up of how this week unfolded (six releases, the Oxygen arc, why the API not lying matters), it's on my Substack at respira.love. Not selling anything there either; it's free.
--Mihai, Respira for WordPress (respira.press)
Hey all — looking for some honest answers from folks who manage multiple client sites for a living.
I'm trying to understand a specific failure mode better: the one where the site is technically "up" — homepage loads, returns 200 — but something is actually broken. Contact form silently failing, checkout throwing an error after the button click, a plugin update killing the booking widget, etc. The kind of thing your monitoring doesn't catch because it's looking at the wrong thing.
Not pitching anything, not selling anything. I'm trying to figure out if a thing I'm thinking about building is solving a real problem, and I'd rather find that out from people doing the work than from my own head.
Happy to share back what I learn if there's interest.
I have to create a new Wordpress website, and I want to plug Claude to be able to create or modify pages with ease. I thought about creating few templates and use them to create pages. What is the best way (and easier way) to do that?
Thanks
