How I Build and Run This Website With Claude Code

I've built websites since 2012, most of them on WordPress, and I started this blog in 2015. In 2026 I stopped running it the WordPress way. The site is now a folder of Markdown files in a git repo, and Claude Code, Anthropic's coding agent, does most of the hands-on work: it writes the templates, builds the pages, checks every deal price against the vendor's own site, and refuses to deploy if a link is broken.

This post is the full setup, with the real commands, the prompts that work, the mistakes it made and the numbers. If you want to do the same for your blog, you can copy all of it.

What Claude Code actually does on this site

Claude Code is an agent that reads a codebase, edits files and runs commands from your terminal, IDE, desktop app or browser. On a blog, the "codebase" is your whole website. These are the jobs it does here every week:

What it doesn't do: buy things, log in to my accounts, post on social media for me, or publish a review of something I haven't used. Those stay with me.

Why I left WordPress first

An agent works best on things it can read and change as text. WordPress keeps your content in a database, your design in a theme, and half your features in plugins with their own settings screens. An agent can't see most of that, and it can't show you a clean diff of what it changed.

A static site generator flips that. Every post is a Markdown file, every layout is a template, every redirect is a line in a text file, and git records every change. This site runs on Eleventy, which is plain JavaScript with no front-end framework, and Netlify builds it from the repo on every push.

There's an SEO reason too. The old site had 39 thin tag archives, and Search Console listed 27 pages as crawled but not indexed. With everything in files, I could fix all of it in one place.

Step 1: Get the content out of WordPress

The migration ran as a series of small scripts, each one writing a report I could check before the next step. They're still in the repo under scripts/:

1. Audit the WordPress export (layer1-audit.js): 33 posts, 9 pages, 12 categories and 39 tags, plus which URLs Search Console showed.
2. Extract every post to Markdown with its SEO fields (layer2-extract.js). 36 of the 42 had a Yoast meta description; the other 6 got one generated. 45 leftover shortcodes from old page builders were listed for cleanup instead of silently dropped.
3. Scaffold the Eleventy site: 99 pages on the first build.
4. Map redirects from the old affiliate links and WordPress system URLs: 71 rules on day one.
5. Audit media: 206 image references, 203 found locally, 3 on other domains.
6. Validate before launch: every post and page present, every canonical tag absolute.

The point of the reports is that you don't have to trust the agent. Each step leaves a file that says what it did and what it couldn't do.

Step 2: Keep every URL that ever earned anything

A migration that breaks old URLs throws away whatever authority the site built up. Claude Code built the redirect map in src/_redirects, and it's grown to 132 lines. The rules follow one idea: every old URL gets a fate.

• Kept: pages with impressions keep their exact slug and get rewritten in place.
• 301: merged or renamed pages point to the closest new page in one hop. Old categories now point to the new topic hubs.
• 410: pages with no value and no successor say "gone", so Google drops them quickly instead of retrying a 404.

One bug is worth knowing about. Old WordPress links like /?p=123 kept returning the homepage with a 200, because path-based redirect rules don't look at query strings. Netlify needs a separate rule that matches the query parameter. Claude Code found it during an audit, fixed it in netlify.toml, and those URLs now return 410.

Step 3: Give the agent guardrails, not trust

This is the part that makes it safe. Claude Code can write a lot of code quickly, so the site has checks it must pass, and the agent runs them itself before it asks me to approve anything.

npm run check          # build, then: links, JSON-LD schema, page-standard lint
npm run deals:check    # re-read every vendor page behind src/_data/deals.js
node tools/indexnow.mjs https://www.blogginghouse.com/some-page/

npm run check fails the build if any internal link returns 404 or goes through a redirect, if any page has two H1s or no meta description, if structured data is missing required fields, or if an image in the HTML isn't in the build. The tools are about 400 lines of JavaScript in tools/, and Claude Code wrote them too.

The deal checker matters most for a blog like this one. Every deal on the site lives in one data file, with the vendor page it was verified on and the date someone last looked:

deal({
  id: "cloudways-bfcm-2026",
  vendor: "Cloudways",
  offer: "80% off for 2 months + unlimited free migrations",
  promoPrice: 2.8,
  renewalPrice: 14,
  endDate: "2026-12-04",
  code: "BFCM802",
  sourceUrl: "https://www.cloudways.com/en/promo-code.php",
  lastChecked: "2026-11-07",
})

Deals take themselves off the page after their end date, both at build time and in the browser between builds. You can see the result on the Black Friday web hosting deals page, where every price has a "checked" date and the renewal price sits next to the promo price.

For indexing, a small Netlify plugin pings IndexNow after each production deploy. One ping is shared with every participating engine, including Bing, Yandex, Naver, Seznam and Yep. The same build also generates a short llms.txt from the topic hubs; here's what llms.txt does and why I publish one.

Step 4: Plan in tickets, not in chat

Chat history disappears. On day one of the November rebuild, Claude Code turned a 90-day growth plan into 79 ticket files in growth/tickets/, each with the goal, the data, the steps, acceptance criteria and a log. A small CLI picks the next job:

node growth/bin/growth.mjs next             # what should be done now
node growth/bin/growth.mjs claim GRW-060 claude
node growth/bin/growth.mjs log GRW-060 "Drafted; numbers from git log"
node growth/bin/growth.mjs set GRW-060 status review

A ticket that needs me (an account, a purchase, a screenshot) gets marked blocked with the exact ask, and the agent moves on to the next one. That's how a session can run for hours without me watching it.

The prompts that actually work

The best prompts are short, because the context lives in files, not in the prompt. These are the kinds I use most:

• Start of a session: "Read coordination/tracker.md, run the growth CLI's next, and take the top ticket." The agent picks up exactly where the last session stopped.
• Content with proof: "Check every price on the vendor's own page before you write it. If a page won't load, leave that vendor out and say so in the ticket log."
• Design: "Build it, take desktop and mobile screenshots, and show me before you commit." I approve layouts from screenshots, not from code.
• Autonomy with a safety net: "Work on a branch. Commit each ticket separately. Don't deploy." Then I review the branch in the evening.
• Rules that stick: I write lasting rules into the project's memory files, such as "never state a deal that wasn't verified on the vendor's page", so I don't repeat them every session.

What went wrong (and what I changed)

An agent makes mistakes just like a person does, only faster. These all happened on this site.

Every image 404'd from June to November. The WordPress uploads folder was excluded from git, and Netlify builds from git. Local builds looked perfect because the folder existed on my laptop. Nobody noticed until November. Claude Code traced it, copied only the 173 images the site actually uses (9.7 MB out of 2,009 files and 91 MB) into a tracked folder, and added a check that fails the build when an image is missing. Lesson: test what the server builds, not what your laptop builds.

It repeated a false claim about me. An early brief said I'd been blogging for 15 years. The agent put that on the About page and into four drafts. It wasn't true: I bought my first domain in 2012 and started this blog in 2015. I caught it, it fixed every instance, and now the facts about me come from one file. Lesson: an agent repeats your brief confidently, so get the brief right.

It published a deal before the vendor did. A Cloudways "80% off" box went live before the deal showed on Cloudways' own site. When the agent re-checked the vendor page, the deal wasn't there yet, so the box changed to "expected" until Cloudways confirmed it. That's why every deal now carries a source URL and a last-checked date. Lesson: make the agent prove prices against a primary source.

It read a promo price wrong. InMotion advertised $4.79 a month. That's the 1-year price. The 3-year term is $4.99 a month, which changes the 3-year cost from the headline. Lesson: ask for the term behind every price.

It can't do everything. When I approved a LinkedIn post, Claude Code's own permission system stopped it from typing into my account. That's the right default. Anything that speaks for you in public should need you.

The numbers

That last row is the honest baseline. The rebuild is about turning impressions into clicks, and I'll publish the before-and-after here as the data comes in.

Should you build your blog with Claude Code?

It's a good fit if you're comfortable reading a diff, you want full control of your site's code and SEO, and you're willing to move off WordPress. You don't need to be a developer, but you do need to review what the agent did.

It's a poor fit if your site depends on WordPress plugins you can't replace (memberships, complex stores), or if you want to install it and never look at it again. The agent is fast, but you're still the editor.

If you're starting from scratch, set it up in this order: a static site generator, a git repo, a host that builds from git, then the checks, then the agent. Want the rest of the AI side of this site as I build it? It's all going in the AI Blogging hub. For the hosting side, see cheap WordPress hosting compared and my Cloudways review.