Setup guide · no native proxy
Not natively. Webflow hosting offers 301 redirects but no way to proxy a path to another server, and its help center says it doesn't support reverse proxies. Two routes work: blog.acme.com with one CNAME, on any plan, in five minutes; or acme.com/blog through a Cloudflare Worker, if your site runs Cloudflare Orange-to-Orange.
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). Webflow 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.
Then add a Blog link to your Webflow navbar pointing at https://blog.acme.com/. If /blog on your Webflow site used to mean something, a 301 in Site settings → Publishing → 301 redirects from /blog to the subdomain keeps old links working.
A paid Site plan, the site on Webflow's Cloudflare hosting (sites created after April 21, 2025 already are), acme.com's DNS on Cloudflare, and Orange-to-Orange set up with Full (Strict) SSL. Without O2O, Webflow says an orange-cloud record causes 525 errors, so do this first.
Follow the Cloudflare Workers guide: the same Worker, on the routes acme.com/blog and acme.com/blog/*. Webflow's own reverse-proxy article says a path like example.com/blog may still need Cloudflare Workers.
Enter https://acme.com/blog in Settings → Blog address and press Check. Cloudflare's compatibility notes put an asterisk on Workers in an O2O zone; if Check fails, Option A always works.
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.
/blog to our address sends visitors and search credit to us. Fine as a pointer to your own subdomain; not a substitute for the proxy./blog on higher site plans, but its docs never describe proxying to an outside server, so we don't recommend building on it.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. If you can't run the Worker route, publishing steadily on a subdomain beats waiting for the folder.
Not at the same path. Move it, or give the new blog another address such as /articles.
That's the opposite direction: serving a Webflow site under another server's path. It doesn't help bring an outside blog into Webflow.
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.