Full-site editing in WordPress has matured enough over the past couple of years that this year we started offering it as the default for new client builds, rather than the classic theme approach we'd defaulted to previously. The shift wasn't purely technical; it changed the working relationship we have with a meaningful share of our clients, moving a category of small change out of our queue and into theirs.
Clients can now adjust headers, footers, and page layouts themselves through the block editor, which has meaningfully cut the volume of small layout-tweak tickets landing in our support queue. Requests that used to require a developer, moving a section, adjusting spacing, swapping which pages appear in a footer menu, are now things a reasonably comfortable client can do themselves in the WordPress admin without touching code or filing a ticket at all.
That said, the transition wasn't purely additive. A few long-standing clients who'd grown used to submitting a quick request and getting it handled by us were initially less enthusiastic about being handed the keys, since the change also meant more responsibility on their end for changes they'd previously outsourced entirely. We ended up offering a short onboarding session for full-site editing to every client migrating onto it, walking through the block editor's global styles panel and template parts, which noticeably improved adoption compared to just pointing clients at WordPress's own documentation and hoping for the best.
Not every client build has moved to full-site editing yet; a few sites with heavily customized layouts built on older block themes are staying on the classic approach until a planned redesign gives us a natural point to migrate them rather than forcing an disruptive mid-cycle change. For genuinely new builds, though, full-site editing is now the clear default, and the reduction in small-ticket support volume alone has made the switch worth the initial onboarding investment across the client base we've moved so far.
Theme choice mattered more than we initially expected when picking a foundation for these builds. Early on we tried a couple of community block themes that looked polished in their demo screenshots but turned out to have inconsistent support for the specific global styles panel features we wanted clients to rely on, spacing presets and color palette locking in particular. Switching to a more actively maintained base theme with better global styles coverage resolved most of the inconsistencies, and we now maintain a short internal checklist of full-site-editing features a candidate theme needs to support well before we'll consider it for a new client build.
We also had to rethink how we scope client training, since "full-site editing" covers a wide range of actual capability depending on the theme and the specific blocks in use. Rather than a single generic training session, we tailor the walkthrough to whichever template parts and patterns are actually relevant to that client's site, which takes slightly more prep time per client but has produced noticeably fewer confused follow-up support tickets in the weeks immediately after handoff compared to our first attempts at a one-size-fits-all training approach.