Pro plan

Custom domains

Serve your documents from your own branded subdomain with automatic SSL.

A custom domain serves your share links from a subdomain you own, such as docs.yourcompany.com, instead of everypage.co. Share links, QR codes and embed snippets generated while the domain is active all point at it. One domain per account. Adding and verifying a domain requires Pro.

Setting up a custom domain

Custom domains are subdomains only — a root domain (example.com, example.co.uk) is rejected, because routing to it would need an A record. You will need to add two DNS records at your domain provider.

  1. Add your domain on the Account page, under Custom domain. Enter a subdomain like docs.yourcompany.com and click "Add domain".

  2. Create two DNS records. Both target values are printed on the Account page once the domain is added — copy them from there rather than from any documentation, as the CNAME target is set per deployment:

    • A CNAME record pointing docs.yourcompany.com at the CNAME target shown on the Account page
    • A TXT record at _everypage.docs.yourcompany.com whose value is the verification token shown on the Account page

    If your DNS provider proxies records (for example, Cloudflare's orange-cloud setting), set the CNAME to "DNS only" instead of proxied. Providers that flatten CNAMEs into ALIAS records also verify, as long as the name resolves to the same addresses as the target.

  3. Verify ownership with "Verify domain" on the Account page. Both records are checked; if either is missing, the page names which one. DNS changes can take up to an hour to propagate. Once both checks pass, EveryPage registers the hostname with Cloudflare, which issues the HTTPS certificate.

Until then the status reads "Waiting for DNS verification". After verification it shows "Verified · certificate provisioning…" while the certificate is being issued, then "Verified & active".

What a custom domain serves

A custom domain is a document-serving surface only; it does not mirror the rest of the account. Anything outside an explicit allowlist of viewer paths returns 404 on that host, so sign-in, billing and account pages can never execute on a customer hostname.

The allowlist covers:

  • Document share links (/<identifier>) and the viewer pages behind them
  • The embed path (/embed/<identifier>)
  • The viewer's own API calls — metadata, download, password verification, view and page telemetry, notes, receipts, page marks, annotations, hotspots, reporting
  • oEmbed discovery (/oembed), so consumers can resolve links written on your domain

Sign-in, signup, account settings, upload, billing, readership dashboards and admin all live on everypage.co only. A custom domain also serves only its own owner's documents: another account's link pasted under your host returns 404.

Vanity slugs and custom domains

Vanity slugs (all-lowercase custom identifiers like /reports) resolve only on your verified custom domain. On the canonical everypage.co domain, share links use short IDs instead.

A slug is only usable while the domain is active — that is, verified and on Pro. If the domain is removed or the plan drops below Pro, slug links stop resolving, and the short-ID form on everypage.co is what still works.

QR codes and embed snippets use the durable short-ID path, never a vanity slug, so they survive a slug rename.

The host is a separate question. Both are generated against whichever base your links use at that moment, so an artifact produced while a custom domain is active carries that domain — and stops working if the domain is later removed or the account drops below Pro, because an inactive custom host serves nothing. Artifacts produced before you added a domain point at everypage.co and keep working regardless. If you print codes or hand out embed snippets, do it after the domain decision is settled.

Managing your domain

Removing a domain

"Remove" on the Account page deletes the domain and releases its Cloudflare hostname registration, which also removes the certificate. New links revert to everypage.co immediately, slug links stop resolving, and any QR code or embed snippet already produced on the branded host stops working.

Removal itself is not tier-gated — the endpoint accepts the request on any plan — but the Account panel that exposes the control is replaced by an upgrade prompt below Pro. In practice, remove or change a domain before downgrading; after a downgrade the domain stays on file, stops serving, and cannot be removed from the interface until Pro is restored.

Downgrading below Pro

The domain record is kept, but it goes inactive: the host serves nothing, share links go back to the everypage.co short-ID form, and slug links stop resolving. Restoring Pro reactivates the same domain without re-verifying.

Replacing a domain

Remove the current domain first, then add the new one — the Account page only offers the entry field when no domain is configured. The replacement starts its verification from scratch with a fresh token.

DNS troubleshooting

If verification fails, check:

  • The CNAME record points to the exact target value shown (spaces or typos prevent routing)
  • The TXT record is at the exact host _everypage.<your-domain> with the exact token value
  • DNS changes have propagated (this can take up to an hour)
  • If your provider proxies by default (like Cloudflare's orange cloud), the CNAME must be set to "DNS only"

Verification is a live DNS check, so once both records are correct, click "Verify domain" again — there is no waiting queue.

Adding a domain can also fail before verification starts: "That domain is already in use" means another EveryPage account has registered the same hostname, and "root domains aren't supported" means you entered a registrable domain rather than a subdomain of one.