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

Blog /

blog.yoursite.com or yoursite.com/blog? A decision for your vibe-coded site

By Nealey

You picked WordPress for the blog half of your vibe-coded site. The next decision is where that WordPress install actually lives on the domain.

There are three real answers. They behave very differently. SEO people, devops people, and your future self all weigh them differently.

This post is the comparison and the recommendation.

Option A: subdomain (blog.yoursite.com)

The simplest plumbing of the three. Two DNS records. Two hosts. WordPress on one, your vibe-coded front-end on the other. No proxy logic.

What you pay for that simplicity:

  • Worst SEO of the three options. Google treats subdomains as related-but-not-the-same authority. Your homepage backlinks do not fully carry into the blog’s domain authority and vice versa. People will argue with this; the working assumption in the SEO trade for ten years has been “same domain beats subdomain when you can choose.”
  • Cookie scope splits. A session cookie set on yoursite.com does not get sent to blog.yoursite.com unless you explicitly scope it to .yoursite.com and arrange the headers carefully. Signed-in readers on the homepage are not signed in on the blog without extra glue.
  • Two analytics setups, two consent banners, two cookie policies, two tag managers. You will copy goals between them and they will go out of sync.
  • Two SSL certs, two DNS records, two backup schedules. Often automated, still two.
  • Hardest to undo. Once blog.yoursite.com/post-slug URLs are indexed and linked, migrating to yoursite.com/blog/post-slug is a redirect map and a six-month traffic dip.

Pick subdomain if you already have it shipped, or if your hosting setup makes Options B and C impractical.

Option B: subdirectory reverse proxy (yoursite.com/blog)

A separate WordPress instance, but the public URL is on the main domain. A reverse proxy at the edge (Cloudflare Workers, Vercel rewrites, Nginx, Caddy) forwards /blog/* to the WordPress host.

What you get:

  • Same-domain SEO. The blog’s link equity and the homepage’s link equity stack.
  • Shared cookies if you set them up to share. The browser sees one origin.
  • One analytics property with cleaner attribution.

What you pay for that:

  • A reverse proxy you have to maintain. Rewrite rules, edge caching headers, hostname rewriting in the response body. Six months from now, when something breaks, you will have to remember why the Cloudflare Worker exists.
  • WordPress has to “think” it lives at /blog. Set WP_HOME and WP_SITEURL to https://yoursite.com/blog. Set permalinks consistent with that prefix. Some plugins hardcode their own URLs and need patching. Some assume they are at the site root and emit broken asset paths.
  • Asset path leaks are the recurring bug. A plugin emits /wp-content/plugins/foo/style.css. Your proxy only forwards /blog/*. The CSS 404s. You either also forward /wp-content/* (now WP owns half the URL space at the edge) or you patch the plugin.
  • Two hosts to bill, two hosts to back up. Cheaper than Option A in one place: the front-end host can be a static CDN with no per-seat fee.

Pick subdirectory reverse proxy if you already have a front-end on Webflow, Framer, Vercel, or similar that you are not migrating, and you need a WordPress blog under the same domain.

Option C: one WordPress install hosting the front-end too

This is the shape covered in the pillar post. Your vibe-coded front-end deploys into the WordPress install as a DesignSetGo App with mount.mode: "root". WordPress serves /blog, /wp-admin, /wp-json, /feed. The app serves every URL you declare for the front-end.

What you get:

  • One origin, one cert, one database, one analytics, one sitemap, one auth.
  • Best SEO of the three. Single domain, no proxy gymnastics, no rewrites that could leak paths.
  • No reverse proxy to maintain. The dispatch happens inside WordPress on a request-by-request basis.
  • No theme drift, because there is no second site to drift toward. The blog can import the same CSS variables the front-end uses.

What you pay for that:

  • WordPress is your only host. If you specifically wanted the front-end on Vercel for its edge cache, this is not that. Most static front-ends do not actually need Vercel’s edge cache; a half-decent WordPress host with a CDN in front is fine for a marketing site that updates monthly.
  • CLI deploy is a Pro feature. Free DesignSetGo Apps lets you upload one app through the admin HTML importer; Pro at $149.99/year per site adds designsetgo apps deploy from Claude Code or Cursor, the in-admin AI builder, scheduled jobs, webhooks, and unlimited apps. The 14-day Pro trial activates on install with no card.
  • One root-mounted app per site. Deliberate constraint. A second large surface mounts at a prefix.

Pick this if you are starting fresh, or if the existing front-end host is something you would happily turn off.

The comparison on six axes

A: subdomain B: subdirectory proxy C: one WP install
SEO domain authority weakest shared shared
Cookies / sessions split shared shared
Reverse proxy to maintain none yes none
Theme drift risk high medium none
SSL certs to manage two two one
Hosts to bill two two one
Cost of undoing later high medium low

Worked examples

A wedding photographer’s site. Portfolio, pricing, contact, and about were vibe-coded in Lovable. Looks great. Builds to static HTML. The blog is wedding stories with embedded galleries, ten posts a year, written in Gutenberg. One brand, the buttons should match.

Choice: Option C. Deploy the Lovable export as a DSGo App with mount.mode: "root". WP serves /blog. The blog’s theme imports the same CSS variables the Lovable export uses. Same nav, same footer, edited from wp-admin.

A consultancy with an existing Webflow homepage. Already on Webflow, paying for it, no migration appetite. Needs a blog now.

Choice: Option B. Run a small WordPress at wp.consultancy.com. Reverse-proxy consultancy.com/blog to wp.consultancy.com. Set WP_HOME and WP_SITEURL to https://consultancy.com/blog. Use an SEO plugin that respects the proxy. Webflow stays the front-end. Migration to Option C is a future decision when the Webflow site needs a refresh anyway.

A solo founder shipping a side project. Vibe-coded the homepage in a Claude Code session over a weekend. Wants a blog because their last side project died from no SEO. Has zero appetite to maintain a reverse proxy.

Choice: Option C. The Claude Code project is already a static build. One CLI deploy puts it inside a WordPress install. The blog stays at /blog and the founder never thinks about it again unless they publish something.

How to decide in one minute

  • Already shipped on a subdomain? Stay on the subdomain unless SEO is the reason you are reading this.
  • Front-end already on a CDN you are paying for and happy with? Option B.
  • Starting fresh, want one bill, want one auth? Option C.
  • The blog is the centerpiece, not the homepage? Reconsider whether you needed a separate vibe-coded site at all; WordPress with a good theme might be the whole answer.

Related reading

Keep reading

More from the blog.