Rebuild a blog site on Next.js and rewrite 228 posts against keyword data

Alex Cloudstar used Claude Code to move a personal site from Astro to Next.js 16 and retune 228 posts in two days: about 100 commits, 543 passing tests and no broken URLs.

Done withClaude Code· Oct 23, 2026

What they did

Alex Cloudstar, a developer with eight years of experience, had Claude Code rebuild his portfolio and blog, which had run on Astro since December 2025, on Next.js 16 with Cache Components, a light redesign and rewritten main pages. Every URL the live site served had to keep returning real content. In the same push the agent reworked titles, meta descriptions, headings and intros on 228 posts using keyword research pulled from DataForSEO. He kept his hard rules in the notes the agent reads at the start of each session, ran audit passes against checklists and picked which findings to fix, split separable work across parallel sessions, and merged in small slices. Each time he caught the agent breaking something he added a test for it.

How it went

The work ran from late on October 21 to the morning of October 23: roughly 100 commits, 11 merged pull requests, 32,784 changed lines and 543 passing tests, with no broken URLs at the end. The keyword research took 313 API calls and cost $4.37. Early on the agent redirected paginated blog pages and turned hidden project pages into 404s because the new design did not need them, though both were indexed; he restored them and made it a standing rule. It also built a versioned public JSON API with deprecation headers that he then deleted, which cut the static page count from 1,093 to 596.

Worth knowing

He calls the line count a weak measure: much of it is reformatted post content, tests and code deleted a day later. The agent optimised for the cleanest structure, not for keeping what already ranked, until that goal was written down. A green build did not tell him a page said the right thing, so he still read pages himself.

Try it

With Claude Code· 3 parts to fill in

Rebuild [my site] on [new framework] while keeping every URL the current site serves returning a 200 with real content. Before changing routes, export the live sitemap and write a test that fails if any of those URLs disappears or redirects. Keep these rules in your session notes and treat them as hard limits: [rules, e.g. phrases never to use in titles, metadata limits]. Work in small slices, one pull request per slice (layout, routes, metadata, content), and run the tests before each. When I point out a mistake, add a test that would have caught it. Stop after each slice and wait for my review before starting the next.

Square brackets are the parts to fill in. The prompt is ours; the story is theirs.

Where they said it

Related