The technical guide.

The short version

Cloudflare sits in front of your domain. A small program at Cloudflare’s edge (a Worker) answers only the pages in the test, and only for visitors who came from an ad. Every other request goes to your current host exactly as before. If the Worker ever fails, the request goes to your host too. Nothing is installed on your servers, and your site builder or CMS keeps working.

What runs where

Three ways to set it up

The first is the one we recommend. All three keep your current site running.

A subdomain is the fastest to set up. Google says it has no ranking preference between a subdomain and a folder, so the trade-offs are practical. Your ads point at a different address, Search Console needs its own property, and a same-URL test isn’t possible. Some site builders don’t allow a proxy in front of them. We check yours first, and where it isn’t allowed, we use a path or a subdomain. Webflow supports Cloudflare in front through its Orange-to-Orange setup on paid site plans.

Step 1 · DNS

Email never goes through anything new: only the website records are proxied.

1. Create the zone in Cloudflare, in your account with Discovery invited (DNS and Workers permissions), or in ours.
2. Export your current DNS and import it. Compare every record line by line: MX, SPF, DKIM (including your email platform’s), DMARC, verification TXT records, and every subdomain your app uses.
3. Proxy only the website. The apex and www go through Cloudflare. Everything else stays DNS-only.
4. Settings before the switch: SSL/TLS set to Full (strict); a cache bypass for API paths. Turn off Bot Fight Mode, AI-crawler blocking and managed robots.txt. Otherwise Cloudflare blocks ChatGPT, Perplexity and Claude and edits your robots.txt.
5. Switch. Lower TTLs a day ahead, then change nameservers at a quiet hour. Leave the old DNS zone untouched for rollback.
6. Check. Run our search check, test email both ways, and send one real form.

Step 2 · The test

The Worker attaches to a route on your domain. On a test page, a visitor joins the test only when their link carries an ad platform’s click id or a paid UTM medium:

gclidgbraidwbraiddclidfbclidmsclkidttclidli_fat_idtwclidScCidepikrdt_cid utm_medium=cpc|paid

• A visitor in the test gets A or B at random and keeps it for 90 days, through a first-party, HttpOnly cookie, dx_split. It holds only the test name, the version and a random id.
• Everyone else, crawlers included, gets your page straight from your host.
• Test pages answer Cache-Control: private, no-store and Vary: Cookie, so no cache serves one visitor’s version to another.
• Three states: the soak (everyone in the test sees your page through the new setup), the split (50/50), and the rollout (everyone in the test sees B). Switching state takes seconds.
• QA links: ?dx_variant=a and ?dx_variant=b show a version at the real URL, and are never counted. ?dx_variant=origin shows your live page, and ?dx_variant=clear forgets the version.

Step 3 · Tracking

Both versions load your own tag manager and pixels, with the same IDs. We never add a pixel. On every page a visitor in the test sees, the Worker pushes this before your tags load:

dataLayer.push({ event: "dx_split", dx_test: "<test>", dx_variant: "A" | "B" })

• dx_split_view on each page view, and dx_split_conversion (with dx_conversion) on a conversion. They go to the data layer, and to gtag when it’s on the page.
• When a Meta pixel is on the page, it gets SplitView and SplitConversion custom events carrying dx_variant.
• What counts as a conversion: a form sent, a HubSpot or Typeform embed submitted, a Calendly booking, or a click on the links you choose (sign-up, call, email).
• A first-party log at /__split/e records views and conversions per version, source and device. It never records personal details.

On your side: register dx_variant as a custom dimension in GA4, and add it to custom conversions where you want each version split.

Step 4 · Forms and your CRM

Version B sends its form to the same place your page does today: your own API or your form provider. Every sign-up still lands in your system, and Discovery’s CRM gets a copy for the report. If you’d rather run leads through Discovery’s CRM, it alerts your team instantly and answers each lead; sending them on into your CRM is built and switching on now.

Search safeguards

• Same URLs, no redirects, and nothing new for search engines to crawl.
• Crawlers never join the test. Joining depends on the link, not the user agent, so it isn’t cloaking.
• Version B carries your page’s exact title, meta description, canonical, robots, hreflang, structured data and language.
• Our search check runs before the DNS switch, right after it, after every change, and weekly. It confirms each time that:
  • Googlebot and organic visitors get your page.
  • Googlebot, Bingbot, OAI-SearchBot, ChatGPT-User, GPTBot, PerplexityBot, ClaudeBot and Claude-User all get a 200.
  • robots.txt is unchanged.
  • Every URL in your sitemap answers as it did before.

Rollback

What we need from you

• An export of your current DNS, and where the domain is registered
• A Cloudflare account with Discovery invited, or your OK to use ours
• Where your forms send leads (your API, your form tool, your CRM) and any fields they require
• Fifteen minutes to add dx_variant to your tag manager and analytics
• A heads-up before anyone edits the test page during the test