# WordPress to Astro migration

Move an existing WordPress site to Astro and a CMS built around your business — content, media and URLs carried over, redirects mapped, SEO risk kept low.

**Canonical:** https://spoko.space/wordpress-to-astro/  
**Language:** en  
**Updated:** 2026-09-21

---

## Your website doesn't have to run on WordPress.

*WordPress → Astro*

Move the website you already have to Astro and a CMS built around your business. Your content, your URLs and years of SEO work come with it.

SEO-conscious migration · Content preserved · Custom CMS · Fast by default

[Check my website](#audit) · [See how it works](#how-it-works)

## WordPress works. Until your website becomes a project of its own. {#wordpress-works-until-your-website-becomes-a-project-of-its-own}

*The problem*

None of this is an argument against WordPress. It is what one particular installation turns into after a few years of adding to it.

- **A plugin for every decision** — Each one solved something real on the day it was installed. Together they are what you now update, test and hope nothing breaks.
- **A frontend that ships everything** — The theme, the page builder and their libraries load on every page, whether that page uses them or not.
- **Maintenance on someone else’s schedule** — Core, theme and plugin updates arrive when they arrive, and each one is a small risk somebody has to carry.
- **An editor built for every site at once** — The admin covers everything the web can be, which is why it rarely fits the handful of things your team actually does.

## Migration, not another rebuild from scratch. {#migration-not-another-rebuild-from-scratch}

*Key promise*

The expensive version of leaving WordPress is the one where everything starts at a blank screen: the text is rewritten, the images are re-uploaded, the URLs change and the site spends six months earning back what it already had.

**Start with the website you already have.** Your pages, posts, images and addresses are the input, not a thing to be recreated later. What changes is what sits underneath them.

**Keep what matters. Replace what doesn't.** The content, the structure and the addresses stay. The plugin stack, the page builder and the theme are what get left behind — and I don't migrate complexity: anything rebuilt is rebuilt because it earns its place.

## Same website. Different foundation. {#same-website-different-foundation}

*Before / after*

What a visitor reads stays the same. What the browser downloads, and what you maintain, does not.

### Today, on WordPress {#today-on-wordpress}

A stack where each layer depends on the one under it.

- WordPress core, kept current or kept at risk
- Plugins for forms, SEO, caching, galleries, consent
- A page builder that owns how content is stored
- A theme the layout cannot outlive
- Maintenance as a standing monthly task

### After the migration {#after-the-migration}

A static front end and a content model that belongs to you.

- Astro, rendering pages ahead of time
- Content stored as structured data, not as markup
- Minimal client-side JavaScript — only where a page needs it
- A CMS built for the handful of things your team edits
- Deployment automated, so publishing is not a maintenance event

## What gets migrated? {#what-gets-migrated}

*Scope*

Content preserved. URLs mapped. Functionality rebuilt.

- **Content** — Pages, posts, categories and tags, with their structure — headings, lists, tables and embeds intact.
- **Media** — The image library, re-encoded to modern formats and sized for the layouts that use it.
- **SEO** — Titles, descriptions, canonical tags, structured data and the sitemap, plus a redirect for every address that changes.
- **Functionality** — Forms, search, filtering, galleries and member-only areas — rebuilt as part of the site rather than bolted on.
- **Analytics** — Analytics, tag manager and consent, reconnected and verified against the events you already report on.
- **Integrations** — Newsletter, CRM, booking, payments — whatever the site talks to keeps talking to it.

## What about Google? {#what-about-google}

*SEO*

Nobody can promise a migration with no movement in the rankings, and anyone who does is selling you something. What can be done is to remove the reasons a migration usually causes it — almost always the same handful, and all of them avoidable with a plan made before anything moves.

The mapping is written first, checked against the live site, and verified again after launch against Search Console and the server logs.

- **URL mapping** — Every address on the current site is listed and matched to its new one before the rebuild starts.
- **301 redirects** — Anything that does move is redirected permanently, so links and rankings follow it.
- **Metadata** — Titles and descriptions come across as they are, unless a page is being rewritten anyway.
- **Canonical tags** — One canonical address per page, so the two versions of a site never compete during the switch.
- **Sitemap & robots.txt** — Regenerated from the new site and submitted, rather than carried over by hand.
- **Structured data** — Article, breadcrumb, product and FAQ markup rebuilt from the content itself.
- **Internal links** — Rewritten to their new targets, so the migration does not leave the site linking to its own redirects.
- **Indexability** — Staging stays closed to crawlers, production opens on launch day — checked, not assumed.

## Your CMS should fit your business. Not the other way around. {#your-cms-should-fit-your-business-not-the-other-way-around}

*Custom CMS*

A general-purpose admin panel has to be ready for every website there has ever been. Yours has to be good at the five things your team does every week — publishing a post, swapping a photo, changing a price, adding a case study, updating a page in two languages.

This is not a product mock-up: the screenshots are a CMS I built and run for client sites, with a block-based page builder, translations, media and deployments in one place. [See how it is put together](https://spoko.space/custom-cms-with-ai/).

- **Only what you need** — The fields your content actually has, and no settings page anyone has to be told to ignore.
- **Structured content** — Content stored as data rather than as markup, so it can be reused, translated and rendered anywhere.
- **Built for your workflow** — Roles, review and publishing that match how your team already works, not the other way round.
- **AI-ready, if you want it** — The same content, reachable by AI tooling over MCP under the same permissions as the panel itself.

## Three ways to make the move {#three-ways-to-make-the-move}

*Migration paths*

Which one fits depends on how much of the current site you want to keep. Every path is quoted after the assessment.

### Faithful migration — Path 1 {#faithful-migration}

The site you have, on a new foundation. The visual design stays; everything under it changes.

- Existing design rebuilt as it is
- Content, media and URLs carried over
- Redirects mapped where addresses change
- A CMS for the parts your team edits
- The fastest way off the current stack

### Migration with a redesign — Path 2 {#migration-with-a-redesign}

The move and the redesign you have been postponing, done in one pass instead of two projects.

- New design, built on the existing content
- Information architecture revisited
- Content edited where it needs it
- The same SEO mapping discipline
- One rebuild, one launch, one disruption

### Custom migration — Path 3 {#custom-migration}

For sites that are doing real work: shops, member areas, multilingual content, integrations.

- Functionality rebuilt rather than ported plugin for plugin
- Multilingual content and its URL structure
- Integrations with the systems you already run
- A content model designed for the domain
- Scoped in detail before anything is quoted

## How a migration runs {#how-a-migration-runs}

*Process*

Nothing moves until the map exists, and nothing launches until the new site has been checked against the old one.

- **Audit** — What the site is made of: pages and their addresses, plugins and what each one is load-bearing for, content structure, integrations, traffic.
- **Plan** — The URL map, the content model, what gets rebuilt and what gets dropped — written down and agreed before any code is written.
- **Rebuild** — The new front end in Astro and the CMS around your content model, on a staging domain closed to crawlers.
- **Migrate & verify** — Content and media moved, redirects in place, then the new site checked page by page against the old one.
- **Launch** — DNS switched, sitemap submitted, redirects and indexing watched in Search Console for the weeks that follow.

## Not sure whether you should migrate? {#not-sure-whether-you-should-migrate}

*Start here*

Send me your website. I'll look at the current WordPress setup and tell you what moving to Astro would actually involve — including the case where the honest answer is that it isn't worth it yet.

*No sales deck. No generic audit. Just a practical look at your website.*

- **Performance** — What the site loads today, and how much of it is the stack rather than the content.
- **Plugins & dependencies** — What is installed, what is load-bearing, and what would need rebuilding.
- **Content structure** — How the content is stored now, and what it would look like as structured data.
- **SEO** — Addresses, metadata and structured data — what has to be mapped before anything moves.
- **Functionality** — Forms, search, shop, logins, integrations: what the site does beyond publishing pages.
- **Migration scope** — Which of the three paths fits, roughly how long it takes, and what it would cost.

## Get a migration assessment {#get-a-migration-assessment}

The website address is the only thing I really need — everything else I can read from the site itself.

I reply within 1–2 hours on business days, with what I found rather than a calendar link.

## Questions people ask before moving {#questions-people-ask-before-moving}

### Do I have to redesign the site to migrate it? {#faq-do-i-have-to-redesign-the-site-to-migrate-it}

No. The faithful migration path rebuilds the design you have, so the change is invisible to visitors and the site simply stops running on WordPress. A redesign is worth folding in when you were going to do one anyway — doing both at once costs less than doing them a year apart.

### What happens to my existing content? {#faq-what-happens-to-my-existing-content}

It moves. Pages, posts, categories, tags and the media library are exported from WordPress and imported into the new content model, with their structure intact. Nothing is retyped, and nothing depends on you copying and pasting it.

### What about my plugins? {#faq-what-about-my-plugins}

Each one gets looked at during the audit and lands in one of three buckets: rebuilt as part of the site (forms, search, galleries), replaced by something the platform does natively (caching, image optimisation, sitemaps), or dropped because nothing on the site still uses it. I don't migrate complexity.

### Will I still be able to edit the site myself? {#faq-will-i-still-be-able-to-edit-the-site-myself}

Yes — that is what the CMS is for. The difference is that it holds the things your site actually has, so editing a page means filling in fields rather than fighting a page builder. If your team is comfortable in the WordPress admin, keeping WordPress as a headless CMS is also an option.

### Will the migration hurt my SEO? {#faq-will-the-migration-hurt-my-seo}

Any migration carries risk, and nobody can honestly promise rankings hold. What I can do is remove the usual causes: every address mapped before the rebuild, 301 redirects for anything that moves, metadata and structured data carried over, sitemap resubmitted, and Search Console watched after launch so anything that does slip is caught in days rather than months.

### Does this work for a multilingual site? {#faq-does-this-work-for-a-multilingual-site}

Yes. Languages are part of the content model rather than a plugin, so each language has its own addresses, its own sitemap entries and hreflang tags linking the versions. This site runs the same way, in English and Polish.

### Can I keep WordPress as the CMS? {#faq-can-i-keep-wordpress-as-the-cms}

You can. In a headless setup your team keeps the WordPress admin it knows and the front end is rebuilt in Astro, reading content over the REST API. It is a smaller change and a good fit when the admin is not the problem — the frontend is. That path is covered on the WordPress Rescue page.

### How long does a migration take? {#faq-how-long-does-a-migration-take}

It depends on how much the site does, which is exactly what the assessment establishes. A brochure site with a few dozen pages is a different project from a shop with member accounts, and I would rather tell you which one you have before either of us commits to a date.

### What happens on launch day? {#faq-what-happens-on-launch-day}

The new site has been running on a staging domain and checked page by page before that day arrives. Launch is a DNS switch, the sitemap submitted, and the redirects verified against the live site. If something is wrong, the old site is still there to switch back to.

## Your next website doesn't have to start with a blank screen. {#your-next-website-doesnt-have-to-start-with-a-blank-screen}

Send me the address of the site you have. I will tell you what moving it would involve.

[Check my website](#audit)