Learn · Claude Code
How We Rebuilt eseospace.com With Claude Code
A 2,200-page WordPress site, one day to go live on the new host, and three months of running it with Claude Code. What worked and what didn't.
In June 2026 we moved eseospace.com off WordPress and onto a static build, with Claude Code doing most of the engineering and our team making the decisions and reviewing the work. Three months later the same setup runs the site day to day. This is what we did, what it cost us in mistakes, and what we would tell anyone about to try it.
The starting point
eseospace.com was a WordPress site built on the WoodMart theme with the WPBakery page builder, Contact Form 7 and Popup Maker, hosted on Kinsta behind Cloudflare. It had grown to about 2,227 URLs: roughly 1,650 blog posts, about 220 pages and nearly 300 portfolio entries. It worked, but every change went through a page builder, plugins needed constant updates, and site-wide edits meant clicking through hundreds of pages.
The goal we gave ourselves was strict: the new site had to look and behave exactly like the old one on day one, keep every URL, and keep every title, meta description and piece of structured data, so visitors and search engines would notice nothing except speed.
First attempt: a clean rebuild, and why we abandoned it
We started with a clean Next.js rebuild: crawl every page from the sitemaps, strip out WordPress markup and plugin JavaScript, and store tidy HTML while keeping the theme's compiled CSS so the design stayed identical. Claude Code wrote the crawler and the clean-up pipeline in the first hours.
It looked right in screenshots and broke in use. Removing the theme's JavaScript took out animations, FAQ accordions, the booking widget, the review widgets, the background video, menu positioning and the portfolio grids. Every fix exposed another missing behavior. By the end of the first day we made the most important decision of the project: keep the theme's own JavaScript, exactly as it shipped, and change the page as little as possible. The tool could have kept patching; a person had to decide that fidelity mattered more than clean code.
What we built instead
The new approach treats each crawled page as the source of truth. A preservation step saves every page as a complete, self-contained HTML file with its scripts and styles, rewrites asset URLs to local copies, and undoes the WordPress speed plugin's "delay until interaction" trick so scripts run normally. A build step writes the finished site as plain static files.
Two infrastructure changes followed quickly:
- Fully static hosting. The first deploy used a Next.js server function, but the bundle was far too large for the host's form handling, so we switched to publishing plain static files to Netlify with a single serverless function for forms.
- Forms without the host's form detection. Netlify only registers forms it detects during its own build, and ours was built beforehand, so no forms registered. We kept the original contact forms and added a small script that sends submissions to a serverless function, which emails them through Mailgun.
The site went live on the new host on 23 June 2026, the day after the first commit.
Keeping SEO intact
Before switching DNS, Claude Code wrote a comparison script that fetched the head of every page on the old and new sites and compared titles, meta descriptions, robots directives, canonical tags, structured data types and H1s. On the first run the only difference was that some URLs had become relative during the asset rewrite. After the fix, the comparison showed zero differences across all 217 pages checked. Sitemaps and robots.txt were mirrored at first and are now generated from the site's own page index, so a retired page drops out of the sitemap automatically.
Over the following weeks we used the same pipeline for SEO work that would have taken days in WordPress: adding missing meta descriptions, regenerating tables of contents from each post's real headings, rebuilding sitemaps, and keeping GEO and AEO signals such as structured data and an llms.txt file consistent across the site.
Performance
Keeping the theme's JavaScript for fidelity had a cost. In our own lab test with PageSpeed Insights, the desktop score was 56, and almost all of the problem was Total Blocking Time: about 1,200 milliseconds spent running theme scripts on load.
The fix was a self-hosted version of the trick WordPress speed plugins use: most theme scripts wait until the visitor first scrolls, taps or types, then run in their original order. Search engine crawlers see the complete page without them. In the same lab test, the desktop score went from 56 to 86 and Total Blocking Time from about 1,200 milliseconds to near zero, with no JavaScript errors before or after interaction. A separate pass combined each page template's roughly 70 stylesheets into one file, cutting CSS requests on a typical page from 75 to 4.
These are lab measurements from our own tests on specific pages, not field data. Your results depend on your theme, plugins and hosting.
Running the site with Claude Code
The rebuild was the easy part to describe. The bigger change is how the site is run now. Every recurring job is a small script that can be run again safely, and the scripts run in a fixed order before each build. There are 262 of them. A few examples:
- Publishing. A new article is a text file and an HTML body. One script renders it into the blog template, registers it, adds it to the sitemap and the blog listings, and gives it a hero image. More than 300 articles have been published this way, including our recent link-builder series.
- Site-wide corrections. In September 2026 we ran a full accuracy audit of the site, checking claims against primary sources. The fixes, more than 4,400 corrections across about 750 pages, were applied as scripted edits, each tested on a copy first. We then rebuilt the whole site from scratch in a sandbox to confirm that none of the corrections would be lost on a future rebuild.
- Redirects. Retired and merged pages are handled in one redirects file, currently 235 rules, generated into the host's redirect format on every build.
- Forms and spam. The contact function filters known spam patterns before anything reaches the inbox.
Mistakes that taught us our rules
Almost every rule in our CLAUDE.md templates exists because something went wrong. The ones worth sharing:
Every new post showed the same article
New articles were built by copying an existing post as a template. The script replaced the wrong container, so for a while every new post still carried the template post's text. We caught it in review. Lesson: when a script copies a template, check the output of the second page it produces, not just the first.
A safety check that made scripts skip everything
Two scripts checked whether a page had already been processed by looking for a class name, but the same class name appeared in the stylesheet those scripts added. After the first run, every page looked "already done" and the scripts silently skipped the whole site. Lesson: check for the actual element, not a word that might appear anywhere, and always read the counts a script reports.
A price that ate itself
When we updated our plan prices across the site, the new text included amounts such as "$1,200". In JavaScript's replace function, "$1" inside the replacement text means "the first matched group", which garbles the output. Lesson: when replacement text can contain dollar signs, use a function rather than a string, and read the result, not just the count of changes.
One missing brace broke the header
Combining stylesheets exposed a theme file with an unclosed curly brace. On its own the browser forgave it; combined with the next file, the error swallowed the header styles on every page. Lesson: validate combined output in a real browser before shipping, not just the build log.
Two sessions, one site
We sometimes run more than one Claude Code session on the site. Once, one session regenerated a group of pages while another had just edited them, and the edits disappeared. Lesson: before any deploy, check the git history for changes you did not make, and re-run your own steps if needed.
Who did what
| Our team | Claude Code |
|---|---|
| Decided fidelity mattered more than clean code | Wrote the crawler, preservation and build pipeline |
| Chose the host and approved every deploy | Wrote the deploy steps and the form function |
| Owned brand facts, prices and what the site claims | Applied site-wide edits and found every copy of a changed fact |
| Reviewed diffs, screenshots and audit findings | Ran comparisons, link checks, audits and before-and-after tests |
| Signed off on content before publishing | Rendered, linked and registered each new page |
What we would tell you
- Decide what "done" means before you start. Ours was "identical to the old site, same URLs, same SEO head". A clear test let the AI check its own work.
- Make every change repeatable. A script you can run twice safely beats a perfect one-off edit, because you will need to run it again.
- Keep people on the decisions. The tool is fast at doing things and poor at deciding which things matter.
- Verify facts, not just code. A site can build perfectly and still say something wrong. Our accuracy audit found far more problems in the words than in the code.
- Start small. Let it fix one page type, review it, then widen the scope.
Frequently asked questions
Did Claude Code build the site on its own?
No. It wrote nearly all of the code and ran most of the checks, but people made the key decisions, owned the content and approved every deploy. Treat it as a very fast engineer who needs a clear brief and a reviewer.
Did the migration hurt search rankings?
We kept every URL and matched every page's title, description, canonical tag and structured data before switching, which is what protects rankings in a migration. We have not published a traffic comparison here because traffic changes over this period also reflect Google's own updates and our content work.
Could we do the same with our WordPress site?
Often, yes, especially if the site is mostly content and forms. Sites that depend on logged-in areas, e-commerce checkouts or live plugin features need a different approach. Our AI-built website migration page explains the options.
What does a setup like this cost to run?
Static hosting is inexpensive, and the ongoing cost is mostly Claude Code usage and review time. The real saving is that site-wide changes take minutes of review instead of days of clicking.
We plan, build and review AI-assisted migrations and keep every URL and SEO signal intact.
Talk to us about a migration