Minus 2,000,000 Lines of PHP: How We Rebuilt Our Website with Claude Code

Our company website no longer has a backend. No WordPress, no PHP, no MySQL, no plugin zoo to patch on a Sunday evening. One commit - 779d02f5, “refactor to Astro” - touched 14,917 files, added 117,883 lines and removed 2,088,895. The deletions were, to be fair, mostly the WordPress tree itself: core, plugins, theme, vendor code. That was the point. The cut-over was the feature.

What makes this story worth telling is not the framework swap. It is that the entire migration - analysis, code, visual verification, SEO continuity, performance tuning - was done with Claude Code: AI agents orchestrated by workflows, verified by other agents, reviewed and decided on by humans. The final migration session lasted 105 minutes and contained exactly 4 human prompts. (To be honest about it: that was the final session. The whole project spanned 21+ sessions and around 90 human prompts from late May onwards.)

The starting point and the two non-negotiables

Before: a classic WordPress stack - WPML for English and German, ACF, Yoast, a collection of plugins, a PHP+SCSS theme, MySQL. And the classic pains: hosting bills, updates and vulnerabilities to babysit, slow TTFB rescued by caching plugins, editing through wp-admin.

We set two hard constraints for the rebuild:

1. The site must look identical. Pixel parity with production, not “close enough”.
2. Zero SEO loss on the technical level. The same URLs (trailing slash included), hreflang, meta tags, JSON-LD, and a 301 map for every legacy slug variant.

After: Astro 7 (we started on 6 and moved up during the project), fully static build. Content lives in markdown with schema-validated content collections (Zod). The build produces over 250 static pages - English at the root, German under /de/, with the architecture ready for more languages without a rebuild. Hosting moved to Cloudflare Workers Static Assets: served from the edge, with static asset requests free and unmetered. There is no backend in the classic sense - nothing to hack, nothing to patch.

Method: a system, not a chat

This was not “chatting with an AI”. It was a system built from three blocks.

CLAUDE.md - the repository’s brain. It documents the architecture, the verification commands, what must not be touched, and - crucially - a list of things that look like bugs but are not: randomized “related posts” (orderby=rand), content hidden behind hover states or display:none, the boundaries of text-comparison windows. Every session and every agent starts with this context instead of guessing.

Dynamic workflows - script-driven orchestration of many agents at once, with deterministic phases, loops and fan-out: parallel page analysis and migration, diagnose->fix->re-render->compare loops, vision QA where a model literally looks at screenshots, and a build verification gate after every phase.

Skills - 13 packaged procedures in the repo. Six are content operations written for non-technical people (new blog post, edit page content, new case study, job offers, team management, digital business cards) and seven are technical (Astro, SEO, performance, Core Web Vitals, accessibility, best practices, quality audit).

The binding principle: humans decide and review - agents execute, verify and report. Trust comes from verification loops, not from faith in a model.

AI verifying AI: the visual parity pipeline

The most interesting engineering artifact of the project is the self-contained audit->fix->verify cycle that enforced pixel parity:

1. Production mirror. A local server serving a mirrored copy of the live WordPress site as the source of truth for looks and content.
2. Paired screenshots. Puppeteer with 16 parallel headless browsers rendering the same page on production and in Astro, desktop and mobile. The first full scan compared 236 pages in 214 seconds of rendering: 92 OK, 109 minor, 34 major, 1 critical.
3. Diff and clustering. 6,762 crop diffs (1.2 GB) sliced into atomic differences; 79 unique structural page signatures grouped into 32 clusters with identical diff signatures - for example, one “flexible” cluster covered 73 blog posts sharing the same section layout. Diagnose once per cluster, not once per page.
4. Agent-based diagnosis. One agent per page reads the diff data and the image crops, and classifies every difference atom: real defect or known artifact. Then an adversarial verification pass - 25 independent confirmations of root-cause groups plus regression-risk scoring - and a synthesized fix plan. At peak, the diagnosis workflow ran 79 agents, one per page signature, each with its own 1M-token context.
5. Surgical fixes. 24 approved fixes: 15 root-cause and 9 page-specific, applied sequentially without file collisions. The leverage of root-cause thinking: correcting a single global body text color (#060112 vs Bootstrap’s reboot #212529) fixed 231 pages at once; a collapsed Bootstrap grid fix repaired 120 pages; one hero font-size fix covered 92 technology pages.
6. Before/after measurement. A full re-render of all 236 pages and a deterministic compare: 156 pages improved, 79 unchanged, exactly 1 regression - which triggered a bounded “repair until dry” loop.
7. A separate track for interactivity. Tabs, steppers, sliders, accordions, filters and forms were ported from the WordPress theme’s JavaScript to vanilla JS modules - one agent per component in parallel, verified by driving actual clicks against a dev server with the requirement that the initial state matches production.

The evidence directory ended up holding 7,968 screenshots - 1.5 GB of proof that the new site looks like the old one.

SEO continuity, engineered

In parallel to the visual track ran a simpler, script-driven content track:

• A source inventory built from the WordPress database: 225 pages and posts, 220 sitemap URLs, 55 team records - reconciled against the sitemap with zero discrepancies in either direction.
• A content parity report comparing text page-by-page between the Astro build and the production HTML.
• 64 generated 301 redirects covering legacy slug variants and retired pages.
• Validation scripts that diff the build output against the production inventory (required result: zero expected URLs missing) and check every internal link (required result: zero dead links).

One honest caveat: “zero SEO loss” here means technical continuity - identical URLs, hreflang, meta and redirects. Search rankings are decided by search engines over time; we engineered the conditions, not the outcome.

What the polish phase looked like in numbers

The later refinement workflows ran with full telemetry, which gives a rare concrete picture of what multi-agent work actually costs. One run - restoring lost inline CSS blocks and auditing the whole site for similar issues - used 12 agents over 19.3 minutes of wall-clock time (peak 5 in parallel), mixing models by task: fast models for execution, stronger models for vision QA and the hardest JavaScript port. Another - implementing PageSpeed recommendations - used 6 agents over 27.9 minutes: five working on disjoint files (fonts, images, CSS splitting, LCP, cache headers) plus a verifier running local Lighthouse audits.

The result of that second run: PageSpeed mobile Performance 99, Accessibility 91, Best Practices 81, SEO 92.

Across the polish phase, agents processed 29.2 million tokens and made 591 tool calls, alongside 268 in the main sessions - 859 tool invocations in total, in roughly 104 agent-minutes of parallel work.

The new editing model: a prompt instead of a CMS

The migration changed more than the stack - it changed who can edit the website and how:

1. Prompt in Claude Code Web (it works from a phone): “add a blog post about…”.
2. Branch and PR - Claude creates a branch and writes markdown that conforms to the content schema; a packaged skill knows the frontmatter contract.
3. Preview URL - Cloudflare Workers Builds compiles the branch and posts a link to the rendered page in the PR.
4. Review - a human clicks through the preview, requests changes by prompt or approves.
5. Merge -> live - green CI plus an approval; the main branch is protected.

Today, every pull request - AI-authored or not - passes the same CI gates: type checking, a CSS check, a full static build, URL validation against the production inventory, an internal link check, and FAQ sync validation. And the cloud session sees only the GitHub repository: no secrets, no production access. You cannot break the site with a prompt.

The only “backend” that remains is a single Cloudflare Worker endpoint handling the four contact forms, forwarding submissions to Slack and email with Turnstile antispam.

What we actually learned

• Constraints made it work. “Identical pixels, identical URLs” is a verifiable target. Verifiable targets are what agents are good at closing in on.
• Verification loops beat trust. Every claim in this article traces back to an artifact in the repository: diff reports, screenshots, inventories, CI logs. The agents were never asked to be right - they were asked to prove it.
• Root causes have leverage. One CSS fix repairing 231 pages is the difference between an agent swarm that converges and one that thrashes.
• The human role shifts, it does not disappear. Ninety-odd prompts over the project were decisions: what to build, what counts as done, what to ship. Everything between those decisions was execution, verification and reporting.

And one last proof point: this very article was written by a prompt in Claude Code Web, went through a branch, a PR, a preview URL and a human review - exactly the workflow it describes.