# Moving a WordPress marketing site to Astro

> What happens to plugins, page builders, Yoast metadata and forms when a WordPress marketing site moves to Astro, and when staying on WordPress is better.

Published: 2026-10-20
Updated: 2026-10-20
Canonical: https://augustynglowacki.com/posts/moving-a-wordpress-marketing-site-to-astro

I would consider Astro when WordPress is serving marketing pages and the team wants a simpler frontend to maintain. I would first check what the plugins do. Replacing a theme is one job. Replacing a shop, booking system or membership service is a much larger one.

The move also needs an editing plan. I agree where the content will live and how the team will preview and publish it before rebuilding the pages.

## Keep the features the business uses

I start by listing active plugins and deciding which features the new site needs. Caching and image optimization can move into the static build and image pipeline. Forms need a destination for submissions. Analytics, chat and cookie banners usually remain the same vendor scripts in the Astro layout.

| What the plugin does                      | What it becomes on Astro                                                           |
| ----------------------------------------- | ---------------------------------------------------------------------------------- |
| Caching, minification, image optimization | A static build with an image pipeline                                              |
| Security, login protection, backups       | The static frontend has no WordPress login. A WordPress CMS still needs protection |
| SEO fields, sitemaps, redirects           | Content-model fields, a sitemap integration and host redirects                     |
| Forms                                     | A form service, CRM form or serverless function                                    |
| Analytics, chat, cookie banner            | The same vendor's script in the Astro layout                                       |
| Shop, memberships, courses, bookings      | A separate application that needs its own scope                                    |

I agree how each retained feature will work and who will maintain it.

## Move the content and rebuild the layouts

[WordPress's export tool](https://wordpress.org/documentation/article/tools-export-screen/) produces a WXR file containing posts, pages, custom post types, comments, fields, taxonomy and users. A script can convert that XML into the new CMS's import format. The REST API provides JSON and rendered post HTML, which I can map to the new fields.

Media files need a separate copy. The export lists attachment URLs, but the files stay on the old server. I copy the uploads folder or download the attachment URLs before the old host is switched off.

Page builder layouts take more work than posts. WordPress's block editor stores blocks as HTML comments and attributes around their HTML ([Block Editor Handbook](https://developer.wordpress.org/block-editor/explanations/architecture/key-concepts/)). Core paragraphs, headings, lists and images can convert to Markdown or Portable Text. Third-party builders have their own formats. On WordPress sites I have moved, those pages came out of the API as nested markup filled with builder classes.

I rebuild the repeated sections as Astro components with defined fields, then recreate the pages from them. The CMS exposes those sections to editors. Posts written in the block editor can usually move as content without rebuilding their layout.

## Give editors a setup they can use

Astro replaces WordPress's page rendering. It can fetch content at build time so visitors no longer depend on the WordPress theme, PHP or its frontend plugins. Where the content lives is a separate choice.

The [Astro migration guide](https://docs.astro.build/en/guides/migrate-to-astro/from-wordpress/) covers moving content into Astro or another CMS. Keeping WordPress as a headless CMS is also an option. Astro can read its existing REST API at `/wp-json/wp/v2/`, while editors keep the admin they know ([headless WordPress guide](https://docs.astro.build/en/guides/cms/wordpress/)).

I would keep WordPress when the team depends on its editor and that workflow still suits them. Moving to fixed page sections can initially slow down a marketing team that currently builds new layouts every week without a developer. I want that limitation discussed before the new site is built.

## Bring the search settings and forms with you

Yoast adds `yoast_head` and `yoast_head_json` to REST responses, and exposes an endpoint for reading a URL's SEO head at `/wp-json/yoast/v1/get_head?url=` ([Yoast REST API](https://developer.yoast.com/customization/apis/rest-api/)). I can import the custom titles, descriptions, canonical URLs, Open Graph images and robots settings into fields on the new site.

After importing, I check that custom titles and descriptions remain, `noindex` pages stay excluded, and redirects stored in WordPress have moved to the host. Those settings can disappear when the old database is retired.

Forms need the same attention. A WordPress plugin may store submissions in its database or send email from its server. On Astro, I agree whether submissions go to a form service, the CRM or a serverless function. I add spam protection that does not depend on WordPress and submit every form on the preview site before launch.

## I would not move every WordPress site

If WooCommerce, memberships, courses or bookings run the business, keeping WordPress for those parts may be the better decision. The same applies to a site that is fast enough, maintained and rarely changed.

For a marketing site that does need to move, I plan the frontend, existing content and plugin replacements together in an [Astro and headless CMS migration](/services/migrate-to-astro). An optional audit can check the current plugins, editing setup and upkeep before you commit. It may show that staying on WordPress makes more sense.

## Sources

- [WordPress documentation, Tools Export screen](https://wordpress.org/documentation/article/tools-export-screen/)
- [Yoast developer portal, REST API](https://developer.yoast.com/customization/apis/rest-api/)
- [WordPress Block Editor Handbook, key concepts](https://developer.wordpress.org/block-editor/explanations/architecture/key-concepts/)
- [Astro docs, migrating from WordPress](https://docs.astro.build/en/guides/migrate-to-astro/from-wordpress/)
- [Astro docs, headless WordPress and Astro](https://docs.astro.build/en/guides/cms/wordpress/)