WordPress is not always the right solution for a website.

That is a strange sentence for me to write. I have spent 20 years building with WordPress, and I still think it is the right tool for a lot of publishers, like my clients at https://cultivatewp.com.

In the past I used WordPress for everything: blogs, business sites, internal CRMs, and I even rebuilt my favorite bookmarking site using WordPress.

But nowadays, Astro is my tool of choice for many projects. A site that once needed a CMS, custom fields, plugins, and an admin workflow can now be replaced with a simple static site and developer-assisted (or AI assisted) content updates.

I recently rebuilt the Sundheim Group site by rebuilding the 9yr old WordPress site as a static Astro build hosted on Cloudflare (see the case study here).

My Hermes agent did the initial work of mapping out all the existing site content, creating an Astro design based on the existing WordPress site, and rebuilding the site’s content using Astro components. Then came the manual work of reviewing content, redesigning and rebuilding what didn’t transfer over well, and rebuilding functionality previously handled by WordPress plugins (SEO, forms, etc).

When Astro is a good fit

Astro is a good fit when the public site is mostly static and the editing workflow can be handled in code (Markdown) or by chatting directly with your AI tool of choice (Codex, Claude).

That describes a lot of brochure sites and small business sites where WordPress is mostly being used as a database of simple content.

The Sundheim Group site is a good example. We built the original site in 2017 and only minimal content changes had been made since then. Doug’s active writing and podcast work had moved to Substack. The WordPress site had become the front door: services, case studies, credibility, and contact.

Keeping a full WordPress stack online for that job meant expensive WordPress managed hosting, core and plugin updates, backups, and an admin backend that was rarely used.

Astro let us keep the public website and remove the ongoing CMS burden.

Start with an inventory and design brief

The first step is creating an inventory of all content. The XML sitemaps generated by WordPress SEO plugins are great for this - they list all the posts in all the content types, as well as the taxonomies. I created a Migration Inventory.md file listing all the content types, URLs, and the content architecture.

Next was to define the visual design direction. The goal was not to redesign Sundheim Group’s site from scratch. They already had an established, professional visual identity. The rebuild preserved that look and converted the implementation into cleaner, reusable pieces. I created a DESIGN.md file based on the existing website design, and used this as a starting point for the Astro site design brief.

Once those were in place, my agent used the design brief and the content migration inventory to build the initial Astro site.

Manual review of content

You can copy the obvious pages and still miss the behavior hiding in the content: old forms, newsletter embeds, survey scripts, YouTube iframes, tracking snippets, shortcode output, image paths, redirects, and one-off page templates.

On Sundheim Group, the first Astro pass moved the visible content over, but the cleanup work afterward found important details embedded in the old WordPress content:

  • The contact page needed a real replacement form.
  • The newsletter page needed a working Substack signup form instead of stale Gravity Forms form markup.
  • Assessment and speaking pages contained third-party form and survey embeds that had to be preserved deliberately.
  • A video page contained an old YouTube video shortcode that needed to become a responsive HTTPS iframe.

I extracted the contact form into a reusable Astro component, routed submissions through a Cloudflare Worker, added Turnstile verification, and used safe redirect fields so the same form could appear on multiple pages.

For the newsletter page, I inspected the live Substack form and rebuilt a simple static form that posts to Substack’s real endpoint.

For the assessment page, I kept the SurveyGizmo script because that page’s purpose was the external assessment itself. The difference is that it is now isolated in a route-specific component instead of buried inside a large escaped content blob.

SEO is easier when it is centralized

Astro gives you a clean slate, which is both helpful and dangerous. A static site can be very SEO-friendly, but not if every page hand-rolls its own title tag, canonical URL, Open Graph data, and schema.

Joost de Valk’s Astro SEO: the definitive guide is the resource I keep coming back to. The practical takeaway is to centralize SEO instead of sprinkling tags everywhere.

On these Astro builds, that means:

  • A shared layout-level SEO layer.
  • Canonical URLs derived from the configured production site URL.
  • Robots handling that can noindex staging while allowing production indexing.
  • @astrojs/sitemap for sitemap output.
  • RSS feeds for blog or article content.
  • JSON-LD structured data for the site, person or organization, pages, breadcrumbs, and blog surfaces.
  • Build-time checks for metadata length, H1s, image alt text, and internal links where possible.

The important part is not the exact package choice. The important part is making SEO part of the site architecture, not something you remember to paste into each page.

PageSpeed usually improves, but not automatically

Astro starts with a big advantage: static HTML, minimal JavaScript, and assets that can be served from a CDN. But the first build is not always the final performance pass.

On Sundheim Group, the old WordPress site scored 35 for mobile performance in PageSpeed Insights. After the initial build, the Astro version was around 85 Performance score, and I eventually reached 100 across Performance, Accessibility, Best Practices, and SEO by:

  • Optimizing images and generating lighter WebP versions.
  • Adding responsive image variants for large hero images.
  • Avoiding unnecessary JavaScript on pages that did not need it.
  • Making embedded video responsive instead of layout-breaking.
  • Replacing custom fonts with a modern font stack

Astro makes a fast site easier to build, but PageSpeed still rewards the boring details: image sizes, font loading, layout stability, and removing scripts that no longer serve the page. AI agents are great at using Lighthouse to iteratively identify and fix pagespeed issues.

It’s much simpler to optimize an Astro site than a WordPress site. I can hyper-optimize my WordPress theme, but then the performance gets destroyed by a plugin or script added after launch.

The tradeoff

The tradeoff is editing convenience.

WordPress gives non-technical users an admin UI. Astro gives you a simpler, faster, safer public site, but content changes usually move into Git, Markdown, code review, and deployment.

For many of my business clients, emailing me directly to make minor content changes a few times a year is an improvement over their experience editing a WordPress site, and the the cost savings by not having to pay monthly for hosting & plugins is much higher than the cost of hiring me to make content changes.

But for my clients that are active publishers, the lack of a CMS is a complete non-starter. They’ve built their editorial workflow around WordPress and their preferred plugins, and an Astro-based CMS like EmDash will never meet their needs.