Islands, content collections, schema, vitals
Check what your Astro site ships, island by island.
You get one score out of 100 for your Astro site, with the evidence behind each of eight pillars, read from the pages you ship. The assessment checks your headers, markup, schema and script weight. It can't see your analytics, your logins or your field data. And that limit is deliberate (a crawler never gets those either). You get only what a crawler sees on your site.
On this page 8 sections
- 01Is Astro good for SEO?
- 02What do islands mean for crawlers and Core Web Vitals?
- 03How do layouts and content collections control titles, canonicals and schema?
- 04Astro vs Next.js: which ships less to the browser?
- 05Where do Astro sites usually lose points?
- 06How do you check an Astro site from the outside?
- 07Questions, answered
- 08Your next read
Is Astro good for SEO?
Yes, Astro can give you a search-friendly site: it renders every UI component on your site to HTML and CSS and strips client-side JavaScript by default. View source on your homepage. You want the raw response, not the inspector, and in it you should find your title, your meta description, your canonical link and your one h1.
A crawler gets your headings, copy and links with no rendering step. Astro's own homepage chart shows 71% of real-world Astro sites passing Core Web Vitals. But that is a vendor figure. Treat it as a signal, not a verdict, and test your pages before you trust it.
Astro does not write your metadata, and your configuration file does nothing for SEO. You add title and meta tags to your page head, usually in your shared layout. So your score depends on the templates you wrote and the content you filled in. The assessment reads your pages and shows you which pillar is dragging.
What do islands mean for crawlers and Core Web Vitals?
With islands, the crawler reads plain HTML for every component on your pages. Only the components you mark with a client: directive load JavaScript in your visitors' browsers. That is where your cost sits, and it is the only place.
Search your templates for client:load, client:idle and client:visible. Your client:idle components wait until the browser is idle, while your client:visible components hold off until they enter the viewport. Put client:load on your hero and your script ships with your first load. Ask whether your page needs that (it often doesn't).
Check what you ship in your HTML. Your copy and main image should appear in view source, because web.dev advises you to load your largest image through an img element with src or srcset, not behind JavaScript. Core Web Vitals measure loading, interactivity and visual stability, and each directive you choose touches at least one. The assessment counts the script weight your pages ship. But it can't show you your visitors' real experience. Web.dev says lab measurement is not a substitute for field measurement, so check your field data.
How do layouts and content collections control titles, canonicals and schema?
Your shared layout controls all three. Write your title, meta tags, canonical link and JSON-LD once in its head, and every page you build inherits them. A mistake there doesn't stay put: it repeats across your whole site.
Open your layout and look for three things: a title and description you pass in as props, a canonical you build from your site setting, and a JSON-LD script. For canonicals, set the deployment URL in the site option of astro.config.mjs. You can also set base and trailingSlash. Skip site, and your canonicals have nothing to build from.
Your collections cover the other half you control. Astro lists them as a way to organize, validate and type-check Markdown content, so you can require a description or a date in your schema before you build. Themes such as Casper claim collections validated with Zod alongside JSON-LD, so check whether yours does. The assessment checks your shipped HTML for structured data. It does not check the template you were promised (a promise isn't markup).
Astro vs Next.js: which ships less to the browser?
In the comparisons you can read, Astro ships less JavaScript to your pages than Next.js does. And Vercel states that both give you server-rendered HTML, so search engines can index your pages either way (which is the part people tend to worry about first). Choose Next.js, and your pages stay visible.
In Tech Insider's September 2026 docs-site benchmark, you see about 12 KB of JavaScript for Astro and around 187 KB for Next.js. A Devsplainers video shows 1.75 KB against 168 KB on a homepage, so check your own homepage for a gap like that. Kunal Ganglani puts the Next.js router and hydration cost at 80 to 150 KB on a typical marketing site, which gives you a range to hold your pages against. Figures vary by source and by site. None measures yours. So test your own site before you trust any figure: the number your build gives you is the one that counts.
Vercel adds that Astro's higher Core Web Vitals pass rates in HTTP Archive data reflect the kinds of sites using each framework, not a verdict on your build. To get your own number, follow LogRocket's method: run astro build and serve your dist with npx serve dist, or build Next.js with output: 'export' and serve your out directory. The assessment reads what your live pages ship, so you see your own result, not a benchmark's. Compare your build with what you ship live. And your gap is your answer.
Where do Astro sites usually lose points?
On Astro, you usually lose points in your templates and your content. Rendering rarely costs you. Your default output is already HTML, so look first at the pages you wrote, not at the framework.
Check your sitemap first. The @astrojs/sitemap integration builds entries from your statically generated routes, including those from getStaticPaths(), but it can't generate entries for your dynamic routes in SSR mode. If you render routes on demand, confirm they reach your sitemap another way. Then open your translated pages and check your hreflang tags. Do your canonicals point at the wrong host, or at the wrong trailing-slash form?
Images come next, and you can check them in your markup. Astro's Image component sets width and height automatically to avoid Cumulative Layout Shift. A plain img tag you write by hand has only the attributes you gave it. Your pages lose points when your JSON-LD is thin or missing, when a client:load component never needed to be interactive, or when one title repeats across your pages. And the assessment lists the evidence for each pillar, so you never have to guess about your own site.
How do you check an Astro site from the outside?
To check your Astro site from the outside, read what it ships: fetch your pages, then inspect your headers, markup, structured data, headings, script and image weight, and robots and canonical signals. Run curl on your homepage. Confirm you can see your title, canonical, h1 and JSON-LD in your first response (if you can't, a crawler won't find them either).
Then open your robots.txt and your sitemap URL. Repeat the check on a few of your templates, such as your post, your listing and your translated page. A layout fix can pass on one. But it can still fail on another.
The free assessment does this for you. It reads your homepage plus up to eight sampled pages, scores your site on eight weighted pillars and returns one number out of 100 in about two minutes. You enter your work email, and your report link is sent once. You get three checks per hour per connection. It does not log in to your site, read your analytics or use your field data, so pair it with your own field measurement.
Questions, answered.
01Does Astro need a sitemap plugin?
You need one if you want it generated for you. The @astrojs/sitemap integration builds a sitemap from statically generated routes, including getStaticPaths() routes, but it can't create entries for dynamic routes in SSR mode. Set the site option in astro.config.mjs first. Canonical URLs and the sitemap both depend on it. Skip that step and both break without warning (and nothing in your build will tell you).
02Do Astro islands hurt SEO?
Not by themselves. Astro renders your components to HTML, and only components marked with a client: directive load JavaScript. Islands cost you script weight and timing, so consider client:visible or client:idle for anything below the fold. The assessment reports the script your pages ship. It does not report how visitors feel it.
03Can the assessment read my Astro site if it is server rendered?
Yes. It reads your public pages as a crawler would, so it sees headers, markup and structured data whether the HTML was built ahead of time or rendered on demand. It samples your homepage plus up to eight pages. It does not log in. So pages behind a login stay out of reach.
04Is a Core Web Vitals pass the same as a good Astro SEO score?
No. Core Web Vitals cover loading, interactivity and visual stability, and web.dev says lab measurement is not a substitute for field measurement. Your score also weighs performance, architecture, security, search, schema, AI readiness, editorial experience and operational health. The assessment reads shipped pages. It cannot replace your field data, and it was never meant to.
Sources
Facts on this page come from the documents below, checked on 2026-10-25. Figures about the assessment itself describe how it works.
Free automated assessment