How to publish a blog post to Storyblok

To publish blog posts to Storyblok automatically, you need a script that creates each post as a new story and publishes it through Storyblok's Management API. Most teams instead have the post prepared ahead of time and publish it in Storyblok's editor, which takes only a few minutes when every field is ready.

Storyblok is a headless content management system. It stores your content as stories, and your website's code, often a Next.js, Nuxt, or Astro site, fetches the published version of each story and builds a page from it. Stories live in folders, so a post called "pricing-your-first-plan" in a folder called "blog" gets the full path blog/pricing-your-first-plan, which usually becomes yoursite.com/blog/pricing-your-first-plan.

Every story is built from a content type, which Storyblok calls a block, and your team defines its fields in the Block Library inside Storyblok. That means your blog content type has exactly the fields someone gave it. A typical one has these:

• A title
• A teaser or excerpt, which often appears on your blog index
• A body, usually a rich-text field, or a Markdown field on some sites
• A featured image, picked from your Storyblok asset library, with alt text stored on the image
• An author, often a reference to a separate author story
• A publish date your site displays
• An SEO field on many sites, with a meta title, meta description, and share image

Storyblok also keeps tags on each story, and the story's name and slug sit outside the content fields, in the story's own settings.

There are a few ways to get a post in. Most teams use the editor: someone creates a new story in the blog folder, chooses the blog content type, fills in the fields, and clicks Publish. Until then, Storyblok keeps the story as a draft, and Publish makes the current version the one your site reads. Depending on your plan, you can also schedule a story to publish at a set time. Developers can skip the editor and create stories from a script with Storyblok's Management API, using a personal access token, which is how teams wire up publishing from another tool. Storyblok also offers AI features inside the editor that help draft or translate the text in a field.

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. The rich-text field adds one more detail. Storyblok stores rich text as structured content rather than plain HTML, so a body that arrives as plain text, from a script or a tool that strips formatting, lands as one long run of paragraphs with no headings.

The last step depends on your site. A site that requests stories from Storyblok on every visit shows a new post right away. A site built ahead of time shows it only after the next rebuild, which usually starts from a Storyblok webhook that calls your hosting provider when a story 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 tags match the rest of your blog, and the post appears at the address you expect.

Kite does that work for you. It learns how your blog stories 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 Storyblok blog. You can ask it to write one:

"Write a post on how small clinics should choose scheduling software, for our Storyblok blog."

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

"Get the Google Doc I just shared ready for our Storyblok blog, with Sam as the author and the Guides tag."

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, your competitors, 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 Storyblok space so Kite can read your existing posts. You connect it with your space's preview or public access token, plus the region if your space is hosted in the United States. 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 Storyblok and asks for your Space ID and a personal access token from your Storyblok account settings, which is the kind of token that can edit stories. Kite checks that the token can manage the space as soon as you save it.

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

Kite starts by reading your published blog stories, because they show exactly what a complete post looks like in your space. Through your Storyblok connection, it pulls the stories in your blog folder by content type, such as every Article. Storyblok returns each story with its content type and every field it holds, so Kite learns which fields your posts actually use, which ones your team always fills in, and which ones your site seems to rely on. It also reads each story's slug, full path, tags, and first publish date.

The same reading shows Kite your conventions. It looks at how your slugs are formed, how long your teasers run, how often your posts use headings and lists, and how your meta descriptions are written. It reads the tags you already use and follows each post's links to the author stories it points to, so it can use the same ones. When your space uses field-level translations, Kite reads a post in each language to see which fields your team translates.

Kite checks your blog folder 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 your published stories and links for the slug it plans to use. Storyblok won't let two stories in the same folder share a slug, so catching the clash first keeps your editor from running into that error when they create the story.

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 stories. A finished post usually includes these:

• Story name and slug. The name your editors see in the content list, and a short slug made from the post's main idea rather than the full title, formed the way your other slugs are.
• Title. The headline, written the way your other titles are.
• Teaser. A summary that reads well on its own, at the length your other teasers run.
• Body. The article with real headings, lists, and links, formatted so it keeps its structure when pasted into Storyblok's rich-text editor, or written as clean Markdown when your body field uses Markdown.
• Featured 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 tags. The existing author story to select and the tags to apply, such as the person you named or the author of your recent posts on similar topics.
• Publish date. The date the post should show, when your blog content type has that field.
• SEO fields. A meta title and a meta description written for search results, placed in your SEO field when your content type uses one.

Each field is labeled the way it's labeled in your Storyblok editor and listed in the order your editor shows them. When the author or tag you named doesn't exist in your space yet, Kite tells you, so your editor can create it first.

Your editor publishes the post in Storyblok, because Kite's Storyblok connection changes stories that already exist rather than creating new ones. When the post is ready, Kite hands it over in the conversation along with the featured image. Your editor creates a new story in your blog folder, chooses the blog content type, pastes in each field, uploads the image to the asset library with the alt text Kite wrote, selects the author and tags, 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 Storyblok instead of publishing right away. Kite can suggest a 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 Storyblok space. It reads the published version of the story back from Storyblok 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.

Kite can change the wording of a published post directly through your Storyblok 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. Kite finds the story and the exact field inside it that holds the text, writes the new text, and publishes the story in the same step, because Kite sends the change to Storyblok's API with the instruction to publish it in the same request. Then it reads the story back to confirm the published version holds the new words. When the same text appears in more than one story, Kite shows you each match and asks which one you meant.

Storyblok publishes a story as a whole, so any saved but unpublished changes an editor has left in that story go live with Kite's change. If someone is mid-edit on a post, have them finish or publish it before Kite rewrites it.

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 Storyblok space holds a complete new blog story, your site shows it, and your conversation with Kite records what was published and how it was checked.