WordPress to Astro rebuild: how we score the decision

It is 11pm and a Dutch agency owner forwards us an email from her biggest client. The client read a thread about Astro and now wants to know why their WordPress site, which still works, still ranks, still converts, has not been migrated yet. She needs an answer by Friday's strategy meeting. She has thirteen sites like this on retainer.

We get this email about four times a quarter. The honest answer is almost never "rebuild on Astro" and almost never "leave it alone". The honest answer is a scorecard with three axes, and once you score the site the decision tells itself.

The two real options, plus a middle path

Skip the marketing post that promises six options. In production there are two, with a third middle path that most agencies underrate.

Option A: a hardened WordPress 6.7 stack. Auto-updates on, plugin count under fifteen, the admin behind Cloudflare Zero Trust or a basic-auth gate, daily managed backups, and a staging clone that mirrors production weekly. The editorial team uses Gutenberg. Content goes live in minutes. WordPress 6.7 is a credible defensive position if you actually patch it.

Option B: a static rebuild on Astro with content in markdown or MDX, deployed on Vercel or Cloudflare Pages, with images going through a CDN. The site is fast, secure by default, and costs about ten euros a month to host. The editors now work in a git workflow or a headless CMS like Sanity, Storyblok, or Payload.

Option C, the middle path, is headless. WordPress stays as the editing surface and the database, but the front end is Astro pulling from the WP REST API or WPGraphQL, often with Advanced Custom Fields driving the schema. The editor keeps her Gutenberg muscle memory. The visitor gets a static page. The agency takes on the most operational complexity.

Axis 1: editor literacy

Score this from one to five.

A one is a fifty-something communications director who pastes from Word, uses the visual editor, and calls the agency when the image gallery breaks. A five is a content team that ships through pull requests, knows what a frontmatter block is, and would prefer markdown to TinyMCE.

The honest reality at Dutch SMEs in the 500k to 50M revenue range is that most editors score 2 or 3. They can copy a YouTube embed code. They cannot resolve a merge conflict. If your client scores below 3, an Astro rebuild with a pure git workflow will create a permanent dependency on you, the agency, for every typo fix. That is a fee opportunity and a relationship risk at the same time.

Score of 4 or higher and Astro plus markdown is genuinely faster for the editor than Gutenberg ever was. We have seen content teams ship three times their previous cadence because pull request review forces them to stop and think before they publish.

Axis 2: content velocity

How many content updates land per week, on average, over the last six months? Pull the WP audit log or look at wp_posts.post_modified and count.

• Under five updates a week: build time does not matter. Astro wins on every other axis.
• Five to twenty: still fine for Astro with incremental builds, but you need to actually wire those up.
• Twenty to a hundred: a full rebuild on every save becomes a UX problem. The editor saves, refreshes preview, sees nothing changed, saves again. Now you have ghost edits.
• Over a hundred: stay on WordPress unless you go fully headless with on-demand revalidation, and even then test for a month before committing.

A small SQL query you can run in phpMyAdmin or wp-cli:

SELECT
  DATE_FORMAT(post_modified, '%Y-%m') AS month,
  COUNT(*) AS edits
FROM wp_posts
WHERE post_status = 'publish'
  AND post_modified > DATE_SUB(NOW(), INTERVAL 6 MONTH)
GROUP BY month
ORDER BY month;

If the monthly average is under twenty, Astro is on the table. If it is over a hundred and the editors are non-technical, you are almost certainly looking at the middle path or a stay.

Axis 3: who picks up the phone at 11pm

This is the axis nobody scores honestly, which is why we put it last and weight it heaviest.

WordPress breaks in known ways. Plugin update breaks the cart. Theme conflict eats the menu. A managed host like Kinsta, WP Engine, or Savvii has on-call engineers who have seen the failure mode before. The agency owner can call her host's support line at 23:14 on a Sunday and get a rollback within twenty minutes.

Astro breaks in newer ways. A build fails because someone bumped a content collection schema. The CDN serves a stale page because revalidation was misconfigured. Sanity goes down and the build cannot fetch content. Vercel deprecates an edge runtime API on a Tuesday and your contact form stops working on Wednesday.

Score the agency, not the site:

• Does someone on the team know how to read a Vercel build log at 11pm?
• Is there a runbook for "the site builds locally but not on CI"?
• Does the agency have a contract that pays for after-hours response, or is the agency owner herself the on-call?

If the answer to all three is no, do not put the client on a stack the agency cannot operate. A neglected WordPress is still safer than an Astro site whose maintainer cannot debug a build error.

The scorecard

Take the three axes. Add them up. The total runs from 3 to 15.

• 3 to 7: hardened WordPress 6.7. Audit the plugins, lock the admin, set up daily off-site backups, and bill a quarterly maintenance retainer.
• 8 to 11: the middle path. Astro front end, WordPress as the headless source. The editor keeps Gutenberg. The visitor gets a fast static page. The agency takes on the build pipeline.
• 12 to 15: full Astro rebuild with markdown or a developer-friendly headless CMS. Editor team works in a git or PR flow. The agency commits to monitoring builds.

That is the entire method. You do not need a Notion doc with twenty criteria. Three numbers, an honest conversation, a decision.

The middle path is underrated

Most of the sites that come across our desk score between 8 and 11. Headless WordPress with Astro on the front is genuinely the right answer for them, and most agencies talk themselves out of it because the build pipeline feels heavy.

It is not light. You will set up ACF with WPGraphQL, write Astro content loaders, handle preview tokens, and figure out webhooks for on-demand revalidation. But the editor still opens wp-admin, still uses Gutenberg blocks she trained on, and the public site is no longer one zero-day vulnerability away from a defacement.

When we built the middle-path rebuild for a Dutch publishing client last year, the thing we ran into was that ACF flexible content blocks did not map cleanly to Astro components. We ended up solving it with codegen: an Astro build step reads the ACF JSON export and generates a typed component map, so the editor adds a new block in WP and the developer gets a typed prop in the next deploy. That is the kind of plumbing we set up for agencies under our legacy migration work.

A five-minute audit before Friday

Open one client's site tonight. Score it on the three axes. If the total is under 8 and you have been thinking about an Astro rebuild, stop thinking about it. If the total is over 11 and the client is still on a stack with seventeen plugins and no patch policy, you have your answer for Friday's meeting.