Serve your Hatch blog from a subfolder like /blog

By the end of this guide your Hatch blog will appear at yoursite.com/blog on the same domain as your existing marketing site, served by your Hatch frontend behind the scenes.

How it works

Your marketing site keeps serving yoursite.com. When a visitor opens any /blog/* path, your host reverse-proxies or rewrites the request to the Hatch frontend. The visitor never sees the frontend’s own address. A subfolder keeps your blog on the same domain, which consolidates search authority better than a subdomain. The Hatch frontend itself always runs on Cloudflare Workers.

In every setup below, replace https://your-hatch-frontend.workers.dev with the frontend address shown on the Hatch Connection tab.

Option 1: your own server with Nginx or Caddy

1. In the marketing site’s Nginx server block, add a location /blog/ block before the catch-all location /.
2. Inside it, proxy_pass to your frontend address, turn on proxy_ssl_server_name, and set the X-Forwarded-Host header to your domain.
3. Add sub_filter rules that rewrite href="/ and src="/ to the /blog/ prefix, with sub_filter_once off.
4. Test and reload: sudo nginx -t && sudo systemctl reload nginx.

With Caddy, use handle_path /blog/* and reverse_proxy to your frontend. handle_path strips the /blog/ prefix before proxying, so the frontend sees /hello-world while the visitor sees /blog/hello-world. Reload with sudo caddy reload --config /etc/caddy/Caddyfile.

Option 2: marketing site on Vercel

1. In the marketing site’s vercel.json, add two rewrites: /blog to your frontend address, and /blog/:path* to your frontend address plus /:path*.
2. Redeploy the marketing site. The rewrites take effect on the next build.

If CSS or JavaScript files fail to load, the frontend may need to emit paths that start with /blog; this is set with basePath in the Astro config.

Option 3: Cloudflare

Marketing site on Cloudflare Pages: add two lines to its public/_redirects file that send /blog and /blog/* to your frontend with status 200. A 200 means Cloudflare proxies the response instead of redirecting the browser, so the address bar stays on your domain.

Marketing site elsewhere: put your domain on Cloudflare (the free plan is enough) and deploy a small Worker on the route yoursite.com/blog/*. It strips the /blog prefix, fetches the same path from your Hatch frontend, and returns the response.

Tell Hatch about the subfolder

1. Open Hatch, then the Connection tab.
2. Keep the frontend address set to the frontend’s own address, for example the workers.dev address.
3. Set the Site URL to https://yoursite.com/blog. This makes Hatch emit canonical URLs that point at the public /blog path, not the proxy origin.

Check it

1. Open yoursite.com/blog and a few posts.
2. Open your browser’s developer tools and confirm styles, scripts and images load without errors.
3. View the page source and check the canonical link uses /blog.

What to do next

• Use your own domain with Hatch
• Check Hatch Connect is working
• How headless WordPress with Astro works in Hatch