If you run a small WordPress site and haven’t thought much about optimization, security, or caching — this series is for you. A few weeks ago I used Claude, an AI assistant by Anthropic, to do a full technical review of this very site — the one you’re reading right now. Claude walked me through every problem it found and every fix in real time, while I made the changes directly in my dashboards. What we uncovered was not great — but the process turned out to be genuinely useful, so I’m documenting every step here so you can do the same thing on your own site.
I’m not a developer. I know enough to get around WordPress, use cPanel, and follow instructions — but I don’t write code and I don’t spend my days in server dashboards. If that sounds like you, keep reading. This series was written with exactly that person in mind. And yes — Claude also helped write these posts, based on the actual work we did together.
What the Site Looked Like Before
This site had been running for a few years without much maintenance beyond publishing posts and keeping plugins updated. On the surface it seemed fine — it loaded, the WooCommerce store worked, people could check out. But when we started actually looking under the hood, a different picture emerged.
Here’s what we found:
- xmlrpc.php was wide open — this is a legacy WordPress file that bots actively scan for. It was accessible and unprotected, which is an open invitation for brute-force attacks.
- The WordPress login page was at the default URL — wp-login.php, the standard address every attacker tries first.
- readme.html was still sitting in the root folder — this file publicly advertises your exact WordPress version number, which helps attackers target known vulnerabilities.
- The REST API was leaking the admin username — anyone who visited /wp-json/wp/v2/users could see the account name used to log in.
- Cloudflare was set up but configured wrong — there was a duplicate DNS record, FTP and cPanel were being proxied through Cloudflare (which breaks them), and SSL was set to a weaker mode.
- No meaningful caching rules were in place — Cloudflare wasn’t caching HTML pages at all, so every visitor was hitting the origin server directly.
- PayPal’s SDK was loading on every page — not just checkout pages. This was bloating the page weight and hurting performance scores on pages that had nothing to do with payments.
- A vulnerable plugin was handling a security header — the HTTP Headers plugin was flagged as a security risk, yet it was active and responsible for a key browser protection setting.
None of these were catastrophic on their own. But together they added up to a site that was harder to hack into than an unlocked door, but not by much. If I’d been asked to give it a grade at that point, I’d have said D+.
Why This Actually Mattered
You might be thinking: “I’m a small site, nobody is targeting me.” That’s mostly true — but the attacks that hit small sites aren’t usually targeted. They’re automated. Bots constantly scan the web looking for sites running vulnerable plugin versions, exposed login pages, or open xmlrpc endpoints. They don’t care if your site gets 200 visitors a day or 200,000. If your door is unlocked, they’ll try it.
Beyond security, performance had a real business impact. This site runs a WooCommerce store. A slow checkout process or a cart that shows stale items because of aggressive caching costs actual sales. And since Google uses Core Web Vitals as a ranking factor, a sluggish site also means worse visibility in search results — fewer people finding you in the first place.
The other thing worth mentioning: a lot of these problems were invisible. The site looked fine. Nothing had gone wrong — yet. But the gaps were there, quietly waiting.
What We Decided to Fix
Rather than tackle everything randomly, we worked through the problems in a logical order: Cloudflare configuration first (since it affects everything else), then WordPress security hardening, then performance, then WooCommerce-specific issues. Each step built on the last.
Here’s how the full series breaks down:
- Post 1 (this one): The starting point — what was wrong and why it mattered
- Post 2: Setting up Cloudflare the right way for a WordPress site
- Post 3: WordPress security hardening without touching code
- Post 4: Speeding up a WordPress and WooCommerce site
- Post 5: WooCommerce-specific fixes — caching, checkout, and cart problems
- Post 6: Lessons learned and final results
Tools We Used (All Free or Already Installed)
One thing I want to flag early: almost everything we did used free tools. No premium plugins were purchased for this project. Here’s what was in play:
- Cloudflare (free plan) — for DNS, caching, SSL, and security rules
- WP Optimize — for WordPress-level caching and database cleanup
- Jetpack Boost — for CSS optimization and lazy loading
- WPS Hide Login — to move the login page off the default URL
- Code Snippets — to run small PHP fixes without editing theme files
- PageSpeed Insights (Google, free) — to measure performance before and after
- SecurityHeaders.com (free) — to verify browser security headers were working
- HostGator cPanel — for database access via phpMyAdmin when WordPress’s UI wouldn’t cooperate
Nothing exotic. If you have WordPress hosted somewhere with cPanel access and Cloudflare on your domain, you can follow along with everything in this series.
The Honest Truth About Small Site Maintenance
Most small site owners — and I was absolutely one of them — do the minimum. Keep plugins updated, make sure the site loads, move on. That’s understandable. You’re running a business or a blog, not a DevOps operation.
But there’s a category of problems that don’t announce themselves. They sit quietly in the background: a misconfigured DNS record that’s been wrong for two years, a login URL that bots are hammering every day, a caching setup that’s technically active but doing almost nothing useful. You don’t know they’re there because nothing has broken yet.
The value of a proper review isn’t just fixing problems — it’s finding out what you don’t know you have. That’s what this series documents.
What’s Next
In Post 2, I’ll walk through exactly how we reconfigured Cloudflare from scratch — fixing the DNS records, setting up proper cache rules, enabling security features, and upgrading SSL. It’s the foundation everything else in this series builds on, and it’s one of those things that’s easy to get mostly right but surprisingly easy to get slightly wrong in ways that matter.
If you want to follow along with your own site, the only thing you need before Post 2 is a Cloudflare account with your domain added. The free plan is all you’ll need.
→ Continue to Post 2: Setting Up Cloudflare the Right Way for WordPress
Things that I use, like, and am affiliated with:
Mint Mobile offers great cell phone service for $15 flat, get $15 off using the link. Get discounted phones with service activation and no contract.
I never spend money before I check Mr Rebates or Rakuten to get cashbacks, rebates, discounts, coupons or cheaper gift cards.