DesignSetGo apps
How it works Examples Docs Pricing Blog WP Blocks Install free

Blog /

Keep WordPress for the blog, vibe-code the rest? Try one site instead of two.

By Nealey

You vibe-coded your homepage. Maybe in Lovable. Maybe v0. Maybe Claude Code or Cursor with an Astro project. The interface came out good enough that you stopped reaching for a theme.

You also want a blog. Not because you love writing one. Because Google still rewards a real one, your customers still expect a Blog link in the footer, and your competitors are still publishing.

WordPress is the default answer for the blog half. Open-source, every host on Earth runs it, every plugin you might want already exists, every editor your client has ever met starts with wp-admin.

The natural plan then becomes: two sites. Your vibe-coded thing on Vercel or Netlify or wherever. A separate WordPress install for the blog, on a subdomain or behind a reverse proxy.

That plan is not wrong, exactly. It is more expensive and more fragile than people remember, and there is a one-site shape that costs less and breaks less. This post is about both.

Why the two-site plan starts looking attractive

It feels modular. The front-end is yours. The blog is WordPress doing what WordPress is good at. You imagine you can change either side without touching the other.

That is the marketing version. The lived version has more cables.

  • Two hosts to pay for. Vercel Pro at $20/mo per member, plus whatever the WordPress host costs. Often two database providers, depending on the front-end stack.
  • Two SSL certs, two DNS records, two backup schedules.
  • Authentication that lives in one place but needs to be recognized by the other if you ever want a signed-in reader to feel signed-in in both places.
  • Cookie scope problems on subdomain splits. Login on yoursite.com does not see the cookie set by blog.yoursite.com unless you go out of your way.
  • Two analytics setups, two consent banners, two cookie policies, two tag managers.
  • An SEO sitemap that does not actually unify across hosts unless you put it there by hand.
  • A theme that drifts. The vibe-coded site has one button style. The WordPress blog has a different one. Every post looks visibly off-brand by month four because nobody is updating the theme.

None of this is hypothetical. Anyone who has shipped a “main site + WordPress blog” split has lived all of it.

The shape that avoids the split

The alternative is to keep one WordPress install. Your blog lives where blogs live in WordPress: at /blog, with whatever theme you want, with the editor your client already knows.

The rest of the site is your vibe-coded bundle. It deploys into the same WordPress install as a DesignSetGo App, mounted at the site root. WordPress hands /blog, /wp-admin, /wp-json, and the feeds to itself. Every other URL on the domain is your app.

In the manifest it is two lines:

"mount": { "mode": "root" }

That tells DesignSetGo Apps: this is the front-end. Serve my routes for /, /pricing, /about, /contact, anything I declare. Leave the rest to WordPress. The blog stays at /blog. The admin stays at /wp-admin. The RSS feed at /feed stays exactly where Google has been crawling it.

Same domain. One SSL cert. One database. One auth system. One sitemap. One theme conversation, because the vibe-coded front-end is the theme. The blog can pull the same buttons, same fonts, same nav by importing the same CSS or by reading the bridge for site metadata. It will not drift, because there is no second host to drift toward.

What you actually keep from each side

You keep the part of WordPress that is good and lose the part you do not want.

What stays from WordPress:

  • The editor your client already knows.
  • The post types, categories, tags, RSS feeds, archive pages, SEO plugin, sitemap, search.
  • Roles and capabilities for who can publish what.
  • Comments, if you want them. Pingbacks, if you really want them.
  • Every plugin you would have installed for the blog half (Yoast, Rank Math, Akismet, Newsletter Glue, whatever).

What stays from the vibe-coded side:

  • The actual interface you spent the weekend on. Real HTML, real URLs, real meta tags, crawlable.
  • Whatever stack you built it in. Astro, plain HTML, a Lovable export, a v0 export, a Claude Code project, a Bolt project. If it builds to static files, it deploys.
  • Your design system. Your fonts. Your motion. Your copy.

What you do not have to build:

  • A second authentication system.
  • A headless content API and the cache that backs it.
  • A reverse proxy with rewrites that you forget the syntax for every six months.
  • A handoff document explaining to the client which CMS edits which page.

How the deploy actually works

The fastest path is from Claude Code or Cursor, where you probably already built the front-end.

npx designsetgo apps init
# scaffolds dsgo-app.json with mount.mode = "root"

# edit your front-end as normal until it is ready

npx designsetgo apps login
npx designsetgo apps deploy --site https://yoursite.com

That copies your build output into the WordPress install, registers the routes you declared, and exposes them at the URLs you specified. Five minutes from cold to live.

If you would rather not use the CLI, the WordPress admin has an HTML importer that takes a zip of your built front-end and does the same thing through the dashboard. Same result, no terminal.

The blog is already there. You did nothing to it. Your visitor goes to yoursite.com, sees your vibe-coded homepage. They click Blog in the nav, see WordPress with whatever theme you put on it. Same domain, same login, same brand.

What this does not do for you

This is not a free move. Three honest limits:

  1. You still need a WordPress host. $5 to $15/mo somewhere. It is not free. The compensation is that you stop paying for the second host you would have used for the front-end.
  2. Root-mounted apps deploy through the CLI on Pro. Free DesignSetGo Apps gives you one app and read-only access; the CLI deploy, scheduled jobs, AI bridge methods, and abilities live in Pro at $149.99/year per site. A 14-day trial unlocks all of it on install, no card. If your front-end is small and you do not mind the admin importer, the free runtime is enough to host the bundle.
  3. Only one app per site can claim root. That is a deliberate constraint; “what is the homepage” cannot be a question with two answers. A second large surface mounts at a prefix like /app/whatever.

That is the entire footnote section.

The honest comparison

The two-site plan is right when:

  • You have an existing front-end on a separate host already in production and the migration cost is higher than the recurring split-tax.
  • Your front-end is a JavaScript app that you actively redeploy multiple times per day, and you do not want the WordPress install to gate that cadence.
  • You have a dedicated team for each side and the org chart already maps to it.

The one-site plan is right when:

  • You are starting fresh and the front-end has not gone live yet.
  • The blog is the second priority, not the main reason for the site.
  • You want the brand, auth, and SEO to be one thing.
  • You are the only one maintaining it and a second host is a second pager.

If you are the second case, run one site.

Related reading

Keep reading

More from the blog.