AI SEO With a Human in the Loop: How We Do It at Macronimous

Jeffy Susan November 1, 2026 0 comments

Autopilot is the wrong promise

Every few weeks someone sends me a link to another AI SEO tool that promises to run a site’s SEO on autopilot. You connect Search Console, hand it the WordPress login, and it rewrites titles, adds schema, sets up redirects and publishes a few hundred pages a month while you sleep.

Sure. Some of these tools are honestly good at finding problems, and I’ll give them that.

But finding a problem and changing a client’s live site are two different jobs, and the autopilot tools treat them as one. A bad title tag on the page that brings in half a client’s leads isn’t a typo. It’s a phone call. And “a few hundred AI pages a month” sits uncomfortably close to what Google calls scaled content abuse in its spam policies, which is not a phrase I want anywhere near a client’s domain.

So we use AI heavily at Macronimous, for audits, for drafting fixes and for drafting reports, and we let it change nothing on its own. It’s the same thinking behind our approach to controlled AI coding. This post gets into some WordPress plumbing near the end, because that’s where most “undo” promises quietly fall apart.

What the AI hands us is a proposal

The AI’s output is never a change. It’s a proposal, and a proposal has to say what changes, on which URL, why, and what data backs it up. “Rewrite this title” doesn’t qualify. “This page gets steady impressions for a query it ranks sixth on, its click-through rate is under 1%, and here’s a title that matches what people actually type” does.

Every proposal has to carry these before it enters the queue:

• The URL and the exact field being changed
• The current value, word for word
• The proposed value
• The evidence from Search Console or the crawl
• A risk tier

If the AI can’t fill in the evidence line, the proposal doesn’t get in. That one rule throws out a lot of noise (the “add your main keyword to the H1 again” kind of suggestion that sounds helpful and isn’t).

Not every change deserves the same review

If a senior SEO person had to approve every alt-text tweak, the process would collapse inside a month and people would start rubber-stamping. Rubber-stamping is worse than no review, because it looks like review. So we tier.

Risk tier	Typical changes	Who signs off
Low	Image alt text, broken internal links and missing schema fall here.	A team member can approve these in batches, and the client sees them in the monthly log.
Medium	Title tags, meta descriptions and new internal links fall here.	A senior SEO person approves each one before it ships.
High	Content rewrites, new pages, redirects on ranking URLs, canonical tags, noindex and robots.txt fall here.	The client approves each one, and our team checks the live page after it goes out.

The redirect row is the one people argue with. Plenty of tools file redirects under low risk, right next to broken links. On a page nobody visits, fine. On a URL that ranks and has earned links over years, a redirect is a small site migration, and I’ve never met a migration that was as harmless as the ticket said it would be.

The before value gets saved first

Before anything is applied, we save the exact current value. Not a note that says “old title was about pricing.” The actual string.

I know this section is drier than the rest. It’s also the part that matters most on WordPress, because WordPress gives you a false sense of safety here. It keeps revisions of post content, so you’d assume undo is free. It isn’t. Custom fields only get revisions if whoever registered them switched that on (the revisions option for registered meta arrived in WordPress 6.4, and it’s off by default), and as far as we’ve seen, SEO plugin fields usually aren’t set up that way. Your SEO title, meta description, canonical, schema settings and redirect table mostly live outside revisions. Restore an old revision of the post and the title tag you changed last Tuesday stays changed.

Without a record of the old value, undoing an AI change means someone opening the post, guessing what the title used to say, checking whether the Wayback Machine happened to crawl that page that month, emailing the client to ask if they remember, and finally typing in something close enough, which is exactly the kind of quiet damage nobody ever reports because nobody can prove what the page said before. This is the same mess we describe in hidden technical debt in WordPress SEO, just created faster.

So we keep our own record for every change: the before value, the after value, who approved it and when. That record is what makes “one click to undo” true rather than a sales line.

Then we watch it

Once a change is live, we track that URL in Search Console for a set window after the change. We look at clicks, impressions, average position and the queries the page shows up for, and we compare them with the same stretch before the change.

Most changes don’t do anything dramatic in either direction. Some help. Now and then one hurts, and that’s the case the window exists for.

Why we don’t let software roll back on its own

Some tools undo a change automatically if rankings dip within a week. It sounds responsible. I don’t think it is.

Rankings drop for plenty of reasons that have nothing to do with your edit. Google ships core updates (it posts them on the Google Search Status Dashboard), competitors publish better pages, demand shifts with the season, and rank trackers have bad days too.

If the drop came from a core update, rolling back fixes nothing. If it came from a competitor, rolling back fixes nothing. If it came from a seasonal dip, rolling back removes a good change and teaches the system the wrong lesson.

So the system flags the drop, and a person decides. They look at what else happened that week, check the queries that moved, and then choose. The rollback itself takes one click. Deciding to click it is a human job.

Reports go through the same gate

Our monthly SEO reports start the same way. AI drafts them from the Search Console and analytics data, and then a person checks every number against the source and rewrites anything that reads like a machine trying to sound pleased with itself.

Each report also lists every change we shipped that month, who approved it and what traffic did afterward. I suspect clients read that list more closely than the charts. It’s also where our AEO work for AI search shows up, since schema and content changes for answer engines go through the identical queue.

What this costs us

It’s slower than autopilot. A medium-risk fix waits for a person, and some weeks the queue is longer than I’d like. If you want 300 AI pages a month published without anyone reading them, we’re the wrong agency, and I’d rather say that now.

What we get in return is simple to state. For any line on any client site we manage, we can answer “who changed this, when, and why?” and we can put it back. That’s worth more to me than speed, and it fits the way we’re thinking about SEO strategy for 2026 in general.

If you’re running AI on client sites and you’ve found a cleaner way to handle rollback, I’d like to hear how you do it.