Setup guide · no native proxy
Not natively. Lovable hosting has no rewrite or proxy rules, so nothing inside Lovable can point /blog at another server. Use blog.acme.com with one CNAME (Lovable's own DNS takes CNAME records), or put Cloudflare in front with Lovable's proxy option for custom domains and run our Worker on /blog.
In AmplifySignal, open Settings → Blog address, enter https://blog.acme.com and save. Nothing public moves until the check passes.
Wherever acme.com's DNS records live, add a CNAME named blog pointing at sites.amplifysignal.com. If that is Cloudflare, leave it DNS only (grey cloud). Lovable itself needs no change; we issue and renew the certificate once the record resolves, usually within minutes.
Back in Settings, press Check. When it passes, links, canonical tags, the sitemap and the RSS feed switch to https://blog.acme.com, and the old address redirects there.
If you bought acme.com through Lovable and it still uses Lovable's nameservers, add the CNAME in Lovable's domain settings; Lovable lets you add A, CNAME, TXT and other records there.
Custom domains need a paid Lovable plan. When connecting acme.com, choose the advanced option Uses Cloudflare or similar proxy: Lovable gives you a CNAME to your project's lovable.app address instead of an A record. Add it in Cloudflare as proxied (orange cloud). Lovable says it doesn't configure, validate or monitor your proxy, so the next steps are yours.
Follow the Cloudflare Workers guide: the same Worker, on the routes acme.com/blog and acme.com/blog/*. Everything else still goes to Lovable.
Enter https://acme.com/blog in Settings → Blog address and press Check.
Lovable syncs the project to GitHub, GitLab or Bitbucket, and its docs cover deploying to Vercel or Netlify. Both can proxy /blog: follow the Netlify or Vercel guide. Cloudflare Pages can't: its _redirects doesn't proxy to outside domains. Only worth it if you were leaving Lovable hosting anyway.
Three requests from any terminal show whether the rule works before you press anything:
curl -sI https://blog.acme.com/ | head -1
# HTTP/2 200
curl -s https://blog.acme.com/_verify.json
# {"edge":true,"host":"acme.com","service":"amplifysignal"}
curl -sI https://blog.acme.com/<an-article>/ | head -1
# HTTP/2 200A 301 on the article that points at the same URL, again and again, means something on the way is dropping the trailing slash. "edge":false means the rule points at amplifysignal.com instead of sites.amplifysignal.com.
Then press Check in Settings → Blog address, or run as site blog-check acme.com. Check fetches /_verify.json through your address and passes when it answers for this site through our edge. From then on, links, canonical tags, the sitemap and the RSS feed use your address, and the old /b/ links redirect to it.
For a /blog route, run the same requests against https://acme.com/blog.
Search engines treat blog.acme.com as its own site, so its authority builds separately from acme.com; a folder shares it. A subdomain still ranks, and it's the setup with nothing to maintain.
No. The blog is served by us as plain server-rendered HTML whichever option you pick; your app's rendering doesn't touch it. (Lovable says apps created since May 13, 2026 render on the server anyway.)
You can, but then the writing, scheduling and sitemap are yours to build. The options here keep your app as it is and add a blog next to it.
sites.amplifysignal.com is our edge: a request there tells us it came through your proxy, so we serve the page as yours. Once your address is verified, amplifysignal.com redirects a blog's visitors to your address instead, so a proxy aimed there would send people in a circle. Check names the problem if a rule points at the wrong one.
The mechanics carry over: swap the destination for any server that hosts your blog under a path. Copy two things along with them. Keep the trailing slash if that server's URLs end in one, and make sure its links and canonical tags name your address, or search engines index the other host instead. Ours switch the moment Check passes.
Yes, on any platform: one CNAME from blog to sites.amplifysignal.com, and we issue the certificate. A folder shares your main domain's authority, which is why these guides lead with it; the subdomain steps are on the overview.
Checked against the platform's documentation on 2026-10-14; where the facts above say tested, we ran the snippet ourselves against the servers that host our own blog and followed every URL to a 200.
AmplifySignal hosts it, drafts the articles from your keywords and Search Console data, publishes them on a schedule and sends the social posts. Every account starts with a free week, or begin with a free 90-day launch plan.