:format(webp)){kind=small}
Storyblok is often our first choice for marketing-led websites, because it combines a headless setup with a visual editor that marketers can work in. But the editor is only as good as the structure behind it. Much of what makes a Storyblok site pleasant or painful for marketing is decided before the first line of code: which building blocks exist, how flexible each page type is, who can publish, and how languages work.
This guide covers those decisions from the marketing team's side, so you can shape them with your developers rather than inherit them. It isn't a review of Storyblok as a product.
Start from your pages, not from Storyblok
Before anyone opens Storyblok, list the kinds of pages your website needs and how often you create each one:
Home and core pages, such as services or products, changed a few times a year.
Campaign landing pages, created often and quickly.
Articles and case studies, published regularly with a fixed structure.
Legal and utility pages, rarely touched.
For each type, note the sections that keep coming back: a hero, a feature list, customer logos, a quote, a form, a call to action. That list is the first draft of your building blocks.
Blocks: the building materials
Storyblok builds everything from blocks. A few terms are worth knowing:
Content types are the kinds of pages, such as a landing page or an article.
Nestable blocks are the sections editors place inside a page, such as a hero, a testimonial or a form.
Universal blocks work both as a page of their own and as a section inside other pages, such as a call to action.
Fields are the inputs inside each block, such as a heading, an image or a link.
Good block libraries share a few traits:
Blocks are named after what they do for the reader, such as "Customer quote" or "Pricing table", not after how they look. "Customer quote" survives a redesign; "Gray two-column box" doesn't.
Each block has one clear job. A block with twenty options is hard to use and easy to break.
Fields explain themselves, with help text such as recommended length or image size, so editors don't need a manual.
The library stays small. It is easier to add a block later than to remove one that is used on fifty pages.
Decide how much freedom each page type gets
Not every page should be equally flexible. Storyblok lets developers limit which blocks can be used in each area of a page, so you can decide per page type:
Articles and case studies: a fixed structure with a few optional blocks, so they stay consistent and quick to publish.
Landing pages: wide freedom to combine blocks, because campaigns need it.
Core pages: somewhere in between, with key sections fixed.
Agree on this with your developers early. It is much easier to loosen a structure later than to tighten one after editors have used it.
Roles, approvals and publishing
Write down who should be able to do what:
Who creates and edits content, and in which parts of the site.
Who approves it, for example brand, legal or a product owner.
Who can publish, and whether some pages need a second pair of eyes.
Every Storyblok plan includes a default workflow with three stages: Drafting, Reviewing and Ready to Publish. Custom roles and custom workflows need a Premium or Elite plan, so check your approval process against Storyblok's pricing before you buy.
Languages and markets
If you publish in more than one language or market, decide the approach before the build, because it shapes the structure. Storyblok's internationalization options include:
Field-level translation: one page holds every language. Best when pages are the same in every language, just translated.
Folder-level translation: a separate folder per language or market. Best when markets need different pages or different content.
Space-level translation: a separate Storyblok space per language or market. Best when separate teams run their own markets with a lot of local content.
The approaches can be combined, for example translated core pages with market-specific campaign pages.
Preview and the visual editor
Storyblok's visual editor shows the real page while you edit it. It has to be connected to your website by your developers. Before launch, check that:
every page type opens in the visual editor,
clicking a section in the preview opens the right block,
drafts are visible in preview but never on the live site.
SEO and housekeeping
A few fields save a lot of work later:
Page title, description and social sharing image on every page type.
Alt text for images, written by the editor who knows what the image shows.
Redirects that editors can manage, so a renamed page doesn't need a developer.
A naming convention for folders and URLs, agreed before the first hundred pages exist.
Train the team and write it down
A short editor guide pays for itself. It should cover how to create each page type, how to publish and unpublish, how to add a redirect and who to ask for help. For this resource hub, for example, we wrote a one-page guide on creating, ordering, publishing and redirecting articles before the first one went live.
What it looks like at scale
For MeisterTask's marketing website, the team built the homepage and core feature pages first, as reusable components configured in Storyblok, with design working one sprint ahead of development. Later pages reused those components. See the MeisterTask case study. Libraries tend to grow unchecked. When Perk rebuilt its site, its components had drifted across several rewrites, and the new front end mapped 205 Storyblok components to 29 page templates (Perk case study). A small, well-named library is easier to keep consistent from day one.
This planning is the first step in our headless CMS website projects. If you are moving existing content across, our tips for a content migration to Storyblok cover that part.