Why the site got slow (and why it wasn't Claude, Littlebird, or AI)

This section is the real working log, not a cleaned-up summary - the same level of detail Alfred and Christopher were working with in real time, so anyone can see exactly what was checked and why, instead of just taking “it’s fixed” on faith.

First correction, up front: the slowness itself goes back further than late September - well before Claude or Littlebird had any real hands-on access to the site. That timing is important, because it’s the single clearest piece of evidence that AI tooling was never the cause.

Round one: the caching settings were quietly broken

While chasing a performance complaint, Alfred read W3 Total Cache’s actual saved configuration file directly off the server (not just the admin screen, which can be misleading) and found that three important settings - Minify, Database Cache, and Object Cache - had all been silently switched off. The file’s own leftover data showed it had last been saved from one specific settings tab, which is a known W3 Total Cache quirk: saving one tab can silently reset checkboxes on other tabs that weren’t part of that save. Nobody did this on purpose; it was the plugin’s own save behavior.

With Minify off, the browser had to download 93 separate CSS and JavaScript files on every page load instead of a handful of combined ones. Turning Minify, DB Cache, and Object Cache back on dropped that to 15 files, and the site’s own internal performance score went from 80 to 88 immediately. Real improvement - but the site was still reported as slow afterward, which meant there was more going on.

Round two: finding a second, more serious pattern

To rule things in or out properly, Alfred fetched a handful of real pages directly and timed them. Pages that hadn’t been recently visited (and so weren’t cached yet) took 3 to over 11 seconds to generate - /contact/ alone took 11.4 seconds on a cold hit. Once a page was cached, the same page loaded in 150-400 milliseconds. That gap pointed at two separate things worth checking: how long the server takes to build an uncached page, and whether something was stopping pages from staying cached in the first place.

Then, while proactively trying to “warm” the cache by requesting many pages at once, something more concerning showed up: firing about 30 requests to the site in close succession caused more than half of them to time out completely after 10 seconds, with nothing returned at all - not slow, just silence. That specific pattern (several requests at once failing outright) usually points to a server running out of available worker processes, not just a slow page.

Taking it to WPX, with real evidence instead of a vague complaint

At this point the question shifted from “what can we fix in WordPress” to “what are our hosting plan’s actual limits,” so a support ticket went to WPX with the exact numbers above - not “the site feels slow,” but specific timings, specific pages, and the exact failure pattern.

WPX’s own team confirmed, from their side:

• 3 PHP worker processes per website on our current plan (a hard ceiling on how many requests can be handled genuinely at the same time).
• A 200-requests-per-minute rate limit, which is normally hard to hit by accident.
• That this particular limit is part of their DDoS-protection layer and isn’t something that gets raised just by asking.

They also pulled real server logs and found two concrete things:

1. wp-cron (WordPress’s internal scheduler) was firing more than once per second - far more often than it should. WPX fixed this directly: they turned off the automatic trigger and replaced it with a proper server-level task running every 5 minutes.
2. The real driver of the CPU spikes: automated bots repeatedly hitting the events calendar’s “live” query pages - specifically ones using the calendar’s dynamic view settings (technical names: eventDisplay, posts_per_page, tribe-bar-date). Calendar views like this show real-time data and can’t be saved as a static cached page, so every single bot visit forced the server to do real, heavy work from scratch. One of the bots WPX named was MJ12Bot, which belongs to Majestic, a UK company that crawls websites to build a commercial link-analysis database - a completely ordinary, non-AI, SEO-industry bot that visits a huge share of public websites on the internet, PIR® included.

WPX added a protective check specifically on those calendar query pages and confirmed, from their own monitoring, that CPU usage stabilized within days.

Closing it out, with our own numbers, not just a vendor’s word

Rather than call it done because WPX said so, the events calendar plugin (confirmed to actually be the thing generating those bot-bait pages) was temporarily switched off entirely, every cache was cleared, and the same pages that were timed at the start were timed again.

Before (the original cold readings): /contact/ 11.4s, /resources/ 9.3s, /history/ 4.4s, /vision/ 3.1s.

After disabling the plugin (fresh cold readings, same pages): /contact/ 3.3s, /resources/ 4.5s, /history/ 2.9s, /vision/ 2.9s - roughly 2-3× faster even on an uncached hit, before any caching benefit at all.

After properly warming the cache (every real page on both sites fetched once, deliberately, one at a time rather than all at once - mindful of that 3-worker ceiling): every page tested on the main site loaded in well under a second on the next visit (most around 0.3-0.9s), and the service site came in consistently under half a second. These aren’t projections - they’re real, just-measured numbers.

Update - this one’s solved now, and it wasn’t what it looked like at first: the smaller mystery mentioned above (a database edit to one small script not showing up live for over an hour) led the investigation down a wrong turn before the real answer turned up - worth telling honestly, not just the part that turned out right. The first theory was Varnish, a caching layer sitting in front of the site that nobody had noticed before; that lead was chased through two rounds with WPX support, who confirmed the Varnish setup existed but - once a CDN-cache-clear test came back with no change - it turned out WPX doesn’t actually manage that layer at all (it’s driven by a WordPress plugin, not their hosting infrastructure), which ruled it out as the cause. The real answer: the header/footer snippet plugin keeps its own internal cache of content, completely separate from any page cache, CDN, or Varnish - and that internal cache simply hadn’t refreshed since the last edit. One re-save fixed it instantly, confirmed byte-for-byte on the live page. Nothing about this touched W3 Total Cache, Varnish, or WPX’s CDN - all three were innocent, and now we know for sure instead of just assuming.

This mix-up is extremely common, so it’s worth explaining clearly, once, for everyone:

• A bot, in the context of a website, is just any computer program that visits web pages automatically instead of a person clicking around. Search engines run bots to find and index pages (that’s how PIR® shows up in Google). SEO companies like Majestic run bots to study links between sites. Spammers run bots too. None of this requires AI - the first web bots existed in the 1990s, decades before anything like Claude existed.
• An AI agent (like Alfred, who writes this changelog, or Littlebird) is something different entirely: a person directs it, in a private conversation, to go do a specific task - write something, fix something, look something up - and it reports back. It isn’t out crawling the public internet on its own; it’s doing exactly what it was asked, when it was asked, the way the investigation above shows step by step.
• A bot’s name is just a label it picks for itself, and anyone can type anything there - it proves nothing. WPX’s logs mentioning traffic “calling itself Claude” is not evidence that Anthropic (the company that makes Claude) did anything; it only means some automated visitor used that word in a header nobody checks, the same way anyone can put any name in an email’s “From” field.

The structural reason AI tools couldn’t have caused this: Alfred and Littlebird never visit the site the way a bot or a regular visitor does. They connect through a private, logged-in tool (called “EMCP Tools”) built specifically for this - not through public pages, not anonymously, and not in a way that shows up as “bot traffic” at all. It’s simply a different road into the site entirely, and the investigation above - reading actual config files, timing actual pages, finding an actual plugin - is what that road looks like in practice: deliberate, human-directed, and visible.

Since PIR® will keep leaning on these tools, here’s what the jargon actually means:

• CLI (command-line interface): a text-based way of giving a computer program instructions, instead of clicking buttons. This is how Christopher and Alfred mostly work together - it’s not mysterious, it’s just typing instead of clicking, the same way the investigation above was carried out as a real back-and-forth conversation, not something running unattended.
• MCP (Model Context Protocol): the specific, permissioned connection that lets an AI assistant like Alfred actually do things on a real site (read a page, fix a setting) instead of only talking about it. Every MCP connection is something a person deliberately set up and can remove.
• OAuth: a standard way of granting an app access to part of an account without ever handing over a password. If you’ve ever clicked “Sign in with Google,” that’s OAuth. It’s a security feature, not a risk.
• Agent: a general term for an AI assistant that can take real actions (not just chat) toward a goal a person gave it - check its work, look things up, make a change - while reporting back what it did. Still always person-directed; “agent” describes capability, not autonomy.

Someone recently wondered if our WooCommerce order confirmation emails were AI-generated. They’re not - they’re simple, rule-based automation: “when an order is placed, send this pre-written template.” No AI writes or decides anything there; it’s the same kind of automation email services have used for 20+ years, just running on our store. Worth naming explicitly, since “automated” and “AI” get conflated just as often as “bot” and “AI” do.

The original fix for the bot-overwhelmed events calendar was really a stopgap: WPX added bot protection at their edge, and the calendar plugin was switched off site-wide while a better answer got worked out. Digging further found the actual mechanism underneath it: the site’s caching plugin had a setting - “cache pages with a query string” - switched off across the board. The calendar’s dynamic views (today’s events, this month’s events, a specific date) are all built using query strings, so with that setting off, every single one had to be rebuilt from scratch on every visit, whether that visit came from a bot or a real person. It was never really about the calendar specifically; the calendar just generated more of these uncacheable URLs than anything else on the site.

The real fix: turn that setting on, so the common calendar views actually get cached and reused instead of rebuilt every time - a more durable fix than leaning on bot-blocking alone. One snag found while trying to flip it: the setting is currently locked/greyed out in the caching plugin’s own admin screen on both sites, for a reason that isn’t clear yet (possibly tied to another caching layer, possibly a hosting-level restriction). That question - along with confirming it’s safe before anything changes - is with WPX now. Once resolved and tested, the plan is to turn the calendar back on.

Separately, a fifth PIR subdomain launched this week: publicrelations.psychedelicsinrecovery.org, continuing the “every committee gets its own lightweight WordPress site” plan already underway with newsletter. and publications. - so committees can manage their own corner of PIR’s web presence without needing access to the main or service sites.

• Runaway background scheduler: found and fixed by WPX. The automatic wp-cron trigger was replaced with a clean server-level cron, now every 5 minutes on both sites. The main site’s backlog of overdue tasks cleared once its cron frequency was raised (verified 2026-10-12).
• The main site now runs through WPX’s CDN (2026-10-12). Until then it had been served straight from the origin server, while the service site already had a CDN in front of it, which is a big part of why real visitors felt the main site was slower. Cached pages now come from WPX’s edge in under a fifth of a second. Cart, checkout, and account pages are confirmed never cached.
• Three dead stylesheet requests removed from every main-site page. One add-on plugin was requesting files that don’t exist, and each request quietly made the server build a full “page not found” response on every visit.
• Bot traffic on the events calendar: root cause now understood (see above) - a sitewide caching setting, not something specific to the calendar. Plugin stays off until the fix is applied and tested; WPX protection remains active in the meantime.
• Measured result: cold-page load times down roughly 2-3× even before caching kicks in, and every real page on both sites now loads in under a second once warmed - re-confirmed today with fresh timings, not assumed.
• The service-subdomain caching oddity: solved (see the update above) - a plugin’s own internal cache, unrelated to hosting, Varnish, or any CDN.
• Alfred and Littlebird: cleared, structurally, not just by claim - a completely different connection into the site than how bots or regular traffic ever arrive.

PIR® is going to keep using AI tools like Claude and Littlebird going forward - carefully, with real humans directing every action, the same way this whole investigation happened - because they genuinely help a small, volunteer-run fellowship get more done than its people alone have time for. Hopefully this makes the “how” a lot less mysterious, and a lot easier to trust. 🙏