Should You Build Your Marketing Site in Astro?

The short answer

Astro is a good default for a site whose job is to publish pages and get them read: marketing sites, blogs, documentation, product and pricing pages, content hubs. It renders to HTML at build time and ships zero JavaScript to the browser by default, which removes an entire category of performance problem before you write any code.

It is a bad default for three specific situations, and they are common enough that you should check them first: app-like products, teams already deep in a React toolchain, and teams with no developer and no plan to hire one. Those cases are covered further down, and if you land in one of them the rest of this page will not change your mind.

Everything below is about the mechanism, not about benchmark screenshots. Page speed depends on your images, your fonts, your third-party tags and your host at least as much as on your framework. A framework can only decide how much work the browser is forced to do before your content appears. That is the part Astro changes.

What "zero JavaScript by default" actually means

Most frameworks start from a JavaScript runtime. React, Next.js, Nuxt and SvelteKit all render through a client-side framework, so a page load involves downloading a bundle, parsing it, executing it and then hydrating the markup that was already there. For an application with authenticated state and real-time updates, that cost buys you something.

For a pricing page, it usually buys you nothing. The visitor scrolls, reads, clicks a link, maybe submits a form, and leaves.

Astro's documented design is the inverse. Components run at build time and produce HTML. Nothing ships to the client unless you explicitly ask for it, using a client directive on a single component. Astro's own documentation describes this as a zero-JavaScript-by-default architecture, and it is a design fact you can verify by building an empty page and looking at the network tab, not a performance claim that needs a study behind it.

The practical consequence: the floor is HTML. You can still ship a heavy page in Astro by adding a video background, three analytics scripts and an uncompressed hero image. What you cannot accidentally do is ship a framework runtime to a visitor who only needed to read a paragraph.

The SEO case, stated as a mechanism

There is no ranking bonus for using Astro. What exists is a chain of documented cause and effect.

Google's Search Central documentation describes page experience, including Core Web Vitals, as a signal used in ranking, and Google's Web Vitals documentation defines the thresholds: Largest Contentful Paint at or under 2.5 seconds, Interaction to Next Paint at or under 200 milliseconds, and Cumulative Layout Shift at or under 0.1. Those are field measurements, collected from real Chrome users through the Chrome UX Report, not lab scores from a tool you run once on your laptop.

Two of those three metrics are directly sensitive to how much JavaScript the main thread has to process. Interaction to Next Paint measures how long the browser takes to respond to input, and a busy main thread is the usual reason it is slow. Largest Contentful Paint degrades when the element that matters is rendered by script that must download and execute first. HTTP Archive's Web Almanac has tracked the amount of JavaScript shipped per page rising year over year, which is the trend Astro is reacting to.

So the honest formulation is this: Astro does not make Google like you. It removes the most common reason a content page fails a threshold that Google has said it measures. If your site is currently failing Core Web Vitals because of image weight or a tag manager container, changing framework will not fix it, and you should measure your own CrUX data before assuming the framework is the bottleneck.

Two things Astro genuinely gives you on the technical SEO side, both verifiable in its docs: complete control over the document head with no platform-injected markup, and first-party integrations for sitemaps and RSS. Neither is exotic, but on a hosted builder they are frequently the exact things you cannot fully control.

Content collections, and where your content actually lives

Astro's content collections let you keep content as Markdown or MDX files in the repository, define a schema in Zod, and get type-checked, queryable content with validation at build time. A missing meta description becomes a build failure rather than a discovery three months later.

The real decision underneath is not a feature comparison, it is: who edits, and how often. Content in Git is version-controlled, reviewable and branchable, which is excellent if the people editing it are comfortable with a pull request, and hostile if they are not.

If they are not, Astro connects to any headless CMS: Sanity, Storyblok, Contentful, Keystatic, Payload and others all have working integrations. That is a genuine option, not a consolation prize. It does mean you are now running two systems and paying for one of them, which belongs in your cost estimate rather than in a footnote.

Islands: the part that actually decides your architecture

Astro's island architecture is the feature to evaluate hardest, because it determines whether your specific site fits.

The model: a page is static HTML, and individual components can opt into client-side JavaScript with a directive such as client:load, client:idle or client:visible. A component marked client:visible loads its JavaScript only when it scrolls into view. Islands are independent, so an interactive pricing calculator at the bottom of the page does not impose its cost on the hero at the top.

This is a very good fit when interactivity is localized: a carousel, a search box, a filter, a calculator, a form. It is a poor fit when interactivity is global, because islands do not share client state with each other by default. If your page is really one connected application where a change in one place updates four other places, you are fighting the architecture, and a framework designed around a single client-side tree will serve you better.

That question, localized or global interactivity, is a better predictor of whether Astro suits you than any performance number on this page.

You can bring the components you already have

Astro renders React, Vue, Svelte, Solid, Preact and Lit components alongside its own .astro components. An existing component library usually carries over, and a team that knows React does not have to learn a new component model to be productive.

Write .astro for anything static, which is most of a marketing site, and reach for your existing framework components for the parts that genuinely need to run in the browser. This lowers the cost of trying Astro considerably, because the exit cost is low too.

Why the repository matters for AI-assisted work

An Astro project is plain files: HTML, CSS, JavaScript, Markdown, in a Git repository. Coding agents work well against that shape, and the reason is not the framework, it is the repository. The agent gets the whole artifact, can branch, can run the build, can see the test or type error it caused, and the change can be reviewed in a diff and reverted with a single command.

Hosted platforms have moved on this: Webflow, Wix and WordPress all now expose official MCP servers, so "AI cannot touch a hosted site" is out of date and you should not believe anyone still saying it. The durable difference is not access, it is the verification loop. An API surface gives an agent partial, rate-limited, unversioned reach into your content. A repository gives it the build.

Where Astro is the wrong choice

This is the section that decides it for most readers.

Your product is an application, not a site. Dashboards, authenticated multi-step workflows, real-time collaboration, anything with substantial shared client state. Use Next.js, Remix or SvelteKit. Astro can render an app shell, but you would be choosing a framework for a property, the static default, that your product cannot use.

Your team is already deep in React tooling. If you have a shared component library, an established Next.js deployment pipeline, engineers fluent in React Server Components and a design system built around it, the JavaScript you would save on marketing pages may cost less than running and maintaining a second build system and a second deployment target. A well-configured Next.js marketing site is not slow. The framework is not what makes most sites slow.

Nobody on the team writes code, and nobody is going to. Astro requires a developer, at minimum for changes to structure, layout and components. If your marketing team ships landing pages on Tuesday afternoons without asking anyone, a hosted visual builder is genuinely serving you, and moving to Astro trades a capability you use every week for a performance gain you may not need. Pairing Astro with a headless CMS returns editing to non-technical staff, but it does not return page building.

Your pages must be personalized per request. Astro supports server-side rendering, so this is possible. But if most of your site is dynamic per visitor, you have given up the static default that was the reason to choose Astro, and you should compare it against alternatives on their own terms rather than on the zero-JavaScript argument.

You need it live this week and have no developer available. That is a scheduling constraint, not an architecture one, and it is a real reason to stay where you are for now.

What it costs

Two numbers, and they are separate.

Running an Astro site: $0 to $20 per month on a static-first stack hosted on Cloudflare Pages, which has no commercial-use restriction, or roughly $20 to $50 per month on Vercel with a managed database. Note that Vercel's Hobby tier is non-commercial only, covering a paid employee or consultant writing the code, so a company or client site starts at Pro, currently $20 per user per month. If you add a headless CMS, budget for it separately: Sanity's Growth tier is $15 per seat per month and Storyblok's free tier is a single seat, which is usually the constraint that forces an upgrade once you hand a site to a client.

Building or rebuilding one: a 50 to 100 page site typically runs $5,000 to $25,000 depending on template count, CMS complexity and how much of the content needs restructuring rather than moving. Figures are as of July 2026 and vendor pricing moves, so check before you budget against them.

Compare that against what you pay now on a per-seat basis. On hosted builders the recurring cost tends to scale with editors rather than with traffic, which is the arithmetic that eventually makes a rebuild pay back.

How to decide, in five questions

1. Is interactivity localized to a few components, or spread across the whole page? Localized favours Astro strongly.

2. Who edits content weekly, and are they comfortable with Git? If not, price a headless CMS into the decision now.

3. Do you already have React infrastructure worth keeping? If yes, the marginal gain shrinks.

4. Are you actually failing Core Web Vitals in the field, per your Chrome UX Report data, and is JavaScript the reason? Measure before you migrate.

5. Do you need to own the output? Code you host anywhere is a different asset from a site that runs on one vendor's servers.

If the answers point to Astro, the follow-up questions are platform-specific. If you are on Webflow, the step-by-step process, exports, redirects and CMS mapping are covered in the Webflow to Astro migration guide. If you are still weighing the two platforms against each other rather than deciding on Astro itself, the Astro vs Webflow comparison sets them side by side.

Astro is not the best framework for everything. For a site whose job is to publish content and be found, it starts from the right default, and it is honest about the cases where that default does not help.