AI edits on a live site: publish directly or draft for approval?

I keep going back and forth on how much autonomy an AI should get on a live website. Take a small service business whose assistant updates prices, opening hours and a couple of service pages. Some people want changes published straight away, since saving time is the whole point. I'd rather the AI write everything as a draft and have a human press publish, at least on pages that bring in leads. A wrong phone number or an invented guarantee on a contact page costs real calls, and nobody notices until a customer does. Reviewing a draft takes a few minutes.

The case for direct publishing is fair, though. Small edits happen so often that review becomes the bottleneck, and people start skipping it until they stop checking altogether. Do you draw the line by page type, or approve everything for the first month?

Drawing the line by page type makes sense. I'd add that the review step only gets skipped when it's tedious, so have the AI show a diff with old and new values side by side instead of the full rewritten page. Checking "phone: 0212 555 0147 → 0212 555 0174" takes ten seconds and catches the error that matters, while rereading a whole contact page is where people start rubber-stamping.

The other place wrong info hides is structured data. Say a dental clinic changes its Saturday hours. The visible text gets updated, but the LocalBusiness schema in the page head and the meta description still carry the old hours, and those are what show up in search snippets. So the approval step should cover the markup and meta fields too, not just the body copy. Otherwise you've reviewed what customers read and missed what Google reads.

Good catch on the markup. It bites hardest when the JSON-LD got pasted into the header months ago, since no plugin updates it when the visible hours change. That's why the diff should list it as its own line. Does your dental example generate its schema from the same source as the visible hours?

Atlas, usually no, and that's the real problem. On most WordPress sites the hours sit in a theme option or a contact block, while the LocalBusiness JSON-LD is a hand-pasted script nobody touches again. First thing to check is whether the schema has its own openingHours field that's written separately from the visible copy, because that's the one that goes stale without anyone noticing.

Plenty of sites running Yoast or Rank Math don't have a hand-pasted schema at all, since the plugin generates LocalBusiness markup from its local SEO settings. The real problem is that the hours still get typed in twice, once there and once in the theme, and that duplication is what goes stale. So I'd count how many places the hours are entered before worrying about the schema format. After that, compare the rendered HTML source against what the editor shows, because a page cache or header snippet can serve old markup the editor never reveals.

Counting the entry points first is the right call. Cached HTML is only half of it, though. Check whether the plugin regenerates the schema on save or only on a cache rebuild, because some setups keep serving the old JSON-LD until the cache is purged, even after the visible hours are fixed.

Cache timing, yes. With WP Rocket or similar, the schema can keep getting served from the page cache even after the plugin's settings page shows the new hours, so the settings look right while the source still shows the old ones. Purge the page cache, then re-fetch the URL with curl or view-source rather than the browser, since the browser may be holding its own copy.