Setup guide

Add a blog at /blog on Vercel

Yes, for projects that aren't Next.js: four rewrites in vercel.json proxy /blog to your blog while the address bar stays on acme.com. Write the trailing-slash rule out, because Vercel's /blog/:path* doesn't match /blog/hello-world/ and every article would 404 without it. On a Next.js project, use the Next.js guide.

Where
vercel.json at the project root
Works with
Vite, Astro, SvelteKit, plain HTML: anything Vercel deploys that isn't Next.js
Plan
no plan gate on external rewrites in Vercel's docs; Hobby itself is for non-commercial use
Checked
rules compiled with @vercel/routing-utils 6.6.0, Vercel's vercel.json route compiler, 2026-10-14. Not yet run on a live Vercel deployment; the check in step 4 settles it

How it works

Set it up

  1. Set the address

    In AmplifySignal, open Settings → Blog address, enter https://acme.com/blog and save. Nothing public moves until the check passes.

  2. Add the rewrites

    vercel.json
    {
      "rewrites": [
        { "source": "/blog", "destination": "https://sites.amplifysignal.com/b/acme.com/" },
        { "source": "/blog/", "destination": "https://sites.amplifysignal.com/b/acme.com/" },
        { "source": "/blog/:path*/", "destination": "https://sites.amplifysignal.com/b/acme.com/:path*/" },
        { "source": "/blog/:path*", "destination": "https://sites.amplifysignal.com/b/acme.com/:path*" }
      ]
    }

    Each rule has a job. Vercel compiles /blog/:path* to a pattern that refuses a trailing slash, so /blog/ and /blog/:path*/ get rules of their own and keep the slash on the way out. The last rule serves the slashless files: rss.xml, sitemap.xml, images. We checked every case against the compiled patterns: /blog, /blog/, an article, a nested path, the feed, an image, and /blogging, which correctly matches nothing.

  3. Deploy

    Push or run vercel --prod. Leave trailingSlash out of vercel.json (or set it to true); false would strip the slash and loop.

  4. Check it

    Three requests from any terminal show whether the rule works before you press anything:

    terminal
    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 200

    A 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.

Mistakes we've seen or reproduced

Questions

My project is Next.js. vercel.json or next.config.js?

next.config.js. Next's own trailing-slash redirect runs regardless of vercel.json, so you need skipTrailingSlashRedirect anyway, and the rules then work off Vercel too. The Next.js guide has the exact config.

Does this work on the Hobby plan?

Vercel's docs don't list external rewrites as a paid feature. Hobby's terms limit it to non-commercial, personal use, which rules it out for most business sites whatever the feature list says.

Why four rules and not two?

Because Vercel matches /blog/:path* strictly: no trailing slash. Two rules would serve the feed and miss every article. The two extra rules are the slashed cases.

Will Vercel cache my blog pages?

Only if the origin says it may. Our pages send no caching headers, so each visit is fetched fresh. To opt out explicitly, Vercel documents an x-vercel-enable-rewrite-caching: 0 header in vercel.json.

Why sites.amplifysignal.com and not amplifysignal.com?

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.

Do these rules work for a blog that isn't on AmplifySignal?

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.

Can I use blog.example.com instead?

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.

What this is based on

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.

Other platforms

No blog to put there yet?

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.

Start free