Everbase
Send your site
sanity with astro

Sanity with Astro

Your team edits structured content in Sanity while Astro renders the website. I connect the content model, page components and publishing workflow so editors know how to preview a draft and when a published change reaches the public page.

Connect Sanity See the setup

Sanity at a glance

What I do
Keep content editing in Sanity and render the website in Astro, with a clear path from draft preview to published page.
Typical setup
Adds 1–2 weeks
How it is bought
Part of a migration scope, or a Continuous development request once the site is yours
Category
CMS

Setup

How I set up Sanity

Sanity is strongest when content is shared across products, apps and websites, and this is the arrangement it was built for: the model lives in one place and anything that needs it queries it. An Astro site is one of those things.

The build queries the documents, resolves the references and renders the pages. Sanity remains the content source, and the public HTML reflects the content at the last successful build. Publishing needs a rebuild trigger, a visible result and a way to handle a failed build.

Portable Text is the work. Each mark, block, embed and custom object becomes a component, and the ones nobody maps render as nothing, so I go through the types the content actually uses rather than the ones the schema permits. Then two things get decided out loud: when an edit reaches the public site, which is when a build runs and can be triggered by a webhook, and how an editor previews a draft without publishing it to find out.

How the handoff works

  1. 01

    Document

    Published in Sanity

  2. 02

    Webhook

    The change leaves the Content Lake

  3. 03

    Map

    Portable Text and references resolved

    Key handoff

  4. 04

    Build

    The page rendered from the document

  5. 05

    Verify

    The rendered page against the document

Why this is the key handoff

One model, rendered. Sanity keeps the model and the editing workflow; the build renders it. The public pages are rendered from the content at build time, so the publishing workflow also needs to trigger and verify a successful rebuild.

Included

What gets connected

  • Sanity documents queried at build, or on demand where a page needs to be current

  • Portable Text rendered as components rather than flattened to HTML

  • References synced in the right order

  • Assets copied or re-hosted where needed

  • Deletes, unpublishes and draft states handled cleanly

Before you add it

What to watch out for

  1. 01

    Portable Text is a decision, not a conversion

    Marks, blocks, embeds and custom objects each need a component to render them, and the ones nobody maps render as nothing at all. I go through the types actually in use rather than the ones the schema allows, because those are rarely the same list.

  2. 02

    Publishing in Sanity is not publishing on the site

    A built site shows what it was built with, so an edit reaches the public page when a build runs. A webhook from Sanity can trigger one, but the relationship has to be deliberate and visible, because nobody wants the answer to "is it live yet" to be a guess.

  3. 03

    Drafts and previews need their own path

    The published build reads published documents, which is correct and is not what an editor wants while writing. Preview is a separate mode reading drafts with its own token, and it is worth building properly rather than leaving editors to publish in order to see.

More tools

Keep exploring

All integrations Astro development Continuous development

Next step

Let me plan your next step.

Send your site

I can scope a migration. Send a brief and I will reply by email with next steps.