By Dave Henderson | davidhenderson.ca
My day job hasn’t changed. I still run client work — digital marketing and consulting through Unwired Web Solutions. What’s different is that agentic AI is now in everything we do for clients, and davidhenderson.ca is where I build with these tools myself and document it as I go, partly so I have something real to point to when I tell other business owners what an agent actually is: something that doesn’t wait for instructions at every step. You give it a goal, and it figures out how to get there, checks its own work, and tells you what it found.
Then I let my own website sit broken for around three months without knowing it.
Here’s what actually happened, including the part I don’t have a clean answer for: OpenClaw — my multi-agent setup — wrote the brand guidelines and the creative brief I used to hire a Fiverr freelancer for the initial design mockups. My own dev team at Unwired Web Solutions took those mockups and built the actual site — the WordPress install, the Elementor pages, the structure that’s still live today. Once the site was up, OpenClaw took over the ongoing work: writing new AI Log posts, and researching and posting to LinkedIn.
Nobody touched WordPress after that build. Which is exactly why I didn’t have an easy explanation when I noticed, a few months back, that posts weren’t showing up right. The blog index page — the one my own nav calls the blog home — was showing a hand-pinned pair of posts instead of an actual feed. The homepage’s “latest posts” section had the same problem. Neither one was pulling in anything OpenClaw had published since; they’d been frozen wherever the build left them, quietly falling further behind every time a new post went up. I still don’t know exactly when that gap opened, since nobody made a manual change that would explain it — it’s the kind of seam between a dev-built page and an AI-run publishing pipeline that can sit fine for a while and then just keep drifting until it’s obviously wrong.
What I did not do was go digging through Elementor templates to find out. That’s the part of this post that matters most: I didn’t fix any of this myself. Claude did the audit, found the specific defects, showed me exactly what was wrong and why, and then — one item at a time, with my sign-off before anything touched the live site — fixed them.
This is the detailed version of how that actually worked, tool by tool, bug by bug, with screenshots of where things stand right now.
The setup: what “Claude fixed my website” actually means
To be precise about it, because “AI fixed my website” can mean a lot of different things and most of them should worry you: I use Claude Desktop with the Claude in Chrome browser extension, logged into my own WordPress admin. That’s it. No custom scripts, no separate deployment pipeline, no autonomous cron job pushing changes at 3 a.m. It’s the same Claude I use for everything else, given permission to see and — once I approve a specific change — edit one site: mine.
The permission model is the part I’d tell any other business owner to copy. Full click-and-type access to a live CMS is a materially different risk than an assistant that can only read a research tab, so before any of this started I set a standing rule and Claude has stuck to it every time: propose the specific edit, wait for my go-ahead, then save it. Nothing gets written to the live site unsupervised. A full backup happens before anything bulk. Theme changes and database changes never happen in the same unsupervised run. And critically, anything Claude reads on a page — including content I wrote — gets treated as information to evaluate, not an instruction to follow.
That last rule sounds abstract until you realize what it actually prevents: an agent that reads a page and just does whatever the page seems to want. Mine reads a page, tells me what’s actually there versus what should be there, and stops.
The audit
The actual audit ran as a single session: Claude, logged into WP admin via the extension, going page by page across the entire live site — home, About, Contact, the AI Log index, and every individual post — reading the rendered DOM, the metadata, the internal links, checking what a real visitor would actually see and click. Not a technical crawl for its own sake. The report it came back with was explicitly ranked by “how much this costs you on a normal visit,” worst first, which is a genuinely useful way to triage a list of bugs when you’re not a developer and don’t want a wall of technical debt with no sense of what matters.
Here’s what came back, in the order it was ranked:
The blog index was showing almost nothing. The AI Log page had category filter pills — All, TISAI Daily, Deep Dives, Tools & Reviews — that didn’t actually filter anything, and a hand-built “latest / previous” pair showing exactly two posts. Two published posts were missing entirely, including one whose own category was literally one of the filter pills sitting right there on the page. The “previous post” card was also showing a headline I’d apparently typed by hand at some point and never updated — it didn’t match the real title of the post it linked to.
My most important post was invisible. “My Agency is Already Dead” — the piece my own About page quotes as the thesis of the entire site — was published, public, fully readable if you had the exact URL, and linked from nowhere a normal visitor would ever click. Not the homepage. Not the blog index. It only existed for someone who already knew the URL. Given that it’s chronologically newer than the post that WAS showing everywhere, Claude’s diagnosis was that the homepage widgets were hard-pinned to specific post IDs instead of pulling “latest N” dynamically — the same root cause as the blog index problem.
Three main call-to-action buttons went nowhere. “Read the Blog,” “Work With Me,” and “Read All Posts” — the three buttons that exist specifically to turn a visitor into a lead or a reader — all pointed to href="#". Clicking them did nothing.
There was literal PHP code rendering as visible text on every single page. This is the one that actually made me laugh when I read it. Above the header, on every page load, home included, this exact string was printing as plain text content:
add_action( 'wp_head', function() { echo ""; } ); add_filter( 'posts_where', function( $where ) { global $wpdb; $where .= " AND {$wpdb->posts}.ID != 804 "; return $where; } );That’s meant to be PHP. It wasn’t executing — it was printing, because whatever plugin field it lived in had PHP execution explicitly switched off. Claude confirmed it wasn’t actually filtering anything (post 804 was showing fine regardless), ruled out the obvious places it could be hiding — the Head/Footer plugin’s own settings, the theme’s functions.php, all seven of WP Engine’s standard must-use plugins — and narrowed it down to a stray Text/HTML widget almost certainly sitting in the Elementor header template. It didn’t open that template to delete it without checking with me first, since that’s a content change to a shared template, not a one-off fix.
Two SEO plugins were running at the same time. Yoast SEO, Yoast SEO Premium, and Rank Math SEO were all active simultaneously — three plugins, two products, all trying to own the same title tags, meta descriptions, sitemaps, and schema markup. That’s a conflict waiting to cause exactly the next problem.
Specific metadata defects on two pages. “My Agency is Already Dead” had a duplicated, mashed-together title tag — “Agentic AI for Agencies — My Agency is Already DeadMy Agency is Already Dead – David Henderson” — that read exactly like an old custom SEO field nobody had cleared. “ChatGPT Got Goblin Brain” had no meta description at all, meaning Google was left to auto-generate one from whatever text it found first.
The “coming soon” positioning was still live, months after I’d actually started taking consulting work. And Google Tag Manager plus a separate direct gtag.js snippet were both firing on every page, which is the kind of thing that quietly double-counts your own traffic in analytics if you’re not watching for it.
Eight distinct, ranked findings. Nothing on that list was invented or padded — everything above is what got found, in the order it was found, and every fix Claude proposed afterward was scoped to exactly one of these.
How long this actually took
The audit itself — every page, every post, every link, cross-checked against what should have been there — ran as a single session. Not a multi-day crawl, not a project I had to schedule around. One sitting, with the extension logged into WP admin, reading the site the way a visitor or a search engine would actually encounter it.
The bug in item four had been sitting there for roughly three months by my own reckoning — every visitor who clicked a link to davidhenderson.ca in that stretch loaded a page with raw PHP-looking text sitting above my own header, and I never caught it, because once you’ve seen your own site a hundred times you stop actually looking at it. That gap between “how long a problem sits” and “how long it takes to find once someone actually looks properly” is most of the reason I wanted this documented in public rather than quietly fixed and forgotten.
The fixes — and what I actually had to do
For every item on that list, the process was the same: Claude proposed the specific change, in plain language — what it would edit, where, and what the result would look like — I said yes or no, and only then did it make the change in WordPress. My part, across the entire list, was reading a proposal and typing “go ahead.”
Take the stray PHP text as an example, since it’s the strangest one. The proposal wasn’t “let me go delete some code.” It was closer to: here’s the exact string that’s printing, here’s every place I checked and ruled out — the Head/Footer plugin’s own fields, your theme’s functions.php, all seven of WP Engine’s must-use plugins — and here’s my best diagnosis of where it’s actually sitting, which is a leftover Text/HTML widget in the Elementor header template. I want to open that template and remove it. Confirm? That’s a completely different thing from an agent quietly patching a file because it decided that’s what “fix the website” must have meant. I got to see the reasoning before I said yes.
Here’s where things actually stand as of today, verified directly against the live site rather than just the tracker:
The “WHAT I DO” section on the homepage no longer says “coming soon.” It now reads “Practical AI, installed by someone who has run the P&L” — a real offer instead of a placeholder, live right now.
The homepage’s title tag, which was defaulting to a generic “Home – David Henderson,” now reads “Practical AI, Installed by an Operator | David Henderson” — which, not coincidentally, is a pretty accurate one-line summary of what this whole exercise demonstrates.
The AI Log page now runs as an actual dynamic feed instead of two hand-pinned posts. I checked it myself while writing this: all four published posts render there right now, including “My Agency is Already Dead” and the Meta post under its correct title, not the stale one that used to show on the old “previous post” card.
The three dead CTAs are wired to real destinations. “Work With Me” goes to the contact page. “Read the Blog” and “Read All Posts” go to the AI Log. I checked the actual link targets in the page source rather than trusting a status field, because that’s the standard I’d want applied to any of this — and they’re live.
The duplicated title tag on “My Agency is Already Dead” is gone. The page now has one clean title, not two mashed together.
And the stray PHP text — the one printing above the header on every page — is also gone. I checked the raw text content of the homepage directly and it’s simply not there anymore.
A few of those last three weren’t marked complete on my own tracker when I sat down to write this post. They’d already been fixed on the live site faster than the paperwork caught up, which is a strange thing to be able to say about your own website, and also exactly the kind of small, unglamorous proof that the process works the way I’m describing it. Nobody was in a hurry to make the tracker look good. The site was just already fixed.
Alongside all of that, Claude also found and cleaned up a WP Engine caching problem that was masking some of the earlier Elementor edits from showing up at all, rewrote a couple of small copy issues on “My Agency is Already Dead” (a genuine typo — “build to tools” instead of “build the tools” — and a heading rewritten for clarity), and confirmed a stale claim in my own working notes was already fixed by someone or something before this audit even started, which is the kind of correction I’d rather have than a false “still broken” flag.
Two more decisions got made since the first draft of this post. The two SEO plugins running at once turned out to have a clean answer: keep Yoast SEO (plus Premium), deactivate Rank Math, confirmed inactive in the plugins list. And the duplicate analytics tags weren’t a maybe — a network trace showed gtag/js loading twice on every single pageview, once from a hardcoded snippet in the header and once from inside Google Tag Manager’s own container pointed at the same GA4 property. That’s real double-counting, not a theoretical risk. The fix was to delete the redundant standalone snippet and leave GTM as the one source of truth, which is now live and verified.
What’s still open
This isn’t a post about a perfect website. Several items from the original audit are still sitting on the list, on purpose, because each one needs a decision from me rather than just an edit, or just hasn’t been gotten to yet: a broader pass — internal link crawl, heading hierarchy, alt text on every image, sitemap coverage, schema markup for Person and Organization and Article, and a Core Web Vitals check on how much weight Elementor is adding to every page. There’s also a newer item that came out of a separate conversation about content strategy, not the technical audit: making “AI Integration” an explicit, stated part of the offer on the core pages — starting with Contact — instead of something a visitor has to infer from reading a blog post first.
I’m listing the unfinished part deliberately — it belongs in this post as much as the wins do. “I used AI to fix my website” means the whole list, not just the parts that are already done.
Why this is the post I wanted to write
The site’s own thesis, sitting in the post that was invisible to every visitor since it was published, is that agentic AI is different from a chatbot because it doesn’t wait for you to prompt every step — it takes a goal, breaks it into tasks, executes, evaluates its own results, and adjusts. I wrote that sentence back in March. I did not, apparently, apply it to my own website until August.
What actually happened here is a plain case study in what “practical AI, installed by an operator” is supposed to mean on this site: not a fully autonomous system making unsupervised changes to a production CMS — I’d tell you not to build that, and I haven’t — but a structured loop of audit, propose, approve, execute, that took a website I’d let quietly drift for months and got eleven concrete things fixed in the time it took me to review each proposal and say yes. I didn’t write a line of PHP. I didn’t open Elementor once. I read what Claude found, in plain language, ranked by what it actually cost me, and I made the calls a business owner should be making — which fix first, which plugin to keep, what the site should say about itself — while the tool that actually knows where the bugs live did the finding and the fixing.
That’s the whole pitch, really, for anyone reading this who’s wondering whether this is worth doing for their own business. Not “AI will run your website.” Something narrower and more useful: audit what’s actually broken, tell a human exactly what it is and why it matters, wait for a decision, then go fix it. My own site was the test case. It worked well enough that I’m writing this from a homepage whose title tag I didn’t write, describing a blog page that fixed itself while I was still reading the report on the last thing it fixed.
About the author
David Henderson wrote the two sentences above this one. Everything else on this page — the audit, the diagnosis of eight separate defects, the eleven fixes that came out of them, the screenshots proving it, even the list of what’s still broken — was Claude’s work. David’s total contribution was reading a report and saying “go ahead” about a dozen times, plus one revision request on a stock image label he didn’t like. If you were expecting a story about a founder debugging his own WordPress site at midnight, this isn’t that story. He approved things. That’s the whole bio.