Managing my website with Claude Code
If you look at the timestamps on this website, you will notice a long gap. The last post before this one dates from 2015. That is eleven years of silence — not because I stopped building things, but because managing the website itself became too much of a burden.
Why the website went quiet#
The site was originally built using Nanoc , a static site compiler written in Ruby. At the time it was a good choice: content in Markdown, a compilation step, clean HTML output. But over the years, a few things went wrong:
- I migrated machines and lost the build environment. Reconstructing it meant reinstalling Ruby, the right gem versions, Nanoc itself, and all its dependencies — fiddly work I kept putting off.
- Nanoc has become less actively developed and its ecosystem has shrunk. Things that used to work stopped working.
- The feedback loop between writing a post and seeing it live became long enough to be discouraging.
The content was still there. The will to write was still there. But the toolchain was broken and rebuilding it kept falling to the bottom of the list.
That changed when I started using Claude Code .
What is Claude Code?#
Claude Code is Anthropic’s AI coding assistant that runs in your terminal. It is not a chat interface — it is an agent that can read and write files, run commands, browse the web, and work iteratively on complex tasks. You describe what you want in plain language, and it figures out the implementation.
This is a subtle but important distinction. You are not writing prompts and copy-pasting responses. You are having a conversation with something that has access to your actual project and can act on it directly.
For a personal website like this one, that means Claude Code can handle the full lifecycle: setting up the build toolchain, migrating content, fixing broken paths, managing URL redirects, committing to version control, and deploying to the web host. All of this through plain language instructions, without touching a terminal yourself.
Setting up Hugo and the Blowfish theme#
I told Claude Code I wanted to migrate my website to a modern static site generator. It recommended Hugo — a fast, well-supported static site generator written in Go — and presented the available theme options. I browsed through them and selected Blowfish based on its clean design and the features it offered.
Claude Code then installed Hugo, set up the Blowfish theme as a git submodule, configured the directory structure, and adjusted the configuration files to match my preferences. I did not write a single config file by hand. I described what I wanted — the site title, the menu structure, the footer, the colour scheme — and Claude Code made the changes, ran hugo server to preview the result, and iterated until it looked right.
The whole setup, including custom CSS overrides and a modified footer that credits Hugo, Blowfish, and Claude Code, was done through conversation.
Migrating the old content#
This is the part that would have taken me days or weeks to do manually.
The old site was still running live at its public URL. Claude Code scraped every page from the live site, converting each HTML page back into a clean Markdown file with proper frontmatter. It preserved the content, images, categories, and dates — working entirely from the public HTML with no access to the original source files.
After the initial conversion, it then went through each post to fix image paths, making sure they pointed to the right locations in the new Hugo directory structure. It also handled posts that contained embedded code blocks, tables, and other structured content, converting them accurately.
Later, I found a backup of the original images and Markdown-formatted source posts. I instructed Claude Code to use these as the authoritative source instead of the scraped HTML, and it re-processed the content accordingly — a good example of how you can redirect the work mid-process without starting over.
Keeping old URLs working#
One of the less obvious problems with migrating a static site is URL continuity. My old site used URL patterns like /posts/TS-50%20USB%20Interface/ — with spaces and mixed case. Hugo generates clean slugified URLs like /posts/ts-50-usb-interface/. Anyone who had bookmarked or linked to the old URLs would hit a 404.
Claude Code handled this in two ways. First, it added aliases in the frontmatter of each post, mapping the old URL to the new one. Hugo uses these to generate redirect pages automatically.
Second, it analysed the external backlinks pointing to the site and created static HTML redirect files in /static/categories/ for old category URLs that used the .html extension format.
These are exactly the kinds of details that are easy to overlook in a manual migration and tedious to fix after the fact. Claude Code did it proactively.
Deploying to FTP#
My hosting at LWS uses plain FTP. After building the site with hugo --minify, the generated files in /public need to be uploaded to the web host.
I mentioned this constraint once. Claude Code figured out the rest: it found the FTP credentials in a local credentials file, wrote the upload script, and can now deploy the site with a single instruction. No manual FTP client, no remembering hostnames or paths.
Committing to GitHub#
The site source is version controlled in a GitHub repository . Claude Code handles commits too — staging the right files, writing a sensible commit message, and pushing to the remote.
For this session, for example, I asked it to commit the current state of the site before writing this post. It did that, then started the brainstorm for this article.
The iterative conversation model#
What makes Claude Code useful for ongoing work is that it is not a one-shot tool. Within a session it has full context of what it has done, what files it has changed, and what decisions it has made. You can ask follow-up questions, correct mistakes, and change direction mid-task.
Across sessions, context is preserved through a CLAUDE.md file in the project root. Claude Code maintains this file itself, recording key architectural decisions, important file paths, deployment procedures, and session history. When you start a new session, it reads this file and picks up where it left off. It functions as a kind of institutional memory for the project — written by the AI, for the AI.
There is also a /changelog skill that documents what Claude Code did in a session to a changelog file. Between CLAUDE.md and the changelog, the project history is well-documented without any manual record-keeping.
What this means in practice#
Before Claude Code, updating this website meant:
- Remembering how the build environment was set up
- Reinstalling anything that had broken since last time
- Writing the post
- Running the compiler and checking for errors
- Uploading manually via FTP
Now it means:
- Writing the post (or asking Claude Code to draft it based on notes)
- Saying “build and deploy”
The saved time is real. The migration alone would have taken me several days of focused work — and I probably would have cut corners, skipped the redirect handling, and left some posts broken. Claude Code did it thoroughly in a single session.
More importantly, the friction is low enough that it is now worth posting again.