This hits a real pain point, the constant tab-hunting overhead is underrated until you're past a dozen sites. I'm at 37+ across clients and agency work, so workspace-per-client is the right mental model. Any plan for syncing across machines, or intentionally local-only for simplicity? Five days with Claude Code to ship is a solid turnaround, what was trickiest, the new-tab override or the storage/persistence layer?

Headless WP setup is exactly the kind of repetitive work that should be solved once and reused, especially the custom field mapping, that's usually where teams hand-roll the most boilerplate. Curious how it handles relationship fields (ACF repeaters, post object fields) since that's typically where auto-generated endpoints start to struggle. I'm working through a similar problem on the Astro side right now, the field mapping logic ends up looking different once you're consuming the API rather than just generating it. Would like to test yours against a non-trivial content model.

Code gets reviewed, admin panels don't. That's the gap. The fix is treating shared config like code: versioned, diffed, flagged when a site's actual state drifts from the source of truth. Most WordPress tooling isn't built for that, so it ends up needing custom tracking.

That framing resonates exactly. It is rarely one decision that causes the problem. It is a handful of small ones made at different times by different people, each reasonable in isolation, that collectively push sites in different directions. By the time it becomes visible, tracing it back is difficult.

On your question: in my experience, configuration drift and unexpected admin changes are usually the bigger source than the automation itself. Automation tends to fail visibly. A broken workflow stops working and someone notices. Configuration drift is quieter. A plugin setting changed here, a custom field structure modified there, a cron job adjusted without documentation. None of it breaks anything immediately, but months later the sites behave differently in ways that are hard to diagnose.

The automation actually helps with this in one specific way: if the automation expects a consistent environment and something has drifted, it tends to surface the inconsistency faster than a manual workflow would. But that only works if the automation is tight enough to notice.

What has helped most for me is treating shared configuration as something that needs a single source of truth rather than something each site owns independently. Once that shift happens, drift becomes easier to detect and correct.

Managing consistency across 30+ WordPress sites — what actually breaks first?

I currently manage over 37 WordPress sites across direct clients, agency work, and white-label partnerships. Different stacks, different hosts, different plugin sets, different update cadences.

The technical work is manageable. What gets harder as the number grows is consistency.

Not plugin versions or core updates. Those have solutions. The harder problem is everything underneath that.

When you add AI workflows, custom rules, or automation to one site, keeping those consistent across the rest becomes its own project. The same instruction that works cleanly on site one behaves slightly differently on site five because the setup drifted somewhere along the way. Nobody noticed at the time. It just accumulated.

What I have been finding is that the real consistency problem is not technical. It is operational. How do you define shared rules once and have every site use the same definition? How do you update a workflow in one place and have it reflect everywhere without manually touching each site?

Curious how others are approaching this at scale.

Are you handling each site independently and accepting some drift? Keeping shared rules somewhere central? Or have you built something that actually solves it? #wpfolks #wordpress #question #feedback