Astro SEO automation: content into your repo, without the manual MDX
AutoSEO does the research, writing and optimisation and delivers the finished article as a signed webhook payload — your handler commits the MDX or writes the content collection entry.
Try AutoSEO with AstroQuick answer
AutoSEO has no dedicated Astro connector; you use the generic Custom webhook connector. Each finished article is POSTed as an HMAC-signed JSON payload to an endpoint you control, and that endpoint commits a Markdown or MDX file into your content collection — or writes to whatever data source your site reads — so your existing build and deploy pipeline publishes it. Everything before that step, from keyword research to metadata and schema, is automated.
There is no Astro-specific connector in AutoSEO — the honest description is the generic Custom webhook. AutoSEO POSTs the article as HMAC-signed JSON (title, slug, HTML body, excerpt, meta title and description, canonical, keywords, hero image, structured data, stable external ID) to an endpoint you run. For Astro that endpoint is typically a small serverless function that converts the payload into a content-collection entry and commits it, letting your normal build and deploy pipeline do the publishing.
To be clear about what exists: there is no dedicated Astro connector in AutoSEO today. Astro is reached through the generic Custom webhook, with an endpoint you run doing the final placement. If a one-click Astro install appears later, this page will say so — until then it does not.
Step-by-step setup lives in the webhook integration guide.
Generic SEO advice fails on Astro for platform-specific reasons. These are the ones that actually change what you should do.
Astro validates frontmatter against your collection schema at build time, so a payload field that does not match will fail the build rather than publish quietly. Map the fields once, deliberately, and every article afterwards lands cleanly.
Astro ships zero JavaScript by default and hydrates only the components that need it. Article text is in the static HTML, which is exactly what both search and AI crawlers want.
A statically built site has no natural prompt to revisit an old post. Decay detection matters more here than on a platform with an editorial dashboard in front of you every day.
Generative engine optimisation is a different job from ranking. An answer engine lifts a passage and decides whether to credit a source — so the questions that matter on Astro are whether AI crawlers can read the page, whether you control what they're told, and whether the page carries attribution they can resolve.
The pattern across every platform is the same: content quality is rarely what stops a citation — missing attribution is. Check what an engine can currently see with the free SEO tools, or read the SEO automation overview.
What is Astro SEO automation?
How do you improve SEO on Astro?
| Manual on Astro | AutoSEO | |
|---|---|---|
| Keyword research | Occasional, when someone has time | Scheduled, before every article |
| Writing | In-house hours or a freelancer | AI-drafted, reviewed as much or as little as you want |
| Getting it into Astro | Copy, paste, format, fix | Signed delivery to your endpoint |
| Meta, schema, internal links | Remembered sometimes | Applied to every article |
| Refreshing old content | Rarely — nothing prompts it | Decay detection flags it |
| Rank + AI-visibility tracking | — | ✓ |
| Ongoing cost | Writers and tools billed separately | One subscription — see pricing |
Key takeaways
Astro ships zero JavaScript to the browser by default. Every page is rendered as static HTML at build time unless you explicitly opt into server-side rendering or client-side hydration. This single architectural fact changes almost every SEO decision you make: crawlers receive fully-formed HTML without waiting for JavaScript execution, Core Web Vitals scores start from a much stronger baseline, and the common React or Next.js pitfall of content hidden behind hydration simply does not exist in a default Astro build.
Understanding this output model is the foundation of Astro SEO. Before touching a sitemap plugin or a meta tag, you need to know exactly what Astro is sending to Googlebot — and why that gives you a structural advantage most frameworks cannot match out of the box.
Astro projects follow a file-based routing system. Every .astro, .md, or .mdx file placed inside the src/pages/ directory becomes a route. The file path maps directly to the URL, which means your information architecture is visible in your folder structure — a significant advantage for keeping URL logic clean and auditable.
Astro supports two primary output modes that affect SEO in different ways:
For most content sites, blogs, and marketing pages, static output is the correct choice. For e-commerce or user-generated content, hybrid mode lets you keep product pages static while rendering account pages dynamically.
Astro's Content Collections API, introduced in version 2.0 and significantly improved in version 3.0, organizes Markdown and MDX files under src/content/. Collections are defined with a schema using Zod, which validates frontmatter fields at build time. From an SEO standpoint, this matters because it enforces that every piece of content has the required metadata fields — title, description, canonical URL — before the build succeeds. You cannot accidentally publish a page with a missing title tag if your schema marks it as required.
Astro does not have a built-in head management library equivalent to Next.js's next/head. Instead, you control the <head> directly in your layout components. The correct pattern is to create a reusable SEO.astro or BaseHead.astro component that accepts props for title, description, canonical URL, Open Graph tags, and Twitter Card tags, then include it in every layout.
The most common mistake here is duplicating head content. If a layout includes a head component and a page also manually adds meta tags, you end up with duplicate title tags or duplicate canonical URLs — both of which send conflicting signals to search engines. Centralizing all head logic in one component and passing data through props eliminates this risk entirely.
Astro provides the Astro.url and Astro.site globals, which make constructing canonical URLs straightforward. Setting site in your astro.config.mjs is a prerequisite — without it, Astro.site returns undefined and any canonical URL logic built on top of it will silently fail. Always verify your canonical tags in production output, not just in development, because the base URL differs between environments.
The official @astrojs/sitemap integration generates a sitemap automatically from your static routes at build time. Configuration is minimal: add the integration to astro.config.mjs, ensure site is set, and the sitemap appears at /sitemap-index.xml after build. For large sites, the integration automatically splits the sitemap into multiple files.
Key configuration options that matter for SEO:
pubDate or updatedDate from frontmatter and inject it via a custom sitemap serializer.Astro does not generate a robots.txt file automatically. Place a static robots.txt in the public/ directory and it will be copied to the root of your build output. For sites with SSR routes, you may need to serve the file through your adapter's routing configuration rather than relying on static file serving.
Astro's component model makes injecting JSON-LD straightforward. Create a typed Schema.astro component that accepts a structured data object as a prop and renders it inside a <script type="application/ld+json"> tag in the document head. Because Astro renders this server-side, the JSON-LD is present in the raw HTML response — no hydration required, no risk of Googlebot missing it.
Common schema types by Astro use case:
| Site Type | Recommended Schema | Key Fields |
|---|---|---|
| Blog or editorial | Article, BlogPosting | headline, author, datePublished, dateModified, image |
| Documentation | TechArticle, BreadcrumbList | name, description, breadcrumb, url |
| E-commerce | Product, Offer, AggregateRating | name, price, availability, ratingValue |
| Local business | LocalBusiness, Organization | name, address, telephone, openingHours |
| FAQ pages | FAQPage, Question, Answer | name, acceptedAnswer, text |
Astro's zero-JS default is the single largest performance advantage it offers for SEO. Largest Contentful Paint scores on static Astro pages routinely outperform equivalent React or Vue pages because there is no render-blocking JavaScript bundle to parse. However, several Astro-specific patterns can still damage performance if applied carelessly:
@astrojs/image integration or the built-in Image and Picture components from astro:assets (Astro 3+). These automatically generate WebP or AVIF variants, apply correct width and height attributes to prevent layout shift, and support lazy loading. Skipping this and using raw <img> tags is the fastest way to destroy your CLS and LCP scores.client:load, client:idle, or client:visible. Using client:load on a component in the hero section forces JavaScript to load immediately and blocks rendering. Use client:idle or client:visible for anything that does not need to be interactive on first paint.is:inline attribute carefully, and prefer loading third-party scripts with defer or async attributes, or through a Partytown integration for off-main-thread execution.Every absolute URL Astro generates — canonical tags, sitemap entries, Open Graph image URLs — depends on the site property in astro.config.mjs. Leaving it unset causes these values to either error out or produce relative URLs that are invalid in contexts where absolute URLs are required. This is the single most common configuration mistake on new Astro projects.
Astro does not inject canonical tags automatically. If your base layout does not include a canonical URL component, every page on your site is technically missing a canonical declaration. On sites with pagination, tag archives, or content syndicated from a headless CMS, this creates duplicate content problems that compound quickly.
Astro's getStaticPaths function makes generating paginated routes simple, but it does not handle the SEO implications. Paginated pages need canonical tags pointing to themselves (not the first page), and you should carefully consider whether pages beyond page one should be indexed at all or consolidated using a canonical pointing to the root category or tag page.
Wrapping static content — a navigation menu, a footer, a testimonial block — in a framework component with client:load forces unnecessary JavaScript onto the page. If a component does not need interactivity, write it as an .astro component with no client directive. Reserve hydration for components that genuinely require browser APIs or user interaction.
Because neither file is generated automatically without configuration, Astro projects frequently go live without a robots.txt or without the sitemap submitted to Google Search Console. The sitemap integration generates the file, but you must manually submit the sitemap URL in Search Console and verify that the robots.txt does not accidentally block crawling of the sitemap or key page paths.
The most effective SEO workflow for Astro combines static-site strengths with structured content operations: audit your site structure, research keywords, write optimized content, configure on-page elements in frontmatter, build and deploy, then submit URLs for indexing and monitor rankings over time.
Before writing a single word, confirm your Astro project outputs clean, crawlable HTML. Run a crawl with Screaming Frog or Sitebulb and check for:
astro.config.mjsFix structural issues first. Ranking improvements from content work are undermined when crawlers hit dead ends or duplicate metadata.
Map one primary keyword and two to four supporting keywords to each URL before writing. For a content collection entry, this mapping lives in a planning document or directly in frontmatter as a custom field. Prioritize keywords where:
Use tools such as Ahrefs, Semrush, or Google Search Console's Performance report to find queries already sending impressions but not clicks — these are fast-win targets for existing pages.
Each Astro page or content collection entry should follow a consistent on-page checklist:
Astro's content collections use frontmatter as the single source of truth for SEO metadata. Define a Zod schema in config.ts that enforces required fields: title, description, pubDate, canonicalURL, and noindex. Your layout component reads these fields and populates <title>, <meta name="description">, and <link rel="canonical"> automatically. This prevents metadata from being forgotten on new pages and makes bulk audits straightforward — every SEO property is visible in one file per page.
Run astro build and inspect the dist folder before deploying. Spot-check that title tags, canonical URLs, and Open Graph tags rendered correctly in the static HTML. After deploying to Netlify, Vercel, Cloudflare Pages, or your preferred host, validate the live sitemap at /sitemap-index.xml and confirm robots.txt does not block Googlebot.
New and updated pages need to be discovered quickly. Submit the sitemap URL in Google Search Console under Sitemaps. For individual high-priority pages, use the URL Inspection tool and request indexing manually. For Bing, submit the sitemap in Bing Webmaster Tools. If your Astro site uses an RSS feed — easy to generate with @astrojs/rss — submit the feed URL as well, since some crawlers and content aggregators use it as a discovery signal.
Connect Google Search Console and Google Analytics 4 to monitor impressions, clicks, average position, and Core Web Vitals. Set up a rank-tracking project in Ahrefs or Semrush to watch target keywords weekly. Review performance at 30, 60, and 90 days after publishing. Pages that rank on page two for their primary keyword are strong candidates for a content refresh: expand thin sections, add FAQ schema, improve internal linking, and update the publish date in frontmatter to signal freshness.
AutoSEO handles every stage of the SEO workflow — from keyword research through publishing and index submission — without requiring manual steps between tools. For Astro sites specifically, it connects to your repository, writes content that maps to your frontmatter schema, commits files to your content collections, triggers a build, and pings Google after deployment.
AutoSEO pulls keyword data from search APIs, analyzes your existing sitemap to avoid cannibalization, and produces a prioritized content plan. You review and approve topics before any content is written. The output includes a primary keyword, supporting keywords, target URL slug, and recommended schema type for each planned page — all formatted to match Astro frontmatter fields.
AutoSEO generates content that follows the on-page checklist described above: optimized title tag, meta description, H1, structured heading hierarchy, internal link suggestions, and alt text for images. Output is formatted as Markdown with frontmatter, ready for Astro content collections. You can review drafts in the AutoSEO editor before committing anything to your repository.
AutoSEO connects to GitHub, GitLab, or Bitbucket. After approval, it commits the new .md or .mdx file to the correct content collection directory, which triggers your CI/CD pipeline and rebuilds the Astro site automatically. No copy-pasting between tools, no risk of frontmatter formatting errors.
Once the build completes and the new URL is live, AutoSEO uses the Google Indexing API and Bing Submission API to request crawling immediately. This cuts the typical discovery lag from days or weeks down to hours for sites that qualify for the Indexing API.
AutoSEO pulls data from Google Search Console and rank-tracking APIs into a single dashboard. You see impressions, clicks, position, and Core Web Vitals per page alongside the content AutoSEO published. When a page stagnates, AutoSEO flags it for a refresh and can generate an updated draft automatically, maintaining the same URL and frontmatter slug to preserve link equity.
| Workflow Stage | Manual Approach | AutoSEO Approach |
|---|---|---|
| Keyword Research | Ahrefs or Semrush, exported to spreadsheet | Automated discovery, deduped against existing sitemap |
| Content Writing | Writer follows brief, formats frontmatter manually | SEO-structured draft generated, frontmatter auto-populated |
| Publishing to Astro | Copy file to repo, push, wait for build | Direct commit to content collection, build triggered automatically |
| Index Submission | Manual URL Inspection in Search Console | Indexing API call fired automatically post-deploy |
| Rank Tracking | Separate rank tracker, manual reporting | Unified dashboard tied to published content |
Yes. Astro content collections let you define a Zod schema that enforces frontmatter fields like title, description, and canonicalURL. Your layout component reads these fields at build time and injects them into the <head> of each static HTML file. This means every page in a collection gets unique, validated metadata without any manual HTML editing.
Astro does not set canonical URLs automatically. You need to add a <link rel="canonical"> tag in your layout component and pass the correct URL from each page's frontmatter or from Astro.url. For content collections, storing the canonical URL as a frontmatter field gives you explicit control and makes it easy to audit across all pages.
The @astrojs/sitemap integration generates a valid XML sitemap that includes all statically rendered pages. It supports filtering pages via the filter option and setting changefreq and priority values. For most sites it is sufficient. If you need per-page lastmod dates pulled from frontmatter, you will need a custom sitemap script or a plugin that reads content collection data.
Create a reusable Astro component that accepts schema props and renders a <script type="application/ld+json"> tag. Place this component inside your layout's <head> and pass the appropriate schema type — Article, FAQPage, Product, BreadcrumbList — from each page's frontmatter. This approach keeps schema logic centralized and makes it easy to validate with Google's Rich Results Test after deployment.
No. Astro renders full HTML at build time regardless of which components are hydrated on the client. Search engines receive complete, readable HTML for every page. JavaScript-heavy interactive components hydrated with client:load or client:idle do not hide content from crawlers because the surrounding page content is already present in the static HTML output.
When using Astro's SSR mode with an adapter such as @astrojs/node or @astrojs/vercel, pages are rendered on request rather than at build time. SEO metadata still needs to be set in the <head> of each page, and you should ensure response times are fast enough to meet Core Web Vitals thresholds. For SEO-critical pages, consider using static pre-rendering (export const prerender = true) even within an SSR project to get the performance benefits of static HTML.
Astro sites built with zero client-side JavaScript consistently score at or near 100 on Lighthouse performance audits, which directly supports Core Web Vitals metrics that Google uses as a ranking signal. Content-focused Astro sites without React, Vue, or Svelte components are among the fastest sites on the web by default, giving them a measurable technical SEO advantage over sites built with client-rendered frameworks.
The fastest reliable method is submitting the URL through the Google Indexing API immediately after deployment. This requires verifying your site in Google Search Console and setting up API credentials. For sites that do not qualify for the Indexing API (which was originally designed for job posting and livestream pages but is used broadly in practice), the next best option is submitting the updated sitemap in Search Console and using the URL Inspection tool to request indexing manually for high-priority pages.
AutoSEO has no dedicated Astro connector. You use the generic Custom webhook connector: a URL you own + a shared secret, and an endpoint you run does the final placement — that is the accurate description, not a one-click install.
Only what you ask it to. New articles are delivered on the cadence you choose — as drafts for review, or published straight away. Existing pages are audited and surfaced as recommendations first; nothing is rewritten in place until you turn that on.
It depends on the domain, not the platform. An established site with existing authority usually sees movement on long-tail queries within weeks; a new domain in a competitive niche takes considerably longer. Publishing consistently is what compounds — which is the part automation actually fixes.
Plans are per site with volume discounts as you add more, and there is a trial. Current numbers are on the pricing page rather than repeated here, so they cannot go stale.
Yes. AutoSEO is built to sit alongside what you already run rather than take over the page head — on WordPress it writes into your existing SEO plugin's fields instead of adding a competing set of tags, and on every platform it leaves the platform's own SEO settings alone.
No. Astro is served by the generic Custom webhook connector, not a dedicated one — we would rather say that than list an integration that does not exist. The webhook guide covers the payload and signature verification.
That is the usual pattern: verify the signature, write the MDX file, commit, and let your existing CI deploy. The alternative is writing to a database or CMS your Astro build already reads.
Works alongside your existing Astro setup. See pricing for plans and the trial.
Connect Astro