Web agencies are building their own websites in Astro, and increasingly they’re building client sites in it too. Some of that is genuine fit — Astro is an excellent tool for fast, content-heavy sites. Some of it is developers using their preferred framework regardless of whether it’s the right choice for your project. Here’s what you need to understand before you sign a contract for an Astro-built site.
Why Agencies Are Moving to Astro
The pitch is straightforward: Astro sites are fast, score well on Core Web Vitals, and have low ongoing hosting costs. For an agency’s own portfolio site, that translates to credibility. A web agency with a Lighthouse 97 on their own homepage is demonstrating competence in a way that an agency running Elementor with a 44 score cannot.
For agency client sites, the performance story is the same — and it’s legitimate. Astro performance benchmarks for SEO show that 60% of Astro sites pass Core Web Vitals compared to 43% for WordPress. That’s a real structural advantage for sites where organic search traffic matters.
Agencies also benefit from Astro’s developer experience. The component model is clean. Deployments are fast. Version control is straightforward. A developer maintaining 10 client Astro sites has a more consistent, predictable workflow than managing 10 WordPress installations with different plugin stacks.
None of that is bad for you as a client. What matters is what it means for ownership, maintenance, and your ability to operate the site independently.
The Code Ownership Question
When a WordPress agency builds your site, the assets are mostly universal: PHP files, a database, plugins with public licensing. A different developer can step in, look at the codebase, and understand it with moderate effort. The ecosystem is large enough that finding competent WordPress developers is not hard.
Astro is a smaller ecosystem. It’s growing, but it’s not WordPress-sized. A custom Astro build is specifically the code your developer wrote — there’s no plugin marketplace, no theme ecosystem, no “standard” way to build an Astro site. One developer’s Astro architecture looks different from another’s.
This matters in practice. If your agency relationship ends — they go out of business, you have a falling out, they raise rates — and you need a new developer to take over the site, you’re looking for someone who:
- Knows Astro specifically
- Can read another developer’s component architecture
- Has capacity for your project
That pool is smaller than the WordPress developer pool. It’s not a crisis-level constraint, but it’s worth knowing before you sign a contract for a custom Astro site with a boutique agency.
Ask before signing: Who else can maintain this codebase if your team is unavailable? Get a realistic answer, not a reassurance.
What You Should Own After Launch
Regardless of the framework, you should own all of these at launch. If your contract is vague on any of them, clarify before you sign:
The code repository. Your site’s source code should live in a repository (GitHub, GitLab, Bitbucket) that you own. The agency can have collaborator access; you should be the owner. If the agency holds the repository and the relationship ends, you may lose access to your own codebase.
The hosting account. Your deployment platform account (Vercel, Netlify, Cloudflare Pages) should be in your name. The agency can be a team member with deployment access. Account ownership determines who controls the site’s domain configuration, environment variables, and billing.
The domain. Your domain should be registered in your account. Not the agency’s. This is a basic client protection that some agencies still violate. Check your contract.
The CMS access. If your Astro site uses a headless CMS, your team should have admin access. The agency can have developer access for integration changes.
The analytics. Google Analytics, Search Console — your property, your credentials.
Five things. Any agency that pushes back on you owning any of these five is telling you something about how they manage client relationships.
Content Management — What Non-Developers Can Actually Do
An Astro site without a CMS is a site that requires a developer to update. This is appropriate for some clients (those with in-house developers or agency retainers) and inappropriate for others (marketing teams that need to publish blog posts on Tuesday without filing a ticket).
Agencies building client Astro sites should include headless CMS setup as a default, not an upsell. If your proposal doesn’t include it, ask explicitly: how does a non-developer on our team update a blog post?
The common CMS options for Astro sites are:
- Contentful — Enterprise-grade, $0–$300/month depending on scale, well-documented
- Sanity — Flexible, developer-friendly schema, $0–$99/month for most clients
- Storyblok — Visual editor, good for non-technical teams, $0–$90/month
- Decap (formerly Netlify CMS) — Free, Git-based, simpler interface
If the answer is “we use Markdown files in the repository,” that’s a technical team answer. It means every content edit goes through Git. For a small business without in-house developers, that’s a maintenance dependency every time you need to change a headline or add a blog post.
See Astro CMS options for non-developers for a detailed comparison of each option and what day-to-day use actually looks like.
The Maintenance Reality After Launch
WordPress maintenance has a bad reputation — rightfully, in some cases. Plugin updates that break layouts. Security vulnerabilities patched monthly. Database backups that need monitoring. It’s real overhead.
Astro sites have different overhead, not zero overhead.
What typically needs ongoing developer attention on an Astro site:
Dependency updates. Astro releases new versions regularly. Outdated dependencies accumulate security risk. A developer should review and apply updates every 3–6 months. This is roughly 2–4 hours per year.
CMS integration maintenance. If your CMS provider updates their API or changes their authentication model, your site’s integration may need updating. Rare, but it happens.
Component changes. Any visual or structural change requires a developer. Unlike WordPress, you can’t drag-and-drop layout changes in Astro. Every new section, every redesigned block, every added feature is code.
Build pipeline monitoring. Astro sites rebuild when content changes. If a build fails — usually because a dependency is broken or a CMS API connection is down — the content update doesn’t publish. Someone needs to catch and fix this.
The maintenance burden is genuinely lower than a WordPress site with plugins, but it’s not zero. And critically, it requires a developer with Astro knowledge, not a generalist WordPress admin.
Red Flags in Astro Agency Proposals
Here’s what to watch for when reviewing an Astro agency proposal:
No CMS mentioned for a client-updated site. If your team needs to update content and the proposal doesn’t specify a CMS, the answer is “you’ll file requests with us.” That’s a retainer dependency disguised as a build.
Repository in the agency’s account. Some agencies hold client code as a retention tactic. They own the repository; you need them to transfer it if you leave. This should not happen.
Vague about deployment platform. “We deploy to the cloud” means nothing. Ask specifically: Vercel, Netlify, or Cloudflare Pages, and in whose account.
No redirect handling mentioned. If you’re migrating from an existing site, redirects from old URLs to new ones are critical for SEO continuity. If the proposal doesn’t mention URL mapping and redirect setup, ask. Losing organic rankings because of missing redirects is avoidable and agencies sometimes skip it to cut scope.
Performance promises without specifics. “We’ll make it fast” is theater. Ask: what Lighthouse performance score does the proposal guarantee on mobile, and what happens at launch if it misses? Our own custom WordPress development has performance floors in the contract. Other agencies should too.
When Astro Is the Wrong Choice for an Agency Site
Astro vs WordPress for business sites covers this in detail, but the short version: Astro is the wrong choice for an agency site when:
- The client’s team needs full content independence without developer involvement
- The site has complex functionality (client portals, booking systems, WooCommerce)
- The budget doesn’t include CMS integration ($0 CMS = code-in-repository editing)
- The client will need to switch agencies frequently and wants maximum portability
WordPress’s lower technical floor is a real advantage in these scenarios, not a concession. A well-built custom WordPress site with no page builder — hand-coded templates, optimized images, no Elementor — achieves Lighthouse scores of 85–92 on mobile and costs less to hand off to a new developer. The ecosystem depth is an asset.
What a Fair Astro Agency Contract Looks Like
The scope should specify:
- Site ownership (code repository, hosting account, domain)
- CMS platform and which team has what level of access
- Performance floor (specific Lighthouse score, not “we optimize for performance”)
- Redirect handling for any migration
- Browser and device testing scope
- What’s included in warranty/support period after launch
- What’s excluded (ongoing content updates, new features, CMS training)
A 10-page Astro site with headless CMS integration should run 40–80 developer hours depending on design complexity. If a proposal is significantly below that, ask what’s not included. If it’s significantly above, ask what’s adding the time.
FAQ
Can I hand an Astro site to a different developer if I change agencies? Yes, with caveats. The Astro codebase is portable — it will run for any developer who knows the framework. The challenge is finding a developer familiar with Astro specifically and with the architecture decisions your original agency made. It’s more involved than handing off a standard WordPress site, but it’s not a major project if the code is well-organized and documented.
Should my agency’s website be in Astro? Depends on your agency’s technical capacity. If you have in-house developers or a close agency relationship, Astro’s performance advantages are real and worth the lower technical floor. If you need to manage the site independently without developer help, a well-built WordPress site is more practical.
Is Astro more expensive to build than WordPress? Per hour, developer rates are similar — the framework doesn’t change the hourly rate. Total hours can be comparable or slightly higher for Astro because CMS integration is more manual than installing WordPress plugins. A well-built custom WordPress site without a page builder takes similar time to a well-built Astro site with CMS integration. Page-builder WordPress is cheaper to build and worse to own.
What happens when Astro releases a major new version? You don’t have to update. Your site will continue to work on the version it launched with. Updates become relevant when you’re adding features that require newer functionality, or when security issues are found in dependencies. A developer can audit and update an Astro site on a 6–12 month cycle without it becoming a project.
Can Astro handle e-commerce? Basic e-commerce is possible with Snipcart or similar JavaScript cart overlays. Complex WooCommerce-style e-commerce is better in WordPress or a dedicated platform like Medusa.js. Astro is not the right choice if e-commerce is a primary function.
How do I know if an agency actually knows Astro? Ask to see 2–3 Astro sites they’ve built and launched. Ask about their CMS integration experience specifically. Ask what version of Astro they’re currently building in and what changed in recent major releases. If they know the framework, these are easy questions. If they’re learning as they go on your project, the answers will be vague.
Whether you’re evaluating an Astro proposal or a WordPress one, the ownership questions matter more than the framework. If you own the code, the hosting, and the domain, you can always switch tools later. If you don’t, the framework choice is the least of your problems. For custom WordPress development or Astro builds with explicit ownership transfer at launch, see our fixed-price packages.