Astro in 2026: Content Collections and Server Islands, Updated for Astro 7

A quick note before anything else: if you are searching for Astro 5, the current release is Astro 7.2. Content Collections and Server Islands both arrived in Astro 5 and are still core features, so what you are looking for still exists — but two major versions have shipped since, and some of it works differently now.

This guide covers both: how these features work today, and what changed on the way here.

What Astro is for

Astro ships zero JavaScript by default. A component renders to HTML at build time and that is what the browser receives — no hydration, no framework runtime, nothing to download.

You then opt into interactivity per component, which is the islands architecture:

---
// src/pages/index.astro
import Header from '../components/Header.astro'
import SearchBox from '../components/SearchBox.jsx'
---

<Header />                       <!-- static HTML, 0 KB JS -->
<SearchBox client:visible />     <!-- hydrates when scrolled into view -->

Only SearchBox ships JavaScript, and only once the user scrolls to it. On a content site that is the difference between a few kilobytes and a few hundred.

Content Collections

Collections give your Markdown a schema, validated at build time. A typo in frontmatter fails the build rather than rendering "undefined" in production.

// src/content.config.ts
import { defineCollection, z } from 'astro:content'
import { glob } from 'astro/loaders'

const blog = defineCollection({
  loader: glob({ pattern: '**/*.md', base: './src/content/blog' }),
  schema: z.object({
    title: z.string().max(60),
    publishedAt: z.coerce.date(),
    draft: z.boolean().default(false),
    tags: z.array(z.string()).default([]),
  }),
})

export const collections = { blog }

---
import { getCollection } from 'astro:content'

const posts = (await getCollection('blog', ({ data }) => !data.draft))
  .sort((a, b) => b.data.publishedAt.valueOf() - a.data.publishedAt.valueOf())
---

<ul>
  {posts.map(post => (
    <li><a href={`/blog/${post.id}`}>{post.data.title}</a></li>
  ))}
</ul>

The title: z.string().max(60) line is worth copying. It makes an over-long SEO title a build failure instead of something you discover in Search Console months later.

Two things changed since Astro 5 here. The config file moved to src/content.config.ts, and collections now use explicit loaders — glob() for files, or a custom loader for a CMS or API. That last part matters: a collection is no longer tied to local Markdown.

Server Islands

Server Islands solve a specific and common problem: a page that is almost entirely static except for one personalised fragment.

Without them you choose between rendering the whole page per request — losing your CDN cache for the sake of one element — or fetching that element client-side, which means a loading spinner and a layout shift.

---
import Cart from '../components/Cart.astro'
---

<ProductGrid />                          <!-- static, cached -->
<Cart server:defer>
  <CartSkeleton slot="fallback" />
</Cart>

The page ships from cache immediately with the skeleton in place; the cart is rendered on the server and streamed in separately. You keep the CDN cache on 95% of the page and still get personalisation.

The fallback slot is not optional in practice — without it users see a gap where the island will land.

What changed since Astro 5

Astro 7 is a speed release rather than a new mental model. The headline is Vite 8 bringing Rolldown, a Rust bundler that is far faster than Rollup — on a large content site the build time difference is the kind you notice on every deploy.

If you run a big collection, Astro 7.1's deferRender is worth knowing about: entries are stored without being rendered during sync, which cuts memory use on sites with thousands of pages.

Upgrading from Astro 5

npx @astrojs/upgrade

Go one major at a time — 5 to 6, then 6 to 7 — and read each upgrade guide rather than jumping. The common friction points are integrations that have not kept pace and any code depending on Rollup-specific bundler behaviour, since Rolldown is a different implementation.

When Astro is the wrong choice

• Highly interactive applications. A dashboard where nearly everything is dynamic fights Astro's model. Every component becomes an island and you lose the benefit.
• Heavy shared client state. Islands are isolated by design. Sharing state across many of them means adding a store and working against the grain.
• Your team is deep in one framework's ecosystem. Astro supports React, Vue and Svelte, but framework-specific routing and data libraries often assume they own the page.

Astro is exceptional for content: documentation, blogs, marketing sites, e-commerce catalogues. The more of your page that is static, the more it wins. That is a genuine strength, not a limitation — but it does mean the fit is specific.

Frequently asked questions

What is the latest version of Astro?

Astro 7.2. If you are reading about Astro 5, it is two majors behind — the features still exist, but the bundler, routing and content collection APIs have moved on.

What is the difference between Astro 5 and Astro 7?

Astro 7 is primarily a speed release: Vite 8 with the Rolldown bundler, stable route caching, stable advanced routing, src/fetch.ts, a background dev server and structured JSON logs. The mental model is unchanged, so upgrading is mostly mechanical.

What are Server Islands in Astro?

A way to keep a page cached while rendering one part per request. Mark a component server:defer with a fallback, and the static page ships from cache while that component is streamed in from the server.

How do Content Collections work?

You declare a collection with a loader and a Zod schema in src/content.config.ts. Astro validates every entry at build time, so a bad date or a missing title fails the build instead of reaching production, and queries come back fully typed.

Is Astro good for SEO?

Yes — pages are server-rendered HTML with very little JavaScript, so they are fast and trivially crawlable. That removes a technical obstacle; it does not substitute for good content, metadata and internal linking.

Can I use React with Astro?

Yes, along with Vue, Svelte, Solid and others, and you can mix them on one page. Each is rendered to HTML and only hydrates if you add a client: directive.

Should I use Astro for a web application?

Usually not. Astro is built for content-heavy pages that are mostly static. For a dashboard or anything highly interactive, a framework designed around client state will fit better.

How do I upgrade from Astro 5 to 7?

Run npx @astrojs/upgrade and move one major at a time, reading each upgrade guide. Watch for integrations that lag behind and anything relying on Rollup-specific behaviour, since Astro 7 bundles with Rolldown.