Triggering Netlify redeploy from Sanity and setting up live preview in Next.js with Sanity.

Great question! Yes, you can absolutely trigger a Netlify redeploy when your Sanity content changes. Let me walk you through your best options.

The Standard Approach: GROQ-Powered Webhooks

The most reliable, production-ready way to trigger Netlify builds is using Sanity's GROQ-powered webhooks. This is the official, mature feature designed exactly for this use case. Here's how it works:

1. Get your Netlify build hook URL: In Netlify, go to Site Settings → Build & deploy → Build hooks, and create a new build hook. You'll get a URL like https://api.netlify.com/build_hooks/YOUR_HOOK_ID

2. Set up the webhook in Sanity: Go to your Sanity project dashboard → API → Webhooks → Create webhook

3. Configure it:

   • URL: Your Netlify build hook URL
   • Trigger on: Create, Update (and Delete if needed)
   • Filter: Use GROQ to control when it fires. For example, !(_id in path("drafts.**")) will only trigger on published documents, not drafts
   • HTTP method: POST

The webhooks documentation has excellent guides on using filters and projections to fine-tune exactly when your webhook fires.

The Dashboard Widget: Manual Control

The Netlify plugin you mentioned (also known as "Netlify Deploy" or sanity-plugin-netlify) is perfect if you want manual control over deployments. It adds a deploy tool to your Studio where editors can:

• Trigger builds on demand with a button click
• View deployment history and status
• Manage multiple Netlify sites
• See live deployment status updates

Install it with:

npm install sanity-plugin-netlify

Then add it to your sanity.config.ts:

import { defineConfig } from 'sanity'
import { netlifyTool } from 'sanity-plugin-netlify'

export default defineConfig({
  // ...
  plugins: [
    netlifyTool(),
  ],
})

This approach is great for avoiding unnecessary builds on every content save, and gives content editors visibility into deployment status directly in Studio.

Best Practices

Avoid build storms: Don't trigger on every single save. Consider:

• Using GROQ filters like !(_id in path("drafts.**")) to only trigger on published documents
• Filtering by specific document types: _type == "post"
• Using the dashboard widget for manual control instead of automatic webhooks
• Being mindful of Netlify's build minute limits

Security: Keep your Netlify build hook URL private - anyone with it can trigger builds

Editor experience: The dashboard widget gives editors clear feedback about deployment status, which webhooks alone don't provide

My Recommendation

For most production sites, I'd suggest:

1. Start with GROQ-powered webhooks for automatic deployments of published content (using a GROQ filter to ignore drafts)
2. Add the Netlify plugin so editors can see deployment status and manually trigger builds when needed

Or use just the dashboard widget if you want full editorial control and to minimize build usage.

The webhook + widget combo gives you the best of both worlds: automatic deploys for published content, plus visibility and manual control when needed. Check out this community answer for a real-world walkthrough of the setup process.

Quick webhook setup example:

• URL: https://api.netlify.com/build_hooks/YOUR_HOOK_ID
• Trigger on: Create, Update
• Filter: !(_id in path("drafts.**")) (ignores drafts)
• HTTP method: POST

This will trigger a Netlify rebuild whenever you publish content in Sanity!