Do You Actually Need a Headless CMS for Your Blog?

Skip a headless CMS if you write the posts yourself: use Markdown. If someone else writes them, they need an editor, and a headless CMS still leaves you building the blog. That's what DropInBlog is for.

Ask how to add a blog to an Astro or Next.js site, and you get a list. Sanity, Payload, Strapi, Contentful, Directus. Pick one, wire up the API, build some templates, and ship it.

Quick disclosure: I founded DropInBlog and have been building blog software since 2015. I also use it on my own Astro site, so I'm biased, and you should weigh everything below accordingly.

Some of you should skip us too.

Who's going to write the posts?

I started building websites at 19, back when "layout" meant Dreamweaver and a lot of nested tables. That turned into a web agency, and our clients had custom-built sites. Sooner or later, every one of them asked for a blog.

The standard fix was WordPress on a subdomain with a custom theme built to match. It worked. It was also cumbersome. Every one of those installs turned into technical debt: a second site to keep updated and patched, with a theme that had to keep looking like the real one.

That's where I learned that the developer who builds a site is rarely the person who writes its blog. Usually it's someone in marketing, and sometimes it's the founder at 11pm.

If it's just you, use Markdown

If you're the only person writing, and you live in a code editor anyway, you don't need a CMS. You need a folder.

Astro content collections handle this well. One config file:

// src/content.config.ts import { defineCollection } from 'astro:content'; import { glob } from 'astro/loaders'; import { z } from 'astro/zod'; const blog = defineCollection({ loader: glob({ pattern: '**/*.md', base: './src/data/blog' }), schema: z.object({ title: z.string(), pubDate: z.coerce.date(), }), }); export const collections = { blog }; 

Drop Markdown files in src/data/blog, pull them with getCollection('blog'), and you have a blog. Not on Astro? Eleventy, Hugo, and Jekyll have been doing this for years. Hat tip to all of them.

Every post is a commit and a deploy. If you're already deploying the site yourself, that's just how you publish, and your posts get versioned with the rest of your code.

If this is you, you can close this tab. You're set.

If other people write, they need an editor

The moment someone outside the dev team writes, Markdown in a repo gets awkward. They need Git access. They break the front matter with one stray colon. They want to see the post before it goes live.

So you need an editor. There are a lot of ways to get one, and they mostly differ on where the content lives:

All of these are real options. Plenty of good blogs run on each. Payload comes up more than anything else in dev threads right now, and I get why.

But look at the "What you still build" column. With every headless option, the CMS gives you content and an editor. Your app still needs the rest: the post template, the list with pagination, category and author pages, the sitemap, the RSS feed, and the meta tags and schema on every page.

If you already have Sanity, Payload, or something else for the rest of the site, that's fine. A lot of teams keep that CMS and use DropInBlog for the blog, because the blog stays compartmentalized from the rest of the site, and it's already done. Since blogs are all we do, we can go deep on them, instead of the blog being an afterthought in a much larger system.

The difference is our Rendered API. Instead of JSON you have to turn into templates, it returns the finished HTML: the post, the list, categories, authors, the sitemap, the feed, the meta tags. You don't design those pieces yourself. When we ship a new blog feature, it shows up for your marketing team without a frontend pass.

What teams get wrong when they add a blog

The teams that find us usually show up after one of three things: a site migration, a blog nobody wants to touch anymore, or an SEO problem.

Most teams build the post page and call it done. Then the requests start: author pages, categories, a redirect because someone changed a slug. Every one lands in the dev backlog, and the blog becomes a second product nobody planned to maintain.

For us, the hardest part has always been everything around the posts. Matching each site's design. Keeping every page crawlable and indexable.

On Astro, our integration handles that part. Install it and add your keys:

npm install @dropinblog/astro 

# .env DROPINBLOG_BLOG_ID=your_dropinblog_blog_id DROPINBLOG_API_KEY=your_dropinblog_api_key 

Then one entry in your config:

// astro.config.mjs import { defineConfig } from 'astro/config'; import dropInBlog from '@dropinblog/astro'; export default defineConfig({ site: 'https://yoursite.com', integrations: [dropInBlog()], }); 

That registers the blog, category, and author routes, plus a sitemap, RSS feeds, and JSON-LD on every page. It works in static, server-rendered, or Server Islands mode. On a static build, point our build hook at your host's deploy hook. Every publish triggers a rebuild that skips the posts that didn't change.

Your marketing team writes in our editor. Nobody opens a pull request to fix a typo.

An AI assistant can do the same work through our MCP server. Posts come out the way the editor writes them, so they stay easy to open and edit by hand. SEO analysis is the same 0-100 score the panel already shows. Team permissions apply there too: the assistant can only do what that person's role allows in the editor.

When you shouldn't use us

Here's when DropInBlog is the wrong pick:

• You're the only writer and happy in Markdown.
• You're a creator or a newsletter-first publication. There are tools built for that, and we aren't one of them.
• You want something free. We're paid, with a free trial.

If you want the full setup, we have an Astro package and packages for other frameworks.

What's your blog stack, and who actually writes on it?