Setup guide
Yes. A handle_path block strips /blog, a rewrite adds our path, and reverse_proxy fetches the page over HTTPS. Add a redir for the bare /blog, because handle_path /blog/* doesn't match it. Caddy 2.11 and later send the right Host header on their own; the header_up line keeps older versions right.
acme.com/blog/hello-world/sites.amplifysignal.com/b/acme.com/hello-world/acme.com/blog/, with canonical tags and links to matchIn AmplifySignal, open Settings → Blog address, enter https://acme.com/blog and save. Nothing public moves until the check passes.
acme.com {
redir /blog /blog/ 308
handle_path /blog/* {
rewrite * /b/acme.com{uri}
reverse_proxy https://sites.amplifysignal.com {
header_up Host sites.amplifysignal.com
}
}
# ...the rest of your site
}handle_path removes /blog before anything inside runs, so the rewrite sees /hello-world/ and turns it into /b/acme.com/hello-world/. {uri} carries the query string along. The path can't go on the reverse_proxy line itself: Caddy's upstream addresses don't take paths, which is what the rewrite is for.
caddy reload (or systemctl reload caddy).
Three requests from any terminal show whether the rule works before you press anything:
curl -sI https://acme.com/blog/ | head -1
# HTTP/2 200
curl -s https://acme.com/blog/_verify.json
# {"edge":true,"host":"acme.com","service":"amplifysignal"}
curl -sI https://acme.com/blog/<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.
redir. We saw it in testing: /blog falls through to the rest of your site and shows whatever that serves.reverse_proxy https://sites.amplifysignal.com/b/acme.com is rejected; keep the path in the rewrite.header_up. Before 2.11, Caddy passed the visitor's Host (acme.com) upstream, and Cloudflare refuses it with a 403.No, it's a no-op there: since 2.11 Caddy sends the upstream's own host for an HTTPS upstream. It costs nothing and protects a server that hasn't been upgraded.
Either works for a page. 308 keeps the method if anything ever posts to /blog.
For acme.com, yes, as it already does. The connection from Caddy to our edge uses our certificate, verified through SNI, which Caddy sends by default.
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.