The dash was ours first

The first post on this blog went up on 19 February 2008. There are 372 of them now. I’ve written a lot of them, and I have a habit: I use dashes – not always the proper long one, often just the short one with a space on either side, because that’s what the keyboard gives you.

Go and look at December 2013. One post is titled “Does CDN help SEO? – CDN, Google, Page speed and ranking factors.” Another one, the same month, has a dash in its title too. ChatGPT was nine years away.

Today a dash in a blog post gets read as a machine’s fingerprint. So do neat lists, tidy paragraphs and polite openings. Which is a bit rich, because the machines learned all of that from people like us (and, I suppose, from us). We even published a piece this April about a CMS that is actually called EmDash, which didn’t help.

So here’s the odd new job. It isn’t enough to write as a human anymore. You have to write as a human who can’t be mistaken for a machine. Human-human, if you like.

So why is my writing flagged as AI?

Short answer: because you write the way models were taught to write, and they were taught by people like you. So the first thing everybody tries is scrubbing out the habits. It’s the obvious move, and you can’t win that way.

You take out the dashes, and then someone says the real giveaway is the word “delve,” so you take that out, and then it’s groups of three, and then it’s any sentence shaped like “it’s not this, it’s that,” and then it’s being too polite, and by the time you’ve removed every habit a model picked up from human writers, which is all of them, because that’s where it got them, what’s left is a flat, careful page that sounds like nobody at all, which is, of course, exactly how a machine sounds.

The list of tells changes every few months anyway. Dashes were the 2024 tell. I don’t know what next year’s will be, and neither does anyone selling you a checker.

About those checkers. A Stanford team ran seven popular AI detectors over 91 essays written by people for the TOEFL (Test of English as a Foreign Language). The detectors wrongly flagged about 61 percent of those human essays as AI-written, while scoring essays by American eighth graders almost perfectly. That paper is from 2023 and the tools have changed since, so treat the number as a warning more than a measurement. Still. We write from Coimbatore, India, for readers in the US, the UK and Australia. You can guess which pile we’d land in. If you’ve been falsely accused of using AI, this is probably why, and it says nothing about your writing.

And yet the worry behind all this is fair. Merriam-Webster made “slop” its word of the year for 2025. People aren’t imagining the flood. They’re just using the wrong test to spot it.

Yes, I use AI to write. Here’s how.

I’d rather say this plainly than have you wonder. A model typed the first draft of this post.

What I don’t do is ask it for “a blog on a trending topic.” That’s where slop comes from: the machine supplies the thinking and a person supplies the publish button. I do it the other way round. I bring the idea. I give my opinions, my own inputs, what I’d recommend, and a clear path for the argument to take. Then I work on what comes back. I ask for it again, more than once. I add views it missed. I delete the stereotypes (there are always stereotypes).

That’s closer to working with a ghostwriter or a patient editor than to pressing a button, and writers used both long before 2022. It’s the same idea we follow in code, where the AI works inside limits a person sets.

Google, for what it’s worth, isn’t asking anyone to pretend either. Its guidance on generative AI content cares about accuracy, quality and relevance, and suggests telling readers how a piece was made. So I’m telling you.

Where the slop sneaks back in

Here’s the part that’s easy to miss. The ideas are yours, so you assume the post is yours. But readers judge the sentences first, long before they reach the idea, and the sentences are still the model’s.

Two things happen in that gap.

The model smooths your opinions. You say “this is a mistake.” The draft says “this may not be ideal for every business.” Same topic, no spine. It’s worth checking that every opinion survived at full strength.

And the model keeps its own mold. Your input gets poured into a warm-up opening, even-sized sections and a summary at the end. You can delete a hundred clichés and still be left with the biggest one, which is the shape.

The fix is smaller than it sounds. If you only have time to hand-write three things, make them the opening, the ending, and the lines where you take a side. Those carry most of the voice. The middle can stay drafted and, as far as I can tell, nobody notices.

What works on every post

You can’t tell a story from your own history every time. We certainly can’t, not across 372 posts. These don’t need one.

• The post takes a side. “Most agencies do X, and we think that’s a mistake” needs no anecdote, only nerve.
• Each section has one detail only a doer would know. Generic: “caching can cause issues on stores.” Practitioner: “on older WooCommerce stores, a full-page cache shows every visitor the same cart count unless the cart fragments call runs, and that call can’t be cached, so it ends up the slowest thing on the page.”
• The depth is uneven on purpose. Skip what the reader already knows and spend 400 words on the one thing that matters.
• There’s one honest “it depends,” in the one place where it really does, and it says what it depends on.
• The warm-up opening and the summary ending are gone. This costs nothing.

When you do have history, use it, because it’s the one thing nobody can copy. In November 2016 I wrote about a client whose designer left with every server password, and I put four exclamation marks in one sentence, followed by “Wow!” It isn’t elegant – but somebody was clearly upset when they typed it, and models don’t get upset.

The test I use now

If you came here asking “why is my writing flagged as AI,” I’d gently suggest that’s the wrong thing to fix. I’ve stopped asking “does this look human?” as well. The answer changes with the fashion.

If the answer is yes, it’s slop, whether a person or a model typed it (content farms were turning it out by hand long before 2022). If the answer is no, the post proves itself, dashes and all. That matters for search as well, and it’s a big part of how we’re approaching SEO in 2026.

(There are three dashes in this post, by the way. One of them sits in a title from 2013. I’m keeping all three.)

If you’ve found a better test, write it in the comments and I’ll add it here with credit.

The post Why Is My Writing Flagged as AI? We Used Dashes Before the Machines Did first appeared on Macronimous Blog.

Last October I published a post on moving from WordPress to headless about the promised blazing-fast performance. I still like the architecture. I’d write that post differently today, though. It told you what headless does well, which is the half every agency tells you (ours included, if I’m honest), and it skipped the half you only learn after the invoice arrives.

So this is the other half. It’s for business owners and marketing managers who’ve been told headless is the upgrade, and who’d like to know what they’re signing up for before somebody quotes them for a Next.js rebuild.

Is headless WordPress faster than regular WordPress?

Sometimes. But the site people usually compare it against is a slow WordPress site, and that’s an unfair fight.

A traditional WordPress page behind full-page caching is already a static HTML file by the time a visitor asks for it. Put a CDN (content delivery network) in front, or use Cloudflare’s APO (Automatic Platform Optimization) for WordPress, and that file gets served from a data center near the visitor. That’s the same trick a headless Next.js front end uses. On first load, the gap between the two is often small.

Where headless can actually lose is after the page appears. The browser still has to download and run the JavaScript bundle before buttons and menus respond, and Google measures that responsiveness with INP (Interaction to Next Paint), one of the Core Web Vitals. A marketing page carrying a heavy React bundle can pass the loading test and fail the interaction test.

Then there’s freshness. Pre-built pages go stale, so frameworks regenerate them on a timer or when WordPress sends a webhook (Next.js calls this incremental static regeneration). When that webhook fails quietly, your editor updates a price, clicks Publish, and the live site keeps showing the old price until someone spots it. Nothing’s broken, exactly. It’s just one more moving part that didn’t exist before.

Headless WordPress security: better, but not the main reason

Let’s give headless its due here. It does improve security, and I won’t pretend otherwise.

Visitors never talk to WordPress directly. The public pages are pre-built files or come from a separate front end, so a flaw in a plugin that prints something into your pages isn’t exposed to the public the same way. The login page and the API can sit on a private subdomain behind IP rules. And when a bot floods the site, it hits the front end and the CDN, not PHP and MySQL.

But WordPress still runs somewhere, usually on the same hosting it ran on before. Its REST API (the data feed your new front end reads from) is public by default, and out of the box it will list your authors’ usernames at /wp-json/wp/v2/users to anyone who asks. Every plugin on that backend still needs patching. And now you also have a Node.js host, whether that’s Vercel, Netlify, or your own server, with its own packages, environment variables, and deploy keys to look after. The security gain is real, but only if someone locks down the backend and keeps patching both halves for as long as the site lives.

The team at Tars wrote an unusually candid account of running their blog on headless WordPress with Next.js. The front end did stop a struggling WordPress server from taking the whole site down, and that’s a real win. But they found the backend was just as fragile as before; they’d only moved the place where they had to deal with it. They ended up adding timeouts and teaching their cache to tell “this post was deleted” apart from “the API didn’t answer.” In May 2026 they moved their marketing content off WordPress altogether.

Here’s the thing, though. Most of that protection is available to a traditional WordPress site too. A WAF (web application firewall) such as Cloudflare’s, an IP-restricted login, fewer plugins, and updates that actually get applied will close most of the same doors, for a small fraction of what a rebuild costs. So count better security as a bonus that comes with headless. If it’s the main reason on your list, harden the site you have first. The real reasons to go headless are in the checklist further down.

Headless WordPress backend overhead on large sites

This is the part that bites large sites hardest, and I’ll admit it wasn’t in the first draft of this post.

On a traditional WordPress site, a page cache does most of the work. The first visitor makes WordPress build the page, and the next ten thousand get a saved copy. PHP and MySQL barely wake up.

Headless changes who’s asking. Your front end now calls WordPress for data when it builds pages, when it regenerates them, when an editor previews a draft, and on any page rendered at request time. Most page-cache plugins don’t cache REST API responses by default. And a single GraphQL query through WPGraphQL can pull posts, authors, categories, and custom fields in one nested request that’s expensive to run. So the server you thought you’d demoted to “just the admin” has become an API server, and it needs to be sized like one.

At scale, it compounds. A site with tens of thousands of product or article pages can’t rebuild everything on every publish, so it leans on on-demand regeneration, which means live traffic keeps reaching WordPress anyway. Then come the add-ons: object caching with Redis, a cache for API responses (WPGraphQL Smart Cache exists for exactly this reason), purge rules that have to agree across WordPress, the CDN, and the front end, a staging copy of both halves, and monitoring for an API that isn’t allowed to time out. Media usually still lives in WordPress too, so image traffic and storage don’t move either.

None of this is exotic for an enterprise team. But it’s a second hosting budget and a second operations job, and it belongs in the estimate before anyone signs.

Which WordPress plugins stop working when you go headless

The theme isn’t the only thing a headless front end replaces. Anything a plugin used to print into your pages is gone, because the pages don’t belong to WordPress anymore.

None of this is impossible. We’ve written about JavaScript SEO, canonicals, and schema before, and every row in that table can be solved. But you’d be paying, by the hour, to re-solve problems WordPress had already solved for you.

How headless WordPress affects your content editors

Developers tend to love headless builds. Editors tend to put up with them.

On a regular WordPress site, a marketing manager can spin up a campaign landing page on Tuesday morning and share it by lunch. On a headless site, a new layout usually means a new component, and a new component means a ticket, a developer, a code review, and a deploy. Preview may or may not show what the live page will look like. The block editor might still be there, but the front end only renders the blocks someone has written code for (anything else just doesn’t show up).

That’s fine for a product team that ships weekly anyway. For a five-person marketing team that used to be self-sufficient, it’s a real loss, and it rarely comes up in the sales call.

The hidden costs of headless WordPress

You’re paying for two hosts. You’re paying for two sets of updates. You’re paying a React developer for jobs a content editor used to handle alone. And you’re paying, sooner or later, for someone to work out why the build failed on a Friday afternoon.

The build itself is the part everyone quotes, and it’s rarely the part that hurts, because the ongoing work is where headless quietly gets expensive: every WordPress update now has to be tested against an API your front end depends on, and every new plugin has to be checked for whether it even exposes its data to that API, so a job that used to be “update and eyeball the homepage” becomes a two-person, two-repository exercise that somebody has to schedule, and on most small teams that somebody doesn’t exist.

It’s the same kind of hidden technical debt that builds up in overgrown WordPress sites. It’s just split across two codebases now, and two invoices.

When headless WordPress is the right choice

I realize an agency with a headless service page is an odd source for this post. Fair enough. We do build these, and for some projects nothing else makes sense. Headless is usually worth it when most of these are true:

• The same content has to feed a website plus a mobile app, a kiosk, or another product.
• You have JavaScript developers on the team, or you’ll pay for them every month, not just during the build.
• Your editors are happy with structured, form-style editing and don’t need a visual page builder.
• The site has app-like features, such as logged-in dashboards or heavy interactivity, that a WordPress theme would fight.
• You’ve already tried caching, a CDN, a leaner theme, and fewer plugins, and the site still isn’t fast enough.
• You’ve budgeted to run and scale the WordPress backend as an API server, not just to build the front end.
• Nobody on the project is choosing headless mainly because it sounds modern.

If you ticked two or fewer, fix the WordPress site you already have. It’s cheaper, and it’ll probably be faster than you expect. For what it’s worth, this blog is a plain WordPress install (Classic Editor and all) on InMotion hosting.

Headless WordPress FAQs

So, is headless WordPress worth it?

Headless WordPress is a good tool that gets sold to the wrong customers. If you run a headless site and think I’ve got part of this wrong, tell me in the comments. I’d like to know which parts held up for you.

The post Is Headless WordPress Worth It? The Pros, Cons, and Hidden Costs first appeared on Macronimous Blog.

What happened on a Tuesday

On the 8th of September, macronimous.com’s admin went from sluggish to unusable. Opening Pages took long enough to make coffee. By the Wednesday, visitors were getting Cloudflare’s 524 timeout page on the front end, which means Cloudflare reached our server, asked for the page, and gave up waiting after a hundred seconds. The site has been on the same WordPress install since 2015, it has 54 active plugins (we know), and it shares an InMotion account with our blog, which is a second, separate install with 33 plugins of its own.

We’d published Auditra three weeks earlier, a free, read-only MCP server for WordPress that lets an AI client read a site’s plugin inventory, autoload, cron schedule, database tables and known vulnerabilities. So the obvious move was to point it at our own site and see how far it got. This post is the honest version of that: what it found, where it stopped, and what it took to get the rest of the way.

We’ll warn you now, it runs long, because the interesting part is the sequence of wrong turns and not the final fix.

Why is the admin slow when the front end is fine? Where to look, in order

If you’re here because your own admin is crawling and you’d rather skip the story, this is the order we’d check now, having done it the long way.

1. cPanel ? Resource Usage. If CPU and memory are low, faults are zero, and Entry Processes reads 0 while the site is timing out, your PHP workers are running outside your account and you can’t see them. That’s a hosting question, not a plugin question.
2. Bypass Cloudflare. Point the domain at the origin IP in your hosts file and hit the login page with curl. If it hangs direct, Cloudflare is cleared.
3. Hit a bare phpinfo.php. If a one-line PHP file hangs, WordPress is cleared too.
4. Ask the host two things: the PHP-FPM max_children for your pool, and a one-day count of requests to wp-cron.php, 404s, and top user agents.
5. Read the autoload, cron list, and plugin inventory with a read-only audit (Auditra, WP-CLI, or by hand). Fix what’s obviously wrong, but don’t assume it’s the cause.
6. Install Query Monitor, open an admin page, and read the HTTP API Calls tab before anything else. Dead remote calls hide there.

Now the long way.

The 12 MB autoload: a real problem, and the wrong one

The first call was analyze_autoload. Autoloaded options are the rows in wp_options that WordPress pulls out of the database on every single request, admin or not, before a plugin has done anything. A healthy site keeps that under a megabyte. Ours was 12.7 MB across 989 options, and 98% of it was unattributed, which is the tool’s way of saying no active plugin claimed ownership of those rows.

The largest entries were all _transient_string-locator-search-files-N, numbered past 200, at 77 to 90 KB each. String Locator is a search-and-replace plugin we’d used and then deactivated, and it never cleaned up after itself. Every one of those transients had no expiry, and every one of them was autoloaded. We ran one DELETE in phpMyAdmin (206 rows, 0.08 seconds), called analyze_autoload again, and watched the number drop to 730 KB.

The first response from the model that read the audit opened with “Found it.” We’ve left that line in because it was wrong, and because it’s the most useful wrong answer in the whole story. A 12 MB autoload is a genuine defect that costs every request on the site, and fixing it changed nothing we could feel. The admin was exactly as slow afterwards. So the finding was correct and the diagnosis was not, and that distinction is the whole point of a tool that reports facts instead of verdicts.

Where the audit stops

Auditra reads state. It can’t time a request, and it can’t see anything below WordPress. So from here the work moved to things it has no access to: cPanel’s resource graphs, a shell, and the hosting company.

The cPanel numbers made no sense at first. CPU sat at 9 to 15% of the limit, memory under 250 MB of 4 GB, zero faults on every hourly row, and Entry Processes (the count of web requests being handled) at zero while the site was timing out. At one point CPU read 215% with Entry Processes still at zero and six processes total, which is not what a busy website looks like. A ps aux from the cPanel terminal during a hang showed nothing running under our user at all.

To rule out Cloudflare we edited the hosts file on a Mac to point the domain straight at the InMotion IP and ran curl against the origin. The home page came back in 1.4 seconds (a cached file served by WP Fastest Cache from disk, no PHP involved). The login page hung indefinitely. So did phpinfo.php, a one-line file with no WordPress in it. That was the moment the site stopped being the suspect. Nothing in WordPress can make a bare phpinfo() hang.

We read all of that, at the time, as “requests aren’t reaching PHP.” That turned out to be the wrong layer too, and we’ll own it: the requests were inside PHP, in a place we couldn’t see.

Six PHP-FPM workers: the max_children limit on shared hosting

The InMotion engineer (a patient man, by the third hour) found it: the PHP-FPM pool for the account was hitting its max_children limit, and that limit was six. Six PHP processes for a 54-plugin admin, a 33-plugin blog, all their cron jobs, and every bot on the internet. And the number is fixed per plan on shared hosting; it can’t be raised, and there’s no slow log to tell you what’s holding the slots.

In hindsight every odd number fit. The pool runs as a server user outside the cPanel account, which is why ps showed nothing and Entry Processes read zero. The six processes and the 215% CPU on Tuesday were the six workers, all busy. And the front page kept loading because a cached HTML file never asks the pool for anything.

WP-Cron and bot 404s were eating the pool

What was filling six slots all day? The same engineer pulled a day of access logs, and this is where the audit’s cron finding from the first hour turned out to matter after all.

WordPress has no clock. Its scheduled jobs run when a visitor’s page load notices one is due and spawns an extra request to wp-cron.php. With bots hitting the site a few thousand times a day, that’s a few thousand cron spawns, each one taking a worker for a full WordPress boot. Auditra had listed 65 cron events on the main site, one of them (a management connector we’d installed and never used) firing every minute. We’d noted it as “secondary” on day one. It wasn’t secondary. It was a sixth of the pool, permanently.

The 404s were ordinary background noise, scanners probing for install.php and fake plugin paths, no single source worth blocking. The problem was only that each one cost a worker, because a 404 page is never cached.

The last seven seconds

After the cron and bot traffic was dealt with (details below), the admin was still slow, and this is where a read-only audit has nothing left to offer. You need something that times a live request. We installed Query Monitor, opened the Pages list, and read the panel: 13.2 seconds page generation, 569 database queries, and an HTTP API tab that told the rest of the story in four lines.

Simple Job Board, which ran our careers page, was calling its vendor’s add-on marketplace on every admin page load to check for updates. That server was stuck in a redirect loop, so each call ran 2.8 seconds before giving up, and it made the call twice. Five and a half seconds per admin page, holding a worker the whole time, for a marketplace we’d never bought anything from. CrawlWP, an indexing plugin, was trying to refresh a Yandex Webmaster token twice per page and getting a 400 each time, another 1.2 seconds, for a search engine none of our clients use.

We deactivated both. Page generation went from 13.2 seconds to 1.37.

Neither plugin was flagged by anything. Both were up to date, both were actively maintained, both had clean vulnerability records. An inventory tool can’t see that a plugin’s phone-home endpoint died last month. Only a profiler watching the request can, and only when you happen to look.

What we changed

For anyone in the same situation, this is the list, in the order we did it. Most of it is in the wp-config reference and Cloudflare’s cache rules docs if you want the full detail.

• Deleted 206 orphaned String Locator transients (12.7 MB autoload to 730 KB)
• Removed the every-minute management connector, and confirmed via analyze_cron that it left no orphaned events
• define('DISABLE_WP_CRON', true); on both installs, with two cPanel server crons at 5 and 15 minutes replacing 2,800 daily visitor-triggered hits with about 380
• Cloudflare cache rule: 404 responses under /blog/ cached at the edge for an hour, so repeat scans never reach PHP
• Cloudflare WAF rules blocking the two scrapers by user agent, and the usual scanner paths (install.php, xmlrpc.php, .env)
• A physical robots.txt for the blog, because WordPress only serves its virtual one at the domain root
• WP Fastest Cache preload throttled to 4 pages a minute
• 13 inactive plugins deleted, 8 redundant active ones removed, 2 deactivated (down to about 42 active)
• Simple Job Board and CrawlWP deactivated; the careers page became a paragraph of text

Two things we didn’t fix, for the record. The theme depends on Titan Framework, which has an unfixed medium-severity CVE from 2021 and has been closed on wordpress.org for years; replacing it is a theme rework, not a Tuesday job. And the blog’s 33 plugins haven’t been audited yet. If you’ve read our post on technical debt in old WordPress installs, you already know how this goes: you never finish, you just get to the point where the site stops fighting you.

What a read-only WordPress MCP server is actually for

We built Auditra to be read-only on purpose, and we wrote up why in the plugin security post: no write calls, no scores, facts with thresholds next to them, and the reasoning left to whoever (or whatever) reads the output. This week was the first real test of that split on a site we actually cared about, and here’s our verdict.

It did the first hour and the inventory. Autoload, cron, table sizes, the plugin list with vulnerability flags and content usage, all in a few calls, with none of the clicking through fifty settings screens that a plugin cleanup usually means. And it did the verification: after every change, one call confirmed the cron flag was set, the connector was gone, the server cron had fired. That’s the part people underrate. Knowing a fix took is worth as much as the fix.

It could not diagnose a live hang, and we don’t think a read-only tool should pretend to. That took cPanel graphs, a hosts-file bypass, the host’s view of a pool we couldn’t see, and a profiler timing a real request. Four tools, none of them the audit. If we’d sold Auditra as “finds your performance problem,” it would have failed this week, publicly, on our own site.

So the pitch we’d make to another senior WordPress developer is smaller than the one we started with, and we think it’s the right one. Every site you inherit has a history you can’t see from the admin. A read-only audit reads that history in a minute, in a form an AI client can reason over, and tells you what to rule out first. Ruling out is where the hours go on a bad day. It won’t tell you the pool has six workers. But it’ll get you to the question a lot faster, and it’ll confirm you fixed what you think you fixed.

That’s what we found on our own site. We’d be curious what a ten-year-old install of yours turns up, and if Auditra tells you something you didn’t know, or misses something it should have caught, the comments are open and we’ll add it with credit.

The post Our WordPress Admin Took 13 Seconds a Page. Here’s the Audit. first appeared on Macronimous Blog.

The question a client asked me last month

“Should we just block all the AI bots?” That’s the email, more or less, that landed from a client who runs a cremation arrangement service a few weeks ago. He’d read a headline about Cloudflare blocking AI crawlers, opened his dashboard, found a toggle that said Block AI Bots, and had his finger on it. He wanted to know if it was a good idea.

It isn’t, for him. And I suspect it isn’t for most of the people reading this, because if you run a business site, your content isn’t the product. It’s the bait. The whole point of the service page is that someone finds it, reads it, and calls you. If an AI assistant reads it and tells a prospect “these people do Magento migrations, here’s their site,” that’s the same outcome, just with a different middleman.

So no, I wouldn’t block everything. But I also wouldn’t allow everything, and the reason is that “AI bots” is three different things wearing one label.

Three bots, not one

Every big AI company now runs at least three crawlers, and they have different jobs. OpenAI is the clearest about it. OpenAI’s crawler documentation lists GPTBot for training, OAI-SearchBot for ChatGPT’s search index, and ChatGPT-User for the moment a real person asks ChatGPT to open your page. Anthropic mirrors that with ClaudeBot, Claude-SearchBot, and Claude-User. Google does it the odd way round: one Googlebot fetches everything, and a separate robots.txt token called Google-Extended tells Google after the fact whether it may use what it fetched to train Gemini.

Cloudflare’s names for the three are the ones that stuck, so I’ll use them:

The trouble with a single Block AI Bots switch is that it treats a Perplexity fetch that’s about to cite you the same as a Bytespider crawl that’s copying your site for a model you’ll never hear of. Those aren’t the same decision.

What each one is worth to a business site

Search bots are easy. Block them and you vanish from search, and now “search” includes ChatGPT search, Perplexity, and Bing Copilot. OpenAI says plainly that a site which opts out of OAI-SearchBot won’t be shown in ChatGPT search answers. Allow these. I can’t think of a business reason not to.

Agent bots are the ones people don’t understand yet, and they’re the ones that matter most for what we’ve been calling answer engine optimization. When someone types “reliable WooCommerce developers with SEO experience” into Claude or ChatGPT and the assistant goes and reads three agency sites before answering, that read is an agent fetch. If you’ve blocked it, you’re not in the answer. You don’t get a pageview in Google Analytics for it (well, sometimes you do, depending on the bot), but you get the thing a pageview was always a proxy for: a prospect hearing your name.

Training bots are the honest “it depends.” A training crawl gives you no click, no citation, and no attribution. What it might give you, and I’m guessing here because nobody outside the labs really knows, is that the next model has some idea who you are. For a small agency that’s arguably worth more than the content it takes. For a publisher whose articles are the product, it’s a straight loss, and that’s the audience Matthew Prince was writing for when he declared Content Independence Day back in July 2025. His numbers were brutal: by Cloudflare’s count it’s roughly 750 times harder to get a click from OpenAI than from old-school Google, and 30,000 times harder from Anthropic. Fair enough, if you sell ads. Most of our clients don’t.

What I’d allow, and what I’d block

Here’s the split I’d use for an agency, a SaaS product, a B2B service firm, or a local business. Publishers and paywalled sites are a different post.

Allow everywhere: every search crawler, every agent fetcher. No exceptions on public pages.

Allow on marketing content: training crawlers on your service pages, your blog, your case studies, your about page. This is the content you want a model to have absorbed when a prospect asks it a buying question next year. You wrote it to be found. Let it be found. The exceptions are in the next two paragraphs.

Block training on: anything you sell or gate. Pricing calculators, downloadable frameworks, client portals, proposal PDFs, course content, the internal playbook you accidentally left at /wp-content/uploads/. This is content with standalone value, and a training crawl is the only kind of visit that takes the value without leaving anything.

Block outright, whatever the category: crawlers that give nothing back and don’t declare themselves. Bytespider (ByteDance) is the usual offender. Unknown user agents hammering the same unchanged pages. Anything that ignores robots.txt, which, I should note, Cloudflare reported Perplexity doing with undeclared crawlers in August 2025. That one was a category problem, not a business decision.

Where Cloudflare comes in, and what changed on September 15

This is the part that’s been in the news, and it’s also the part I had to rewrite the night before publishing, because Cloudflare moved the goalposts on September 15. Bear with me for a slightly technical section.

On July 1, 2026, Cloudflare retired the single Block AI Bots toggle and replaced it with the three controls above: Search, Agent, and Training, each one you can set separately, on every plan including Free. The July announcement also warned that from September 15 a Training block would catch Googlebot, because Googlebot does search and training in one fetch. That warning is why half the SEO industry spent the summer nervous.

Then on September 15 Cloudflare published a follow-up that mostly defuses it. There’s a fourth option for the Training control now, called Disallow AI Training. Pick it and Cloudflare writes the no-training preference into your robots.txt for you (Google-Extended, Applebot-Extended, and so on), keeps letting Googlebot, Applebot, and Bingbot crawl for search, and blocks the training-only crawlers from OpenAI, Anthropic, Meta, and Amazon at the edge. Google, Apple, and Microsoft signed up to what Cloudflare is calling the Accountable designation, which means they’ve promised that opting out of training won’t touch your rankings. One gap: Bing doesn’t read a no-training line in robots.txt yet (Microsoft says early 2027), so for Bing you still need the NOARCHIVE meta tag.

The trap didn’t go away, though. It moved. The plain Block setting on Training now does exactly what it says, which means a site owner who reads “Block” as “block AI” (a reasonable reading, and the one every headline since July has encouraged) and picks it because it sounds like the safe choice will find that Cloudflare takes them at their word and stops Googlebot, Applebot, and Bingbot at the edge, with a 403 that never touches robots.txt and never reaches the server, so the site looks fine from the inside while pages quietly drop out of the index, and the first anyone hears of it is a crawl-stats dip in Search Console three or four weeks later. The good news for the people who flipped the old toggle in 2025 and forgot: Cloudflare migrated that to Disallow AI Training, not Block, so Googlebot keeps coming. The migration also sets Agent to “Block on pages with ads,” which does nothing on a site without ads. If you never touched any of it, everything stays on Allow.

Why blocking doesn’t protect you much anyway

This next part is what the logs show, whether or not it sounds defeatist.

Robots.txt is a request, not a lock. The well-behaved crawlers honor it (OpenAI, Anthropic, Google, Bing all say they do, and as far as I can tell they mean it). The badly behaved ones don’t, and those are the ones you were worried about. A Cloudflare edge block is stronger because it’s enforced before the request reaches you, but it’s only as good as Cloudflare’s ability to identify the bot, and a crawler that spoofs a Chrome user agent from a residential proxy looks like a person. So you end up in the position where a block reliably keeps out the polite companies that would have cited you, and unreliably keeps out the ones that wouldn’t have. That’s a bad trade for a site whose content isn’t for sale.

Blocking is worth doing when the content has a price. As a gesture it costs you citations and protects nothing.

What we do on our own sites

Macronimous.com has sat behind Cloudflare since 2013 (I wrote about setting it up back then; it took under ten minutes and I stand by that). Our current policy is exactly the split above: Search and Agent allowed everywhere, Training allowed on the public marketing pages and blog, and blocked only on the handful of paths where we keep client deliverables and internal tooling. We’ve never turned on the legacy Block AI Bots toggle, so the September migration left everything on Allow, and I checked the dashboard on Tuesday to make sure. I’ll probably switch Training to Disallow AI Training once I’ve watched it for a couple of weeks on a test domain.

Over the last thirty days our logs show around 30 requests from agent-class bots against the blog. Jeffy on our team pulled that from Cloudflare’s AI Crawl Control; I haven’t verified it against the origin logs yet, so treat it as directional, and yes, thirty is a small number for a site our size. We’re also building a small internal tracker that asks the major assistants our own buying questions every week and records whether Macronimous comes up. Early, and I’ll write it up when the numbers mean something.

The robots.txt I’d start with

For a typical WordPress business site, this is the baseline. Adjust the training block to your own gated paths.

# Search: allow
User-agent: Googlebot
User-agent: Bingbot
User-agent: OAI-SearchBot
User-agent: PerplexityBot
User-agent: Claude-SearchBot
Allow: /

# Agent: allow
User-agent: ChatGPT-User
User-agent: Claude-User
User-agent: Google-Agent
Allow: /

# Training: allow public, block gated
User-agent: GPTBot
User-agent: ClaudeBot
User-agent: Google-Extended
User-agent: CCBot
Allow: /
Disallow: /resources/premium/
Disallow: /client-portal/

# Gives nothing back: block
User-agent: Bytespider
Disallow: /

Note that Google-Extended in that list doesn’t stop Googlebot from fetching the page; it only tells Google not to train Gemini on it. Cloudflare’s Disallow AI Training setting writes that same line for you, so if you’re on Cloudflare you can let it manage this block and keep the rest.

Checks to run this week

• Open Cloudflare, go to Security, then Settings, and read what the Training control migrated to. It should say Allow or Disallow AI Training. If it says Block, Googlebot is blocked; change it today.
• If you want to refuse training, pick Disallow AI Training, not Block, and turn on Bot Preference Sync so the robots.txt lines get written for you.
• For Bing, add the NOARCHIVE meta tag on pages you don’t want used for training, because the robots.txt preference doesn’t reach Bing until 2027.
• Pull a week of origin logs and look for 403 responses to Google’s published IP ranges. That’s the only place an edge block shows.
• Watch Search Console’s crawl-stats report for a drop in Googlebot requests since September 15.
• Update robots.txt along the lines above, and check the live file, not the one in your theme folder (a stale plugin-generated robots.txt is a classic piece of WordPress technical debt).
• Run your key service page through our AEO readiness checker to confirm agent bots can actually read what’s on it once they’re let in.

That’s about all I know at this point. The rules changed the day before I published this, and Cloudflare has already said AI summaries opt-outs are next, early next year; if you’ve seen something in your own logs that contradicts any of this, tell me in the comments and I’ll correct the post with credit. For where this sits in a wider plan, our 2026 SEO strategy notes cover the rest of the AI-search picture.

The post Should Your Website Block AI Bots? A Practical 2026 Answer first appeared on Macronimous Blog.

A white screen right after a plugin update is almost always that plugin throwing a PHP fatal error. The fix is to deactivate it without going through wp-admin (which you can’t reach anyway): click the recovery mode link WordPress emailed you, or rename the plugin’s folder over FTP. The site comes back. Then you decide what to do about the plugin.

So your site is a blank white page, wp-admin is a blank white page too, and the last thing you did was click Update on a plugin. I’m going to assume that’s you, because that’s who searches for this. You did not break anything permanent, and this is roughly a ten-minute job if you have hosting-panel or FTP access (or can get it from whoever set the site up).

Make sure it’s actually the plugin

It usually is. But “usually” has cost people an afternoon, so spend two minutes checking.

Look in the site admin’s inbox for an email from WordPress with a subject like “Your Site is Experiencing a Technical Issue.” WordPress has sent these since version 5.2 (that’s 2019, so unless your site is a museum piece, you have it). The email names the plugin that failed and includes a special login link. If it names the plugin you just updated, you’re done diagnosing. Skip to the fix.

No email? Check spam, then check the hosting error log. cPanel calls it “Errors”; on Hostinger it’s under the site’s PHP settings; on InMotion it’s a file called error_log sitting in your site root or in wp-admin. You’re looking for a line that starts with PHP Fatal error and contains a path with /wp-content/plugins/ in it. The folder name after that is your culprit.

If the log points at /wp-content/themes/ instead, it’s the theme (same fix, rename the theme folder). If it says “Allowed memory size exhausted,” the update tipped a tight PHP memory limit over the edge, and raising it in wp-config.php fixes that. Those are the other two suspects. This post is about the plugin case, which is by far the most common as far as I can tell from the tickets that reach us.

The fix, three ways, easiest first

Pick the first one you can do. You don’t need all three.

Way 1: the recovery mode link

This is the one WordPress built for exactly this situation, and almost nobody uses it, which I think is because the email goes to whatever address was typed into Settings, General back when the site was built, which was often the developer’s address, or a mailbox that was created for the launch and never opened again, so the link sits there unread while the owner is on a forum reading about FTP.

• Find the “technical issue” email and click the recovery mode link. It’s valid for 24 hours by default, so don’t sit on it.
• Log in as normal. You’ll see a “Recovery Mode Initialized” notice, and the broken plugin will be listed as paused.
• Go to Plugins, deactivate the paused one, then click “Exit Recovery Mode” in the admin bar.

The WordPress.org recovery mode page has screenshots if the admin screen looks unfamiliar.

Way 2: rename the plugin folder

No email, or the link expired. This is what I’d do anyway; it takes a minute and it’s hard to get wrong.

• Open your hosting file manager (cPanel, hPanel, whatever your host calls it) or connect with an FTP client like FileZilla.
• Go to wp-content/plugins/ and find the folder named after the plugin. It’s usually obvious: woocommerce, elementor, wordfence.
• Rename it. Add -off to the end, so elementor becomes elementor-off. Reload the site.

WordPress can’t find the plugin’s main file anymore, so it quietly deactivates it and carries on. Your site is back. Once you’ve sorted the plugin out, rename the folder back and reactivate.

Way 3: WP-CLI

Only if you have SSH access and that sentence made sense to you. If it did:

cd /path/to/your/wordpress   # the folder that contains wp-config.php
wp plugin list --status=active
wp plugin deactivate the-plugin-slug

It’s back. Don’t walk away yet.

Clear every cache you have, in this order: the caching plugin (WP Rocket, LiteSpeed Cache, W3 Total Cache), then the hosting cache (most managed hosts have a purge button in the panel), then Cloudflare if the site runs through it. Skip this and you’ll get a call in an hour from someone still seeing the white page while you’re looking at a working site. Been there.

Then click three things. The homepage. One inner page that matters, a product page or a services page. The contact form, and actually send it. A site that renders but can’t take an inquiry is still down as far as your business is concerned.

Now the plugin. You have three options, and I’d rank them like this:

1. Roll it back to the version that worked. The WP Rollback plugin does this from the Plugins screen for anything on WordPress.org. For a premium plugin, download the previous version from the vendor’s account area and upload it over FTP.
2. Leave it deactivated and wait. If the update broke you, it broke a few hundred other people too, and there’s often a patch within days.
3. Replace it. If this is the second or third time the same plugin has done this, that’s your answer.

When you shouldn’t do this yourself

This is the part I’d rather write honestly than write well. Everything above assumes a simple case: one plugin, one update, one error. Some white screens aren’t simple, and the DIY route makes them worse.

The last one is a different problem wearing the same symptom. Renaming a plugin folder won’t help, and poking around in the file system while a site is compromised can destroy the evidence someone needs to clean it properly. That’s a security cleanup, not a maintenance job, and it’s the one case where I’d say close the FTP window and pick up the phone.

On the WooCommerce one, I’ll admit I’m more cautious than most Reddit answers. A store that stays white for twenty more minutes while a developer checks the order tables is cheaper than a store that comes back with a broken checkout nobody notices until Monday.

So it doesn’t happen again

Three habits. Nothing clever. Test the update on a staging copy first; most hosts give you one for free now. Take a backup right before you click Update, not the nightly one from twelve hours ago. And update one plugin at a time, so when something breaks you know which one did it. That’s the whole prevention plan.

Quick questions

The post WordPress White Screen After a Plugin Update: How to Fix It in 10 Minutes (and When Not To) first appeared on Macronimous Blog.

We have been shipping a lot of apps with agents lately: Claude Code on some projects, our developers on Kilocode and Codex on others. The developers adapted fast. The question that kept bothering me was our test engineers, and whether twenty years of testing discipline just became obsolete overnight. This post is my answer: it did not. It became more important, and it moved to a different place in the process. Along the way I will also answer the question that follows immediately after: if agents write the code, who reviews it, and does agent-reviewing-agent even make sense?

The safety net became the steering wheel

For twenty years, tests sat downstream of code. You wrote the feature, then you wrote tests to prove it worked, and everyone quietly accepted that half the time the tests came late or not at all. Tests were insurance. Skipping them was a debt, not a disaster.

Agentic coding flipped the direction of that arrow. When Claude Code, Cursor, or any autonomous agent writes and modifies code in a loop, the test suite is the only channel through which reality reaches the agent. The agent cannot see your product spec. It cannot sit in your standup. What it can do, thousands of times an hour, is run a test and read the result. That makes tests the primary steering mechanism, not the final checkpoint. Anthropic’s own Claude Code best practices put test-driven workflows at the center for exactly this reason: a red-to-green cycle gives the agent unambiguous feedback it can iterate against without a human in the loop.

Here is the position I will defend: in an agentic team, writing tests after the code is not a smaller version of testing. It is theater.

What happens when an agent codes without tests

The failure modes are predictable, and if you manage a web team using AI agents, you have already seen at least one of them.

• Hallucinated correctness. The agent reports “done, all working” for code it never executed against a real assertion. It is not lying. It has no ground truth to check against, so its confidence is a language pattern, not a verdict.
• Fix one, break three. Ask an agent to patch a Laravel endpoint and it will happily rewrite a shared helper, silently changing behavior in two other controllers. Without a regression suite, nobody notices until a client does.
• Spec drift. Over a long session, the agent’s idea of the feature slowly diverges from yours. Each individual change looks reasonable. The sum is a checkout flow that does something you never asked for.

There is a fourth failure mode that surprises people: unlike a human developer, an agent almost never says no. A senior developer will push back on a bad requirement. An agent builds whatever you describe, including the unwise version, and builds it convincingly. Tests are the mechanism that replaces the pushback you lost.

Test-driven prompting: write the contract, not the code

The practical shift for developers is that you stop typing assertions by hand and start defining behavior up front, in plain language or minimal test skeletons, then instruct the agent to write code that makes those tests pass. Kent Beck, who literally wrote the book on TDD, calls this discipline the difference between vibe coding and augmented coding: in one you only care that the behavior looks right, in the other you own the tests and the design while the agent does the typing.

The working sequence looks like this:

1. "Write failing tests for the coupon validation endpoint.
   Expected: 422 on expired codes, 200 with discount object on valid codes,
   409 when the coupon is already redeemed. No implementation yet."
2. "Run the tests. Confirm they all fail."
3. Commit the failing tests.
4. "Now implement until every test passes.
   Do not modify the tests."

Step 3 is not optional. Agents will sometimes edit a test to make it pass instead of fixing the implementation. Committing the failing tests first means any tampering shows up in the diff, and you can revert it in seconds. That one git commit is doing the supervision work a human reviewer used to do line by line.

For web teams, the same pattern applies at every layer: Pest or PHPUnit for the API, Vitest for React components, and Playwright for the end-to-end flows that actually pay the bills, like login, cart, and checkout. The agent can write and run all of them. Your job is deciding what they must assert.

Fix bugs backwards: regression test first, patch second

When a bug surfaces, the old reflex is to dive into the implementation. The agentic reflex should be different: prompt the agent to write a test that reproduces the bug, watch it fail, and only then allow the agent to generate the fix.

This ordering matters for two reasons. First, a reproducing test proves the agent understood the bug; a patch without one proves nothing. Second, that test stays in the suite forever, so the same agent (or the next one, or the junior developer six months from now) cannot reintroduce the bug without the pipeline going red. Every incident becomes a permanent constraint. Over a year, this is how a codebase touched by agents gets more stable instead of less. This is the same discipline we described in controlled AI coding, applied to defects instead of features.

Can an agent review agent code?

This is the question that sounds like a trap: if the agent wrote the code, having an agent review it feels like a developer testing his own work. Sometimes it is exactly that, and sometimes it is not. The difference is context, and it is worth being precise about.

An agent reviewing code inside the same session that wrote it is worthless. It carries the full memory of its own reasoning, so it re-approves its own assumptions, the same way you cannot proofread your own email five seconds after sending it. But a fresh agent session with no memory of the implementation is a genuinely different reviewer. It reads the diff cold, with no attachment to the decisions behind it, which is closer to a new team member reviewing a PR than to a developer grading himself. Anthropic recommends this writer/reviewer split as a standard pattern for the same reason.

So agent review is real, but it is narrow. A fresh agent catches logic errors, missed edge cases, and deviations from the test contract. What it cannot do is be accountable. Both agents still share the same training, the same blind spots, and the same inability to know your client, your compliance obligations, or your business. That is where the human stays, and not as a formality:

• Owning the behavior contract. A human decides what the tests must assert. Agents can propose edge cases; a person approves them.
• Reviewing the tests, not the volume. Nobody honestly reads 800 generated lines. A human reads the 60 lines of tests that govern them, plus a spot-check of anything touching money, auth, or data deletion.
• Architectural and product judgment. Whether this feature should exist, whether this dependency is acceptable, whether this shortcut will hurt in a year. No test suite encodes that.
• The merge. A human presses the button, and that name in the git history means something a bot’s cannot.

Put plainly: shipping unreviewed code was never acceptable, and agents do not change that. They change what review looks like. Test contract reviewed by a human, implementation reviewed by a fresh agent, judgment calls and the merge held by a human. That is not weaker than traditional code review. Done honestly, it is stricter, because the contract is explicit instead of living in a reviewer’s head.

What changes for the team lead

If you run a web team, the shift is bigger for you than for your developers. The summary:

The review change deserves emphasis. An agent can generate 800 lines of plausible React in a minute; no human reviews that honestly. What a human can review is the 60 lines of tests that define what those 800 lines must do. Review the contract, spot-check the implementation. Where the web development life cycle used to place QA as a phase, agentic teams place it as a gate: CI runs the full suite on every agent-generated commit, and the agent is simply not allowed to ship red. Budget-wise, the hours you used to spend on post-build QA move upstream into behavior definition. The total testing effort does not shrink. It moves to the front, where it is cheap.

A policy checklist worth adopting before your team’s next sprint:

• Every agent-built feature starts from tests the agent was given or asked to generate first, committed while still failing
• Agents are instructed never to modify existing tests; any test change requires a human commit
• No agent-generated PR merges with a red pipeline, no exceptions for “it works locally”
• Every production bug gets a reproducing regression test before its fix is accepted
• Critical user flows (auth, cart, checkout, payments) have end-to-end coverage the agent must keep green
• Reviewers read tests first and sign off on behavior, not line-by-line implementation

Your testers just got promoted

The uncomfortable conclusion for managers: the people on your team who are good at defining expected behavior, edge cases, and failure conditions just became your highest-leverage engineers. That skill used to be undervalued as “QA work.” It is now the interface through which your team controls its fastest developer, the agent. The developers who thrive in this model are the ones who can hold the whole behavior of a feature in their head and write it down precisely, which is also the skill we argued matters most in vibe coding for web developers and in writing clean code with AI.

So no, test cases did not die in the age of agentic coding. They stopped being paperwork and became the steering wheel. The teams that treat them that way will let agents run fast safely. The teams that skip them will discover that an agent with no constraints is just a very fast way to write next quarter’s incident report.

The post Testing in Agentic Coding: From Safety Net to Steering Wheel first appeared on Macronimous Blog.

The argument nobody wins

The criticism is familiar. WordPress is insecure because anyone can bolt forty plugins from forty strangers onto a site and never look at them again. Say it in any developer forum and you will get agreement within a minute.

The defense is equally familiar. That is not WordPress’s fault. It is the site owner’s fault for installing carelessly, or the host’s fault, or the plugin author’s fault. I am on the defending side more often than not, and I have made the case that WordPress still beats the AI site builders where it counts.

Here is my problem with that exchange, as someone who has run a WordPress development business for years: the defense is technically correct and practically useless. “Be more careful” is not a mechanism. It gives nobody a way to act differently on Monday morning.

Both sides are arguing about blame. Almost nobody is arguing about what a site owner can actually see.

Your plugins screen shows three fields

Open any WordPress admin. The plugins screen gives you a name, a version number, and a description the author wrote about themselves.

That is the entire interface most people have for reasoning about risk. It does not tell you which of those plugins has a published vulnerability at the version you actually have installed, as opposed to merely appearing somewhere in an advisory database. It does not tell you which one loads 19 KB of autoloaded options into every single page request. It does not tell you that the plugin you deleted in 2019 left a scheduled job still firing every hour.

None of that is hidden. It sits in wp_options, in the cron array, in SHOW TABLE STATUS, and in public feeds like the WPVulnerability database. Getting to it means being a developer with a database client and a free afternoon.

So we have an ecosystem whose central criticism is a security one, and the people responsible for those sites cannot answer basic questions about them without writing SQL. That gap is where I think the useful work is. It is the same shape as the technical debt that accumulates quietly in WordPress: not dramatic, not visible, and expensive later.

What a ten-year-old site leaves behind

We pointed a read-only audit at one of our own sites. It has been alive since 2015 and it is not unusual in any way.

The orphaned tables told a story. A contact form plugin, long since removed, had left three tables holding 71 form submissions and 642 field-value rows. Names, email addresses, and messages from people who contacted the business years ago, sitting in tables that no privacy tool on that site can see, because no installed plugin claims them.

An invoicing plugin had left eight tables, all empty. Installed, never really used, deleted, and never cleaned up. A background job queue had 35 queued actions and 93 log rows belonging to a plugin nobody could name.

Nothing there is a vulnerability in the CVE sense. No scanner would flag it. But if you had asked me before that audit whether we held a decade of stranded contact form submissions on that site, I would have said no, confidently, and I would have been wrong.

So I built something that can only look

The result is Auditra, a free plugin that turns the site it runs on into a read-only MCP server. You enable an endpoint, generate a token, paste the connection URL into an AI client, and then ask questions in plain language. Which plugins are vulnerable at the versions installed. What is bloating the options table. What did deleted plugins leave behind.

The interesting part is not the tool list. It is the three things it refuses to do, each of which cost me something.

It cannot change anything. No activating, no deactivating, no updating, no writing to the database at all. That is structural rather than a promise: there is no write call anywhere in the codebase, and the build fails if one is ever added. A tool that can only look has nothing to sell you afterward.

It does not score anything. No grades, no risk numbers, no “this plugin is dangerous.” Scores sell, which is precisely why so much security tooling has them and precisely why I do not trust them. The plugin returns facts with documented thresholds and leaves the judgment to the model reading them, which also means the analysis improves as models improve without me shipping anything. That is the same principle behind keeping AI on a short leash while coding: give it accurate context, not conclusions.

Saying “I don’t know” is the whole design

The decision I spent longest on sounds trivial. If the plugin could not check anything at all, what should it return?

The obvious answer is an empty list of findings. That is what most tools do, and it is wrong, because an empty list reads as clean. A security tool that implies “clean” when it checked nothing is worse than no tool, because it manufactures confidence that was never earned.

So it returns no findings list at all in that case. Not an empty one. A response saying what could not be checked, why, when the data was last fetched, and when it will retry. When only some plugins could be checked, the ones that were skipped are named individually. Every data source reports its own coverage.

That is a small technical decision, but it is the entire argument in miniature. The reason WordPress security discourse is so poor is that too much of the tooling is confidently wrong. Scanners emit scores. Plugins claim protection. Almost nothing ever says “I could not check that.” I would rather ship something that admits ignorance loudly than something that looks authoritative and is occasionally lying to you.

What this does not fix

Plenty. Seeing that a plugin has been unmaintained for three years does not patch it. Knowing an orphaned table holds old contact submissions does not delete it, and deliberately so, because a read-only tool cannot make that mistake on your behalf.

It also needs an AI client on the other end, which today means a narrower audience than the WordPress user base. I would rather say that plainly than pretend otherwise.

And there is a fair objection I should answer rather than dodge: this adds an HTTP endpoint that returns information about your site, which is a new surface. True. It ships disabled and answers 404 until an administrator turns it on, it requires a token compared in constant time, it is rate-limited, it is revocable in one click, and it exposes no post content, no user accounts, no credentials, and no option values. Only names and sizes. That is a considered trade, not an accident, and the readme spells out exactly what an enabled endpoint exposes so nobody has to take my word for it.

The plugin ecosystem is the best thing about WordPress. It is also the thing that makes a ten-year-old site an archaeological dig. I do not think that tension is going away, and I do not think another scanner with a letter grade helps. Better visibility might, a little. That is the whole intention, and it is a small one. The rest of the argument belongs to the ecosystem, which has been having it for fifteen years and will probably still be having it in another fifteen.

The post WordPress Plugin Security Starts as a Visibility Problem first appeared on Macronimous Blog.

The app an AI builds is the app in its training data

The standard advice for AI-assisted development is simple: let the agent write the code, then review it. We follow a stricter version of that ourselves and wrote it up as controlled AI coding. But this build taught us where that advice runs out. Review catches the mistakes you already know to look for. It does nothing about the mistakes that look like correct code.

Some context, kept short. We run a software-export business in India, and export invoicing follows rules that generic tools don’t model. Exports of services are zero-rated under Section 16 of the IGST Act, payment must arrive in convertible foreign exchange, the bank issues a FIRC (Foreign Inward Remittance Certificate) as proof, each remittance carries an RBI purpose code, and invoice numbers run gapless per financial year, which in India starts on April 1. This is our working understanding, not tax advice; confirm specifics with your chartered accountant.

Because no off-the-shelf tool ties a FIRC to the invoice it settles, we built our own system, with Claude Code doing most of the typing. The agent was fast, confident, and produced clean PHP. It also produced two failures that never threw an error, never failed a test we had at the time, and would have passed any code review that judged the code as code.

Incident one: the agent built a void feature and made it law

Every accounting tutorial, every open-source invoice app, every SaaS product the model has ever seen handles a wrong invoice the same way: void it, keep the number, never delete. So the agent built exactly that. Not a suggestion, a complete feature: a Void button, a confirm dialog, a reinstate action, and a comment declaring the behavior as rule “§1.10” of its own spec. From invoice-view.php at commit 99d6730:

/* Tax-invoice document (§2). Born paid — status is `issued` or `void`,
 * voided, never deleted (§1.10). */
if ($action === 'void' && $inv['status'] === 'issued') {
    $DB->prepare("UPDATE invoices SET status='void' WHERE id=?")->execute([$id]);
    flash('Invoice voided. The number is retained (never reused).');
}

As generic accounting software, this is correct. As software for an Indian exporter, it is a liability generator. In our reading of GST, an issued tax invoice creates a tax liability whether or not you later mark it void. A wrongly issued invoice has to be removed and its proforma reverted, so the liability never exists on paper. We caught it in the functional-gap review, and the fix went in as commit c9f4107, whose message states the reasoning better than any paragraph I could write here:

“invoice-view: replace Void with ‘Undo conversion’ — deletes a wrongly converted invoice, reverts its proforma to Paid, frees the FY number (an invoice that exists is a GST liability, so wrong ones are removed).”

That last part deserves a beat. The agent didn’t hedge. It codified the pattern as canonical, complete with a section number, and every later piece of generated code would have treated void as settled behavior. A wrong assumption an agent writes into its own spec compounds with every subsequent prompt.

Incident two: numbering that was right everywhere except India

The first version of next_invoice_number(), from the initial commit f6b7863, made two default choices in one function:

$st = $db->prepare('SELECT prefix, next_seq FROM companies WHERE id = ? FOR UPDATE');
// ...
return sprintf('%s-%s-%03d', $row['prefix'], date('Y', strtotime($issueDate)), $seq);

One global counter per company, and date('Y'): the calendar year. Reasonable everywhere the model’s training data comes from. Wrong in India, where invoice sequences reset on April 1 for the new financial year, and where our proforma and its resulting tax invoice must share a sequence number so the books line up. The catch, again, came from a review question, not from the code: “every business year, April 1st, we change the invoice numbers.” That single sentence forced a rebuild into per-company, per-document-type, per-FY gapless sequences.

Then the second layer, and this one is the more interesting failure. The rebuilt version used INSERT IGNORE plus SELECT ... FOR UPDATE plus UPDATE, a sequence that deadlocks under InnoDB when two transactions create invoices at the same moment. No human review caught this. It was caught by a concurrency test that existed for one reason: someone asked “what if a team member creates an invoice on their machine at the same time?” The question generated the test; the test caught what eyes could not. The fix was a single atomic statement.

That is the arc worth remembering: naive, then domain-corrected, then concurrency-corrected, each step with a diff. And the mechanism differed. The FY miss was caught by knowledge. The deadlock was caught by a test that a question produced. If your process only has “review the diff,” you get the first catch and miss the second.

The mistake that never happened

I expected a third incident. Agentic tools routinely model payment as a boolean, an is_paid flag on the invoice row, because that’s what tutorial invoice apps do. It never happened here. The very first schema, commit f39c0b2, already had a payments table with amount, currency, and FIRC linkage as a first-class record.

Why? Because the FIRC requirement was in the spec before the agent generated a line of code. When the spec says every foreign payment must carry its remittance certificate and purpose code, a boolean cannot satisfy it, so the wrong shape never gets generated. Nobody had to catch this mistake, because the constraint made it impossible to make.

Three rows, one pattern. The only mistake that cost nothing was the one the spec prevented.

The MCP connector: agentic defaults trust too much

The system has an MCP connector, so an accountant can open Claude Desktop and type “create and send an invoice to Acme Ltd for the March retainer” without ever logging into the app. The agentic default for this kind of connector is full write access, because that’s the frictionless demo. We went the other way. The connector is a thin layer over the app’s own token-authenticated API: writes are draft-first and require confirmation, every AI-initiated change is audit-logged, and the token is role-scoped so the AI cannot see or touch more than that accountant could. It’s stateless, single-request JSON, which lines up with where the 2026-07-28 MCP specification took the protocol. The AI holds no business logic. The invoice system stays the single source of truth, which matters for the same reason everything above matters: an agent that improvises accounting logic is an agent that improvises liabilities.

Review catches what you know. Specs prevent what you don’t.

Agentic tools never say “that’s unwise.” A human developer with export clients would have asked about the financial year before writing a numbering function. The agent shipped date('Y') without a flicker of doubt, and it would ship the void feature again tomorrow. We’ve written before about keeping AI-generated code clean and about why vibe coding needs guardrails before production, but this build sharpened the point: cleanliness was never the problem. Every one of these mistakes was clean.

So put the domain in writing before the agent starts. For anything with statutory weight, our pre-build spec now answers:

• Which jurisdiction’s rules govern this system, and which documents are statutory records?
• What is the full lifecycle of each document, including what may be voided, deleted, reverted, or never touched?
• What are the numbering rules: sequence scope, gaplessness, and which fiscal calendar they follow?
• What proof documents (FIRC, purpose codes, certificates) must exist as first-class records, not fields?
• What happens when two people do the same thing at the same time, and which test proves it?
• If an AI connector exists, what is its write model: scope, confirmation, and audit trail?

Every “what if” question in that list is a test waiting to be written. Ask it early and the agent generates the right shape from the first commit, the way the payments table proved.

The bottom line, and the code

The agent was worth it. It typed the app in a fraction of the time it would have taken us by hand, and both incidents were cheaper to fix than a single GST notice would have been to receive. But the value of the build lived in the two moments a human said “not in India” and the one moment a spec made the question unnecessary. Speed came from the agent. Correctness came from the domain.

We’re releasing the system under MIT for other Indian software exporters and freelancers with the same compliance shape: a single-business kit that self-installs on ordinary PHP and MySQL shared hosting, with your data in your own database. It is deliberately narrow. Built around Indian GST and export-of-services rules, it is not a fit for domestic billing at other tax rates or for non-Indian firms without changes. The repository is on GitHub; if you find a rule we got wrong, an issue telling us so is the most useful contribution you can make.

The post Agentic Coding Mistakes: Lessons From a Real App build first appeared on Macronimous Blog.

You already move files. You just never kept the receipts.

I have been uploading files to servers since SmartFTP and WS_FTP were the normal way to do it. FileZilla and Cyberduck are still open on my Mac most weeks. There is a specific muscle memory to FTP: edit the file, drag it into the client, watch the progress bar fill, done. It works. It has worked for over twenty years.

Here is the catch. FTP has exactly one job: take the file on your machine and put it on the server, on top of whatever was there before. The server holds one version of the truth, the current one. The moment you upload a broken file over a working one, the working one is gone. No note about what you changed. No way back. If a colleague edited the same file an hour ago, your upload quietly erases their work.

FTP has no memory, and it was never trying to have one. Version control is the memory FTP never had.

Git and GitHub are not the same thing

Before the vocabulary, clear up the one confusion that trips up everyone who picked this up by osmosis. Git and GitHub are two different things.

Git is the version control system. It runs on your own machine and keeps the full history of your project in a hidden folder. It does not need the internet to work. Git itself is free, open source, and describes itself as a distributed version control system, which is a precise way of saying every copy carries the entire history.

GitHub is a website that hosts Git repositories and adds a layer of collaboration on top: a place to keep the shared copy, review changes, and discuss them. GitLab and Bitbucket do the same job. Almost every term below is a Git concept. Only one of them, the pull request, actually belongs to GitHub. People say “GitHub” the way they say “Google it” when they mean search. That is fine in conversation. But once you can see the line, the rest stops being mysterious.

The FTP-to-Git Rosetta Stone

Here is every term you have heard, mapped to something you already do in FileZilla. Read the middle column first, then the right one.

The three things FTP simply cannot do

The table makes these look like translations. Three of them are not translations at all. They are things FTP has no answer for, and they are the whole reason version control exists.

You can always go back. Every commit is a labeled save point. Break the site at 4pm and you can return to how it was at 2pm, with a record of what happened in between. This is the one that changes how it feels to work.

You can experiment without a test folder. A branch is the /public_html_test/ trick done properly. You spin off a parallel version, try the risky redesign, and the live code is never touched. If it works, you bring it in. If it does not, you throw the branch away and nothing was ever at risk. No more folders named test, test2, test-final, and test-final-REAL.

Someone can review before it goes live. A pull request is that email to your boss, except it is structured, it shows the exact lines you changed, and the review stays next to the code forever. For anyone who inherits other people’s codebases for a living, this is the difference between “trust me, it works” and “here is exactly what I changed and why.”

Where the FTP comparison breaks

No analogy survives contact with the details. Three points are worth knowing before you start, so they do not surprise you later.

Merge is not always automatic. When two people change the same lines of the same file, Git stops and asks you to resolve the conflict by hand. That feels like a failure the first time. It is the opposite. FTP would have silently let the second upload erase the first. Git refuses to guess when it cannot be sure, which is exactly the behavior you want from a tool that is holding your history.

Push does not overwrite, until you force it. Normal pushes only add to the history. There is a “force push” that rewrites it, and it can undo other people’s work if you are careless. Treat it the way you treat rm -rf: know it exists, do not reach for it.

The history lives on your machine first. This is the part FTP people find strangest. Your commits are saved locally, in full, before anything touches a server. You can work on a plane, commit ten times, and push all of it when you land. The server copy is a convenience for sharing, not the source of truth. That inversion is the entire point of a distributed system.

Why WordPress developers got away without it

I will be honest about the reason so many capable developers skipped version control for years: for a lot of work, FTP was genuinely enough. One person, one WordPress site, a plugin update here, a CSS tweak there. Git felt like ceremony around a job that took ten seconds. That is a fair reason, not laziness, and I am not going to pretend otherwise.

But the reason stops holding the moment the work gets real. The day a second developer touches the same files. The day a client asks what changed on the 14th and whether you can undo just that one thing. The day you inherit a codebase someone else built and need to understand its history before you touch it, which is exactly where version control sits inside a real web development process. FTP has no answer to any of those. Version control answers all three without you thinking about it.

There is a newer reason too. Every serious AI coding tool now assumes Git. Claude Code, GitHub Copilot, and Cursor all lean on version control to show you what they changed and to let you throw it away. A controlled AI coding loop is impossible without it, because the whole safety net is being able to reject what the tool wrote. If you care about clean code from AI tools, version control is the floor you build it on.

So here is the opinion, plainly. If you build websites for a living and version control was never part of how you work, that is a gap, not a preference. WordPress made it easy to avoid. It did not make it wise to avoid. For a seasoned developer, keeping the full history of your work should be as automatic as keeping backups.

Starting without the terminal fear

The fear is almost always the terminal, and you can skip it entirely. GitHub Desktop and the built-in Git panel in editors like VS Code give you commit, push, and pull as buttons, with the change history laid out visually. It looks a lot more like FileZilla than like a command line.

Pick one project, ideally a small one, and start there:

• Install GitHub Desktop, or open the Source Control panel in VS Code.
• Put one existing project under version control (the tool calls this “create a repository”).
• Commit whenever you would normally save, and write a one-line note each time.
• Push when you would normally upload to the server.
• Create a private repository on GitHub as your off-site backup.

Do that for two weeks on one project and the vocabulary stops being vocabulary. It becomes muscle memory, the same way dragging a file into FileZilla once did. When you want the full picture, the free Pro Git book is the reference worth keeping open.

You are not learning a new discipline. You are finally getting the receipts for the one you already practice.

The post GitHub for FTP Users in the age of Agentic coding: first appeared on Macronimous Blog.

The spec changed the night before we submitted

On July 28, 2026 the Model Context Protocol shipped its fifth revision. We were hours away from uploading our WordPress MCP plugin to the plugin directory.

The headline change was a stateless core. MCP went from a bidirectional, stateful protocol to plain request and response. Sessions gone. The initialize and initialized handshake, retired outright. You can read the maintainers’ release notes for the full list, and Anthropic published its own summary of what’s rolling out across Claude the same day.

So the first question was not “should we adopt this.” It was “are we broken.”

Mostly, no. And for a deeply unglamorous reason.

Why WordPress was already the right shape

In the first week of the build we had a choice about how the server replies. The old spec allowed a persistent event stream, or a single JSON response per request. We took the single response. Not because we saw anything coming, but because server-sent events inside PHP, under a shared host’s process model, is a bad afternoon that turns into a bad week.

The simpler option was permitted. We took it and moved on.

Eight months later the protocol moved to exactly that shape. Every server that had built the sophisticated version now has a migration to do. We had already accidentally arrived.

There is a general point buried in that, and it’s the reason this release matters beyond one plugin. WordPress has always been shared-nothing. A PHP request boots, does its work, and dies with no memory of the request before it. The previous MCP spec fought that model by asking for a connection WordPress does not naturally hold. The new spec asks for exactly what WordPress already does.

What broke was the handshake, and only the handshake

initialize and initialized were the first code written on this project, the thing that proved a WordPress site could act as an MCP server at all. Both are now retired in favor of an optional server/discover call. The most protocol-shaped part of the build was the part that aged worst.

Everything downstream, reading site data and returning JSON, did not care at all.

Here is what a call looks like now. Note that there is nothing to establish first, and nothing stored between requests.

POST /mcp HTTP/1.1
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: search

{"jsonrpc":"2.0","id":1,"method":"tools/call",
 "params":{"name":"search","arguments":{"q":"otters"},
 "_meta":{"io.modelcontextprotocol/clientInfo":{"name":"my-app","version":"1.0"}}}}

Protocol version, client identity and client capabilities all travel in the request itself. Any request can land on any instance behind an ordinary load balancer. For a plugin running on shared hosting, that is not an abstract scalability win. It removes the one requirement PHP was worst equipped to meet.

We’re supporting both generations, not switching

The new spec carries a formal deprecation policy with a twelve-month minimum window. That changes the calculation. A plugin installed on somebody else’s site has to work with whatever client that person happens to have. You do not get to pick.

So version negotiation decides per request, and nothing is stored between them. Two code paths, one endpoint, no session table.

Agencies will recognize the shape of this problem. If you maintain WordPress sites for other people, you already live with the gap between the version you’d like everyone to run and the version they actually run. Protocol support is the same discipline applied one layer down, and it accumulates the same way technical debt accumulates in WordPress: quietly, until a release forces the accounting.

The timing call was harder than the code

Directory review takes weeks. Submitting on the previous spec would have meant being reviewed, approved and listed as already out of date, in a category where the audience reads specifications for a living.

A day of work against several weeks of looking dated is not a close call.

The engineering question was answered in an hour. The publishing question was the harder one, because the cost of shipping something correct-but-stale is paid entirely in credibility, and you cannot patch that in version 1.0.1.

The small win: tool lists are cacheable now

One change we are quietly pleased about. List responses now carry a time-to-live and a cache scope.

Through the entire build, every time we added a capability, we had to disconnect and reconnect the client, because it had cached a stale catalog with no way to learn it was stale. Minor, constant, mildly maddening. Now the protocol handles it.

Nobody will write a headline about that one. It is the change that will show up most often in daily use.

The rest of the changelog, for WordPress builders

If you are building or evaluating anything MCP-shaped on WordPress, these are the items worth reading properly in the 2026-07-28 specification rather than skimming.

Simple survives revisions. Clever gets rewritten.

Budget for the specification moving. Not as a line in a risk register, as a genuine expectation.

You cannot predict which way it moves, so insulation is not foresight. What actually protected us was choosing the simplest option the spec permitted, at a moment when the constraint was our own platform rather than any theory about the future. And keeping the protocol layer thin and separate from the work, which is the same discipline we apply to controlled AI coding and to keeping AI-generated code clean.

• Take the simplest option the spec permits, especially when your own platform is the constraint
• Keep protocol handling in its own layer, separate from the code doing the actual work
• Support two spec generations rather than switching, if your code runs on installs you don’t control
• Negotiate the version per request and store nothing between requests
• Test that nothing in front of your endpoint strips Mcp-Method or Mcp-Name
• Read the deprecation policy before planning a migration, not after

We got this one right by accident. That is not a method, and I would not want anyone reading this to treat it as one. A hands-on guide to connecting a live WordPress site to Claude is in progress and will follow this post.

The post Building a WordPress MCP Server When the Spec Changed first appeared on Macronimous Blog.