How to Add a Blog to a Website Without a Full CMS Migration

You have a website that already works. The design is done, the product pages convert, and the stack is the one your team chose on purpose. Then someone asks for a blog, and every tutorial you open tells you to install WordPress, move the whole site onto a builder, or rebuild on a platform you did not pick. Adding a blog should not mean replatforming a site that already works. It does not have to, and this guide shows the paths that skip the migration entirely.

Quick takeaways

• You do not need to migrate. A blog is content plus a place to render it, and you can add both to an existing site without touching your current stack.
• Put the blog on a subdirectory (yoursite.com/blog), not a subdomain. In practice it consolidates domain authority: Salesforce roughly doubled blog traffic after moving its blog from a subdomain to a subdirectory.
• There are five real options: WordPress in a subdirectory, a subdomain CMS, a JavaScript embed widget, a static-site rebuild, or a headless CMS delivered over a REST API.
• The lowest-disruption path for a custom site is a headless CMS: your front end stays exactly as it is, and a new /blog route fetches article JSON from a standard REST API.
• Kamaan delivers blog content as standard JSON to Next.js, Nuxt, SvelteKit, Astro, React, or Vue, so you keep your design and add a blog with no migration. Starter is the entry tier, first month free.

Why adding a blog turns into a full migration (and why it should not)

The trouble starts with a category error. Most advice treats "add a blog" as "adopt a blogging platform," so the recommendation is always to install a system that wants to own the whole site. WordPress is the usual suspect: the fastest way to add it is to drop it at the root or a subdirectory, at which point you are running a second content system, a second theme, and a second thing to patch and secure next to the product you actually ship.

A blog is really two separate jobs. One is managing content: writing posts, editing them, attaching SEO fields, and scheduling. The other is rendering that content: turning it into pages a reader and Google can see. The migration trap comes from picking a tool that couples those two jobs and then insists on rendering the pages its own way, in its own theme, on its own URL scheme.

Once you split the two jobs, the migration disappears. You can manage content in one place and render it inside the site you already have. Your existing front end stays the front end. The only new thing is a blog section that pulls its content from somewhere. That is the whole idea behind a headless CMS, and it is why "headless" and "no migration" tend to be the same conversation. For the longer version of that argument, see WordPress vs headless CMS: when each one wins.

The five ways to add a blog to an existing website

Every real option for bolting a blog onto a live site is a variation on one question: who renders the blog pages, and how much of your current stack do you have to give up to get there. Here they are side by side.

The WordPress and subdomain routes both add a second system, which is fine if you want a distinctly separate blog but heavy if you just want posts under your own domain. The embed widget is genuinely quick, but the posts are injected by client-side JavaScript, which limits how much control you have over markup, styling, and how cleanly search engines see the content. A static rebuild is a good fit only if your site is already a static build. For a custom app that you do not want to disturb, the headless-over-REST route is the one that changes the least, which is why the rest of this guide focuses there. If you are integrating into a product specifically, the developer-focused guide to adding a blog to a SaaS product goes deeper on the same path.

Where the blog should live: /blog beats blog.yoursite.com

Before you wire anything up, decide the URL. This choice outlives the tool, so get it right once. The default should be a subdirectory on your root domain (yoursite.com/blog), not a subdomain (blog.yoursite.com).

Google's official line is that it treats subdomains and subdirectories equally. What practitioners repeatedly measure is different. A subdirectory keeps every post under one domain, so backlinks and internal links compound into a single authority profile instead of being split across two properties. Real migrations back this up: when Salesforce moved its blog from a subdomain to a subdirectory, organic traffic roughly doubled, and Embarque documented a company that moved the other way and lost about 47% of its organic traffic. The exception is narrow: use a subdomain only when the section is genuinely a separate business unit or needs its own tech stack and hosting.

There is a second reason a subdirectory wins that matters if you ever go multilingual: hreflang is far simpler under one domain. A path like /es/blog sits cleanly under your root, and search engines map the language variants without cross-site guesswork. The full breakdown lives in subdirectory vs subdomain for SEO. Pick the subdirectory, then choose a tool that can actually serve content into it.

The headless approach: keep your front end, add a /blog route

Here is the path that avoids a migration on a custom site. You manage articles in a hosted CMS, and your front end fetches them over a REST API and renders them with your own components. Nothing about your product code, design system, or hosting changes. You are adding routes, not replacing a site.

The shape of the work is the same in any modern framework:

1. Add a blog CMS account and create your first posts. In Kamaan this is the Article CMS: rich-text editing, SEO metadata fields, and scheduling, with the content stored centrally rather than baked into your codebase.
2. Add two routes to your app: a list route at /blog and a detail route at /blog/[slug]. These are ordinary pages in your framework, styled with your existing components.
3. Fetch the content as JSON from the REST API in each route. A standard fetch() is all it takes, because the API returns plain JSON. Kamaan's REST API Delivery serves content this way to Next.js, Nuxt, SvelteKit, Astro, React, or Vue.
4. Render it with your own markup, so the blog inherits your header, footer, fonts, and layout automatically. The reader never sees a seam between your product and your posts.
5. Point sitemaps and internal links at the new /blog paths so the section is crawlable and linked from your main navigation.

The fetch itself is deliberately unremarkable. The pattern in a React or Next.js route looks like this (the exact base URL and route names for your account come from the Developer Setup Documentation):

// Server-side fetch in a Next.js route
export async function getBlogPosts() {
  const res = await fetch(`${KAMAAN_API_BASE}/articles`, {
    headers: { Authorization: `Bearer ${process.env.KAMAAN_API_KEY}` },
  });
  const { articles } = await res.json();
  return articles; // plain JSON: title, slug, body, published_at, SEO fields
}

Because it is a standard JSON REST API, there is no proprietary query language to learn for a blog and no SDK you are locked into. Any framework that can call a REST endpoint can render the content. The honest time budget: the CMS-side benchmark from publishing to live is roughly 14 minutes, and first-time front-end wiring on something like Next.js takes about 40 to 60 minutes. Kamaan manages and delivers the content; your front end owns the rendering, which is exactly what keeps your design intact. For the framework-specific version, see the Next.js integration walkthrough and the deeper blog API guide.

Choosing a headless CMS for the job

Once you commit to the headless route, the tool choice comes down to how much setup ceremony it demands, how it delivers content, and what it costs when you run more than one blog. The table compares the common hosted options a founder or developer actually evaluates.

The gaps are specific, not slogans. Contentful is mature but bills per space, so three product blogs mean three spaces and three bills starting around $300 a month each. Sanity wants schema-as-code, which is configuration you should not have to write for a plain blog. Ghost publishes beautifully but has no native multilingual, so extra languages need extensions or hacks. Strapi is open source and flexible, but you run and patch the server yourself. Kamaan's angle is the opposite of all four: a no-config Article CMS, a plain REST API into any framework, and native multilingual delivery, managed so there is no server to run. If you are weighing the self-hosted route specifically, multi-site CMS management covers running several blogs from one account.

Real-world scenarios

A solo founder runs one SaaS product on a Next.js marketing site and wants a blog for SEO without touching the design. She creates posts in Kamaan's Article CMS, adds a /blog and /blog/[slug] route, and fetches the content over REST API Delivery so the posts render inside her existing layout. Her front end never changes, and Kamaan Starter covers her one site, first month free.

A three-product founder already has three live marketing sites and no appetite to stand up three separate blogs. He manages all three product blogs from one Kamaan account with Multi-Site Management, switching between them in a click instead of logging into three dashboards. Each blog renders inside its own product site over the same REST API, and on the Growth tier his English posts go live in every language on the plan with correct hreflang the moment he publishes. He can even run the writing and publishing from Claude or ChatGPT through the MCP Server for CMS, without opening a dashboard at all.

A blog is content plus a place to render it. Split those two jobs and the migration disappears: keep your front end, and let the CMS just deliver the content.

FAQ

How do I add a blog to an existing website without WordPress?

Manage your posts in a headless CMS and fetch them into your current site over a REST API. You add a /blog route to the app you already run, render the content with your own components, and skip installing WordPress or any second system. Kamaan delivers blog content as standard JSON to Next.js, Nuxt, SvelteKit, Astro, React, or Vue.

Should my blog be on a subdomain or a subdirectory?

A subdirectory (yoursite.com/blog) is the safer default. It consolidates domain authority under one property, keeps internal linking tight, and makes hreflang simpler if you go multilingual. Reserve a subdomain for content that is genuinely a separate business unit or needs its own tech stack.

Can I add a blog to a static HTML or static-generated website?

Yes. If you use a static-site generator like Astro or Next.js in static mode, you fetch the posts from a REST API at build time and generate the blog pages alongside the rest of your site. The content lives in the CMS, and your build turns it into static pages, so there is no migration and no separate blog platform.

Does adding a headless blog hurt my SEO?

No, as long as your front end renders the content server-side or at build time so search engines get real HTML. A headless CMS actually helps SEO on the placement side, because the blog lives on your root domain in a subdirectory and inherits your site's authority. Kamaan emits SEO metadata fields and, on multilingual plans, correct server-side hreflang.

How long does it take to add a blog to an existing site?

The content side is fast: Kamaan's benchmark from publishing to live is roughly 14 minutes. The one-time front-end wiring, such as adding the routes and fetch calls in a Next.js app, honestly takes about 40 to 60 minutes for a first integration. After that, publishing a new post is just writing it in the Article CMS.

Can I add a blog to more than one website from one account?

Yes. With Kamaan's Multi-Site Management you run several product blogs from a single account and dashboard instead of a separate login and bill per site. The Growth tier covers three sites, Scale covers ten, and Unlimited covers up to 25 sites, all with first month free.

Related on Kamaan

• How to add a blog to your SaaS product. The developer-focused deep dive on wiring a blog into an existing product.
• Blog API: fetch and render CMS content in any framework. How the REST API and JSON shape work in practice.
• Headless CMS Next.js integration. A step-by-step setup from zero to a live blog.
• Subdirectory vs subdomain for SEO. Why /blog on your root domain usually wins.
• WordPress vs headless CMS. An honest look at when each one is the right call.

Start building with Kamaan

Keep your front end. Add the blog.

Kamaan is a headless blog CMS that delivers your content as standard JSON to Next.js, Nuxt, SvelteKit, Astro, React, or Vue, so you add a blog to the site you already have instead of migrating. Manage every product blog from one account, publish once and go live in 99+ languages with correct hreflang, and run it all from Claude, ChatGPT, or any MCP client. Starter covers one site, first month free.

Start free at kamaan.io