Why Publishing in Sanity Didn’t Update Our Gatsby Site

Diogo Oliveira — Fri, 30 Oct 2026 11:45:30 +0000

I recently updated an article on the RankingPT blog. The revised text was published in Sanity, but the live website still showed the old wording and was missing a new link.

The article’s URL returned 200. There was no obvious error page. The content was simply out of date.

The missing step

Our site uses Sanity for content, Gatsby to generate pages, and Netlify to host them. Publishing in Sanity updates the content available to Gatsby. It does not, by itself, replace the HTML that Gatsby generated during the previous production build.

In development, our Gatsby configuration watches for Sanity changes. That watch mode is disabled for production. The live article therefore keeps showing the version captured by the last build until a new build runs.

The sequence we needed was:

Publish the article in Sanity.

Run a new production build that reads the published content.

Publish the resulting Gatsby pages through Netlify.

We had completed step one. Nothing was triggering step two.

How we diagnosed it

First, we checked the published Sanity document. It contained the revised wording and the new link, so the edit had been saved.

Next, we checked Netlify’s deploy history. No build had started after the Sanity publication. That explained why the live page still contained the old text: the production site was serving HTML generated before the edit.

Finally, we triggered a new production build from our main branch. The Git commit was the same as in the previous build; the content Gatsby fetched from Sanity was newer. Once that deploy was published, the live article showed the corrected wording and link.

This was a useful distinction: a successful CMS publication and a successful website publication are two separate events in a static site workflow.

What we’ll improve

For now, we know to check the production deploy after publishing an article. Longer term, we want a reliable trigger for rebuilding the site when relevant content is published.

A Sanity webhook and a Netlify build hook are a common way to connect those events. We haven’t configured that automation yet. Our Netlify setup also enforces production deployments through the Git branch, so we need to verify that any proposed trigger works with that rule before relying on it.

Whatever trigger we choose, the final check will be the live page: confirm the new text appears, the links work, and the production deploy completed successfully.

Takeaway

If Sanity says “published” but a Gatsby page still shows old content, check when the last production build ran. A working page and a 200 response tell you the page is available; they don’t tell you it contains the latest CMS content.

DEV Community: Diogo Oliveira

Why Publishing in Sanity Didn’t Update Our Gatsby Site