Astro and SEO: what the framework does for you, and what is left to do.

Astro serves fast HTML that Google reads straight away. Titles, sitemaps, hreflang, structured data: what it handles on its own, and what you still have to do.

On this page · 6 sections

“Is Astro good for SEO?” The short answer is yes. The useful answer is longer: Astro handles part of the job very well, and leaves the rest entirely to you.

What Astro does for you, with nothing to install#

It serves a page that is already built. An Astro site is generated in advance: when Googlebot arrives, the text, headings and links are in the HTML. Google processes JavaScript in three phases, crawling, rendering and indexing, and a page waiting to be rendered “may stay on this queue for a few seconds, but it can take longer than that”. With Astro, the content is readable in the first phase.

That is exactly what Google’s JavaScript SEO documentation advises: “server-side or pre-rendering is still a great idea because it makes your website faster for users and crawlers, and not all bots can run JavaScript.”

It ships no JavaScript by default. A page with no scripts displays and responds quickly, which is what Core Web Vitals measure. JavaScript only arrives where you ask for it, one component at a time.

It keeps images stable. Astro’s image component writes each image’s dimensions and converts it to a lightweight format. The page does not jump while loading, which takes care of most of CLS.

Median Lighthouse SEO score: 100 for Astro sites, 92 for WordPress sites.

HTTP Archive Tech Report, September 2026, mobile.

That figure, from the HTTP Archive Tech Report, says the technical basics are in place. It says nothing more, which is what the rest of this article is about.

What you have to add, because it does not come on its own#

Astro provides no tag manager, no sitemap and no structured data. Each of these is added once, in the right place. A community package, astro-seo, bundles the usual tags into one component: handy, but it does nothing a well-written layout does not.

ItemDoes Astro do it?How to set it up
Title tag and meta descriptionNoA shared layout that receives each page’s title and description
Canonical URLNoBuilt in the layout from the site URL and the page path
XML sitemapThrough an integrationInstall @astrojs/sitemap, with the site URL set
hreflang tagsNoIn the layout, or declared in the sitemap, even with Astro’s i18n routing
Structured dataNoJSON-LD written in components: article, breadcrumb, FAQ, organisation
Share images (Open Graph)NoOne image per page, supplied or generated at build time
robots.txtNoA text file in the public folder, pointing to the sitemap
RedirectsNoOn the host, for example a _redirects file on Cloudflare Pages

These points come from Astro’s documentation: i18n routing, available since version 3.5, builds the URLs but not the hreflang tags, and the sitemap integration does not cover pages rendered on demand on the server.

What we set up on astro4b.com#

This site runs on Astro. Here is what we added to the framework, and why.

One layout for every tag. Title, description, canonical, French, English and x-default hreflang, Open Graph and Twitter are written once. Each page passes its values in. A forgotten page is impossible: it inherits the layout.

BaseLayout.astro, simplified excerptAstro
---
const { title, description, path, frPath, enPath } = Astro.props;
const url = (p) => new URL(p, Astro.site).href;
---
<title>{title}</title>
<meta name="description" content={description} />
<link rel="canonical" href={url(path)} />
<link rel="alternate" hreflang="fr" href={url(frPath)} />
<link rel="alternate" hreflang="en" href={url(enPath)} />
<link rel="alternate" hreflang="x-default" href={url(frPath)} />

Sitemaps built by the site itself. Two routes generate one sitemap per language and an index that groups them. Each article declares the URL of its translation there, which repeats the hreflang information in the sitemap.

SEO fields checked before release. The article schema caps the description at 160 characters and the SEO title at 65. Going over makes the site build fail. It happened while rewriting our Core Web Vitals article: a description and a title that were too long, stopped before they reached Google.

Structured data linked together. Each article declares its author through a single identifier, the same in French and English, which points to the author page. The organisation, the site, the breadcrumb and the FAQs follow the same principle.

One share image per article, generated at build time from the article’s title and key figure.

A 404 page kept out of the index. It declares no canonical and no hreflang. We fixed it in October: the canonical pointed to an address that did not exist.

Traps specific to Astro#

The trailing slash. By default, Astro accepts both forms of a URL. But on Cloudflare Pages, a link to /configurator is redirected to /configurator/ with a 308. Every internal click went through a redirect: we fixed 92 links in 29 files. Forcing the trailingSlash option would have been simpler, but on our setup it broke the sitemaps and share images in development. So every link is written with its slash.

Interactive components that bring JavaScript back. Astro ships no script by default, but every component set to run in the browser adds some. A carousel or a widget loaded as soon as the page opens is enough to lose the Core Web Vitals advantage.

Content loaded afterwards. Text fetched by an interactive component once the page is open is not in the initial HTML. It depends on Google rendering JavaScript, and on its delay.

Multilingual without hreflang. Astro’s routing gives clean /en/… URLs and makes it look as if the job is done. Without hreflang tags, Google sees two similar pages without knowing they translate each other.

What no framework will do#

Choosing the queries, answering the search intent, the quality of the content, the links between your pages and the links other sites give you. That is where most of the ranking is decided, and Astro has no more say in it than WordPress.

It is also why comparing Astro and WordPress on technical SEO alone is not enough to choose. Astro removes obstacles. It does not replace editorial work.

Your SEO checklist for an Astro site

  1. One shared layout for title, description, canonical and Open GraphA page that does not inherit the layout is a page without tags.
  2. The site URL set in the configurationThe sitemap and canonical URLs need it.
  3. One sitemap per language, declared in robots.txtThrough the official integration or the site’s own routes.
  4. hreflang on every translated page, plus an x-defaultAstro’s i18n routing does not add them.
  5. JSON-LD for articles, breadcrumbs and the organisationWith a single identifier per author and per entity.
  6. Every internal link written in its final formTrailing slash included, to avoid a redirect on every click.
  7. No important content loaded after the page opensWhatever is not in the HTML waits for Google to render it.

Frequently asked questions#

Is Astro good for SEO?

Yes for the technical side: it serves complete, fast HTML with no JavaScript by default, which is what Google recommends. It does nothing for the rest: titles, descriptions, internal links and content are still up to you.

Do I need a plugin like Yoast with Astro?

There is no equivalent, and you do not need one. SEO tags are set once in a layout shared by every page, and each article's fields can be validated when the site is built: a description that is too long stops the release.

Does Google see the content of an Astro site?

Yes, on the first pass, since the content is already in the HTML. The only exception is content loaded in the browser afterwards by an interactive component: that part depends on Google rendering JavaScript.

Does Astro handle SEO for a multilingual site?

Halfway. Its i18n routing builds the right URLs, but does not add the hreflang tags that tell Google which page translates which. You write them in the layout, or declare them in the sitemap.

Is the sitemap automatic?

No. It comes from an official integration you install, @astrojs/sitemap, which requires your site URL. It does not cover pages rendered on demand on the server.

Does an Astro site rank better than a WordPress site?

Not by nature. It starts with a technical advantage, fast pages and clean HTML, which Core Web Vitals measure. Rankings then depend on content, search intent and the site's authority, which the framework does not touch.


Do you have a site that will not take off despite good content? The technical foundation may be the issue. The configurator gives you the price of an Astro site set up this way, and if you are starting from WordPress, the WordPress rebuild carries over your content and your redirects.

Reading is good. Building is better.