Subpath Hosting (DIY Setup)

Subpath hosting serves your Pendium site under your own domain, for example yourdomain.com/blog/*, by adding a small reverse-proxy rule on your edge or hosting platform. The content is identical; the difference is that it now lives on your root domain, so the SEO and citation authority accrues to you. It works for a site we built for you on Pro and for an older Pendium-hosted site at pendium.ai/{your-username}. On Pro you can set the subpath up while your site is still being built. Once the site is built you review it privately, and the subpath starts serving it when you make it public (where your site lives).

This guide covers the DIY setup the Site → Manage → Domain Connect wizard generates for you. You don't have to copy anything from this page by hand: the wizard mints a snippet bound to your domain, path prefix, and a stable proxy token. This page explains what that snippet does and how to troubleshoot it.

Subpath vs. custom domain

Domain Connect offers two ways to put the site on your domain:

Subpath is the recommended option because search engines and AI crawlers treat yourdomain.com/blog as part of your main site. This guide is about the subpath path; to point a domain you own straight at Pendium instead, see custom domain hosting.

Subpath is also how you keep your existing homepage on the root while serving the site underneath it. The custom-domain option can take a root domain too, but pointing a root at Pendium hands it the whole domain — see root domains.

How it works

Your edge receives requests for yourdomain.com/blog and anything beneath it, and forwards them to Pendium, which serves your site content:

Visitor → yourdomain.com/blog/some-post
            │  (your reverse proxy)
            ▼
          https://pendium.ai/_proxy/{YOUR_PROXY_TOKEN}/some-post
            │
            ▼
          Pendium serves your site page

Only traffic on the prefix is proxied. Sibling paths like /blogger or /blogroll pass through to your own origin untouched.

The contract

Whatever platform you're on, your proxy needs to forward two URL shapes to Pendium:

1. The bare prefix — yourdomain.com/blog → https://pendium.ai/_proxy/{YOUR_PROXY_TOKEN}
2. Anything under it — yourdomain.com/blog/<tail> → https://pendium.ai/_proxy/{YOUR_PROXY_TOKEN}/<tail>

Requirements:

• Preserve the HTTP method and query string verbatim.
• Forward request headers, except your visitors' credentials. Drop Cookie, Authorization, Proxy-Authorization, and any Cf-Access-* header. Pendium never needs them.
• Do not pass Set-Cookie from Pendium's responses back to the browser, and don't follow Pendium's redirects on the proxy. Return them to the browser as they are.
• Do not rewrite the response body — Pendium emits absolute URLs already in your customer-facing shape.
• Recommended: set X-Pendium-Forwarded-Host: yourdomain.com so canonical tags and og:url render with your host instead of pendium.ai.

The {YOUR_PROXY_TOKEN} is minted once when you generate your first snippet and stays stable across regenerations — switching platform tabs or re-generating just refreshes the display, it doesn't rotate the token.

Your visitors' cookies stay on your domain

Session cookies on your site are usually scoped to the whole domain, so a proxy that forwards headers unchanged would send them to Pendium on every page view under your prefix, along with any Authorization header. The Cloudflare Worker and the nginx example below drop them before the request leaves your edge.

Vercel rewrites and Netlify _redirects rules can't remove request headers, so on those platforms the cookies do reach Pendium. Pendium strips Cookie, Authorization, Proxy-Authorization, and Cf-Access-* from every proxied request as it arrives, before any of its code reads them. That also covers a Worker or proxy rule you set up before this change. If you'd rather the cookies never leave your edge at all, use the Cloudflare Worker or a reverse proxy you control.

Cookies set on your domain

Pendium's server doesn't send Set-Cookie on the pages it serves through the proxy. Every Pendium build scans the server code behind those pages for anything that would set one, and fails if it finds it. Dropping Set-Cookie at your edge, as the snippets below do, adds a second layer on top of that.

That check covers the server only. Blog posts and pages served through the proxy also load Pendium's analytics scripts (PostHog, Google Analytics, and the Meta and X pixels). Those scripts run in your visitor's browser, so the cookies they store are set on your domain, and a proxy rule can't strip them. The same goes for pendium_utm, which records the campaign or referring site a visitor arrived from.

Visitors in the EU, EEA, and UK see a consent banner first: Pendium's Google Analytics and ad pixels only load after they accept, and their choice is saved in a cookie on your domain. If you connected your own Google Analytics property, its tag runs on these pages and sets its own cookies too.

Prerequisites

• A Pro plan. Subpath hosting and custom domains are the same Pro feature. On another plan, configuring a subpath or making one your primary destination is refused with an upgrade message; switching back to your pendium.ai address always works.
• A domain you control, with access to its edge/hosting configuration.
• The ability to add one of: a Cloudflare Worker, a Vercel vercel.json rewrite, a Netlify _redirects rule, or a custom reverse-proxy rule (nginx, Apache, Caddy, etc.).
• If you run a WAF or bot filter, allow Pendium's verification probe (user-agent PendiumVerifier/1.0) and normal crawler traffic to the prefix.
• A site to serve. A brand that doesn't have a rendered site yet is refused, with a message saying why; its hosting is set up as part of the site build. A brand whose site is custom-built uses the same snippet, and Pendium forwards the subpath's traffic to that site. Before such a subpath becomes your primary address, Pendium checks that the custom-built site actually answers through it. While a custom subdomain is primary instead, the subpath redirects every page to the same page on the subdomain.

Configuring, verifying, or disconnecting hosting are write actions — an account in read-only mode can view its hosting setup but not change it.

Per-platform setup

Open Site → Manage → Domain Connect, enter your domain and path prefix (defaults to /blog), pick your platform, and click Generate snippet. Paste the generated snippet into your platform, then click "I've added it, verify." The snippets below are templates, and the wizard fills in your real token.

Cloudflare Workers

1. In the Cloudflare dashboard, open your domain → DNS and confirm the apex record (and www if you use it) shows an orange-cloud Proxied icon. Worker routes only fire on proxied traffic.
2. Open Workers & Pages → Create, pick the "Hello World" template, and name the Worker pendium-subpath.
3. Replace the editor contents with the generated Worker script and click Save & Deploy.
4. On your zone, open Workers Routes and add *yourdomain.com/blog* → pendium-subpath. The leading * matches both yourdomain.com and www.yourdomain.com — important if your site redirects between them.
5. Click "I've added it, verify" in the wizard.

// Pendium subpath proxy worker (the wizard fills in your token + prefix)
export default {
  async fetch(request) {
    const url = new URL(request.url);
    const prefix = "/blog";
    const isPrefixExact = url.pathname === prefix;
    const isUnderPrefix = url.pathname.startsWith(prefix + "/");
    if (!isPrefixExact && !isUnderPrefix) {
      return fetch(request); // outside the prefix — let your origin handle it
    }
    const tail = url.pathname.slice(prefix.length);
    const proxyUrl =
      "https://pendium.ai/_proxy/YOUR_PROXY_TOKEN" + tail + url.search;
    // Copy the headers, minus your visitors' credentials.
    const headers = new Headers(request.headers);
    for (const name of [...headers.keys()]) {
      if (
        name === "cookie" ||
        name === "authorization" ||
        name === "proxy-authorization" ||
        name.startsWith("cf-access-")
      ) {
        headers.delete(name);
      }
    }
    headers.set("X-Pendium-Forwarded-Host", url.host);
    const hasBody = request.method !== "GET" && request.method !== "HEAD";
    // Hand Pendium's redirects back to the browser instead of following them.
    const upstream = await fetch(proxyUrl, {
      method: request.method,
      headers,
      body: hasBody ? request.body : null,
      redirect: "manual",
    });
    // Never let a cookie from pendium.ai land on your domain.
    const response = new Response(upstream.body, upstream);
    response.headers.delete("set-cookie");
    return response;
  },
};

If you set up the Worker before this version of the snippet, paste the new one over it. Your old Worker keeps working, and Pendium strips the forwarded cookies on arrival either way.

Vercel

Vercel rewrites preserve method, headers, and query string automatically. A rewrites entry can't remove a request header, so your visitors' cookies and any Authorization header go to Pendium with each proxied request. Pendium strips them on arrival (see Your visitors' cookies stay on your domain).

1. Open (or create) vercel.json at the root of your project.
2. Add the rewrites block below, merging with any rewrites you already have.
3. Commit and push — Vercel deploys the rewrite automatically (usually under 60 seconds).
4. Once the deploy lands, click "I've added it, verify."

{
  "rewrites": [
    {
      "source": "/blog",
      "destination": "https://pendium.ai/_proxy/YOUR_PROXY_TOKEN"
    },
    {
      "source": "/blog/:path*",
      "destination": "https://pendium.ai/_proxy/YOUR_PROXY_TOKEN/:path*"
    }
  ]
}

Netlify

Netlify uses status 200 to proxy transparently (vs. 301, which would redirect). Order matters — the exact match must come before the wildcard. Netlify forwards every cookie on a proxy rule and _redirects can't remove a request header, so your visitors' cookies reach Pendium, which strips them on arrival (see Your visitors' cookies stay on your domain).

1. Open the _redirects file in your publish directory (commonly public/_redirects or static/_redirects). Create it if it doesn't exist.
2. Add the two lines below, keeping the order.
3. Commit and push — Netlify deploys in under 60 seconds.
4. Once the deploy lands, click "I've added it, verify."

/blog        https://pendium.ai/_proxy/YOUR_PROXY_TOKEN        200
/blog/*      https://pendium.ai/_proxy/YOUR_PROXY_TOKEN/:splat  200

Other (nginx, Apache, Caddy, custom)

Translate the contract above into your edge's reverse-proxy syntax, including the headers to drop. Example nginx fragment:

# nginx can't blank a header by prefix, so the two Cloudflare Access headers
# are named. Pendium strips any other Cf-Access-* header on arrival.
location = /blog {
  proxy_pass https://pendium.ai/_proxy/YOUR_PROXY_TOKEN;
  proxy_set_header X-Pendium-Forwarded-Host yourdomain.com;
  proxy_set_header Cookie "";
  proxy_set_header Authorization "";
  proxy_set_header Proxy-Authorization "";
  proxy_set_header Cf-Access-Jwt-Assertion "";
  proxy_set_header Cf-Access-Authenticated-User-Email "";
  proxy_hide_header Set-Cookie;
}
location /blog/ {
  proxy_pass https://pendium.ai/_proxy/YOUR_PROXY_TOKEN/;
  proxy_set_header X-Pendium-Forwarded-Host yourdomain.com;
  proxy_set_header Cookie "";
  proxy_set_header Authorization "";
  proxy_set_header Proxy-Authorization "";
  proxy_set_header Cf-Access-Jwt-Assertion "";
  proxy_set_header Cf-Access-Authenticated-User-Email "";
  proxy_hide_header Set-Cookie;
}

Deploy/reload your edge config, then click "I've added it, verify."

Verification

When you click "I've added it, verify," Pendium round-trips a health check to confirm your proxy is wired correctly:

1. Pendium fetches https://yourdomain.com/blog/_pendium/health?nonce=<random> — a request that flows through your proxy.
2. Your proxy forwards it to Pendium, which signs the response using a hash of your proxy token and the nonce.
3. Pendium verifies the returned signature matches. A match proves the request reached Pendium through your domain using your token.

The wizard polls every few seconds for up to ~90 seconds. Once verification succeeds, it records it and unlocks "Make this my primary destination."

Bot protection blocks your feed (important)

If your domain sits behind a Cloudflare bot filter (Bot Fight Mode, Managed Challenge, or "I'm Under Attack"), it returns a 403 to any non-browser request on the proxied path. Verification fails — but that's the small problem. The bigger one: the AI crawlers your agent feed exists to reach (ChatGPT, Perplexity, Claude, Google's AI surfaces) are non-browser clients too, so the filter blocks them from reading your feed. A feed that AI can't crawl can't get you recommended.

Watch out for "Block AI bots" specifically. Cloudflare's Block AI Scrapers and Crawlers control is a separate managed rule that takes precedence over all other Super Bot Fight Mode rules — it blocks GPTBot, ClaudeBot, PerplexityBot, and friends even when they're verified bots and even if you allow other bots. So a user-agent allowlist for AI bots isn't enough on its own.

The fix is a path-scoped skip, not a user-agent allowlist. In Cloudflare, add a WAF custom rule with a Skip action that matches URI Path equals /blog OR URI Path starts with /blog/, and skips Super Bot Fight Mode for that path. Match it that way precisely: /blog/* alone misses the bare feed root (/blog), while a loose starts-with /blog would also catch unrelated paths like /blogger. The equals /blog + starts-with /blog/ pair covers your feed root and everything under it, and nothing else. Skipping by path (not UA) matters for two reasons:

• It opens the path to all the AI crawlers, including ones not on any allowlist, and it covers the "Block AI bots" rule (which lives under Super Bot Fight Mode).
• It also lets our verifier (PendiumVerifier/1.0) through. Verification round-trips the path with our own user-agent, so a UA-allowlist that only permits AI bots would leave your feed crawlable but verification stuck on a 403. A path skip clears both at once.

If your intent is to block AI from your main site but allow it on your agent feed, that's exactly what the path-scoped rule gives you: protection everywhere else, the /blog path (root and everything under it) open — the content you want AI to read.

On free Cloudflare (plain Bot Fight Mode), you can't skip per-path — it's a single global toggle. Either turn Bot Fight Mode off, or upgrade to a plan with Super Bot Fight Mode + WAF custom rules to scope the exemption to /blog and the paths under it.

Can't get verification to pass but AI can reach your feed? If you've allowed AI crawlers on your proxied path (so they can read it) but our automated check is still blocked, you don't have to stay stuck. In the hosting panel, the subpath destination offers "Set as primary anyway" — it records your attestation and makes the proxy your canonical home. The bar is AI crawlers can reach it, not it loads in a browser: a bot filter blocks crawlers even when it lets browsers through, so a browser-only feed would consolidate your authority onto something AI can't read. It points your canonical URLs and sitemap at the proxy, so only use it once crawlers can actually get in.

Troubleshooting

Making it your primary destination

After verification passes, click "Make this my primary destination" to tell Pendium your domain is the canonical home for the site. Pendium then renders canonical tags and internal links against your domain. On an older Pendium-hosted site, your pendium.ai/{your-username} URL keeps working as a fallback. A site we built for you redirects its other addresses to your domain.

List your sitemap in your root robots.txt

Do this once the subpath is your primary destination and your site is published. Before that, requests to the subpath redirect to your primary address, so its sitemap lists URLs on the other host and Search Console rejects them. An unpublished site's sitemap returns 404.

Crawlers only read robots.txt at the root of a domain. Pendium serves a robots.txt at yourdomain.com/blog/robots.txt that points at your sitemap, but crawlers don't request a robots.txt below the root, so they won't find your sitemap until you list it in the root file.

Add this line to yourdomain.com/robots.txt, using your own domain and path prefix:

Sitemap: https://yourdomain.com/blog/sitemap.xml

A robots.txt file can list several sitemaps, so keep any Sitemap: lines you already have. Once the subpath is primary and the site is published, the hosting panel shows this line with your domain and prefix filled in, plus a Copy button.

Then add your domain to Google Search Console and submit yourdomain.com/blog/sitemap.xml under Sitemaps. If your website builder won't let you edit robots.txt, Google can still find the sitemap this way.

Disconnecting

To stop subpath hosting, clear the proxy configuration in the wizard. Pendium drops the proxy token and verification, and (if the proxy was your primary destination) reverts the canonical home to your site's Pendium address. Remove the proxy rule from your edge afterward so the prefix returns to your own origin.