Astro development for content-driven sites - fast static HTML, JavaScript only where you need it.
Intention InfoService builds fast, content-driven sites on Astro - marketing sites, blogs, documentation and landing pages that ship almost no JavaScript by default and add interactivity one island at a time, by a small senior team at transparent published fixed prices. We build Next.js too, so we will tell you honestly when your site is content that belongs on Astro, and when it needs to behave like an app. You own the code outright, with no lock-in. For startups, SMBs and enterprises worldwide.
Fixed price, code you own, no lock-in.
- You own 100% of the code
- Published fixed pricing
- Ships almost no JavaScript
Astro in 2026v6
- Rendering
- Static HTML, islands where needed
- Interactivity
- Opt-in, one island at a time
- Content
- Content Layer, MDX, collections
- Deploy
- Any host - platform-agnostic
A content page starts as static HTML with no framework runtime - you opt into JavaScript, you do not inherit it.
Content-driven sites, built to be fast and found
Astro's sweet spot is the content site - marketing, blogs, docs, landing pages - where the job is to load fast, read cleanly and rank, with interactivity added only where it earns its place. A typical Astro engagement is one of these:
Marketing & brochure sites
Fast, content-driven marketing sites that ship almost no JavaScript and load quickly for real visitors - the site your campaigns point at, built to be read and to rank, not to run an app in the browser.
Blogs & content sites
Content collections with typed frontmatter and MDX, so writers work in Markdown and the build checks the shape of every post - a publishing setup that stays fast as the archive grows.
Documentation sites
Technical docs and knowledge bases, including on Starlight, Astro's documentation-site toolkit - search, versioned content and navigation that stays quick across hundreds of pages.
Landing pages
Campaign and product landing pages that need to be fast and to convert - static by default, with a single interactive island (a form, a calculator) dropped in only where it earns its place.
Headless CMS front ends
Astro as the presentation layer over a headless source - Sanity, Strapi, Contentful, or WordPress used headless - pulled in through the Content Layer and rendered as fast static or hybrid output.
Migrations to Astro
Moving a slow content or marketing site off an older setup - Gatsby, Jekyll, Hugo, or a heavy WordPress theme - onto Astro, with your content modelled and your URLs mapped so the SEO survives the move.
When it is not really a content site
Astro is for content that must be fast. When your project is really one of these, we will point you to the right place rather than force it onto the wrong tool:
A site that has to behave like an application - Next.js for sites that must behave like an app is the right call - authenticated areas, dashboards, heavy client state, data-driven views that change constantly. Astro shines for content with light interactivity; the moment interactivity becomes the product, that is Next.js, and it is why our own site runs on it.
Content a non-developer edits every day - WordPress, when the job is editing not code is often the honest choice - a familiar admin your marketing team runs without a developer. Astro can read a headless CMS, but if day-to-day editing is the whole point, we will say so.
An online store or shopping cart - Shopify or WooCommerce for a real store is where commerce belongs - a catalog, cart and checkout built to sell. A content site can link out to a store, but we do not build the store itself in raw Astro.
Most content sites ship far too much JavaScript. Astro makes shipping almost none the default.
A content page's real product is its HTML - for a reader, and for a search crawler. Most sites bury that under a client-side JavaScript bundle they never needed, and React frameworks are among the worst offenders, because their default is to ship the framework and then have you claw the weight back with code-splitting and bundle budgets. Astro inverts the default: a page starts as static HTML with no framework runtime, and you opt into JavaScript one interactive island at a time, each a deliberate, reviewable decision. Shipping almost no JavaScript is not a discipline you fight your own tools for here - it is where the page begins. That is a design philosophy, not a benchmark we are asking you to take on faith, and it is the reason a content site belongs on Astro.
What Astro gives a content site
Astro is built for one job - content that has to be fast and findable - and it is very good at it. Here is what that buys you, and, honestly, when it is the wrong tool.
Zero JavaScript by default
A page's default output is HTML and CSS with no client-side framework runtime attached. JavaScript ships only for the components you choose to make interactive, so a content page with nothing interactive can ship no framework code at all.
Islands, hydrated on purpose
Interactivity lives in isolated islands that hydrate independently, each with an explicit client directive - on load, when idle, when scrolled into view, or at a breakpoint. Every byte of JavaScript maps to a named, reviewable decision.
Real HTML for search and readers
Because the default build is pre-rendered static HTML, a crawler sees the finished content with no client render step, and semantic markup is the baseline rather than a retrofit - a strong SEO foundation, and a good starting point for accessibility, both claimed as method.
Content modelled and typed
The Content Layer gives content a typed interface whatever the source - Markdown, MDX, a headless CMS or a database - so a missing field or wrong type is a build error, not a production surprise. The data contract is explicit before layout begins.
Bring the React you already have
Astro is UI-framework-agnostic, so an island can be a React, Vue, Svelte or Solid component. If you already own a React widget - a calculator, a configurator - it mounts inside an otherwise static Astro page instead of being rebuilt.
Open, and yours to move
Astro is MIT-licensed, open-source and platform-agnostic - it deploys to any host, and that stayed true after the Astro team joined Cloudflare in early 2026, because staying open to every platform was a stated condition of the deal. You are not tied to one vendor's cloud.
When Astro is the wrong choice
Astro earns its place on content sites. It is the wrong starting point - and we will say so - when the project needs to behave like an application: authenticated areas, heavy client state, dashboards, data-driven views that change constantly. Past a handful of interactive pieces sharing state, you are fighting the framework, and that work belongs on Next.js, the React framework for sites that behave like apps. When the whole point is a non-developer editing content every day, that is often WordPress, and when you are selling products it is Shopify or WooCommerce. Not sure which side of the line you are on? We will make that call with you before we quote anything.
Modern Astro, decision by decision
There is no live Astro running this static Next.js site to point at, so the proof is the discipline. Everything here is a decision you can inspect on a build we deliver - a client directive, a typed content schema, a rendering mode - which is the point: you should never have to take our word for what a fast content site looks like.
Zero JavaScript by default
The default output of an Astro page is HTML and CSS with no client framework attached; JS ships only for components you hydrate. What you check: view source on a delivered content page and the interactive-heavy bundle a typical React framework sends for the same page is simply not there.
Islands and selective hydration
A page is mostly static HTML with isolated interactive islands, each hydrated on an explicit directive - on load, when idle, when scrolled into view, or at a breakpoint. What you check: every island's directive is a line in the code, so why a component ships JavaScript always has a named answer.
Server Islands
Server Islands combine cached static HTML with a slot rendered on the server per request, on one page - the fast shell stays instant while a genuinely dynamic piece (a personalised block, live inventory) renders server-side without turning the whole route dynamic. An established part of the framework, not a preview feature.
Framework-agnostic islands
An island can be React, Vue, Svelte or Solid, and more than one can coexist on a page. What this unlocks: an existing React component mounts as an island inside a static Astro site instead of being rebuilt. This is also our honest adjacency - our own site is React, so the React-island path is the one closest to what we run.
Content Layer, typed
The Content Layer gives content a typed, validated interface wherever it lives - local Markdown and MDX, a headless CMS, a database - loaded through a schema. What you check: content shape is verified at build time, so a missing field or wrong type is a build error, not a runtime surprise in production.
Content collections and MDX
Collections organise content into schema-validated groups (posts, docs, case studies) with type-safe frontmatter, and MDX lets a Markdown document embed a live component inline - a chart or an interactive island dropped into the middle of prose without leaving the content file.
Astro over a headless CMS
Astro reads a headless source - Sanity, Strapi, Contentful, or WordPress used headless - as a data source through the Content Layer, and renders fast static or hybrid output. The CMS is where non-developers edit; Astro is the presentation layer. If day-to-day editing is the whole point, we would route you to WordPress directly rather than pitch a headless build.
SEO by construction
Because the build is pre-rendered static HTML, the markup a crawler sees is the final content with no client render step, and semantic elements are the baseline. What you check: real headings, articles and landmarks in the shipped source. The same semantic baseline is a good start for accessibility, which we claim as method, never as a finished property.
Performance levers, measured on you
Built-in image optimization, View Transitions for animated navigations, and link prefetch are the levers we build toward passing Core Web Vitals. We treat CWV as a goal and a method, measured on your pages after launch - we put no score on this page, and we never reuse our Next.js site's numbers as if they were an Astro result.
SSR, hybrid and edge deploy
Astro is not static-only: routes can be pre-rendered, server-rendered, or mixed per page. It deploys to any target through adapters - a static host, a Node server, or an edge platform - and stays platform-agnostic. We pick the rendering mode per route and the deploy target to fit your infrastructure, not a single vendor.
Where islands end and an app begins
Islands cover a lot - forms, menus, sliders, modals, embedded React widgets, filtered lists. The honest boundary is behaviour: when a project needs authenticated dashboards, heavy client state or constantly-changing data-driven views, that is a Next.js build, and we say so rather than bend Astro into an app it was not designed to be.
Vite tooling, TypeScript, migrations
Astro is Vite-based with first-class TypeScript, a broad integrations ecosystem, and Starlight, Astro's documentation-site toolkit. Moving a site off Gatsby, Jekyll, Hugo or a heavy WordPress theme onto Astro is a defined, scoped lane - typed code, a modern build, and adapters chosen to match where you deploy.
How we take on an Astro build: decide first whether it is really a content site at all, then model the content as typed collections before layout, build static-first and add islands one directive at a time, bake in image optimization and semantic HTML rather than auditing performance at the end, and choose the rendering mode and adapter to match where you deploy. When the project is really an app, that is Next.js; when it is content a team edits daily, that is WordPress. We say which before we quote.
Our own site is a Next.js build, not an Astro one.
Our React and Next.js pages can say 'this page is the technology, inspect it.' This one can't, and we won't fake it. Our site is a static Next.js and React build on the same npm, Node and TypeScript ecosystem Astro lives in - and an Astro island can be React, which our site is - but it is Next.js, not Astro. Here's the honest part most agencies skip: our site being fast and static proves we know fast static web, but a pure content site built on Astro would ship even less JavaScript than ours does, because that is Astro's default and our site is a growing platform, not pure content. We won't dress a Next.js build up as Astro proof, and we won't show you a performance score for a site we haven't built yet.
The depth on this page is the demo
The capability detail above is written by people who know current Astro practice cold - islands and Server Islands, the Content Layer for typed content from Markdown, MDX or a headless CMS, content collections, View Transitions, Starlight for docs, React or Vue islands, deployed anywhere. Dated or hand-wavy Astro vocabulary is how a buyer spots an amateur; ours is current, and that competence, stated as capability and never as a performance score we invented, is the proof that actually travels. Everything we claimed is a decision you can inspect on a build we ship, not a number you have to believe.
You own 100% of the code, content and IP
A standard Astro project in your repository - your content, your domain - handed over in full. The source, the content collections, the config and the build all live on your side from day one; nothing is held hostage on ours, and you can move to any other Astro developer without asking our permission.
No lock-in - deploy anywhere
Astro is MIT-licensed, open-source and platform-agnostic: it builds to static or hybrid output that deploys to any host - Cloudflare, Netlify, Vercel, your own server, anywhere. That stayed true after the Astro team joined Cloudflare in early 2026 - staying open to every platform was a stated condition of the deal - so you are never tied to one vendor's cloud to run your own site.
Standard, open Astro any team can pick up
Conventional Astro - islands, content collections, the Content Layer, MDX, a clean project structure any Astro developer can read - on the mainstream npm and Node toolchain. We never wrap your site in an in-house layer only we understand.
We adopt or migrate after an audit
Already have an Astro site, or a WordPress or old static build you want moved onto Astro? We start with a paid audit, model your content and map your URLs with redirects so your SEO survives the move, and pick the codebase up where it is - no rip-and-replace as a reflex.
Honest about partners, certs and attestations
The Astro Agency Partner program is real - Astro hand-picks agencies with a track record of shipping Astro sites into a public directory - and we are not an Astro Agency Partner and are not listed in it; it is vetted on a body of Astro work we do not yet have, and we won't imply otherwise. There is also no official certification for the Astro web framework - the Astro certificates you will see are third-party course-completion certificates, not a company credential. The honest governance answer is the license: Astro is MIT-licensed, open-source and platform-agnostic, now stewarded by the Cloudflare team that builds it, so your assurance is that your site deploys anywhere, not a badge. We hold no SOC 2 report and no ISO 27001 certification, and there is no HIPAA certification for anyone to hold. If your project legally needs a vendor who carries a formal attestation, we will say so plainly.
Senior people, direct, since 2016
You talk to the engineers who write your Astro and structure your content - no account-manager layer, no offshore hand-off, no juniors learning islands on your budget. Intention InfoService is a real, incorporated company, small and senior on purpose, so a content site stays architecturally consistent from build to deploy instead of passing between rotating hands.
We ship the exact kind of site Astro is built for - honestly labelled
Our production work is real, custom web builds - a professional-training platform rebuild and a financial-services site - and the first is the exact shape Astro is made for: a large course catalog turned into a fast, filterable experience, templated per-city landing pages, fast static delivery, and a headless-CMS editing path a non-technical marketing team runs itself. You can see the training platform and the financial-services site we actually built, described for what they are and never relabelled as Astro projects, because they weren't. What they prove is one true thing: this team ships fast, content-driven web that holds up in production. The Astro-specific proof is not a borrowed case study - it is the current-standard depth on this page and the standard, open Astro code you would own outright.
How we build a content site on Astro - static-first, JavaScript where it earns its place
The first decision is whether Astro is even right for the job. From there it is static HTML by default, interactivity added island by island, and performance built in rather than bolted on - and most content sites go from kickoff to live in weeks, not months.
Decide if it is Astro at all
firstWe start by deciding whether your project is a content site. If it needs to behave like an app we route you to Next.js, if it is editor-run content to WordPress, if it sells products to Shopify or WooCommerce. Choosing Astro is a call we are willing to argue against.
Model the content, typed
before layoutBefore layout, we define the content schema through the Content Layer - collections, field types and the source, whether Markdown and MDX, a headless CMS or a database - so the data contract is explicit and content mistakes become build errors, not production bugs.
Build static-first, add islands
in sprintsThe site is static HTML by default. Interactivity is added one island at a time, each with a named client directive, so every byte of shipped JavaScript maps to a specific, reviewable decision. Server Islands go in only where a slot genuinely must render per request.
Performance and SEO by construction
throughoutSemantic HTML, built-in image optimization, View Transitions and prefetch are part of the build from the start, not an audit at the end, and we build to pass Core Web Vitals. We measure on your delivered pages after launch - the number that matters is yours, not one printed here.
Deploy, hand over, migrate
on deliveryWe pick the rendering mode per route and the adapter to match your infrastructure, wire a CMS as the source if editors need one, and hand over a documented codebase you own. Moving off Gatsby, Jekyll, Hugo or a heavy WordPress theme is a scoped lane of its own, with URLs mapped so your SEO survives.
The honest static-site framework comparison
We're stack-agnostic, so this is fair, not a pitch. All three build fast static sites - the real choice is how much you want a component model and islands versus raw templates and build speed.
| Astro | Eleventy (11ty) | Hugo | |
|---|---|---|---|
| What it is | Component-based content framework | Minimalist JavaScript static-site generator | Go-based static-site generator |
| Best for | Content sites that want components and light interactivity | Lean, flexible static sites across many template languages | Very large content and docs sites |
| Interactivity | Islands - React, Vue or Svelte where needed | Add your own JavaScript by hand | Minimal - templates only, JavaScript by hand |
| Components & templating | Astro components plus framework islands | Nunjucks, Liquid and more, no component model | Go templates, no JavaScript component model |
| Build speed | Fast | Fast | Fastest, even at huge scale |
| Our take | Our default for a modern content site | When you want minimal and template-first | When raw build speed at large scale leads |
Astro is our default when a content site wants a real component model and islands of interactivity; Eleventy and Hugo are strong when you want something more minimal or the fastest possible builds at large scale. One thing none of these three is: an application framework. A site that is really an app belongs on Next.js, for a site that behaves like an application, and we will tell you when that is the honest answer.
What an Astro content site costs
No quote wall. An Astro site is priced by our published web tiers - the same numbers on our pricing page and everywhere else. A content or marketing site maps directly onto them, and you always see the price before you commit.
Starter
1 week
A single-page site or landing page, live fast
Launch Sprint
2-3 weeks
Startups needing a fast, credible site
Growth Site
3-5 weeks
SMBs that want a lead engine
Commerce Sprint
4-6 weeks
DTC / e-commerce brands
MVP Sprint
6-10 weeks
Pre-seed / seed founders
How an Astro site maps to these numbers
A landing page or small marketing site sits at the Starter or Launch tier; a fuller content site, blog or docs site lands around the Growth tier. A large content platform, or a migration of an existing site onto Astro, is scoped as part of our web design and development service. And if what you need is to keep publishing and grow the site's search traffic over time, that is our organic digital marketing service, not a fresh build.
See full package details on pricing and our web development service.
Astro development, answered
What is Astro used for?
Astro is a web framework for content-driven sites - marketing sites, blogs, documentation and landing pages - where the job is to load fast, read cleanly and rank in search. Its defining idea is that a page ships as static HTML with almost no JavaScript by default, and interactivity is added only where you need it. For a site that has to behave like an application, a framework like Next.js is the better fit, and we will point you there.
Should I use Astro or Next.js?
It comes down to content versus app. For a mostly-static content site - marketing, blog, docs, landing pages - Astro ships less JavaScript and is the leaner choice. For interactive, data-driven or authenticated products that behave like an application, Next.js is the stronger fit. We build both and recommend Astro when a site is content-only and Next.js when it needs to behave like an app, which is also why our own site runs on Next.js.
Is Astro good for SEO?
Yes, for content sites. Astro renders real static HTML that a search crawler reads directly, with semantic markup as the baseline rather than something bolted on afterwards, so the content exists without a client-side render step. We build to pass Core Web Vitals as a method, measured on your pages after launch. We claim SEO as engineering structure, never as a ranking guarantee.
Is Astro production-ready, and is it a risk now that Cloudflare owns it?
Yes to production-ready, and no, the acquisition is not a lock-in risk. Astro is used in production by large brands and hundreds of thousands of developers for content and marketing sites. In early 2026 the Astro team joined Cloudflare and now work on Astro full-time with more resources behind it, and Astro stayed MIT-licensed, open-source and platform-agnostic - it still deploys to any host, not just Cloudflare, and keeping it open to every platform was a stated condition of the deal. You get a mature framework with a bigger backer, not a proprietary trap.
Does Astro support React?
Yes. Astro is UI-framework-agnostic, so an interactive island can be a React component - or Vue, Svelte or Solid - mounted inside an otherwise static Astro page. If you already own a React widget, it can drop in as an island rather than being rebuilt. Our own site is built in React, so this is an area we genuinely understand, though our site itself is Next.js, not Astro.
Can Astro use a headless CMS?
Yes. Astro reads a headless source - such as Sanity, Strapi, Contentful, or WordPress used headless - through the Content Layer, and renders it as fast static or hybrid output. The CMS is where non-developers edit and Astro is the presentation layer. If day-to-day editing by a non-technical team is the whole point, we would often route you to WordPress directly instead.
Is Astro a good choice for a blog, marketing site or docs site?
Yes - that is exactly its lane. Content collections with typed frontmatter and MDX make a blog fast and maintainable as the archive grows; marketing and landing pages ship as fast static HTML with a single island where interactivity is needed; and documentation sites can use Starlight, Astro's documentation-site toolkit, for search and navigation that stay quick across hundreds of pages.
How much does an Astro website cost?
We publish fixed tiers instead of a quote wall: Starter from $300, Launch Sprint from $1,500, Growth Site from $4,000, Commerce Sprint from $7,000, and an MVP Sprint from $12,000. A content or marketing site on Astro maps directly onto the lower tiers - a landing page or small site at Starter or Launch, a fuller content, blog or docs site around Growth. A larger content platform or a migration is scoped as part of our web development service. No hourly rates, no mystery pricing.
Does this website run on Astro?
No, and we will not pretend it does. This site is a static Next.js and React build - it shares the same npm, Node and TypeScript ecosystem Astro lives in, and Astro islands can be React, which our site is, but it is Next.js, not Astro. A pure content site on Astro would actually ship even less JavaScript than ours does, because that is Astro's default and our site is a growing platform, not pure content. The proof on this page is the engineering depth and the standard, open Astro code you would own outright.
Do I own the Astro code you build?
Yes - 100% ownership. It is standard, open Astro on mainstream open-source packages, in your repository and deployed to a host of your choice, so the code, the content collections, the configuration and the IP are yours from day one, and any competent Astro developer can take it over. Astro is MIT-licensed and platform-agnostic, so you are not locked into us or into any single hosting vendor.
Ready to build a fast content site?
Get a fixed-price quote for a content, marketing or docs site on Astro - static-first, almost no JavaScript, and yours to own outright. And if it turns out your site needs to behave like an app, we will tell you that too.