How to publish a blog post to Sanity

To publish blog posts to Sanity automatically, you need code that creates each post as a new document through Sanity's API, so most teams instead have the post prepared ahead of time and publish it in Sanity Studio, which takes only a few minutes when every field is ready. Sanity is a headless content management system. It stores your content as documents in a dataset, and your website's code, often a Next.js site, fetches those documents with Sanity's query language, GROQ, and builds a page from each one at an address like yoursite.com/blog/your-post-slug.

Sanity differs from most CMSs in one way that shapes this whole job. The schema, meaning the list of document types and the fields each one has, is written in code inside your Studio project rather than set up in a dashboard. So your post type has exactly the fields your developers gave it. A typical one has these:

• A title
• A slug, which stores the end of the post's address
• A body, stored as Portable Text, Sanity's format for rich text
• A short excerpt or summary
• A main image, with an alt text field
• An author, which is a reference to a separate author document
• Categories, which are references to category documents
• A publish date
• An SEO object on many sites, with a meta title and meta description

There are a few ways to get a post in. Most teams use the Studio: an editor creates a new post document, fills in the fields, and clicks Publish. Until then, Sanity keeps the post as a draft, a separate copy whose ID starts with drafts., and publishing replaces the live version with it. Depending on your plan and Studio version, you can also schedule a document to publish at a set time. Developers can skip the Studio entirely and create documents through Sanity's HTTP API or its official client libraries, which is how teams wire up publishing from another tool. Sanity also offers its own AI features inside the Studio, such as AI Assist, which fills in fields from instructions your team writes.

Each of those routes moves content in, but none of them decides what the post should say, which slug fits your other posts, which author it belongs to, or which older posts it should link to. Portable Text adds one more trap. It stores every paragraph and heading as a separate block, so a body pasted from a tool that sends plain text arrives as one long run of paragraphs with no headings.

The last step depends on your site. A site that queries Sanity on every request shows a new post right away. A site built ahead of time shows it only after the next rebuild, which usually starts from a Sanity webhook that calls your hosting provider when a document is published.

A good result is a post that reads as if your best editor entered it. Every field your site displays is filled in on purpose, the body keeps its headings and links, the author and categories point to the right documents, and the post appears at the address you expect.

Kite does that work for you. It learns how your posts are built, writes the post to fit each field, hands your editor a post that's ready to publish, and checks the result on your site.

Start by telling Kite which post you want on your Sanity blog. You can ask it to write one:

"Write a post on how to choose payroll software for a 20-person company, for our Sanity blog."

Or you can hand it a draft your team already wrote:

"Get the Google Doc I just shared ready for our Sanity blog, with Priya as the author and the Guides category."

Kite is an AI marketer. It researches your business, builds a growth strategy, and ships the work that brings you new customers. By the time you ask, it already knows your brand voice, your products, your customers, and the questions your buyers ask from that research, so a post it writes sounds like you and links to the pages you care about. You can work with Kite in your browser or in Slack.

Connect your Sanity project so Kite can read your existing posts. You connect it with your Sanity project ID and an API token from your project's settings. Choose a token with the Editor role, because the Viewer token Sanity offers by default can read your documents but can't change them, and Kite needs the Editor role to change the wording of published posts later. Kite checks that the token can reach the project before it relies on the connection. To let Kite change text in posts that are already live, also import your website into Kite from its GitHub repository. Kite recognizes that the site reads its content from Sanity and connects the two.

Kite shows you the finished post in the conversation before anything happens in Sanity. Approve it, ask for changes, or tell Kite who on your team publishes in the Studio.

Kite starts by reading your published posts, because Sanity has no API that describes a schema; the schema lives in your Studio's code. Through your Sanity connection, Kite runs GROQ queries against your dataset to find your post documents and read every field they hold. That tells it which fields your post type actually has, which ones your team always fills in, and which ones your site seems to rely on.

The same reading shows Kite your conventions. It looks at how your slugs are formed, how long your excerpts run, how often your posts use headings and lists, and how your meta descriptions are written. It also lists the author and category documents your posts point to, so it can use the same ones. Kite reads only published documents, so posts your editors are still drafting in the Studio stay as they are.

Kite checks your dataset before it writes, so the new post doesn't repeat one you already have or collide with an existing address. It searches your posts for the same topic, and when it finds one, it tells you and suggests updating that post instead. It also checks that the slug it plans to use isn't already on another document. By default the Studio flags a slug that another post of the same type already uses, so catching the clash first keeps your editor from running into that error when they go to publish.

Kite researches the topic before it writes, so the post answers what readers actually search for. It looks at search demand for the topic, the questions people ask around it, and the pages that rank today, then picks an angle and writes a short brief. You can review the brief before Kite writes, or let it go straight to the draft.

Kite writes in your brand voice, and it opens the post with a direct answer to the main question, because that's the passage search engines and AI answers are most likely to quote. It links to your related posts and product pages where a reader would want them next. When you hand Kite a finished draft instead, it keeps your words and focuses on fitting them to your fields.

Kite prepares the post field by field, matching the fields and conventions it found in your existing posts. A finished post usually includes these:

• Title. The headline, written the way your other titles are.
• Slug. A short address made from the post's main idea rather than the full title, formed the way your other slugs are.
• Excerpt. A summary that reads well on its own, at the length your other excerpts run.
• Body. The article with real headings, lists, and links, formatted so it keeps its structure when pasted into the Studio's Portable Text editor.
• Main image and alt text. A featured image in your brand's style, made by Kite or chosen from images you supply, with alt text that says what the picture shows.
• Author and categories. The names of the existing author and category documents to select, such as the person you named or the author of your recent posts on similar topics.
• Publish date. The date the post should carry, when your post type has that field.
• SEO fields. A meta title and a meta description written for search results, placed in your SEO object when your post type uses one.

When the person or category you named doesn't exist in your dataset yet, Kite tells you rather than inventing one, so your editor can create it first.

Your editor publishes the post in Sanity Studio, because Kite's Sanity connection changes documents that already exist rather than creating new ones. Once you approve the post, Kite hands it over in the conversation with each field labeled the way it's labeled in your Studio, in the order your form shows them. Your editor creates a new post document, pastes in each field, picks the author and categories Kite named, uploads the main image, and clicks Publish. With every field already written, this takes a few minutes.

If your team schedules posts, your editor can set the publish time in the Studio instead of publishing right away. Kite can include a suggested date and time based on when your other posts go out.

Kite checks the post after your editor publishes it, so you know it reached your site and not just your dataset. It reads the published document back from Sanity and compares each field with the version you approved, which catches a field that was skipped or a body whose headings didn't survive the paste. Then it opens the post's address on your site and checks that the title, body, image, and author appear the way they do on your other posts. If your site is built ahead of time and the post isn't there yet, Kite tells you the page is waiting on a rebuild instead of reporting it as live.

Kite can change the wording of a published post directly through your Sanity connection when your site is imported into Kite. Ask it to fix a typo, rewrite the opening, update a figure, or sharpen the meta description, and it finds the exact text in your published documents, writes the new text, and reads the document back to confirm the change is stored. Because a change to a published Sanity document goes live as soon as it's saved, Kite asks you to confirm when the text it's looking for appears in more than one place or it can't be sure it found the only copy.

From there, Kite can keep the post working. It can turn the article into social posts for your connected accounts, or ask the questions the post answers in ChatGPT, Gemini, Perplexity, and Claude to see whether answer engines start citing it. If you want a steady rhythm, ask Kite to research and write a new post every week, and it will bring each one to you for your approval.

When the work is done, your Sanity dataset holds a complete new post, your site shows it, and your conversation with Kite records what was published and how it was checked.