Astro vs WordPress: two system shapes, not two products.

The question cannot be answered in that shape, because the two are not the same kind of thing: WordPress is an editorial system that also renders the site, Astro is a site framework with no CMS. Asked usefully, it becomes: where does it hurt? If the pain is editorial, WordPress wins. If it is what the browser has to load, Astro wins. If it is both, combine them.

Not as a blanket statement. WordPress core is well maintained, and a properly updated installation is not a security problem. The structural difference is the attack surface: a statically delivered site executes no application code in the request path, while a PHP application with active plugins does. In practice, risk concentrates in plugins and in sites that nobody updates.

Not automatically – but the starting position is better, because static HTML is the default and client-side JavaScript only lands where it is requested. A badly built Astro site can still be slow. That is why we measure your Core Web Vitals before and after with your own field data. More on the Astro performance page.

Yes, but you choose how. Three routes: content stays as Markdown in the repository and is edited there; a headless CMS provides an editing interface, WordPress itself included; or changes go through chat. What does not carry over is the block editor's free-form layout building – you maintain fields, not layouts.

It usually stays where it is. A working shop with payment providers, tax logic and order management does not get replaced as a side effect of a website rebuild. The common arrangement is a split: Astro serves the marketing and content pages, the shop keeps running at its own address. Whether more is worth doing is a separate decision with its own budget.

Not if the migration is planned as an SEO project. That means a complete URL inventory, a redirect plan for every old address, carrying over titles, metadata and structured data, and monitoring after go-live. Drops are usually caused by missing redirects and changed page structures, not by the framework. Details on WordPress to Astro.

Three things set the frame: the number of page types, how much business-critical plugin functionality has to be rebuilt, and whether an editing interface is part of the scope. A manageable company site sits well below a multilingual portal with a shop connection. After the first call you get a transparent estimate; the reasoning behind it is on Astro development cost.

The number of posts is rarely the bottleneck: four templates for 4,000 posts are four page types, and content collections are documented with built-in caching for thousands of entries. The work comes from the state of the content – shortcodes, page-builder markup, embedded plugin blocks, old image paths. For a grown archive we plan 8 to 16 weeks. We build in parallel, your WordPress site stays online until sign-off, and the switch happens in a planned window with the redirect map ready.

Not necessarily – this is exactly what the third option is for. If WordPress stays behind the scenes as a headless CMS, your editors keep working in the interface they know; only delivery changes. If you move away from WordPress entirely, the way of working does change: you maintain defined fields in a headless CMS, Markdown files in the repository, or messages in a chat – no more freely built layouts. Which fits depends on how often and how freely your team publishes.

They do not come along as layouts. Page builders store design and content together in the database, in a format only that plugin understands. What carries over is the content, not the builder. We translate the existing layouts into a manageable set of section components that your team combines afterwards. That is real work – but usually also the moment where forty one-off layouts turn into a system.

From the plugin inventory, and that comes first, not as a footnote in the quote. We sort every plugin into four buckets: drops out because Astro brings it along (image optimisation, caching, part of the SEO markup); gets replaced by a service (forms, consent, analytics); has to be rebuilt (anything business-critical); or stays in WordPress. Only that list makes effort and timeline dependable – and sometimes it ends the migration question on the spot.

Yes, but differently. Astro has no translation plugin; it has routing and a content model. Each language version is its own entry in a collection, you define the URL structure, and hreflang comes out of the model instead of a plugin table. That is cleaner and cheaper to maintain long term, but it is construction work. Budget multilingual support as its own line item: it does not double the effort, but it does move the timeline up noticeably.

The argument holds, and we do not treat it as a footnote. WordPress has by far the largest pool of people who can pick a site up. On the other hand: Astro is MIT-licensed, follows semantic versioning and is an ordinary web project with no proprietary layer in between. Anyone who knows React, Vue or Svelte gets up to speed in days, not months. The market is smaller, the barrier to entry is low – both belong in the decision.

Yes, and on grown sites that is often the calmer route. The usual split is by path or subdomain: marketing and landing pages move to Astro first, blog and shop stay in WordPress for now, and a reverse proxy or the hosting configuration routes the requests. That costs a little operational complexity during the transition and demands clean canonical tags – but it lowers the risk considerably compared with a single overnight switch.

Yes. The repository, hosting accounts and domains are in your name from day one – we work inside them, we do not own them. What you get is a standard Astro project under the MIT licence: ordinary conventions, documented structure, no black box and no licence key sitting with us. Handover includes a setup document and, if you want, a working session with your team or your new agency.

We stand behind what we deliver. Before go-live we put in writing what counts as a defect and how quickly we respond; the contractual side belongs in the offer, not in an FAQ. Technically we work so that faults surface early: sign-off in staging, a checklist for URLs, redirects, metadata and structured data – and every change as its own commit with deploy history, so a rollback takes minutes.

Moving tends to make this easier, because many data flows in WordPress come from plugins and themes nobody deliberately chose: embedded fonts, external scripts, tracking inside theme building blocks. In an Astro project every external inclusion is a deliberate line of code and therefore auditable. Consent management, data processing agreements and hosting location remain your decisions – how we implement them is on GDPR-compliant websites.

Yes. Astro is free open-source software under the MIT licence, and WordPress is free software too. Neither charges a licence fee. Costs come from development, hosting and operation – with WordPress often also from paid plugins and themes.

Yes, that is one of its core cases. Posts live as Markdown or MDX in a content collection with a Zod schema, and from that come index pages, categories, feeds and detail pages with TypeScript types. What Astro does not bring is the writing interface – that comes from a headless CMS, from the repository, or by chat.

The starting conditions are good: by default the site is prerendered and delivered as static HTML, so crawlers see finished content, and little client-side JavaScript helps the Core Web Vitals. Rankings still come from content, structure and links. Switching framework does not replace SEO work – see SEO audit.

Yes. WordPress is one of the sources the Astro documentation covers with a migration guide of its own. In practice we read content through the WordPress API or an export and move it into content collections. Text, media and metadata carry over – page-builder layouts and shortcodes do not.

WordPress keeps running as the editorial system but no longer renders the public site. It exposes content through an API, Astro builds the front end and delivers it statically. The editor stays, the delivery changes. Details on WordPress as a headless CMS.