Category: Agency

A quiet thing happened in WordPress over the past eighteen months. Block themes plus the Site Editor became good enough that a meaningful percentage of new sites we build do not need a page builder at all. Here is what changed, what that means for agency workflows, and what is still worth keeping the page builder for.

What block themes finally got right

• Reusable patterns. The pattern library replaced 70 percent of what we used Elementor templates for. Clients edit them in the same UI they edit posts.
• Global styles via theme.json. Colours, typography, spacing, button styles. Changes feel atomic, do not require touching a builder’s settings panel.
• Template parts. Header, footer, query loop, 404 — editable in the Site Editor by anyone with the right capability.
• Performance. Block-theme sites ship measurably less CSS and JS than typical page-builder sites. The default Lighthouse score is higher with no extra work.

What this means for agencies

Three shifts we have made over the past year:

1. New brochure sites default to a block theme. No Elementor unless the client specifically asks. Build time is the same; maintenance burden is lower.
2. Existing page-builder sites stay on the page builder. Migration cost is not worth the marginal benefit. We do not refactor working sites.
3. Page-builder skills still matter, just for different sites. Stores, landing pages, anything with heavy custom layout per page — the builder still wins. The “every site needs a page builder” assumption is what changed.

Where page builders still win

• Landing pages with bespoke layout per page. The Site Editor is designed for templated content; landing pages are by definition not templated.
• WooCommerce product page customisation at the per-product level. Builders handle this well; block themes still feel awkward.
• Clients who want to drag. Some non-technical editors genuinely prefer the visual builder UX. That is a valid reason on its own.

Where neither wins and you should hand-code

Sites with a strong design system that the client will not edit. A small custom theme is faster to build, ships less code, and is easier to debug than fighting either the block editor or a page builder. This is a smaller portion of work now than it was, but it has not gone away.

The honest take

Page builders are not dying. They are becoming optional for a class of sites where they used to be the default. That is a real shift, and the agencies that adapted their tooling around it are shipping faster sites with less code. The agencies that did not are paying license fees for builders they no longer needed.

Audit your default build stack at the start of every year. If it has not changed in three years, the ecosystem changed and you missed it.

Managing five WordPress sites is a side project. Managing fifty is a job that breaks ad-hoc tooling. The gap is real and it happens around the fifteen-site mark. Here is the small stack that lets a two-person team run a 50-plus-site portfolio without firefighting.

The three jobs that have to be automated

Three categories of work scale linearly with site count and are the first things to break:

1. Updates. WordPress core, plugins, themes. Five sites: do it by hand. Fifty: you need rolling automated updates with rollback on failure.
2. Backups. Off-site, automated, with quick-restore tested at least quarterly.
3. Health monitoring. Not just “is the site up”, but “are there new PHP errors, slow queries, missing assets, broken cron jobs”.

The stack we run

• WP-CLI driven from a small bastion server. Every site checked in to git. Updates triggered by a cron that runs wp core update; wp plugin update --all, then wp eval-file a smoke-test script and rolls back on non-200.
• UpdraftPlus or BackupBuddy to S3 with weekly full + daily incremental. Restore tested monthly on a staging environment.
• Uptime monitor (UptimeRobot, Better Uptime, anything reliable) on the home page and one deep page per site.
• Log shipping from wp-content/debug.log to a central syslog or a service like Papertrail. Catches the silent fatal errors that uptime monitoring misses.
• Weekly dashboard email aggregating “what changed across all sites” — outdated plugins, security alerts, traffic deltas. The fastest 30 seconds of management we do all week.

The mindset shift

At small portfolio sizes you can react to problems. At fifty plus, you cannot — by the time you notice a broken plugin update on site 12, sites 18, 23 and 34 already have it too. The shift is from reactive (“client called, fix it”) to proactive (“dashboard amber, fix it before client notices”). That is a tooling shift, not a discipline shift.

What we stopped doing

• Logging into wp-admin on individual sites to check anything. If we cannot answer it from the central dashboard, we add it to the dashboard.
• Per-site Slack channels. One client portfolio channel with @mentions for blocking issues.
• Manual plugin updates. Even when “I just want to update Yoast on this one”. The exception becomes the rule.

The fifty-site mark is the size where small process investments pay back inside a quarter. Make them.