+ WEB · ASTRO · MIGRATION

How The Recovery Project moved off WordPress onto Astro without losing a URL & SEO

The Recovery Project sells neurological rehabilitation equipment to NHS trusts and private clinics across the UK, on a WordPress site weighed down by an online shop it had never taken an order through. Flex Solutions rebuilt it on Astro as a fast, pre-built site — moving 73 products, 10 articles and their category and brand pages across, around 200 pages in all, and keeping every existing web address intact.

PLATFORM

Astro

MIGRATED FROM

WordPress

WEBSITEtherecoveryproject.co.uk
CATALOGUE

73 products

Ruta SavaniSr. Fullstack Engineer, Flex SolutionsPublished 1 September 20269 min read
The Recovery Project product catalogue rebuilt on Astro, shown on desktop and mobile
Above — the rebuilt Recovery Project catalogue on desktop and mobile, pre-built on Astro and served from Cloudflare. Web · The Recovery Project

+ IN SHORT

Flex Solutions migrated The Recovery Project, a UK supplier of neurological rehabilitation equipment, from WordPress to Astro in six working days — moving around 200 pages including 73 products and 10 articles, preserving every existing web address, and lifting the Lighthouse performance score from 68 to 92.

+ BRIEF

The Recovery Project supplies neurological rehabilitation equipment to NHS trusts, private clinics, and families across the UK. Customers research equipment in detail, then book an in-person demonstration or request a bespoke quote. The site needed to work as a serious product catalogue — not as an online shop it had never used.

+ OUTCOMES

  • Migrated 73 products and 10 articles from WordPress into a pre-built Astro site.

  • Preserved every live web address, backed by 91 legacy redirects and the original sitemap filenames.

  • Removed the unused WooCommerce shop, the plugin stack, and the database from the live site.

  • Cut a 1.6 GB media library of 2,582 uploads down to the 191 images the site actually uses.

Results at a glance

6
Working days to live
200
Pages pre-built
0
URLs lost
68→92
Lighthouse performance

Why WordPress stopped working for a 200-page catalogue.

The Recovery Project sells bespoke-configured medical equipment through demonstrations and quotes. Its website, however, ran on WordPress with WooCommerce — carrying cart, checkout, and customer account systems the business had never taken a single order through.

Every page view meant running code and querying a database before anything reached the visitor.

The hard constraint was search. The site ranked for equipment buyers researching specific products, so the migration had to happen without losing a single web address or ranking along the way.

What the audit found before we moved anything.

Before a single product moved, Flex Solutions inventoried what the site was actually running — the builder, the commerce layer that had never taken an order, and every endpoint exposed to the public internet.

BUILDER

Bricks page builder with a child theme

COMMERCE

WooCommerce and WooCommerce Payments — never used

PERFORMANCE

A paid optimisation plugin, working against the stack

OPEN ENDPOINTS

wp-admin, wp-login, wp-json, xmlrpc

MEDIA LIBRARY

2,582 uploads · 1.6 GB

Why Astro, and not another CMS.

The catalogue changes slowly and is read constantly — the opposite of the workload WordPress was doing on every request. Astro builds each page once at deploy, so a product page is a file on a global network rather than a database query waiting to happen.

It also meant the security surface could shrink to almost nothing. No database, no plugin layer, no admin panel facing the internet — the three things the client was most anxious about maintaining.

How we preserved search rankings through the switch.

URL preservation shaped the build rather than being bolted on at the end. Where the new site would have used different page paths, we rebuilt the routing to serve the original WordPress addresses directly — so there was nothing to redirect away from.

91legacy addresses redirected
73
Product URLs
9
Product categories
6
Blog categories
3
Legacy top-level paths

What we wouldn’t compromise on.

Every existing web address had to keep working. Equipment buyers had already found these pages through search, so a new URL scheme was ruled out from the start.

No ranking loss during the switch. That ruled out a single big-bang launch: the build proved itself against sample data first, so the only thing changing on cutover day was the content behind already-correct templates.

NHS trusts and clinics research equipment carefully before a purchase. That ruled out any gap in search visibility during the move — search data and web addresses moved before a single product page went live.

+ HOW WE BUILT IT

Redesign to live in six working days.

A 200-page migration usually runs for weeks because the content move and the build fight each other. We planned them as two separate phases, scripted the content transfer instead of copying it by hand, and worked from a fixed set of AI coding skills committed to the repository — so every day started from a written plan rather than a blank editor.

  1. Mon 8 June

    Design system and static build

    The full site built from the approved design against sample data — layouts, templates, navigation.

  2. Tue 9 June

    Content migrated by script

    73 products and 10 articles pulled out of WordPress into version-controlled files — no hand-copying.

  3. Wed 10 June

    Legacy URL routing

    Every original WordPress address mapped, and schema rules set so a malformed product fails the build.

  4. Thu 11 June

    Search data carried across

    Sitemaps rebuilt under their original filenames, canonical addresses and metadata wired per template.

  5. Fri 12 June

    Deployment wired

    Product routing finalised and the site put onto Cloudflare’s global network as pre-built files.

  6. Sat 13 June

    Verified and cutover-ready

    Category, brand and address data checked page by page against the old site before the switch.

+ WHERE AI TOOK THE WEIGHT

Six days is not a shortcut. It is the same work, with the repetitive half automated and the judgement left to people.

  • Design

    The approved design translated into components and tokens rather than reinterpreted, so the build matched the artwork on the first pass.

  • Development

    A locked set of framework and platform skills committed alongside the code, so generated work followed current Astro and Cloudflare practice instead of guesswork.

  • Migration

    The content transfer written as a repeatable script and re-run until the output was clean — 73 products moved without a page being re-typed.

  • Verification

    Every address, category and sitemap entry cross-checked against the old site — the slow, exhaustive pass that usually gets sampled instead.

+ PAGE SPEED

Measured before and after.

68
BeforeWORDPRESS
92
AfterASTRO

Lighthouse performance score

Same page, same test conditions — the WordPress build before cutover, and the Astro build after.

Lighthouse scores and field metrics before and after the migration
MetricWORDPRESSASTRO
Performance6892
Accessibility8696
Best practices77100
First Contentful Paint2.3s1.1s
Largest Contentful Paint2.7s1.6s

Lighthouse, same page and same test conditions on both runs. SEO (92), Total Blocking Time (0ms) and Cumulative Layout Shift (0) were already at target before the migration and were held there after.

+ BEFORE / AFTER

Same site. None of the WordPress underneath.

WordPress + WooCommerce
The Recovery Project homepage on WordPress with WooCommerce, before the migration Before — full homepage.
Astro + Cloudflare
The Recovery Project homepage rebuilt on Astro and served from Cloudflare After — full homepage.

180 KB → 57 KB

Page HTML

17 → 0

JavaScript files

7 → 1

Stylesheets

51 → 0

WooCommerce references
+ HOW WE CHECKED IT

Verified, not assumed.

A migration is only as good as the check that follows it. The last working day was spent confirming the new site against the old one page by page, rather than sampling and hoping.

  • 01 — Addresses

    Every URL crawled, not sampled.

    The old site was crawled in full and each address checked against the new one. 91 legacy addresses resolve; none return a 404.

  • 02 — Catalogue data

    Category and brand checked page by page.

    All 73 products compared against the WordPress export rather than spot-checked — the slow pass that usually gets skipped.

  • 03 — Search data

    Sitemaps kept their original filenames.

    Search engines carried on reading the same files at the same paths, so nothing had to be re-discovered after cutover.

  • 04 — Ongoing

    The build itself refuses bad data.

    Each product is validated against a schema at build time, so a page missing a price or a category stops the deploy instead of shipping broken.

+ TECH STACK

The stack behind the migration.

FRAMEWORK

Astro, MDX

HOSTING

Cloudflare Workers

CONTENT

Astro Content Layer

ROUTING

Legacy URL-preserving

+ HOW IT SHIPS

Publishing, without a login screen.

Removing WordPress meant replacing the admin panel with something the team could still work in confidently. GitHub holds the content, Cloudflare builds it, and every change is previewed on a real page before it reaches the public site.

01 — Content

Every product is a file, not a database row.

Products, articles, categories and brands live as version-controlled files. Each one is checked against a schema, so a product missing a price or a category stops the build rather than reaching the site broken.

02 — Preview

The client sees a change before it is live.

A change is pushed to its own branch, and Cloudflare builds that branch to a private preview address. The team reviews the real page — not a description of it — and approves or asks for another pass.

03 — Deploy

Approving is the deploy.

Merging the branch triggers a build from GitHub and ships all 200 pages across Cloudflare’s global network. No server to patch, no cache to clear, and the previous version stays intact until the new one is live.

04 — Delivery

Images are converted at the edge, on request.

Cloudflare’s image pipeline resizes and re-encodes to modern formats as each request arrives, so editors upload one file and visitors receive a version sized for their device. Contact forms run through the same edge network, bot-screened before delivery.

+ WHAT IT COSTS THEM NOW

No database. No plugins. No update cycle.

Pages are pre-built and distributed globally, so traffic spikes are absorbed without hosting upgrades or caching configuration.

There is no plugin update cycle left to keep on top of — the maintenance work that prompted the migration in the first place.

+ WHAT THEY GAVE UP

The honest trade-offs.

Editors no longer log into a familiar WordPress admin. Content changes flow through version control instead, which is reviewable and reversible — but it is a different habit to learn.

Anything genuinely dynamic has to be designed rather than installed as a plugin. For a catalogue that changes slowly and sells through demonstrations, that was the right trade. It would not be for everyone.

+ FAQ

Questions we get about this migration

Still have questions? Email us.

RelatedHow the WordPress to Astro migration worksHire an Astro development agencyWordPress to Payload, for teams publishing daily

+ SERVICES USED

WordPress to Astro migrationAstro development agency
+ START A MIGRATION

Got a WordPress site you have outgrown?

Send the URL and a rough page count. Flex Solutions replies with a one-page audit and a fixed fee inside four working days.

Start a migration See how the migration service works
Average reply

4 hours, weekdays

First call

30 min, with a founder

Typical engagement

4–8 weeks

NDA

On request

+ NEXT CASE

From Generator to Game Platform: The Growth Journey of Bingo Card Creator

BINGO CARD CREATOR · SaaS · 2025