Astro SEO: Why the Stack Wins on Speed and Citations

Astro is good for SEO because its defaults do most of the work for you. Pages render to static HTML, JavaScript ships only where a component needs it, and the result is fast for visitors and easy for Google and AI crawlers to read. The setup below covers what turns that architecture into a finished, ranking site: sitemaps, images, structured data and crawler access.

Quick links

• Why does Astro’s architecture help SEO?
• What does Astro do for Core Web Vitals specifically?
• How do you add a sitemap in Astro?
• How do you handle images without hurting your scores?
• How do you add structured data in Astro?
• Does Astro help you get cited by AI search?
• When does Astro’s SEO advantage matter less?
• FAQ

Why does Astro’s architecture help SEO?

Because the page a crawler receives is already finished, not something it has to wait for a browser to assemble.

Astro renders components to HTML at build time, then only adds JavaScript back in for the specific pieces that need to be interactive, an approach it calls islands architecture. A pricing table with no interactive parts ships no JavaScript at all. A booking widget on the same page ships only its own small script, isolated from everything else. Most marketing pages have few interactive sections, so most Astro pages end up close to weightless.

This matters for two separate audiences at once. Google’s crawler gets a complete document with nothing hidden behind a script it has to execute first. AI crawlers, which are far less capable of running JavaScript than Googlebot, get the same thing. We covered the underlying data in our Astro versus WordPress comparison: across seven content management platforms, Astro sites passed Core Web Vitals at a noticeably higher rate than WordPress, largely on the back of a lighter page. This post picks up from there and goes into the practical build choices that keep that advantage intact.

What does Astro do for Core Web Vitals specifically?

It removes the most common cause of a fail on each of the three metrics, without removing the need to build sensibly.

Google measures three things at the 75th percentile of real visitors, and a page has to clear all three or it does not pass: Largest Contentful Paint under 2.5 seconds, Interaction to Next Paint under 200 milliseconds, and Cumulative Layout Shift under 0.1, according to Google’s published thresholds. Here is where Astro’s defaults line up against each one:

• Largest Contentful Paint. With no client-side framework deciding what to draw, the browser can paint content the moment the HTML and its images arrive, rather than waiting on JavaScript to hydrate the page first.
• Interaction to Next Paint. Less JavaScript running on the main thread means less contention when a visitor clicks or taps something. INP problems are almost always a JavaScript problem, and Astro starts you with little of it.
• Cumulative Layout Shift. This one is not automatic from the architecture alone, it comes from the built-in Image component, covered below.

None of this makes a bad build fast. A page stuffed with heavy embeds, unoptimised images or a client component wrapped around static content can still fail on an Astro site. The difference is the starting line: WordPress fights its own weight to get to a passing score, and Astro starts near it.

How do you add a sitemap in Astro?

Install the official integration and point it at your live domain. That is most of the job.

The @astrojs/sitemap integration generates a sitemap automatically at build time. Set it up in two steps:

1. Add the integration. Run npx astro add sitemap, or install @astrojs/sitemap manually and add it to the integrations array in astro.config.mjs.
2. Set your site property. Astro needs your deployed URL, beginning with https://, in the config, or the sitemap has nothing to build absolute links from.

Once configured, Astro writes a sitemap-index.xml file plus one or more numbered sitemap files covering every static route and every dynamic route generated through getStaticPaths(), splitting automatically into further files once a single sitemap passes the integration’s configurable entry limit. It picks up every page by default, so if you have thin or duplicate pages you do not want indexed, use the integration’s filter() option to exclude them rather than leaving the sitemap to submit everything.

Server-rendered routes are the one gap: the integration cannot crawl dynamic SSR pages the way it can static ones, so a site mixing static marketing pages with an SSR app section needs to think about that section separately.

How do you handle images without hurting your scores?

Use Astro’s built-in <Image /> component rather than a plain <img> tag, and let it do the conversion and sizing work for you.

The component optimises images automatically in a few ways that map directly onto the metrics above:

• It sets width and height for you, which stops the page reflowing when an image loads and is the main lever against Cumulative Layout Shift.
• It converts images to modern formats such as WebP at build time for pre-rendered pages, without a separate optimisation pipeline.
• It applies lazy loading and async decoding by default, so images below the fold do not compete with what a visitor needs first.
• It generates responsive variants when you configure a layout, so a phone downloads a phone-sized image rather than the same file a desktop gets.

The common mistake is skipping the component for a single hero image because it is quicker to drop in a raw <img> tag. That single image is usually the Largest Contentful Paint element on the page, which makes it the worst possible place to skip the optimisation.

How do you add structured data in Astro?

Write the JSON-LD object as data and render it in a script tag from your base layout. Astro has no dedicated structured data feature, and it does not need one.

Structured data is markup that labels what a page is, in a format search engines and AI systems read directly rather than infer. Google has extended its own structured data documentation to cover how the same markup feeds its AI-driven features, not just classic rich results. Because an Astro component’s frontmatter runs on the server, you can build the schema object there and inject it with a plain <script type="application/ld+json"> tag, and it lands in the HTML the same way any other server-rendered content does. Worth having, roughly in order of value:

• Organization schema on the homepage, naming the business, logo and social profiles.
• Article schema on blog posts, with an author and a published date.
• FAQPage schema on any page carrying a genuine FAQ section.
• BreadcrumbList schema once your navigation has real depth.

Check what you have deployed with Google’s Rich Results Test, against the live URL rather than a local build. Since Astro’s output does not vary between dev and production the way a client-rendered app’s can, what you see locally is a closer match to what ships, but testing the real URL is still the only way to be certain.

Does Astro help you get cited by AI search?

Yes, and for the same structural reason it ranks well: the page a crawler fetches is already the finished article.

Vercel’s analysis of crawler behaviour found that GPTBot, ClaudeBot and PerplexityBot fetch the initial HTML of a page and largely do not execute JavaScript on top of it. A site that relies on client-side rendering to fill in its main content can look close to blank to those crawlers even though it looks complete in a browser. Astro’s default output sidesteps that entirely, since the content a visitor reads is the same content that exists in the raw HTML before any script runs.

Being readable is only step one. Being worth citing is a separate, content problem: answer-shaped headings, a direct answer near the top of each section, and claims backed by a real source. Architecture gets you in the room. What you write once you are there still has to earn the citation.

When does Astro’s SEO advantage matter less?

When the page is not a page at all. Astro’s advantage comes from rendering finished HTML, and that has nothing to offer a screen that is an application in its own right: a logged-in dashboard, a live configurator, anything personalised per visitor that search engines were never going to index anyway.

For that kind of screen, the rendering choice is a different conversation, and one we cover properly in our piece on Next.js SEO. The short version: Next.js can match Astro’s SEO outcomes on its server-rendered routes, but only if you deliberately choose server rendering and resist reaching for a client component out of habit. Astro removes that decision by making the light option the default. For a marketing site, a blog or a case study library, that is exactly the profile where Astro’s defaults do the most good, and where there is the least reason to reach for anything heavier. If your current site is WordPress rather than a JavaScript framework, the comparison runs slightly differently, and we lay that one out in is WordPress good for SEO.