Install
Choose an install method
Wrenda has to see crawler requests before your origin does. There are three ways to arrange that, and the domain wizard asks you to pick one right after the origin probe.
The three methods
| DNS proxy | CDN / web-server snippet | Reverse proxy (manual) | |
|---|---|---|---|
| What you change | Three DNS records | A Worker, CDN origin, or a config block in Nginx / Apache / Caddy / HAProxy / Express | Your own proxy layer, however you run it |
| Who sees all traffic | Wrenda’s edge (humans pass through to your origin) | Your CDN / server; only bot traffic is forwarded to Wrenda | Your proxy; only bot traffic is forwarded |
| SSL | Issued and renewed automatically | Yours | Yours |
| Verification | Automatic (Verify DNS Records) | Manual — Bot Testing / curl | Manual — Bot Testing / curl |
| Integration Health | All seven checks | Route check skipped | Route check skipped |
| Serving modes | Active / Shadow / Paused | Active / Shadow / Paused | Active / Shadow / Paused |
| Best for | Most sites, especially without your own CDN | Teams keeping Cloudflare / Fastly / CloudFront, or who can’t touch DNS | Self-hosted apps with an existing proxy tier |
DNS proxy — for most sites
You point the domain at proxy.wrenda.ai with a CNAME and add two validation records. Wrenda terminates TLS, matches the user agent against your rules, and forwards human visitors to your origin unchanged. It is the simplest method, fully managed, and the only one Wrenda can verify and monitor end-to-end.
Choose it when you control DNS and don't run your own CDN in front of the site. If the domain is already on Cloudflare, Quick Connect creates the records for you.
CDN or web-server snippet — when you can't change DNS
Your existing CDN or web server keeps serving the site. You add a small piece of configuration that detects bots with Wrenda's canonical user-agent pattern and forwards only those requests to https://api.wrenda.ai/proxy/{your-domain}. Wrenda classifies the bot, applies the right action and returns the response through your CDN. Because the bot list lives on Wrenda's side, you never update the snippet when new crawlers appear.
Choose it when you want to keep an existing CDN (Cloudflare, Fastly, CloudFront, KeyCDN), when DNS is owned by another team, or when the site is served from a host that must stay the DNS target. The trade-off: you own SSL and routing, and Wrenda cannot confirm the forwarding is working — you verify it with Bot Testing.
Reverse proxy — manual
The same forwarding idea, but you write and run the proxy layer yourself (or paste the generated Nginx / Apache / Caddy / HAProxy / Express block into infrastructure you already have). Pick this only if you run your own servers; it does not fit static and edge hosts such as Vercel, Netlify or Cloudflare Pages, which should use DNS proxy instead.
How to choose
- Can you edit the domain's DNS records? If yes → DNS proxy. Stop here unless one of the next points applies.
- Do you need to keep a CDN in front of the origin? DNS proxy works with the CDN's hostname as the origin, but if you rely on CDN features tied to the domain (WAF rules, edge functions, geo routing) use the CDN snippet so the CDN stays in the path.
- Is the site on Vercel, Netlify, Cloudflare Pages, Shopify, Webflow or another managed host? Use DNS proxy; see Platforms for the origin and Host-header details per host.
- Do you already terminate traffic on Nginx, Apache, Caddy or HAProxy? Either method works. DNS proxy is less to maintain; the snippet keeps your server as the public endpoint.