Table of contents
I have run this blog on Hugo for a long time, and it has been stable and comfortable. This time I wanted to see whether GPT-6 Astra could rewrite the site in Astro, from the code changes to the Cloudflare Pages settings to the production deploy, with the agent doing all of it. I only made the requests, skimmed the changes, and opened the preview to see how the site felt.
It went smoothly. The home page, category lists, article pages, and pagination all behave the same as the Hugo version. The framework changed, and visitors can’t tell the difference. That was exactly what I wanted.
The site was already hosted on Cloudflare Pages. In January 2026, Cloudflare announced that the Astro company and team were joining Cloudflare, which made me pay attention to the framework. I had also been happy with GPT-6 Astra lately, so I wanted to see if it could swap out the existing site without a visible seam.
Rewriting from Hugo to Astro
My requirement was that, from a visitor’s point of view, the look, the SEO URLs, and the features must match the original. For everything else I asked for the official recommendations and best practices. How to split components and how to read articles were left to the agent, which read the official docs and analyzed the existing code before deciding.
Before any implementation, I had the agent inventory the project and write down the rules, the release flow, and an acceptance baseline taken from the original site. Only after that did I have it open an experimental branch for the rewrite. The baseline was also used later to compare the old and new sites.
The agent kept the Markdown articles and images and mainly rewrote the code that generates the site:
| Part | What was done |
|---|---|
| Page layouts | Converted the Hugo templates to Astro components and rebuilt the home page, list pages, and article pages |
| Article data | Made Astro read the existing articles, dates, categories, tags, and fixed URLs |
| Look and behavior | Reused the CSS and interactive JavaScript, keeping the menu, table of contents, search, and lightbox |
| Article rendering | Matched image sizes, tables, code line numbers, and paragraph links |
| SEO and feeds | Kept canonical URLs, the sitemap, RSS, and redirects from old URLs |
After the Astro build succeeded, the agent kept comparing its output with the original site and fixed the differences one by one: heading sizes, navigation text, images, and pagination aliases.
For example, the C# and CI/CD tags already had public URLs, so the new framework’s default slug conversion could not be used as is. Some older articles also used shorter table headers in Markdown, and after switching parsers the table width on phones needed adjusting. The agent handled all of these differences in code and left the article files untouched.
Cloudflare Pages build settings
The site keeps using the same Pages project and production domain to deploy static pages, so only the build environment and output location had to change. Cloudflare now recommends Workers for new projects. These are the Pages settings I used at the time:
| Setting | Hugo version | Astro version |
|---|---|---|
| Build command | hugo --minify |
npm run build |
| Build output directory | public |
dist |
| Version management | HUGO_VERSION |
Removed the Hugo setting, pinned the Node.js version with .node-version, and locked packages with the lockfile |
npm run build and dist are also the settings listed in the Cloudflare Pages guide for deploying an Astro site.
At that point the experimental branch was already on Astro while the production branch still used Hugo. The agent first made the build command detect which framework the branch uses, so both branches could build. The command was changed to npm run build only after the production switch was done.
The agent also made these settings changes. At most, I took a quick look at the build command on Pages and at the pull request diff to see if anything looked off.
Preview checks and release
I opened the Cloudflare Pages preview and clicked through the home page, category lists, article pages, and pagination. Everything felt the same as the original site.
The agent ran the detailed checks automatically. These were the preview results at the time:
| Check | Result |
|---|---|
| Nine page types, each compared at desktop and mobile sizes | Position and size of the key elements in all 18 combinations differ by no more than 1 px |
| Menu, search, table of contents, RSS copy, and lightbox | The tested interactions match the original site |
| Redirects from old URLs | All 911 checked |
| Pages and assets | 36 pages and endpoints and 310 assets passed |
After the preview worked and the checks came back clean, I told the agent to release. The deploy went through without trouble.
Local development on a new computer
The change I noticed most after moving to Astro is that setting up a new computer no longer means installing Hugo and dealing with Hugo version differences. The project pins the Node.js version in .node-version. After you install that version, run npm ci, and npm installs exactly the package versions recorded in package-lock.json. Then npm run dev runs Astro’s astro dev to start a local development server, and the browser refreshes automatically when you edit an article. The Cloudflare Pages build environment also reads .node-version, so your computer and the production site use the same Node.js version.
Summary
On this blog, GPT-6 Astra completed the switch from Hugo to Astro, and visitors see the same site as before. On a new computer, install the pinned Node.js version and run npm ci to keep writing.
