Most case studies are about a client’s site. This one’s about mine, cityofoaksmarketing.com, my agency’s own site, because it went through the same kind of audit-and-cleanup process I run on client projects, and I have nothing stopping me from showing the actual work.
I’ll say upfront what this post is not: it’s not a before-and-after speed chart. The old version of the site wasn’t benchmarked before it came down, so I’m not going to invent a number to make this look more dramatic than it was. What follows is what actually got found and fixed, with the real numbers I do have.
What an audit of my own site turned up
City of Oaks Marketing runs on the same custom theme I build for clients (internally I call it “oak-city”), and like any theme that’s been through a few years and a few projects, it had picked up debt:
- Leftover files from an earlier, unrelated project. The theme had inherited template files and broken internal paths from a past build that had nothing to do with the current site. They weren’t doing anything visible, they were just sitting there, adding surface area for confusion and risk every time someone (including me) had to figure out what a given file actually did.
- An unused custom post type. A “Team” post type was still registered in the codebase with no content using it. Dead code that’s still wired up is worse than dead code that’s obviously gone. It shows up in admin menus, it gets included in queries, and it’s one more thing a future developer (or future me) has to rule out before touching anything nearby.
- A paid plugin doing what WordPress can already do. Search & Filter Pro was handling the site’s index/listing grids and search. That’s a fine plugin, but it’s a paid, third-party dependency for functionality that native
WP_Querycan handle directly, with fewer moving parts and one less thing to break on a plugin update.
What I did about each
Removed the dead files and fixed the broken paths first, since that’s zero-risk cleanup with no functional change to verify. Retired the Team CPT entirely rather than leave it registered and unused. Rebuilt the index/listing grids on native WP_Query and WordPress’s own header search, and replaced Search & Filter Pro’s search relevance with WP Engine’s Smart Search AI, which is already included with hosting rather than a separate paid layer doing the same job. Net effect: one fewer paid plugin, one fewer unused content type, and a codebase where what’s registered actually corresponds to what the site uses.
Where the site actually stood going into this
Here’s a real number, with the honest context around it: by the time this cleanup shipped, the site’s organic visibility had already grown from a single ranking keyword in January 2026 to 53 by August, per Semrush. That growth happened before the cleanup, from the separate content and SEO work I’d been doing over the year, not because of it. I’m not attributing it to a redesign that hadn’t happened yet. I’m including it because it’s the actual context: this wasn’t a stagnant site getting a facelift, it was a site with real, growing visibility that I didn’t want to put at risk with a messy migration.
What I’m not claiming yet
The cleanup shipped the week of September 5, 2026 (theme version 1.3.x, live on WP Engine). That’s recent enough that there isn’t meaningful post-launch ranking or speed data yet, Search Console and Semrush both need weeks to reflect a change like this, not days. I’d rather say that plainly than publish a number I can’t back up. I’ll revisit this once there’s actually enough time for the data to mean something.
Why this is the same process I run for clients
Audit first, and actually verify what’s unused instead of guessing. Remove dead weight with zero functional risk before touching anything that changes behavior. Replace a paid, third-party dependency with a native solution when the native solution genuinely covers the same job, not as a blanket rule, but when it’s true. And keep working code working: this wasn’t a rebuild, it was a cleanup of a site that was already live and already getting real traffic. That distinction, cleanup versus rebuild, is usually the right call for a site that’s functioning but accumulating debt, and it’s the same evaluation I’d walk a client through before recommending either one.
If your own WordPress site has the “nobody’s quite sure why this is here” problem, let’s talk about it, or see how this kind of work fits into a full custom WordPress development engagement.
