Astro SEO: How to Make an Astro Site Rank on Google and Get Cited by AI

Quick quiz

Is SEO right for you, and how should you start?

Question 1 of 425%

Do people search Google for what you sell?

Yes, I think soNo, it is new or very nicheI don't know

Astro SEO is the work of turning that clean HTML into pages that rank. Google's own guide to JavaScript SEO basics explains that it processes JavaScript sites in three phases (crawling, rendering, indexing) and states that "server-side or pre-rendering is still a great idea" because not all bots can run JavaScript. Astro starts from that position by default. This guide covers the rest, setting by setting, with every behavior checked against the official Astro documentation. For context, the sorank.com site you are reading runs on Astro.

Is Astro good for SEO?

Yes, on the technical side. Astro renders components to HTML at build time and removes the JavaScript that frameworks such as React or Vue would normally send to the browser. The result avoids the classic problems described in our guide to JavaScript SEO: empty HTML shells, content that only appears after rendering, links that are not real anchor tags. It also avoids the routing traps of a single-page application, since every Astro route is a real URL with its own HTML file.

What Astro does not do is just as important. There is no built-in SEO plugin, no automatic meta description, no automatic canonical tag and no structured data. The table below separates what you get for free from what you must build.

Static or server rendering: which mode is best for SEO?

The Astro documentation on on-demand rendering is clear: by default, pages, routes and API endpoints are prerendered at build time as static pages. For SEO, static output is the safest default: each URL is a finished HTML file served from a CDN, fast and identical for every visitor and every bot.

On-demand (server) rendering requires an adapter for your host (Node, Netlify, Vercel or Cloudflare, for example). You then opt a single route out of prerendering with export const prerender = false, or switch the whole project with output: 'server' and opt static pages back in. Both modes produce full HTML, so Google sees the same thing. The differences are elsewhere:

• Speed: a static file is served instantly; a server-rendered page depends on your server's response time, which weighs on Largest Contentful Paint.
• Freshness: server rendering suits pages that change constantly (stock, prices, search results), where rebuilding the site would be too slow.
• Tooling: some integrations, such as the sitemap, cannot see dynamic server routes (see below).

The practical rule: keep marketing pages, blog posts and documentation static, and render on demand only the routes that need live data. Astro's docs make the same recommendation, advising to keep the default static mode until most of your pages need on-demand rendering.

How do you set up meta tags and canonical URLs in Astro?

Create one SEO component (often called BaseHead or Seo) and include it in the head of every layout. It receives a title, a description, an optional image and an optional noindex flag, and outputs:

1. the title tag, unique per page, with the main keyword near the start;
2. the meta description, written by hand for each page (it is your search snippet);
3. the canonical tag, built as an absolute URL from Astro.url.pathname and the site value of your config;
4. Open Graph and social tags (title, description, image, URL) for link previews;
5. a robots meta tag when a page must stay out of the index.

Set the site option in astro.config.mjs first: the canonical, the sitemap and the social tags all depend on it. Then choose a trailingSlash policy ('always' or 'never') and stick to it, so that /blog/post and /blog/post/ never compete as two versions of the same page. Query strings should be stripped from the canonical so that tracking parameters do not create duplicates.

How do you generate a sitemap and robots.txt with Astro?

Use the official integration documented on the @astrojs/sitemap page. Running npx astro add sitemap installs it and adds it to your config. It requires the site option and, at build time, writes a sitemap-index.xml file that points to numbered files (sitemap-0.xml, then more on large sites). Each file holds up to 45,000 entries by default, set by the entryLimit option. If you are new to the format, our glossary entry on the XML sitemap explains what Google does with it.

Three settings matter for SEO:

• filter: a function that receives each page URL; return false for thank-you pages, internal search, drafts or anything with noindex, so the sitemap only lists indexable URLs.
• i18n: maps your locale folders to language codes and adds hreflang alternates to every entry.
• customPages: adds URLs the integration cannot discover on its own.

For robots.txt, a static file in the public folder is enough on most sites. If the content differs between staging and production, generate it from an endpoint (src/pages/robots.txt.ts) instead. In both cases, add a Sitemap line pointing to sitemap-index.xml, and test the result with a robots.txt checker before launch. The same endpoint technique produces an llms.txt file; our guide on how to install an llms.txt file covers its content.

How do you handle hreflang and multilingual sites in Astro?

Astro's built-in i18n routing handles the URL side. In the config you declare a defaultLocale and a list of locales, and choose whether the default language also gets a prefix (prefixDefaultLocale). Helpers such as getRelativeLocaleUrl build localized links, and Astro.currentLocale tells each page which language it is in.

The routing guide does not cover hreflang tags in the head, so plan to write them yourself in the SEO component: for each page, one alternate link per language version, plus an x-default, all as absolute URLs, and every version must list all the others (return links). Generating them from the same locale list as your routing avoids the most common error, an alternate pointing to a page that does not exist. To check the logic on a few URLs, our hreflang generator outputs the full set of tags for a page. Then enable the sitemap i18n option as a second signal.

How do images and islands affect speed and Core Web Vitals?

Speed is where Astro gains the most ground, and it shows in Core Web Vitals. The Astro images guide describes the Image component from astro:assets: it optimizes local images, converts their format, outputs lazy loading and async decoding, and infers image dimensions to avoid Cumulative Layout Shift. The alt attribute is mandatory on it, which enforces a basic rule of image SEO. The Picture component goes further and serves AVIF or WebP with a fallback.

Two habits complete the picture. Keep images that need optimizing in src (files in public are served as they are, with no processing). And do not lazy-load the main image at the top of the page: give it eager loading so it does not delay Largest Contentful Paint.

The islands architecture keeps JavaScript under control. A component is static HTML until you add a client directive: client:load hydrates it immediately, client:idle when the browser is free, client:visible only once it enters the viewport. Reserving client:load for what must react at once (a menu, a cart) is the simplest way to protect Interaction to Next Paint. Server islands (server:defer) let a personalized block load after the cached page, without slowing down the main content.

How do you add structured data to an Astro site?

Astro has no schema feature, which leaves you full control. Build a JavaScript object for each page type (Article, Product, Organization, BreadcrumbList, FAQPage) and output it in a script tag of type application/ld+json, using the set:html directive with JSON.stringify so the JSON is not escaped. Feed it from the same frontmatter or collection data as the visible page, so the markup always matches what users see, which is a requirement of Google's guidelines on schema markup.

To draft the JSON for a new page type, our free schema generator gives you a valid starting block that you then turn into a template. Validate a sample of built pages with Google's Rich Results Test after each change to the template.

How do you handle redirects when migrating to Astro?

Migrations from WordPress or Next.js are the riskiest moment for an Astro site. Keep every URL that has traffic or backlinks, and map the others one by one to their closest equivalent with permanent redirects, as explained in our guide to SEO redirects.

Astro's config accepts a redirects object that maps old paths to new ones. With a server adapter, these become real HTTP redirects. On a purely static build, Astro writes an HTML page with a meta refresh instead, which Google follows but treats as a weaker signal than a server-side 301. For a static site, declare the redirects in your host's own format (a _redirects file on Netlify or Cloudflare Pages, a vercel.json file on Vercel) so that crawlers receive a true 301.

How does Astro help with SEO and GEO?

Being cited by ChatGPT, Perplexity or Gemini starts with being readable. Many AI crawlers fetch the raw HTML and do not execute JavaScript, so a site that ships its full text in the first response, as Astro does by default, removes a barrier that client-rendered sites still have. Clean headings, answer-first paragraphs, structured data and an llms.txt file then make each page easier to quote.

After launch, measure instead of guessing. The Sorank GEO and SEO dashboard brings your Search Console data and your visits from AI assistants together, so you can see whether the new site holds its positions.

Technical quality only pays off with content to rank. Sorank's AI blog article generator writes and publishes articles optimized for Google and AI assistants, and connects to a custom site such as an Astro project by webhook.

Astro gives you crawlable, fast HTML by default; ranking still depends on the head tags, sitemap, hreflang, structured data and redirects you add on top. Set up the shared SEO component and the sitemap first, then work through the table above before launch.