How to Tell if a Website Is Built with Astro

If you want to know whether a website is built with Astro, the fastest answer is to view the page source and look for a single line: <meta name="generator" content="Astro v...">. Astro writes that tag into the head of every page it builds, so finding it is close to conclusive. Back it up with two more signals — <astro-island> custom elements wrapping the interactive parts of the page, and JavaScript and CSS loading from a /_astro/ folder in the DevTools Network tab — and you can name the framework with confidence. Because Astro ships almost no JavaScript by default, a fast, content-rich page that shows these markers is unmistakably Astro. This guide walks through every signal and how to read it in under a minute.

It sits alongside the broader framework guide, how to check what JavaScript libraries a website uses, and the wider how to find out what technology a website uses.

What Astro is, briefly

Astro is an open-source web framework built for content-driven websites — blogs, marketing pages, documentation, and increasingly commerce front-ends. Its defining idea is the islands architecture: Astro renders each page to static HTML on the server (or at build time) and ships zero JavaScript by default, then "hydrates" only the genuinely interactive components — the islands — sending the JavaScript for those alone. The result is pages that are mostly plain HTML, load fast and score well on Core Web Vitals, with interactivity added surgically where it is needed rather than everywhere.

For detection purposes, two consequences matter. First, Astro has a very distinctive output: the way it marks islands and names its asset folder is consistent across sites. Second, because Astro is UI-framework-agnostic, a single site can mix components written in React, Vue, Svelte or Solid, each hydrated as an island. That means you might see React or Vue signals on an Astro site — so the Astro-specific markers are what name the meta-framework above the component layer.

Signal 1: the generator meta tag

The single most reliable Astro fingerprint lives in the page head. Astro writes a standard generator meta tag:

<meta name="generator" content="Astro v4.x.x">

Open View Source (Ctrl/Cmd + U) and search the page for name="generator" or simply Astro. If the generator content begins with Astro, you are almost certainly looking at an Astro site, and you even get the major version. This is the cleanest single check because it is present in the server-rendered HTML before any JavaScript runs, and because Astro adds it by default — most sites never remove it. A team can strip or override the generator tag, so its absence does not rule Astro out, but its presence is a clear positive.

Signal 2: astro-island custom elements

Astro's islands architecture leaves an unmistakable marker wherever an interactive component is hydrated: a custom element called <astro-island>. Each interactive component on the page is wrapped in one, and the element carries attributes describing how and when it hydrates — you will see things like client:load, client:visible or client:idle reflected in the markup, along with a component-url pointing at the component's JavaScript and a renderer-url for the UI framework that renders it. Searching the HTML for astro-island is a strong, Astro-specific signal: no other framework produces that element.

You will also frequently see data-astro-cid-* attributes scattered through the markup. These are Astro's scoped-styling identifiers — Astro scopes CSS to a component by tagging its elements with a content ID — so a page peppered with data-astro-cid- attributes is another distinctive tell. Between astro-island and data-astro-cid-, the source of a typical Astro page is easy to recognise once you know what to look for.

Signal 3: the /_astro/ asset folder

Astro bundles its JavaScript and CSS into a folder served from /_astro/, with hashed filenames for cache-busting. When you load an Astro site and watch the Network tab, you will see requests to URLs like /_astro/hoisted.<hash>.js and /_astro/<name>.<hash>.css. The /_astro/ prefix is specific to the framework's build output — it is not a path other tools use — so seeing it on a site's own assets is a strong corroborating signal. On a heavily static Astro page there may be very few of these requests (sometimes only a CSS file), which itself fits the Astro profile of minimal shipped code.

Signal 4: minimal JavaScript and fast HTML

The fourth signal is less a string and more a characteristic. Because Astro ships no framework runtime by default, an Astro page tends to be light on JavaScript and rich in server-rendered HTML. View Source on an Astro marketing page and you will see the full content present in the raw HTML — headings, paragraphs, images — rather than an empty shell that fills in after hydration. The Network tab shows little JavaScript relative to the content. This profile — meaningful HTML up front, minimal JS, fast load — combined with the markers above, is a tell-tale Astro fingerprint, and it is exactly why teams choose Astro for content and SEO.

The signal table

Signal	Where to find it	What it means
<meta name="generator" content="Astro v...">	View Source (head)	Astro build — strongest single signal
<astro-island> elements	View Source / Elements	Hydrated island — Astro-specific, strong
client:load / client:visible attributes	View Source	Astro hydration directive on an island
data-astro-cid-... attributes	View Source / Elements	Astro scoped-styling identifier
/_astro/... asset URLs	Network tab, View Source	Standard Astro build output — strong
Minimal JS, full HTML in source	Network tab / View Source	Astro's zero-JS-by-default profile

Method 1: View Source

The quickest single check is View Source. Open the page, press Ctrl/Cmd + U, and use the in-page find to search for generator, astro-island and data-astro-cid. If the generator content reads Astro, you are done — that is Astro, and you have the version. Scanning the source also lets you confirm the islands and scoped-style attributes, and to see how much real content is present up front. This works because Astro puts these markers directly in the server-rendered HTML, so they appear before any JavaScript executes — which is exactly why a static source view catches them reliably.

Method 2: the DevTools Network tab

For a live view, open DevTools (F12), go to the Network tab and reload. Filter to JS and CSS, and look for requests to the /_astro/ folder with their hashed filenames. This method is valuable because it shows what the browser actually fetches, and because the volume of JavaScript is itself informative — an Astro page typically pulls far less framework code than a single-page-app would. If you want to identify which UI library renders the islands (React, Vue, Svelte), the same Network view feeds into how to check what JavaScript libraries a website uses, since those libraries' chunks load alongside Astro's own.

Method 3: Wappalyzer and BuiltWith

If you prefer a one-click read, the Wappalyzer browser extension and the BuiltWith site both recognise Astro and will list it in their framework section, usually alongside the hosting and any UI libraries. They are convenient for a quick confirmation and for capturing the whole stack at once. As with any detection tool, treat their output as a strong starting point and verify the important calls against the raw signals — the generator tag and /_astro/ paths are the ground truth, and a quick View Source confirms what an extension reports.

A worked example

Say you are sizing up a competitor's documentation site. You open View Source and search for generator — there it is: <meta name="generator" content="Astro v4.5.0">. That alone is enough, but you confirm the rest. The page's full text content is present in the raw HTML, and you spot several data-astro-cid-... attributes on the styled elements. Scrolling to the interactive search box, you find it wrapped in an <astro-island> element with a client:visible directive and a component-url pointing at a /_astro/ chunk. The Network tab shows a couple of /_astro/*.js files and one /_astro/*.css, and not much else — strikingly little JavaScript for the amount of content. Every signal lines up: this is an Astro site using the islands architecture, hydrating only the search component. In about a minute you have the framework and a clear read on its performance approach.

Distinguishing Astro from other frameworks

Because Astro can host components from other libraries, it is worth knowing how to avoid misattribution. Next.js, Nuxt and SvelteKit are application frameworks that ship a client-side runtime and hydrate the whole page; their tells are /_next/ and __NEXT_DATA__, /_nuxt/ and __NUXT__, or data-sveltekit-* and /_app/ respectively — not /_astro/ and astro-island. A plain React or Vue app mounts into a root element and fills in client-side, with no generator tag naming Astro and no island wrappers. Gatsby exposes ___gatsby and page-data.json. So when you see React or Vue signals and the Astro markers together, the correct read is "Astro site with React/Vue islands", not a plain React or Vue app. A quick rule of thumb: astro-island plus a generator tag reading Astro names the meta-framework, regardless of which UI library renders the individual components.

It also helps to recognise the output modes Astro supports, because they affect what you see. A static build (the default) produces fully pre-rendered HTML, so the content is all in the source and detection is easy. Server-side rendering mode renders on request, which still produces the generator tag, island markers and /_astro/ assets, so the signals hold. Either way the fingerprints are present — recognising which mode a site uses is a bonus insight into how the team balances build-time and on-demand rendering.

Why the framework matters

Knowing a site runs Astro tells you more than a label. It implies a content-first, performance-focused philosophy — Astro is chosen precisely when speed and SEO on content-heavy pages matter, so a site on it is usually built by a team that cares about shipping minimal JavaScript and fast HTML. It suggests a modern build pipeline and often a static or hybrid rendering model with good Core Web Vitals. And the islands approach signals a deliberate, surgical attitude to interactivity rather than a heavy single-page app. For competitive research, hiring or partnership scoping, the framework is one of the most informative single facts about a site, and Astro in particular flags a current, performance-minded front end.

How reliable is Astro detection?

Very reliable. The generator meta tag, the astro-island element and the /_astro/ asset folder are intrinsic to how the framework builds and ships pages, so they are present on the large majority of Astro sites and are not used by unrelated tools. The main edge cases are a purely static page with no islands (no astro-island elements, so you lean on the generator tag and /_astro/ paths) and a team that has stripped the generator tag (in which case the islands and asset folder still carry the detection). Combine the generator tag, the island markers and the asset paths, and you can state "this is Astro" with genuine confidence — and a second, more interactive page usually settles any doubt.

The workflow

1. View Source and search for generator, astro-island and data-astro-cid.
2. Open the Network tab and watch for assets loading from /_astro/.
3. Note the JavaScript volume — Astro pages are unusually light on framework JS.
4. Check a more interactive page to surface islands if the homepage is static.
5. Combine the signals — a generator tag reading Astro plus island markers means Astro.

Go deeper

• The libraries behind the islands: how to check what JavaScript libraries a website uses.
• The whole stack: how to find out what technology a website uses.
• A close cousin to detect: how to tell if a website is built with Svelte or SvelteKit.
• The CMS angle for content sites: how to tell what CMS a website is using.

Want the framework, hosting and full stack identified automatically? Analyse any site with StackOptic — free, no sign-up.