Adding a Blog to a Site You Built With Lovable, Bolt or v0

Shipping a marketing site with an AI builder takes an afternoon. Making it earn search traffic takes content, and that is where founders get stuck: how do you add a blog to a Lovable site, or a Bolt or v0 site, when the builder gave you a single-page React app and no CMS?

The good news is that you have three workable routes, and none of them requires rebuilding your site. The catch is that the default output of these tools is often client-rendered, which is quietly hostile to search engines. Get the rendering and routing right first, and everything else is straightforward.

Why crawlability is the real problem, not the CMS

Lovable, Bolt and v0 typically generate a React application. Depending on the framework and settings, your pages may be rendered in one of two ways.

Server rendering means the HTML that arrives from your server already contains the article text. A crawler fetches the URL and sees the content immediately. Client rendering means the server sends a near-empty HTML shell plus a JavaScript bundle, and the browser builds the page after loading. A human sees the same result. A crawler often does not.

Google can execute JavaScript, but it does so in a second pass that can lag days behind the initial crawl, and it does not always run cleanly. Other crawlers are worse: many AI assistants and smaller search engines read only the raw HTML. If your blog posts are client-rendered, you are invisible to a growing share of the systems that could send you customers. This matters more each year as answers move into chat interfaces, a shift we cover in more detail in our guide to answer engine optimisation.

Three ways to add a blog to a Lovable site

Option 1: build blog pages into the app itself

The most direct route is to ask the builder to add blog routes to your existing project. Prompt it for a /blog index page and a /blog/[slug] template, with articles stored as Markdown or MDX files in the repository, and with pages statically generated at build time so the HTML is complete before anyone requests it.

The phrase to use in your prompt is "statically generated" or "pre-rendered at build time". If your project is on Next.js, that means static generation for the blog routes. If it is a plain Vite and React setup, ask for a pre-rendering step, or accept that you may need to migrate the blog routes to a framework that supports it.

The upside is full control and no extra services. The downside is that you have just built yourself a small CMS, and publishing a post now means editing files and redeploying. That is fine if you enjoy it. Most founders stop after four posts, not because the writing is hard, but because the workflow adds friction to something that already competes with running the business.

Option 2: run the blog as a separate app behind a routing rule

You do not have to put the blog inside your main project. Most hosts that these builders deploy to, including Vercel, Netlify and Cloudflare, support routing rules that send one path to a different application. Your marketing site keeps serving everything, while requests to /blog and below are proxied to a second app: a lightweight Astro or Next.js blog, a headless CMS front end, or a hosted blogging service.

On Vercel this is a rewrite in vercel.json. On Netlify it is a proxy redirect in _redirects or netlify.toml. On Cloudflare it is a route or a Worker. In each case the visitor and the crawler see one domain, one site.

This separation is genuinely useful. You can redesign or regenerate your marketing site without touching the blog, and the blog can use a framework built for content while your app uses whatever the builder produced.

Option 3: point a path or DNS record at a hosted blog

If you do not want to build or maintain anything, hosted blog services will serve a fully rendered blog on your own domain. You add a single DNS record or routing rule, and articles appear at yourdomain.com/blog or blog.yourdomain.com as server-rendered HTML with sitemaps and feeds handled for you.

This is the drop-in route, and for a solo founder it is usually the honest answer. The trade-off is less control over templates, though the better services style the blog to match your site's colours and typography so it does not look bolted on.

Path or subdomain: where should the blog live?

Given the choice, put the blog at /blog on your main domain rather than on a subdomain. Authority signals consolidate more cleanly on a single host, and internal links between your product pages and your articles carry more weight when everything shares one domain. A subdomain is not fatal, and it is far better than no blog, but if your host supports path-based routing, use it.

Whichever you choose, keep URLs stable. Pick a slug format on day one, something like /blog/plain-descriptive-slug, and never change it without a redirect. Every changed URL without a redirect throws away whatever ranking the page had earned.

Sitemaps and getting your first posts indexed

A sitemap is an XML file listing every URL you want crawled. AI builders rarely generate one, and they never update it when you add pages. You need one that includes your blog posts and updates when you publish.

1. Generate a sitemap at /sitemap.xml. Frameworks like Next.js and Astro have built-in or one-line plugin support; hosted blog services provide their own, which you can reference from your main sitemap.
2. Check robots.txt exists, does not block /blog, and points to the sitemap with a Sitemap: line.
3. Verify your domain in Google Search Console and submit the sitemap. If you have not set it up yet, our Search Console setup guide walks through it in a few minutes.
4. After publishing each of your first few posts, use the URL Inspection tool and request indexing. New sites are crawled slowly, and this nudges things along.

Also confirm each post has its own title tag and meta description. Single-page apps often ship one static set of meta tags for every route, which means all your posts show the homepage title in search results. Server rendering fixes this too, which is another reason it comes first.

A five-minute check before you start writing

• Open a blog post and run the view-source test for the article text.
• Fetch yourdomain.com/robots.txt and confirm nothing blocks the blog.
• Fetch yourdomain.com/sitemap.xml and confirm posts are listed.
• Confirm each post has a unique title tag, not the homepage title.
• Confirm old URLs redirect if you have moved anything.

Once those pass, the technical work is done and the harder question begins: what to write, and how often. The plumbing only pays off when articles flow through it regularly.

Where Helio SEO fits in

Helio SEO is the third option made concrete: we serve a fully rendered, crawlable blog on your own domain via a DNS record or routing rule, styled to match your site, and we write and publish an article a day so the pipeline never sits empty. If you are happy building static blog routes and writing the posts yourself, the steps above are all you need. If you would rather ship product while the blog runs itself, that is the gap we exist to fill.