WordPress to Astro Migration: Two Paths Compared

In short

The short answer: WordPress is not a mistake to be corrected. The move adds up when your site is essentially a publishing channel, but its plugin and update surface has to be maintained like an application.
Path A – full migration: content is exported, the content model is rebuilt in Astro content collections, WordPress is retired. Afterwards there is no back end left to patch.
Path B – headless WordPress: your editors keep the WordPress admin they know; Astro becomes the front end and pulls content through the WP REST API or WPGraphQL. Astro documents this setup. In depth: WordPress as a headless CMS.
What does not come along: plugin functionality. Forms, memberships, bookings and WooCommerce in particular have to be replaced deliberately – or they are the reason not to move at all.
When we advise against it: a live WooCommerce store, business logic buried in plugins, or an editorial team that works in the block editor daily and will not give it up. Then you stay – or you go headless.

01 — Triggers

Why teams start looking at a move.

None of these is an argument against WordPress as such. They are the conditions under which a WordPress installation becomes more expensive than the site it serves. If you recognise three of them, the calculation is worth doing:

The update surface grows with every plugin

Each extension is third-party code with its own release cycle, its own security history and its own probability of being abandoned. Twenty plugins mean twenty roadmaps nobody in your organisation controls – plus a publicly reachable admin interface.

Performance degrades gradually, not at once

The site was fast at launch. Then came a slider, a consent banner, a tracking plugin, a chat widget. Each ships its own JavaScript and CSS on every page. The decay is slow, which is why it is only noticed once Core Web Vitals turn red in the report.

Page-builder markup works against you

Elementor, Divi and WPBakery produce deeply nested markup with generated class names and late-loaded styles. That is the price of building visually – and it is exactly the markup that hurts first in Largest Contentful Paint and layout shift.

Hosting cost for a site that mostly publishes

PHP workers, a database, an object cache, a staging environment, a caching plugin and a CDN in front: an entire operational chain so that a page is served which does not change between two editorial updates.

Nobody dares to touch anything any more

Once an update has broken the layout, updates stop happening. Outdated versions pile up, and the fear of the next change becomes a cost factor in itself.

Your site depends on other people’s roadmaps

An abandoned plugin, a theme author who stops replying, a breaking change in the next major release: the timing of your next emergency is decided by people you have never met.

02 — Decision

Move – or stay on purpose.

We build websites with Astro and with Webflow, and we also take over existing WordPress sites for ongoing care. We are genuinely indifferent to the outcome, as long as it fits your team. These two columns are what we use in the first call:

Moving pays off when …

Your site is essentially a publishing channel, and running it takes more attention than the publishing justifies.

Your website mainly delivers content: company site, product pages, blog, magazine, documentation, careers section.
The plugin list has grown over the years and nobody can say with confidence which extension is still needed for what.
Security and update maintenance regularly consumes time or agency budget without making the site any better.
Core Web Vitals matter to you and the page builder is the structural problem, not the image sizes.
Your editors publish rarely and in clear structures – then a typed content model is more comfortable than an editor that allows everything.
You are planning a redesign anyway. Two rebuilds in one step cost less than two rebuilds in sequence.

Stay on WordPress when …

This is not a politeness clause. In these cases we actively advise against moving – it would cost you money and take away capability.

A WooCommerce store carries your revenue. Catalogue, checkout, tax, shipping rules and extensions are interlocked; that is a commerce project, not a website move.
Memberships, courses, bookings or forums are core functionality – those are applications inside WordPress, not content.
Your editorial team works in the block editor daily, assembles its own templates and genuinely uses that freedom.
Your processes depend on plugins that exist only for WordPress – industry solutions, association feeds, portal integrations.
You run a well-maintained, up-to-date installation with a modest plugin list and measurably good field data. Then there is nothing to fix.
Your organisation works without a deployment process and does not want to build one. Then WordPress – or Webflow – is honestly the better tool.

03 — The two paths

Full migration or headless WordPress?

Most enquiries on this topic assume there is only one option: switch WordPress off. There are two, and the second is not a consolation prize. Astro is CMS-agnostic and acts purely as the presentation layer – running WordPress headless behind it is a documented, ordinary setup.

An assessment from our project practice. If your editors live in the block editor, Path B is not the compromise – it is the correct answer.
Dimension	Path A: full migration	Path B: headless WordPress
Where content ends up	In content collections inside the repository – Markdown, MDX, JSON or YAML, validated against a Zod schema	Still in the WordPress database; Astro fetches it through the WP REST API or WPGraphQL
What your editors work in	Content files in the repository, a connected headless CMS, or the chat route	The familiar WordPress admin – block editor, media library, roles and approvals stay untouched
WordPress operations afterwards	Gone entirely: no database, no PHP, no publicly reachable admin	Still there and still needing patching and hardening – ideally no longer publicly reachable
What happens to plugins	Every plugin function is replaced or dropped – deliberately, one by one	Editorial plugins can stay; anything that writes markup into the front end becomes irrelevant
Running cost	Usually lower: static hosting instead of an application server, database and caching chain	Two systems in operation – WordPress plus front-end deployment. The gain is speed and attack surface, not the invoice
Effort to switch	Higher: content model, export, functional replacements, editorial training	Lower on the editorial side, higher on integration: field model, queries, images, preview
Preview before publishing	Via branch previews or the preview of the connected CMS	Needs its own solution – typically an on-demand rendered route with an adapter for your runtime
Fits when …	Editors publish rarely, clear structures are enough, and WordPress mainly produces maintenance work	A team publishes daily and is attached to its workflow – but still needs a lean, fast front end

04 — Process

How a WordPress to Astro migration runs.

Seven phases with results you can check. The order is not negotiable: starting without a complete URL and plugin inventory means finding the gaps after go-live.

Inventory instead of assumptions

We pull every indexed URL, the page types, the full plugin inventory and the traffic distribution. After that it is documented which twenty pages carry most of the organic traffic, and which plugin function anyone actually uses. Frequently this is the moment half the list disappears.

Path decision: A or B

Full migration or headless? This is not decided by technology but by your editors: who publishes, how often, with which approval stages, and how painful the loss of the block editor would really be. Only then does an effort estimate mean anything.

Content model and export

Posts, pages, categories, authors, media and custom post types are exported from WordPress and mapped onto a content model. In Astro they become content collections – “a set of related, structurally identical data” – with a Zod schema that validates every entry at build time. This is where the state of years of content maintenance becomes visible.

Build in Astro

Routes, layouts, components, image pipeline, navigation, search and multilingual structure. Delivery is prerendered HTML; where a route has to render on demand – form handling, preview, personalised areas – an adapter for your target runtime is added. Interactive elements go in deliberately as islands, everything else stays HTML without client-side JavaScript.

Decide the functional replacements

Forms, newsletter, search, consent, languages, gated areas: every plugin function gets either a successor, a deliberate removal, or the note “stays in WordPress”. Whatever is not on this list will be missing from the site later.

Measure before launch

Lighthouse on staging, metadata, sitemap, structured data, an accessibility pass and a full redirect test against the old URL list. We also capture your Core Web Vitals field data before the move – so that the word “faster” is evidence afterwards rather than a claim.

Launch and follow-up

Switch the domain, activate the 301 redirects, verify monitoring and analytics, submit the sitemap in Search Console. Then we watch indexing, rankings and field data for several weeks and correct as needed. A migration is not finished on go-live day; it is finished when the curves settle.

05 — Plugins

What becomes of your plugins.

This is the part proposals like to skip. Content can be exported – functionality cannot. Every plugin function needs a decision: replace it, drop it, or leave it in WordPress. Here are the cases that appear in almost every project:

Contact forms – Contact Form 7, WPForms or Gravity Forms become a form route with server-side handling, or a dedicated form service. Spam protection, GDPR-compliant delivery, confirmation mail and the handover into your CRM all get redefined in the process. That is a work package of its own, not a checkbox in a quote.
SEO plugins – What Yoast or Rank Math manages – titles, descriptions, canonicals, sitemap, structured data, robots directives – becomes part of the layouts and the content schema in Astro. Your editors still maintain title and description per post, as a schema field instead of a plugin box. If you want the existing set cleaned up first, start with an SEO audit.
Caching and performance plugins – WP Rocket, W3 Total Cache and relatives disappear without replacement. When the page is prerendered and served as static HTML, there is nothing left to cache that is not already finished. This is one of the few points where a move genuinely removes complexity instead of relocating it.
Image plugins – Smush, ShortPixel or Imagify are replaced by built-in image optimisation: the image components set alt, loading and decoding, infer image dimensions to avoid cumulative layout shift, and generate several formats and sizes with a fallback. Images that should deliberately stay unprocessed are stored separately.
Multilingual setups – WPML or Polylang become routing and content structure: dedicated routes per language, dedicated entries, clean hreflang annotation. It is cheaper and more robust to run long term – but it is a rebuild, not a move, and we scope it separately.
Page-builder layouts – Elementor, Divi or WPBakery do not come along. Your layouts get translated into a manageable component library, usually with far fewer variants than the builder allowed. That is the actual gain: five years of accumulated variation gets cleaned up once instead of carried over.
Memberships, courses, bookings – Membership, LMS and booking plugins are applications, not content. They cannot be migrated, they have to be replaced – by a specialised service or by real development. Often the smartest option is to leave that area in WordPress for now and move only the marketing site.
WooCommerce – A live store is the most common good reason not to move. Catalogue, cart, checkout, tax and shipping rules, payment providers and dozens of extensions are interlocked. Astro can serve as a storefront in front of a commerce API – but then it is a commerce project with its own risk profile. If your revenue runs through WooCommerce: stay, or move deliberately to a dedicated commerce platform. We advise on that separately.
Security and backups – For the part delivered as static HTML, Wordfence, backup plugins and the weekly update round go away: there is no publicly reachable admin and no database behind the page. History lives in the repository, and a rollback is a deploy. On the headless path, WordPress itself remains a system that needs maintaining – that belongs in the honest version of this list.

What the official guide covers

Astro lists WordPress among its official migration guides and separately documents WordPress as a headless CMS. Both are real documentation – but a guide is not a tool. The export is the easy part; the work sits in the content model and in replacing functionality.

The stack underneath

Astro 7 is the current major line, content collections have existed since Astro 2.0, and the framework is MIT-licensed. There is no platform licence and no dependency on us: repository, hosting account and domain are in your name.

An honest limit

If your editorial team uses the block editor daily and will not give it up, a full migration is the wrong path. Then headless WordPress is the better answer – or you stay where you are.

06 — After the move

Editing after WordPress: maintain the site by chat.

The most common objection to leaving WordPress is not technical but human: “then who changes the text on the home page?” We have a concrete answer to that.

vincubate does not only build with Astro; we put a modern AI stack on top of it. In practice that means you can edit your website in a chat – through a Telegram bot, for example. Change a paragraph, add a blog post, swap an image, correct a price: as a message, not as a CMS session. If you can send a voice note, you can maintain your website.

This works because Astro content lives in a typed, schema-validated content model: content collections with a Zod schema – or, on the headless path, a CMS with an API. Both are machine-addressable. An agent can only fill fields that exist, in formats that validate; a faulty edit fails in the build rather than on the live site. Every change lands as a reviewable commit and a deploy – with history, review and rollback. That is the real difference from an editor where an unfortunate edit is public immediately.

Who it is for: large organisations with an editorial team, and equally the sole trader or SME who will never open a CMS. The second case is the interesting one – someone who currently has three changes a year made for them, because going through an agency feels too cumbersome, will make them personally instead, in thirty seconds.

That chat agents are day-to-day work here rather than slideware is something you can check: we run a WhatsApp AI agent as our own product. How the route works specifically for websites is described under editing your website by chat.

And the limits, so this stays honest: the chat route does not replace an editorial system for large teams with multi-stage approvals – it complements one. Editorial responsibility stays with you: an agent proposes and writes, you decide. Structural changes – new page types, layout, navigation – remain development work. And the scope is defined per project: which collections, which fields, which approval stage. It is not a feature you switch on; it is one you tailor.

For small teams

When two people change something twice a year, an editorial system is pure operational overhead. In those cases the chat route replaces a system that would otherwise cost money every month.

For large teams

With daily publishing and approval stages, a headless CMS stays the foundation. Chat then covers the quick corrections – alongside the workflow, not instead of it.

Who decides

You do. We configure which fields are editable by chat at all – and what deliberately only goes through a pull request.

07 — Timeline

How long does the move take?

We quote prices only after the inventory – timelines we can give beforehand, because they follow from scope. The ranges on the right are our own experience for the seven-phase process described above, counted from kickoff and excluding the observation window after launch. What moves those ranges is listed here, point by point, so you can place your own case:

The number of templates, not of pages – Five hundred blog posts of the same type are one import and cost almost no time. Fifteen hand-built landing pages with individual layouts are fifteen components. So we count page types, not URLs – that is the number which drives the schedule, and it is settled after the inventory.
State and volume of the content – The export itself is automated. What costs time is what sits inside it: shortcodes, page-builder markup, inline styles, inconsistent image sizes, posts without a lead image. With well-maintained content this block almost disappears; with ten years of accumulated material it can account for a third of the project.
Carry over or rewrite – Moving content one to one is a migration. Rewriting the copy along the way is an editorial project – and it runs on your side. This is regularly the point where schedules slip. We recommend separating the two: move first, rewrite afterwards.
With or without a CMS – Without a CMS – content in the repository or by chat – an entire work package disappears. With a connected headless CMS you add a field model, previews, roles and editorial training. Depending on scope, that is one to three additional weeks.
Number of languages – Every additional language means its own routes, its own entries, hreflang annotation and a second approval loop with your translators. Budget a noticeable increment per language rather than a copy – the effort sits in coordination, not in the technology.
Functionality to be replaced – A contact form is days. Full-text search, a members area, a booking flow, a CRM integration or a commerce connection are separate work packages with their own sign-off. This list – not the page count – decides whether a project lands at six weeks or at sixteen.
Your approval cycles – The most honest item on the list: delay rarely originates in development, but in waiting for approvals, access credentials and content still to be supplied. Naming one person who can decide and fixing review dates shortens the project measurably – often by weeks.

Path A – full migration

A tidy site up to roughly 30 pages with four to six page types: 3 to 5 weeks. A typical company site with a blog and several functions to replace: 6 to 10 weeks. A grown portal with a page builder, several languages and custom logic: 12 weeks and up.

Path B – headless WordPress

For comparable scope, usually 4 to 8 weeks. The entire editorial workstream disappears; in exchange, field model, queries, image handling and preview cost time. It is shorter than Path A only as long as the field model in WordPress does not need cleaning up first.

After launch

We plan for 6 to 10 weeks until indexing and rankings settle at a stable level, and we watch during that window. Fluctuation in the first weeks is normal. If something is still off after that window, it is not a law of nature but a fault – and it gets fixed.

08 — At a glance

WordPress to Astro at a glance.

The short version of this page, so you can pass it on without anyone having to read the whole thing again. The final row is our take – not a summary but an opinion, and one we will defend in the call.

An assessment from our project practice, as of 2026. The timings are experience values for the way we work, not a commitment – the range becomes binding only with the inventory.
Dimension	Short version
When moving pays off	When your site is essentially a publishing channel – company site, product pages, blog, magazine, documentation, careers section – while its plugin and update surface has to be maintained like an application.
When you should stay	A live WooCommerce store, memberships and bookings as core functionality, processes tied to WordPress-only plugins, or an editorial team that works in the block editor daily and genuinely uses that freedom.
The two paths	Path A: full migration, WordPress is retired. Path B: headless WordPress – editors keep the admin they know, Astro takes over the front end only.
Timeline	Path A: 3 to 5 weeks up to roughly 30 pages, 6 to 10 weeks in the normal case, 12 weeks and up with a page builder, several languages and custom logic. Path B: usually 4 to 8 weeks. Then 6 to 10 weeks of observation.
What comes along	Content including custom post types and their fields, media, URL structure, metadata, internal linking, structured data – and your legal pages at their existing addresses.
What has to be replaced	Everything a plugin used to do: forms, newsletter, search, consent, multilingual setup, gated areas. Caching and image plugins disappear without replacement; page-builder layouts are translated into components.
SEO continuity	Content inventory, ranking and backlink analysis, 1:1 URL mapping including pagination and query strings, 301 redirects, metadata validation on staging, sitemap, Search Console setup, IndexNow, monitoring through the first weeks.
Editing afterwards	Content collections in the repository, a connected headless CMS – or maintaining the site by chat. On Path B the WordPress admin stays exactly as it is.
Our take	For content-driven sites without a store, moving is the right decision in most cases – the operational overhead disappears, and editors lose less than they expect to. If your revenue runs through WooCommerce, we advise against it: the risk outweighs the gain. And if your team lives in the block editor, headless is not half a move – it is the more honest one.

09 — FAQ

Frequently asked questions about migrating WordPress to Astro.

Will we lose our rankings when we move from WordPress to Astro?

Not if the move is planned. We pull every indexed URL beforehand, turn it into a complete 301 map and test each redirect before go-live. Title, heading and content structure of the load-bearing pages stay stable; structured data and sitemap are rebuilt. After launch we watch indexing and rankings for several weeks and correct as needed. Short-term fluctuation is normal; permanent loss is a planning failure.

How does our content get out of WordPress?

Through the WordPress export, the REST API or a direct database extract – depending on how cleanly the content has been maintained. Posts, pages, categories, authors, media and custom post types are mapped onto a content model and stored as content collections with a Zod schema. The export itself is the easy part. The work sits in the cleanup: shortcodes, page-builder markup and years of accumulated special cases each need a decision.

Can our editors still publish on their own afterwards?

Yes – the only question is where. After a full migration they maintain content either directly in the repository, through a connected headless CMS, or by chat. On the headless path almost nothing changes for them: block editor, media library, roles and approvals stay, and only delivery moves to Astro. If your team publishes daily and is attached to the editor, that is the better path.

What happens to our plugins?

Plugin functionality is not migrated, it is replaced or dropped. Caching and image plugins disappear because Astro ships static HTML and image optimisation is built in. Forms, newsletter, search and consent each get a successor. Membership, booking and store plugins are applications: they either stay in WordPress or get rebuilt. We go through your plugin list line by line before quoting – that is what prevents the expensive surprises after launch.

We run a WooCommerce store – can we still move?

Usually we advise against it. WooCommerce is not a plugin but a web of catalogue, cart, checkout, tax and shipping rules, payment providers and extensions. Astro can act as a storefront in front of a commerce API, but that makes it a commerce project with matching risk. Two sensible options exist: stay on WooCommerce, or move deliberately to a dedicated commerce platform. A middle route is to migrate only the marketing site and leave the store untouched.

What is headless WordPress – and when is it the better choice?

Headless means WordPress stays the editorial back end but delivers content only as data, through the REST API or WPGraphQL. Astro builds the front end. Astro documents this setup explicitly, so it is not an improvised route. It is the better choice whenever your editors should keep the tool they know while you still need a lean, fast front end. We describe it in detail under WordPress as a headless CMS.

What does a WordPress to Astro migration cost?

Three things set the range: the number of distinct page types – not pages – the amount of plugin functionality that has to be replaced, and the state of the content. A tidy site with five page types and three plugins sits well below a grown portal with a page builder, multiple languages and twenty extensions. After the inventory you receive a transparent estimate with its assumptions written down.

Will the site actually be faster afterwards?

We do not promise a percentage, because we do not know your starting point yet. What we do commit to: we capture your Core Web Vitals from field data before the move and measure the same metrics again after launch. Structurally a lot speaks for it – prerendered HTML instead of a database query per request, no client-side JavaScript until it is requested, and an end to page-builder markup. But it is only proven once your own numbers show it.

How long does a WordPress to Astro migration take?

Our experience values for Path A: a tidy site up to roughly 30 pages with four to six page types takes three to five weeks. A typical company site with a blog and several plugin functions to replace takes six to ten weeks. Grown portals with a page builder, several languages and custom logic start at twelve weeks. Path B usually lands at four to eight weeks. Counted from kickoff. The single biggest factor is not the page count but your approval cycles.

We have over 4,000 blog posts. Is there downtime during the switch?

There is no gap for your visitors: the WordPress site stays online untouched until the switch, while the new site is built in parallel on a staging domain. We only cut over once the redirect test against the complete URL list runs clean. Because a DNS change does not take effect at every provider in the same minute, we keep both deliveries live briefly in parallel. For the content reconciliation we agree an editorial freeze of one to two days. 4,000 posts are not a volume problem – the export is automated; the special cases inside it are the work.

We have eight custom post types and hundreds of ACF fields. Can that be mapped?

Yes, and usually more cleanly than before. Each custom post type becomes its own content collection, each ACF field becomes a field in the Zod schema – with the difference that the schema checks at build time whether an entry is valid. Relationships between post types become references; repeaters and flexible content become nested structures or block lists. The effort sits in the mapping: fields that have been empty for years, exist twice, or were filled exactly once each need a decision beforehand.

We run a WordPress multisite network with twelve location sites. Does that work?

Yes, but the network concept itself does not come along. Instead of one installation with twelve sub-sites, you normally get one project with a shared component library and one collection per location – alternatively several deployments sharing the same components. Shared user management and network-wide plugins fall away. The decisive question comes before the estimate: do those twelve sites genuinely share the same templates, or have they become twelve special cases over the years? That is the difference between one component and twelve.

Our members area with logins and gated downloads runs on a membership plugin.

That does not simply move – a members area is an application, not content. Three routes are common. First: the gated area stays in WordPress and only the public site moves. That is often the most economical option. Second: a specialised service handles authentication and payments, and the gated routes render on demand in Astro through an adapter. Third: the area is rebuilt as an application of its own. Which route fits depends on member numbers, revenue share and how deeply the logic sits inside the plugin.

What happens to the comments under our posts?

Three options, and we count first which one is worth it. First: existing comments come along from the WordPress export and are served statically as part of the post – readable and indexable, but closed to new ones. Second: an external comment service takes over new comments, embedded as an island that loads only on scroll. Third: comments are deliberately switched off and the discussion moves where it already happens. In practice the last genuine comment is often years old.

Our imprint, privacy policy and cookie banner still have to be right.

Imprint and privacy policy are ordinary content pages and move at the same URL – which matters, because both are linked from outside and both authorities and platforms expect to find them there. The consent plugin goes away; a consent tool takes its place as an island that loads JavaScript only where it is needed. Often the list of services requiring consent shrinks, because plugins were previously pulling third-party scripts into every page. Legal review of the wording stays with you or your legal counsel: we rebuild, we do not advise on law.

Does a niche framework make it harder to find developers?

Honestly: the hiring pool is smaller than for WordPress – that is the point where WordPress stays unbeatable. In practice it weighs less than it sounds, because an Astro component is HTML, CSS and JavaScript at its core, and interactive parts can be written in React, Vue, Svelte, Preact, SolidJS or Alpine.js. Anyone who knows modern front-end work is productive within days. And none of it is proprietary: Astro is MIT-licensed and the code sits in your repository, not inside a platform.

What happens if we part ways, or if you drop out?

You keep everything you need to carry on. Repository, hosting account and domain are in your name, not ours. Astro is MIT-licensed, there is no platform fee and no component that only runs at our end. A build is a standard command and a deploy is a standard operation any front-end agency can run. Handover includes documentation in the repository and an onboarding session – even when nobody intends to ever need it.

Who is liable if something breaks after launch?

Faults originating in our implementation we fix under the contractual warranty, without a separate invoice. So that this does not become a matter of interpretation, we define acceptance up front: redirect test against the complete URL list, metadata check, Lighthouse measurement on staging, an accessibility pass. Anything that arrives afterwards as a new wish is further development and is commissioned separately. For ongoing operation there is a maintenance agreement – it is not mandatory.

Can we develop the site further in-house afterwards?

Yes, that is the normal case and we build towards it. The project is an ordinary repository with npm scripts and a Git history; anyone who has shipped a front end before will find their way in. Handover includes a README covering setup, build and deploy, the documented structure of the content collections, and the places where changes typically happen. After that we can limit ourselves to maintenance, help occasionally – or do nothing at all. Lock-in would be the worse business for us anyway.

Is Astro free?

The framework is: Astro is open source under the MIT licence. There is no licence fee and no platform fee, however large the site grows. Costs arise for development, hosting and – if you use one – a headless CMS.

Does Astro need a server?

In the standard case, no. Astro prerenders and ships static HTML that any simple hosting or CDN can serve. Only routes that have to render on demand – form handling, preview, personalised areas – require an adapter and a matching runtime.

Can Astro do a blog?

Yes, that is the core case. Posts live as Markdown or MDX in a content collection, a Zod schema defines the required fields, and index pages, categories, author pages and feeds are generated from them. Content collections bring caching for thousands of entries with them.

Is Astro good for SEO?

The preconditions are right: content is in the HTML source because rendering happens on the server, and title, description, canonicals, sitemap and structured data live in the layouts instead of a plugin. Rankings do not follow automatically – the content work remains yours.

Who is behind Astro?

Astro is an open-source project developed in public in the withastro repository on GitHub. The licence text is MIT and names Fred K. Schott as copyright holder, dated 2021. The current major line is Astro 7, and Astro follows semantic versioning.

10 — Related

WordPress to Astro – or keep WordPress and go headless.