WordPress to Astro migration, without losing what works.

Move off a plugin-heavy WordPress install onto a fast, modern frontend with a visual CMS your marketing team can still run, with content, SEO equity, and integrations intact.

Why migrate

Why teams move from WordPress to Astro.

  • Performance you can't optimise into WordPress

    Astro ships almost no JavaScript by default. Pages that were fighting for a passing Core Web Vitals score tend to pass comfortably.

  • No plugin surface area

    No plugin updates, no plugin conflicts, no plugin-shaped security holes. The functionality you need is written once, deliberately.

  • Content as structured data

    Content lives in typed collections rather than a soup of post meta and shortcodes, so it can be reused across pages and channels.

  • Publishing stays visual

    A visual CMS layer means marketing keeps editing pages without touching code or waiting on a developer.

  • Genuinely cheap hosting

    Static output on a CDN removes PHP hosting, caching plugins, and the whole class of problems that come with them.

  • A frontend developers want to work in

    Components, TypeScript, and Git-based workflows instead of theme files and the WordPress loop.

Honest assessment

When Astro is, and isn't, the right answer.

Astro is the right call for most content-driven marketing sites. It is the wrong call often enough that it's worth saying so plainly.

Astro is a good fit when

  • Your site is primarily content and marketing pages
  • Performance and Core Web Vitals matter commercially
  • You want structured, reusable content
  • Your team wants a visual editor but not a monolith
  • You have integrations that need real control
  • You publish often and want fast builds

Astro is the wrong answer when

  • You need heavy authenticated application UI
  • The site is essentially a React app with a marketing skin
  • You depend on a WordPress plugin ecosystem you can't replace
  • Your team has no appetite for a Git-based workflow
  • You need WooCommerce-scale ecommerce as-is

What happens to your WordPress install?

It depends on what WordPress is actually doing for you. In most migrations it gets decommissioned entirely once content has moved and redirects are live.

Sometimes it's worth keeping as a headless content source, particularly where editorial teams are deeply invested in the admin interface.

  • Decommissioned entirely (the common case)
  • Kept temporarily during a phased migration
  • Retained headless as an editorial back end
  • Blog kept on a subdomain, marketing pages moved

Visual CMS

Marketing keeps a visual editor.

The objection to leaving WordPress is almost never technical. It's that someone in marketing will lose the ability to change a headline without filing a ticket. That doesn't have to happen.

  • Edit pages visually

    Content editors work in a visual interface with live preview, not a JSON blob or a YAML file in a repo.

  • Guardrails by design

    Editors compose pages from approved components, so the design system can't be broken by a well-meaning edit.

  • Structured underneath

    Everything the visual editor writes is typed, validated content that other pages and channels can reuse.

Architecture

How it fits together.

Integrations (CRM, analytics, forms, search) attach at the build or edge layer rather than as plugins inside the CMS.

Visual CMS

  • Editors work visually
  • Content stored as typed, structured data
  • No plugins, no theme files

Astro

  • Components and content collections
  • Static output, zero JS by default
  • Git-based, previewable, reviewable

CDN hosting

  • Served static from the edge
  • No PHP, no origin database
  • Instant global performance

Process

How the migration actually runs.

Discovery and audit

Every template, plugin, custom field, integration, and redirect on the current WordPress install gets catalogued before anything moves.

Content model

We design the Astro content collections and CMS schema around how your team publishes, not around how WordPress stored it.

Design

Migrate as-is, refresh selectively, or redesign, mapped to a component system built for the new stack.

Build and migrate

Astro build, component library, CMS wiring, and scripted content migration with a reconciliation pass.

Validate

Redirect testing, Core Web Vitals, accessibility audit, analytics parity, and a full content diff against the old site.

Launch and monitor

Staged DNS cutover, then Search Console, crawl errors, and vitals watched closely for the first weeks.

Content migration

Content moves by script, not by hand.

  • Export and map

    Posts, pages, custom post types, taxonomies, ACF fields, and media are exported and mapped field by field to the new content model.

  • Transform

    Shortcodes, page-builder markup, and inline styles are converted into clean structured content and real components.

  • Media

    The uploads directory is migrated, re-optimised, and re-referenced, including the variants nobody remembers generating.

  • Reconcile

    An automated diff compares every source URL against its destination so nothing is quietly lost in transit.

SEO & redirects

The part that decides whether this goes well.

Full URL inventory

Every indexed URL is pulled from Search Console, analytics, the sitemap, and a crawl, not just the ones in the CMS.

Redirect map

A one-to-one redirect map with 301s, built and tested against the live inventory before launch.

Metadata parity

Titles, descriptions, canonicals, Open Graph, and structured data carried across and diffed page by page.

Crawl and index

Sitemaps, robots, and internal linking rebuilt, then submitted and monitored through Search Console after cutover.

Post-launch watch

Rankings, crawl errors, redirect hits, and vitals monitored for the first weeks, with fixes shipped fast.

The details

Integrations, performance, accessibility.

Integrations

  • HubSpot, Salesforce, Marketo
  • Forms and lead routing
  • Site search (Pagefind)
  • Chat and support widgets
  • GA4, GTM, consent management
  • Webhooks and custom APIs

Performance

  • Zero JS by default
  • Image optimisation at build
  • Edge caching and CDN delivery
  • Core Web Vitals verified pre-launch
  • Real-user monitoring after launch

Accessibility

  • WCAG 2.2 AA as the build standard
  • Semantic markup and landmarks
  • Keyboard and focus states
  • Contrast checked against tokens
  • Screen reader passes on key flows

Relevant work

Migrations we've run.

See all work

FAQs

WordPress to Astro questions.

Will we lose search rankings?

Not if the redirect map, metadata, and internal linking are handled properly, which is most of what this project actually is. Expect short-term fluctuation and a return to baseline or better within weeks.

Can marketing still edit pages without a developer?

Yes. A visual CMS layer sits on top of Astro so editors compose pages from approved components with live preview. That capability is a requirement of the build, not an upsell.

What about our WordPress plugins?

Each one gets assessed during discovery: replaced with a first-class integration, rebuilt as a component, or dropped because it was doing nothing. You'll get that list before the project starts.

How long does a WordPress to Astro migration take?

A small marketing site is six to eight weeks. Several hundred pages with a redesign and complex integrations is typically twelve to twenty.

Do we need engineers on our side?

No, though it helps to have someone who can grant access to DNS, hosting, analytics, and the CRM. We handle the build and the cutover.

What does it cost to run afterwards?

Usually dramatically less. Static output on a CDN removes managed PHP hosting, caching layers, and most plugin licences.