The replatform from WordPress to Astro was supposed to be the project. It turned out to be the prologue. Exporting the content, rebuilding the templates, getting a static site to compile and deploy to Cloudflare Pages took weeks. Then the actual year began: redirects, hreflang, six-locale parity, and a build that outgrew the platform it was deployed to. This is a report on where the time went, because the time did not go where the planning said it would.
The polemic, if there is one, is with the framing of replatforming as a port. “Move off WordPress to a static site” sounds like a one-time migration. For a multilingual content site it is closer to taking ownership of three systems WordPress used to hide: the routing layer, the build, and the cross-locale structure. None of them are hard. All of them are continuous.
WordPress to Astro migration, the real cost: TL;DR in 4 points
- The port is the cheap part. Templates and content export took weeks; the migration took about twelve months to reach stable, regression-free search performance.
- The redirect layer is the first surprise. Thousands of previously indexed URLs each need a 301, and the volume collided with a Cloudflare Pages file-size cap that silently dropped rules.
- Six-locale parity is continuous work, not a task. Hreflang, canonical URLs, and section structure have to stay aligned across every language version, forever.
- The build outgrew Cloudflare’s own runner. An 8GB build ceiling is not enough for thousands of prerendered pages; the answer was to build locally with a 16GB heap and deploy the artifact.
Glossary: static build, prerender, hreflang, edge
The report rests on a few platform terms.
- Static build - the whole site is rendered to plain HTML files ahead of time, during a build step, rather than per request.
- Prerender - generating each page’s HTML at build time. A six-locale site multiplies page count by the number of locales, so the build scales with content times languages.
- Cloudflare Pages - the host. It serves the prebuilt files from the edge and can also run the build, within memory limits.
- Wrangler - Cloudflare’s command-line tool, used here to deploy a locally built artifact directly, bypassing the platform’s build step.
- Hreflang - the links that tell search engines which page is the German, Polish, or Spanish version of the same article.
- 301 redirect - a permanent redirect that carries a moved URL’s ranking signal to its new address.
Weeks: the port that everyone budgets for
The visible migration is the part that gets estimated, and the estimate is roughly right. Content comes out of WordPress, templates are rebuilt in Astro with Tailwind, a build compiles, a deploy lands on Cloudflare Pages. A content site of moderate size reaches a working static build in weeks. This is the phase that demos well and convinces everyone the project is nearly done.
It is not nearly done. It is past the part that was easy to predict and arriving at the part nobody scheduled. The working build proves the templates render; it proves nothing about whether the old URLs resolve, whether the locales agree with each other, or whether the build will still finish when the content triples.
Months: the redirect layer nobody scheduled
The first month of the long tail went to redirects. Every URL WordPress had ever exposed and Google had ever indexed needed a 301 to its new Astro address, or it became a 404 and the ranking signal evaporated. On a single-language blog that is a long list. On a six-locale site with descriptive slugs it runs into the thousands.
That volume hit a wall that is its own field report: Cloudflare Pages silently drops _redirects rules past a 100KB file-size cap, with no warning, so a chunk of the redirect map deployed green and never applied. The symptom showed up months later as 404s in Search Console and unavailable product pages in Merchant Center, long after the migration looked finished. The lesson generalizes past Cloudflare: in a replatform, the redirect map is not a checklist item you complete; it is a system you operate, with its own failure modes and its own monitoring.
Months: six locales that have to agree forever
WordPress, with the right plugins, hides multilingual structure behind an admin. A static build exposes it. Six language versions of every article have to stay structurally parallel: the same section headings in the same order, hreflang links that actually resolve to each sibling, canonical URLs that point where they should, and taxonomy URLs that match across locales. When one locale drifts, the cross-language link graph cracks at the indexing layer while every page still renders fine.
This connects directly to a separate failure mode in how AI translation breaks multilingual SEO: translation tooling that touches structural fields produces locale drift that is invisible on the page and expensive in the index. Post-migration, parity stopped being a milestone and became a standing check, run on every content change, because six locales do not stay aligned on their own.
The tooling you rebuild that WordPress gave you free
A quieter cost of leaving WordPress is that you inherit responsibility for checks the platform and its plugins used to perform invisibly. WordPress validated internal links through its editor, kept a sitemap current through a plugin, and warned about broken references in the admin. A static build does none of that on its own; you build it back, or you ship regressions.
Over the year that meant a small library of validators wired into the deploy: internal-link validation against the real route surface so a renamed slug cannot leave dangling links, structured-data checks so the schema in frontmatter stays well formed across locales, parity checks that compare language siblings for missing sections, and a build-time sitemap and hreflang generator. Each one replaces something WordPress did silently. The net is more control and more confidence (the checks are explicit, versioned, and run in CI) but it is real engineering that the word migration does not mention. Anyone scoping a replatform should add this line item: you are not only moving the content, you are re-implementing the guardrails the old platform applied for free.
Months: the build that outgrew its host
The last surprise was mechanical. Cloudflare Pages serves a large static site effortlessly, but building one is bounded by memory, and the platform’s own build runner tops out at 8GB. A multilingual Astro site with thousands of prerendered pages, each locale multiplying the count, needs more heap than that, and the platform build started failing with out-of-memory errors that took time to recognize for what they were.
The fix was to stop building on the platform. The site now builds locally with a 16GB heap and the finished output is pushed to Cloudflare Pages with Wrangler, which deploys an artifact without rebuilding it. A local M-series machine finishes the build reliably in minutes where the constrained runner could not finish at all. Images forced a related discipline: anything run through Astro’s asset pipeline is optimized at build time, which is excellent but memory-hungry, so pre-optimized backgrounds are served as-is from the public directory and only images that benefit from processing stay in the pipeline, kept reasonably sized to keep the build under its ceiling.
What the migration actually bought
Stated plainly so the year does not read as regret: the move was worth it. Pages render from the edge as static files, which is faster and steadier than rendering on request, the attack surface shrank to roughly nothing dynamic, and crawler access became predictable rather than dependent on plugin behavior. For a content site where speed, stability, and being reliably readable by search and AI crawlers are the point, that is the right trade.
The honest qualifier is the same one that should precede any replatform: it is the right trade for a content site, and the wrong one for a site that lives on dynamic, logged-in functionality, where WordPress’s request-time rendering and ecosystem are the feature, not the liability. The decision is not “static is better.” It is “static is better for this shape of site, and here is the year of tail work that the word migration hides.” More engineering write-ups from this rebuild are on the wppoland blog.
