Building a website with Astro: a practitioner's guide for businesses (Astro 7, 2026)

A few times a year I hear the same sentence from a client, just phrased differently: “I want a site that won't collapse after the next plugin update and won't take five seconds to load on a phone.” More and more often I answer with one word: Astro.

Not because it's trendy. Our company GitHub currently has ten projects built on Astro: my own site, the Kaminski.link agency site, client service sites, topical blogs and a small online shop with a cart and customer accounts. The oldest ones run on Astro 5, the newest on Astro 7. Dashboards and apps with login we build with something else, and I'll write about that too, because an honest answer to the question “should it be Astro” is sometimes “no”.

This text is long because the topic is broad. If you run a business and are wondering whether to order a site built in Astro, read the chapters about when it makes sense, about the CMS, costs and migration. If you're a technical person on the client side, or a developer who wants to see what this looks like in production rather than in a tutorial, you'll also find configuration details here, mistakes I made myself, and things the documentation only whispers about.

What Astro is and what changed in it in 2026

Astro (astro.build) is a framework for building content-first websites: company sites, service pages, blogs, knowledge bases, landing pages. Its core idea is simple: the browser gets ready HTML, and JavaScript only shows up where something actually needs to move. A mobile menu, a calculator, a form with validation. Everything else is a plain document that shows up instantly.

Sounds like a throwback to 2005-era websites, and in a way it is, just with 2026 tooling. You write components, you get TypeScript, you can drop in a React, Vue or Svelte component wherever you need one. At the end of the day you still get lightweight HTML.

More happened around Astro in 2026 than in the previous two years combined:

• On 16 January 2026 the Astro team joined Cloudflare. The framework stayed on the MIT license, with open source code and a public roadmap, and the creators announced it will keep supporting deployments on any platform, not just Cloudflare.
• On 10 March 2026 Astro 6 came out: a new dev server based on Vite's Environment API (locally you get the same runtime as in production), a built-in font API, stable Content Security Policy and stable Live Content Collections, meaning content fetched the moment someone visits the page, no rebuild needed.
• On 22 June 2026 Astro 7 came out: the compiler rewritten from Go to Rust, Markdown and MDX processing also moved to Rust, Vite 8 with the Rolldown bundler. According to the team's own benchmarks, builds are 15 to 61% faster. On top of that, stable route caching and so-called advanced routing, meaning full control over how a request moves through the application.
• In September Astro 7.3 came out, and on 28 September Cloudflare released EmDash 1.0, an open CMS built on Astro. I'll come back to it in the CMS section.

For a business owner, one of these facts matters the most: Astro is now backed by a large, publicly traded company that has a real interest in keeping this framework alive. When you're picking a technology for the next five years, that matters. Astro stopped being a curiosity for developers a while ago. In the State of JavaScript 2025 survey it had the highest user satisfaction among meta-frameworks, and weekly npm downloads grew in 2025 from around 360 thousand to over 900 thousand.

How Astro renders a page, explained without the jargon

This is the part I end up explaining to clients most often, because everything else depends on it: hosting cost, security, speed, and what you can actually do on the site.

Every page in Astro can work in one of three modes.

Prerendered (static). The page gets generated once, at publish time. A ready-made HTML file lands on the server. When someone visits, the CDN just sends it, no database, no calculations. Most business sites should work this way: offer pages, about page, portfolio, articles.

Rendered on request (SSR). The page gets assembled the moment someone visits, either on the server or at the edge. You need this where content depends on the user or changes all the time: cart, customer account, search results.

Server islands. A hybrid I really like. The whole page is static and fast, and one fragment, say “available slots this week” or a price recalculated for a logged-in customer, gets fetched separately. The rest of the page doesn't wait for that fragment.

On top of that there are browser-side islands, meaning interactive components. This is where Astro gives you control most sites lack: you decide when a component should “wake up”. Right away, once the browser is idle, or only when the user scrolls to it.

---
import Calculator from '../components/Calculator.tsx';
import Slots from '../components/Slots.astro';
---
<!-- the rest of the page is plain HTML -->
<Calculator client:visible />

<Slots server:defer>
  <p slot="fallback">Checking available slots…</p>
</Slots>

In practice it looks like this: the service page is prerendered, the pricing calculator only loads its JavaScript once someone scrolls to it, and the slots module gets fetched from the server. The homepage pays for none of that.

Important: you set the mode per page, not for the whole site. You can have a project that renders on the server by default, and prerender specific pages with a single line (export const prerender = true), or the other way round: a static site with a handful of dynamic routes. Kaminski.link runs in server mode, most client sites are static. Getting this balance right is one of the first decisions on a project, and one of the ones that most affects costs down the line.

When Astro is a good choice and when I advise against it

The most damage in this industry comes from contractors who do everything in one technology because it's the only one they know. The WordPress agency will recommend WordPress, the Next.js agency will recommend Next.js. I have all three approaches in my portfolio, and here's how I split projects.

I go with Astro when:

• it's a company or service website where speed, SEO and a clear offer matter,
• the site has a lot of content: a blog, a guide, a knowledge base, a glossary, hundreds of articles,
• you need many similar data-driven subpages: local pages for cities, a service directory, product cards, case studies,
• the site needs to be multilingual and work properly, with hreflangs and sensible URLs,
• it's a landing page for a campaign, where every tenth of a second of load time affects your cost of acquiring a customer,
• the client is tired of updating plugins, patching holes and paying for hosting that "has to be powerful, because WordPress".

I advise against Astro when:

• you're building an application: a client panel, a booking system with complex logic, a SaaS, a dashboard. Here we go with Next.js or a dedicated backend. Astro can do it, but you'll be fighting the framework instead of using its strengths,
• there's someone at the company who likes to "click" the site together in a visual builder like Elementor and move sections around without a developer. You can get close to that experience, but it's a different philosophy, and that needs to be said before the project starts, not after,
• you need a large shop with thousands of products, warehouse integrations, marketplaces and dozens of delivery methods. A ready-made e-commerce platform will do it cheaper. We built a small shop in Astro and it works great, but that was a conscious choice for a specific case,
• the site works, makes money, performs well, and nobody at the company has a problem with it. In that case, migrating just for the sake of the technology is throwing money away.

I say that last point straight to clients' faces in meetings, and it costs me some jobs. I'd rather lose the job than end up with a client who asks a year later what exactly they paid for.

Speed: what the data says, not the marketing

Every agency "running on Astro" writes about scoring 100 in PageSpeed. I'd rather show what the data from real websites says.

HTTP Archive publishes a Core Web Vitals report by technology, combining real Chrome user visit data (CrUX) with data on what sites are built on. In a ranking covered in May 2026 by Search Engine Journal, Astro had the lightest median page weight of all the compared platforms: around 1.65 MB, compared to around 2.76 MB for WordPress. Around 67% of Astro sites had good Core Web Vitals, versus around 49% of WordPress sites, which came last.

Notice one thing "Astro" agencies don't mention: Astro wasn't first in that ranking. Closed platforms like Duda, Wix and Shopify ranked higher. Why? Because there the vendor controls the whole stack and the user has no way to break it. With Astro you can build a site that loads in half a second, and you can build one that loads in three. The framework gives you a good starting point. The result depends on who builds it.

Let me remind you of the thresholds, because they're often confused. Google evaluates Core Web Vitals based on real user data, at the 75th percentile of visits:

• LCP (how fast the main content appears): good up to 2.5 s,
• INP (how fast the page responds to a click): good up to 200 ms,
• CLS (whether elements jump around while loading): good up to 0.1.

A Lighthouse score in the browser tab is a lab test. Nice to have, but it's not what decides anything. The Kaminski.link agency site scores 86–91 on mobile in Lighthouse, not 100. I don't chase Lighthouse points. I chase Core Web Vitals thresholds in real user data, and I make sure every script on the site has a business reason to exist. Analytics, a cookie consent banner or a company font cost a few points, and they're usually worth it.

What most commonly breaks speed on an Astro site:

1. Third-party scripts. Tag manager, pixel, chat, map, review widget. Any one of them can add more JavaScript than your entire site. Astro can't help here, because it's not Astro's code. What helps is discipline: load after interaction, after consent, or not at all.
2. Components "woken up" unnecessarily. A developer used to React drops the entire header in as a component with client:load, and suddenly the site ships 150 KB of JavaScript just to open a menu. A mobile menu can be built in a dozen or so lines of plain script.
3. Images dumped into the public/ folder. Files from that folder go to the server with no optimisation at all. Images imported through Astro's <Image /> and <Picture /> components get converted to AVIF/WebP, with generated sizes and srcset attributes. Since version 5.10 there's a stable layout option that handles responsiveness for you.
4. Fonts. Three families, each in five weights, loaded from an external server. Since Astro 6 there's a built-in Fonts API that fetches fonts, hosts them locally, and generates fallbacks and preloads. This is also a GDPR matter, since a font loaded from Google's servers without consent is a topic that keeps coming back.

Content architecture: Astro's underrated advantage

If I had to name one reason I pick Astro for content sites, it wouldn't be speed. It would be Content Collections.

In short: every content type on a site (article, service, city, case study, team member) has a defined schema. What fields are required, what type they are, what values are allowed. If someone adds an article without a meta description, or with a typo in the category, the site won't build. The error shows up before publishing, not in Search Console three weeks later.

A simplified snippet, similar to what we use on the agency site:

// src/content.config.ts
import { defineCollection } from 'astro:content';
import { glob } from 'astro/loaders';
import { z } from 'astro/zod';

const services = defineCollection({
  loader: glob({ pattern: '*/index.mdoc', base: 'src/content/services' }),
  schema: z.object({
    title: z.string(),
    metaTitle: z.string().max(60),
    description: z.string().min(70).max(160),
    noindex: z.boolean().default(false),
    locale: z.enum(['pl', 'en']).default('pl'),
    alternateSlug: z.string().optional(), // address of the version in the other language
  }),
});

export const collections = { services };

From an SEO point of view this is a huge difference. The length of the meta description is enforced by code, not by the copywriter's memory. Every page has a noindex field, so the decision "should this page be in Google" is stored with the content, not buried in a plugin's settings. And the alternateSlug field solves a problem that once cost me over two hundred broken links. I'll describe it in the SEO chapter.

Watch out for pages generated from data. Astro makes it very easy to create lots of similar subpages: one template, a list of cities, done. And this is the trap I fell into myself on the agency site. An audit showed that our city pages overlapped in content by almost half. A changed town name and two paragraphs are not, to Google, separate, valuable pages. The framework will build you a hundred subpages in a minute. It won't build you a hundred reasons for each of them to exist. That's why today, with local pages, I start by asking what unique data I have for a given city: case studies, reviews, directions, the specifics of the local market. If I have nothing, the page doesn't get made.

How the client edits content: choosing a CMS

Every client asks this question, and they are right to, because the answer decides whether the site stays alive or dies right after launch. Astro has no built-in panel like WordPress. The panel gets connected separately, and that is actually an advantage, because you can pick one that fits the people who will use it.

Options I use or seriously consider:

Markdown files in the repository. Content sits in files next to the code, changes go through Git. Great for developer sites, documentation and companies where content changes once a quarter and a developer changes it. For an average client: no.

Keystatic. Our default choice for business websites. The panel runs in the browser, under the site's own address, and saving makes a commit to the GitHub repository. There is no separate database, no subscription, and the content stays with the client in files. We use it in most projects, including the agency's own site. Two practical notes: the project README has called it “experimental” for years, and in July 2026 the 0.6 line came out and changed the dependencies. You need to pin versions and update deliberately, not on autopilot.

Sanity. A hosted headless CMS with a very good editor, preview and roles. It works well when there is a lot of content, several people publish, or the same content goes to the website, the newsletter and an app. The free plan is enough for many companies. With a bigger team you need to work out the cost of seats.

Storyblok and similar visual CMSs. Closest to the “I click and see what I'm changing” experience. Good for marketing teams who want to assemble landing pages from blocks. More expensive, so I only factor it in when the client will actually use it.

WordPress as a panel (headless). Sometimes the client knows WordPress and does not want to switch. In that case WordPress stays just as a writing panel, and Astro generates the site. Live Content Collections in Astro 6 make this easier, because content can update without a rebuild. The downside: you still have to maintain WordPress, even if it is tucked away and much more secure.

EmDash. A new, open CMS from Cloudflare built on Astro, version 1.0 released on 28 September 2026. It has a plugin registry with isolation, an MCP server for AI agents, and since July it has been running the Cloudflare blog. It looks promising and I will definitely test it. But I am not putting a product that is a week old into a client site meant to run for years. I will come back to this paragraph in six months.

My rule when choosing is simple: I pick the CMS for the person who will use it, not for the developer who implements it. I ask who in the company will be adding content, how often, whether they need a preview before publishing, whether someone has to approve it, and whether the site has language versions. Only from those answers does the right tool emerge.

Technical SEO in Astro: the checklist I run on every project

Astro is good for SEO by design, because the search engine gets finished HTML with content in it, not an empty page waiting for JavaScript. The same goes for AI systems that read pages to answer questions. I wrote about that separately in SEO for ChatGPT and AI Overviews. But “good by design” doesn't mean “done”. Here's the list I go through on every build.

1. One canonical address per page. In the config I set site and decide on the trailing slash (trailingSlash). On the agency site we use always, on one client's site never. Both choices are fine, as long as the version without the slash (or with it) redirects 301 to the right one, the canonical tag points to the same address, and so does the sitemap. The worst case is both addresses returning a 200.

2. A sitemap without junk in it. The @astrojs/sitemap integration dumps everything it built into the sitemap by default. I filter out the search page and pagination pages, and pages marked noindex shouldn't end up there at all. An example from one of our projects:

sitemap({
  filter: (page) => {
    const { pathname } = new URL(page);
    const last = pathname.split('/').filter(Boolean).at(-1);
    const isPagination = pathname.startsWith('/blog/') && Number.isInteger(Number(last));
    return pathname !== '/search' && !isPagination;
  },
}),

Another thing I found during an audit: the sitemap had addresses that already redirected somewhere else. Google got a contradictory signal: “index this”, and under that address a redirect. These days the sitemap generator skips addresses from the redirects list, so this bug has no way of coming back.

3. Multilingual setup and the language switcher. Astro has built-in i18n routing. I usually set Polish as the default with no prefix in the address (prefixDefaultLocale: false), and other languages with a prefix, e.g. /en/. A trap I fell into myself: the language switcher built the English version's address as /en/ plus the Polish slug. The page “/ile-kosztuje-strona/” got a link to “/en/ile-kosztuje-strona/”, which doesn't exist. Multiply that by every subpage and every blog post. The audit turned up over two hundred internal links leading to a 404, most of them because of the switcher. The fix: the equivalent in the other language is stored in the content itself (the alternateSlug field from the schema above), and the switcher takes the address from the data instead of gluing it together itself. On top of that, hreflang tags in the header and in the sitemap, which the sitemap integration can generate with alternate language versions.

4. Redirects under control. During migrations and structure cleanups there are a lot of redirects. On Cloudflare we keep them in a _redirects file, and Astro also has its own redirects option in the config. A lesson from real life: a redirect rule can shadow an existing page. We had one old rule sending a service subpage's address to a blog category, even though the subpage itself existed normally in the project. Nobody noticed, because the page “worked”. That's why after every major change to redirects I crawl the whole site and check every internal link.

5. Structured data. JSON-LD generated in the layout from the same data as the content: Organization or LocalBusiness on the homepage, Article with an author and dates on posts, BreadcrumbList everywhere, FAQPage wherever there's a questions section. Once the content has a schema, structured data stops being manual work.

6. Open Graph images. I generate them statically at build time, separately for each page. That way a link pasted on Facebook or LinkedIn gets its own image with a title, not a logo in a bad crop.

7. A real 404 status code. The error page should return a 404 status, not a 200 with the words “not found” on it. In Astro a 404.astro file is enough, but with non-standard hosting configs I check this with a tool, not by eye.

Security: “static HTML has no vulnerabilities” is only half true

I used to write myself that a static site has no security vulnerabilities. In the purely static version that's almost true: there's no database to inject a query into, no admin panel to guess a password for, no plugins with holes in them. The attack surface is genuinely small.

But a modern Astro site is rarely a hundred percent static. Once server mode enters the picture, you get code that runs on the server, and with it, real vulnerabilities. An example from this year: in April 2026, CVE-2026-41321 was published for the Astro adapter for Cloudflare. The image processing endpoint followed redirects and could be exploited to make requests to addresses outside the allowed list (an SSRF attack). This was actually an incomplete fix for an earlier, very similar bug in a neighbouring piece of code. On the agency site we don't use on-the-fly image processing, so we simply disabled the /_image path from being handled by the worker, and we generate images ahead of time, at build. Less code on the server means fewer places to hit.

The lesson is this: with an Astro site you also need to follow security advisories and update dependencies. The difference is you do it a few times a year in a controlled way, not every week in a panel with thirty plugins.

Content Security Policy, the header that can switch off your analytics. CSP tells the browser where a site is allowed to load scripts from and where it can send data. It's one of the best defences against injected foreign code. Since Astro 6 there's a stable API that calculates script and style hashes itself and assembles the header. On the agency site we generate the policy in middleware, with a one-time key (nonce) for every request.

And here's the story I tell everyone who implements CSP. For long weeks, Google Analytics 4 on the agency site showed practically zero visits. The site worked, the forms worked, Search Console showed clicks from Google. The culprit was the CSP policy: it allowed sending data to *.google-analytics.com domains, but GA4 today also sends measurements to analytics.google.com and www.google.com. The browser politely blocked every event. Nobody noticed the error, because CSP errors only show up in the developer console.

Conclusion: after every CSP change I open the site in a browser, accept the cookies, and check the network tab to see if requests to analytics and pixels go through. And a day later I check GA4 to see if the data is actually there at all. A secure site with no traffic data is a site where you're making decisions blind.

Forms, integrations and dynamic bits

The most common argument against Astro goes like this: “on WordPress a contact form is a plugin and five minutes.” True. On Astro it's an hour of work. Except that hour gives you a form you fully control.

Astro Actions (available since version 4.15) are server-side functions with built-in validation. The HTML form sends data, the action checks it against a schema (valid email, checkbox ticked, field filled in), and only then does something with it:

// src/actions/index.ts
import { defineAction } from 'astro:actions';
import { z } from 'astro/zod';

export const server = {
  inquiry: defineAction({
    accept: 'form',
    input: z.object({
      name: z.string().min(2),
      email: z.email(),
      message: z.string().min(20),
      consent: z.boolean(),
    }),
    handler: async (data) => {
      // send email, save to CRM, notify on Slack
    },
  }),
};

What happens next with that inquiry is my favourite part, since automating processes is what I do day to day. A form submission can go straight into a CRM with a salesperson already assigned, send the client a confirmation with a callback time, and ping the team. Not through three plugins from three different authors, just a few dozen lines of code or a webhook to a tool like n8n. The email goes out through a transactional email provider rather than the server's mail() function, so it lands in spam far less often.

Sessions (stable since Astro 5.7) let you keep user state between requests: a cart, being logged in, a selected branch of the company. Official adapters, including the one for Cloudflare, set up the default session store on their own.

A shop built in Astro? We built a small online shop entirely in Astro in server mode on Cloudflare: cart, registration, login, customer account, orders, category and product pages. A shop like that makes sense when the catalogue isn't huge, the delivery rules are simple, and the client cares about speed and not paying a platform subscription. With a few thousand products and integrations with wholesalers, I'd choose differently. It's a good example of how the line between “a website” and “an application” isn't drawn by technology, but by scale and how much business logic you need to maintain.

Hosting and maintenance costs for an Astro website

You can host a static Astro site pretty much anywhere. We go with Cloudflare, and it's not just because Astro is now part of that company.

A few facts worth knowing before anyone starts talking about “free hosting”:

• On Cloudflare Workers, requests for static files are free and unlimited. If a site is fully prerendered, hosting really does cost zero złoty.
• Requests handled by server-side code (SSR, forms, server islands) are capped at 100,000 a day on the free plan. For a company website that's usually plenty, but for a store or a high-traffic site you need to do the math.
• Since March 2026, the official Astro adapter for Cloudflare supports Workers, not Cloudflare Pages. Cloudflare recommends Workers for new projects. Older projects on Pages still work, but you'll need to plan a move at the next major update.
• You don't have to use Cloudflare. Astro runs on Netlify, Vercel, and on a plain Node.js server. On one client's site we have a setup where the same code builds for Cloudflare or for Node, depending on the environment. It's a decent safeguard against depending on a single provider.

Things that actually cost money in upkeep: the domain, business email, maybe a paid CMS plan, an email sending provider if you have a lot of forms, uptime monitoring. And developer time.

Not updating plugins doesn't mean there's no maintenance. This is the most important paragraph in this section. Astro moves fast. About a year and a half passed between version 5 and version 7, and along the way there were plenty of changes that need to be carried over into a project: Node.js 22.12 or newer required, the move to Zod 4, removal of the old content collections API and Astro.glob(), changes to the Cloudflare adapter. The new Rust compiler in Astro 7 is stricter: an unclosed HTML tag that the old compiler used to quietly fix now breaks the build. The Astro DB package was removed in version 7, so anyone who used it has to switch to something else, like Node's built in SQLite or Drizzle.

Some of our projects, including this site, still run on Astro 5 and run fine, because an old version doesn't suddenly stop working. But I know that moving to 7 is a few hours of work per project, not one click. That's why in every quote I spell out exactly what post-launch support covers, and I suggest updating to the new version once a year, on a planned date, with testing. For the client that's a predictable, small cost instead of an emergency fix when something breaks.

Migrating from WordPress to Astro without losing Google rankings

I already wrote about how I moved my own site off WordPress and what surprised me along the way, in the piece on migrating from WordPress to Jamstack. Here I'll focus on what I actually do when migrating a client's site, where the stakes are Google traffic someone has been building for years.

1. Inventory of URLs. Before the first line of code gets written, I collect every URL of the old site: from the sitemap, from a crawl, from Google Search Console (pages with impressions over the last 16 months), from external links. There are usually URLs the client didn't even know about: old campaigns, PDF attachments, tags, author archives.

2. A decision for every single URL. It stays as is, it gets a 301 redirect to a new address, or it disappears (and then gets redirected to the closest thematic match, not dumped on the homepage). Wherever possible, I keep the existing URLs. The best redirect is the one you didn't need.

3. Moving content and data. I pull content out of WordPress through the REST API and turn it into files or entries in the new CMS. Along with the content I move titles and meta descriptions (from Yoast or Rank Math), image alt texts, publication dates and authors. Content that Google already knows and likes shouldn't change just because the technology underneath it did. There's time to fix up the copy after the migration, once you can see the rankings held.

4. Rebuilding functionality. Forms, newsletter, calculators, maps, integrations. I list every feature of the old site and check each one off on handover. Most commonly forgotten: redirects and scripts added ages ago by some plugin everyone has forgotten about.

5. A test version kept away from Google. The new site runs on a test address, blocked from indexing. There I run a crawl, check the redirects against the list, check structured data, Core Web Vitals, analytics with cookie consent, and CSP.

6. Switch over and watch closely. After launch: submit the new sitemap in Search Console, check the most important URLs with the inspection tool, then for 4 to 8 weeks watch the indexing report, 404 errors and rankings for key phrases. Small wobbles in the first weeks are normal. A lasting drop means something went wrong, and you need to find it, not wait it out.

A migration done well is boring. A migration done badly can cost you half your traffic for half a year. The difference in cost between the two is usually a few extra days spent on inventory and testing.

How much does an Astro website cost

Short answer: usually a bit more than a site built on a ready-made WordPress theme, and usually cheaper to maintain over the following years. The price difference comes from the fact that in Astro you don't assemble a site from ready-made blocks, you design and code it.

The prices are the same as in the quote configurator on Kaminski.link. All amounts are net:

• Landing page for a campaign or a single service: from PLN 1,990, plus PLN 600 with a CMS.
• Company website with a CMS: from PLN 3,900 for five subpages, each additional subpage is PLN 250.
• Blog: PLN 500. Each additional language version: PLN 1,200.
• Online shop: from PLN 6,900.
• Projects with server-side logic (client area, integrations with a CRM or booking system): from PLN 9,900, final quote after a spec.
• Migration from WordPress with SEO preserved: the price of the new site plus the work on the URL inventory, redirects and moving content. I quote that part after reviewing the current site, because it depends mainly on the number of URLs and features to recreate.

Example: a company website with ten subpages, a blog and an English version comes to 3,900 + 5 × 250 + 500 + 1,200 = PLN 6,850 net. The configurator shows a range around that figure, and I give the exact price after we talk.

Beyond these amounts, the cost goes up the most with integrations with external systems, migrating a large volume of content, an extensive CMS with preview and roles, and many different page layouts instead of a few repeatable ones.

I wrote more about what makes up the price of a website regardless of technology in the article on website costs in 2026.

What an Astro website project looks like with me

I'll describe the process, because for a lot of clients that matters more than the technology.

1. Conversation. I ask about the goal of the site, where clients come from, who in the company will be changing content, and what doesn't work on the current site. Often it's already clear at this point that Astro isn't needed, and I say so.
2. Audit of the current site, if there is one. Traffic, keywords, indexing, speed, analytics. That's the basis for deciding what to carry over and what to leave behind.
3. Specification and content model. What content types, what fields, what URLs, what integrations. This is the step most contractors skip, and it's the one that determines whether the site can be expanded in a year without rewriting it.
4. Graphic design based on real content, not lorem ipsum.
5. Implementation with a test version available to the client from the first days, not at the end.
6. Pre-launch testing: Core Web Vitals, crawling and links, redirects, structured data, analytics with consent, security headers, forms tested on real inboxes.
7. Launch and 30 days of monitoring in Google Search Console and analytics.
8. Ongoing care: security updates, yearly upgrade to the new Astro version, site development.

A company website usually takes 3–6 weeks from spec approval, a landing page 1–2 weeks, migrating a larger site 4–10 weeks. Most of the time, it's not the code that affects the schedule, it's when the content is ready.

Most common questions

Is an Astro site better for SEO than a WordPress site?

Technology alone won't rank your site. Astro gives you a better starting point: lightweight HTML, fast loading, full control over code and metadata. But weak content on a fast site is still weak content. I see the biggest gains with companies whose previous site was slow or technically neglected.

Will I be able to edit the content myself?

Yes, if the project includes a CMS. I pick it based on the person who will use it. Changing text, adding an article or a project to your portfolio takes a few minutes in the panel, no coding needed.

What if Cloudflare changes its policies or Astro stops being developed?

Astro is MIT licensed, so the code stays open regardless of who owns the project. An Astro site can be moved to another hosting provider, and the content, especially in file-based CMSs, stays with you. That's less risk than closed platforms, where the site only exists with one provider.

Astro or Next.js?

A content site: Astro. An app with logins, a dashboard and lots of interaction: Next.js. When a project needs both, I often build the marketing part in Astro and the app separately. That way each part uses the technology it's best suited for.

Is hosting an Astro site really free?

For a fully static site on Cloudflare: yes, you only pay for the domain. With server-side elements, the free plan has limits that are rarely a problem for a typical company site. I check them before launch anyway.

How long does building an Astro site take?

A landing page: 1-2 weeks. A company site: 3-6 weeks. Migrating a bigger site: 4-10 weeks. Preparing the content usually takes the most time.

Can I take over an Astro site built by someone else?

Yes, if you have access to the code repository and the hosting account. I always start by reviewing the code, the Astro version and the dependencies. If the previous developer never handed over the repository, that's the first thing to sort out before you pay for anything else.

Is Astro suitable for a site with AI, a chatbot or a search function?

Yes. A chat widget or search box gets added as an island, which only loads when it's needed, so it doesn't slow down the rest of the site. Server-side logic is handled by actions and endpoints.

Astro isn't magic. It's a well-designed tool that, in the hands of someone who understands how search engines, browsers and the client's business work, produces a site that's fast, secure and cheap to maintain. In the hands of someone who copied a template off the internet, it produces a site like any other, just harder to edit.

If you're wondering whether Astro makes sense for your business, or you want to move your site off WordPress and you're worried about your Google rankings, get in touch. I'll start by checking what you have now. Sometimes I'll tell you to leave it alone, and that's a good answer too.