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.
The problem
WordPress works. Until your website becomes a project of its own.
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.
Key promise
Migration, not another rebuild from scratch.
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.
What a visitor reads stays the same. What the browser downloads, and what you maintain, does not.
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
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
Scope
What gets migrated?
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.
SEO
What about 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.
Custom CMS
Your CMS should fit your business. Not the other way around.
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.
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
Which one fits depends on how much of the current site you want to keep. Every path is quoted after the assessment.
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
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
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
Process
How a migration runs
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.
Start here
Not sure whether you should migrate?
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
The website address is the only thing I really need — everything else I can read from the site itself.
Case study
A WordPress that stayed the CMS
polo.blue is a VW Polo DIY workshop: a few hundred long, photo-heavy articles. WordPress has been its CMS from the beginning and still is. What changed is the front end, twice — first a Vue 2 application, then, in March 2023, the Astro site running today.
Both rebuilds left the content alone, and that is the point: the articles, the media library and the addresses were never in a theme, so replacing what renders them was a front-end job rather than a move of the site's substance. The author's panel did not change either time.
The audience roughly doubled over the last two years — 58,027 active users in the first full year on Astro against 118,324 in the most recent twelve months, two thirds of them arriving from search. Three years also added a great many articles, so read that as what the site did, not as what the stack did to it: there is no before-and-after here, because the old front end was never measured.
The part a static site is supposed to fail at is comments. They are not pre-rendered here — the page reads them from the WordPress REST API in the browser and posts new ones through an endpoint of its own, so a comment appears without the site being rebuilt. Static where that pays, dynamic where it has to be.
Three and a half years in production
Live since March 2023 — not a pilot, and not a rebuild that needed doing again.
Astro 2 → 7, no rewrite
Five major versions of the framework, taken as ordinary upgrades rather than another rebuild.
The panel never changed
WordPress is still the CMS, and the person writing the articles works exactly as before.
Content outlived two front ends
Vue 2, then Astro. The articles stayed where they were, because they live in the CMS and not in a template.
Comments without a rebuild
Read from the WordPress REST API in the browser, posted through the site's own endpoint.
57 KB of HTML per article
Measured on the live site: 57 KB compressed, plus ~53 KB of JavaScript shared across the whole site.
Performance
Less code in the browser. More room for the things that matter.
The difference is architectural rather than a matter of tuning.
WordPress rendering the page assembles it on every request: PHP runs, the database is queried, the theme builds the HTML. Caching plugins exist to avoid doing that, which tells you what it costs. A single-page application — the Vue 2 front end polo.blue used to run — moves the cost into the browser instead: the visitor downloads the app, the app asks an API for the article, and only then is there something to read. A static site does neither. The HTML is built when the site is published and the server hands over a finished file, so the text is in the first response.
What that looks like on polo.blue today, from real Chrome users rather than a lab: on desktop it passes Core Web Vitals — LCP 1.2 s, INP 94 ms, CLS 0.03. On mobile it does not, and on one metric only: layout shift at 0.17 against a 0.1 threshold, while LCP (1.6 s) and INP (169 ms) are inside theirs.
Worth saying where that shift comes from, because it is the useful part: not from the page's own markup. Every one of the 165 images on that article carries its width and height, and a lab run of the same page measures no shift at all. It appears for real users when the ad slots and the tag manager load and push the layout. That is the honest division of labour — static rendering removes the waiting it controls, and what is left is what you choose to load on top.
Which is also the outstanding work on that site: the ad and tag scripts on mobile, and a media library where 144 of the 165 images on its longest article are still JPEG rather than AVIF or WebP — the "Media" line in the scope above.
FAQ
Questions people ask before moving
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?
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?
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?
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?
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?
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?
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?
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?
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.
Send me the address of the site you have. I will tell you what moving it would involve.