DEV Community: 301ST

Counting visits on a Cloudflare site with no third party script and no cookies

301ST — Mon, 12 Oct 2026 14:00:41 +0000

My site is static, on Cloudflare. I want to know how many people read which page and how many scanned the QR code on the flyer, without a cookie banner and without sending my visitors to someone else's server.

Cloudflare already ships a free answer to the first half of that, and for many sites it is enough. This guide starts there, shows where it stops counting, and then builds the alternative: a cookieless counter, a Worker on a path of your own site that counts page views, short link clicks and QR scans into a D1 database in your own account. Every Cloudflare limit below was checked against Cloudflare's documentation on 11 October 2026.

What Cloudflare gives you for free

Web Analytics is free, and Cloudflare describes it as "privacy-first analytics" that "does not collect or use your visitors' personal data". On a proxied hostname you turn it on in the dashboard and Cloudflare injects its script into your HTML for you. Its FAQ sets the terms: data for the previous six months, and "We retain unsampled beacon data for the past 7 days, after this point data is aggregated down to around 10%."

If your pages load it, you can live with a script from another host, and you only care about pages, stop here. It costs nothing and you configure nothing.

Where Web Analytics stops counting

A strict Content Security Policy refuses it. The script lives at static.cloudflareinsights.com/beacon.min.js. Automatic setup sends its reports to your own domain's /cdn-cgi/rum, so connect-src 'self' is fine, but the script itself is a third party host, and the FAQ asks you to add it to script-src. This blog is the measured case. Its policy is script-src 'self' 'unsafe-inline'. On 11 October 2026 a page of 301.sh carried the injected tag, with an integrity attribute and the site's token, and Chrome refused it:

blockedURI:        https://static.cloudflareinsights.com/beacon.min.js
violatedDirective: script-src-elem
disposition:       enforce

The resource entry has a transfer size of 0 and the beacon object never appears. Cloudflare injects the tag without looking at the policy, so the dashboard stays empty and nothing tells you why except a line in the browser console.

Blocker lists refuse it by name. Cloudflare's FAQ has a section headed "The analytics beacon is blocked by ad-blockers" and answers it with "Cloudflare is aware". The EasyPrivacy list, checked on 11 October 2026, blocks the host, ||cloudflareinsights.com^$third-party, and also carries generic path rules that match any site: /beacon.min.js, /cdn-cgi/rum? and /cdn-cgi/rum|. Reporting to your own domain does not help when the path is the same on every Cloudflare site.

It counts pages, not links. A QR code on a flyer, a link in a newsletter or in a bio leads to a page only if you make it one. The click itself, and which code was scanned, is not a page view.

The idea: a collector on a path of your own site

A Worker can sit on a route that covers one path of your hostname, say example.com/assets-k3/*. Everything outside that path goes to your origin as before, and so does anything under it that the Worker does not handle, because the Worker passes it on with fetch(request). The page sends one small request to that path on load. To the browser, the CSP and the blocker lists it is a same origin POST to a path that looks like any other.

This works on a static site too. Cloudflare's Pages documentation describes deploying a Worker "on the same custom domain as your Pages project", and the TDS guide on this blog relies on the same arrangement. One order matters, from Pages' known issues: "It is currently not possible to add a custom domain with … a Worker already routed on that domain." Attach the Pages custom domain first, then add the route.

The smallest version is one table, one Worker and one line in the page:

CREATE TABLE views (day TEXT, page TEXT, n INTEGER, PRIMARY KEY (day, page));

export default {
  async fetch(request, env) {
    const url = new URL(request.url);
    if (request.method === 'POST' && url.pathname === '/assets-k3/v') {
      const day = new Date().toISOString().slice(0, 10);
      const body = (await request.text()).slice(0, 200);
      const page = body.startsWith('/') ? body : 'unknown';
      await env.DB.prepare(
        'INSERT INTO views (day, page, n) VALUES (?, ?, 1) ' +
          'ON CONFLICT (day, page) DO UPDATE SET n = n + 1'
      ).bind(day, page).run();
      return new Response(null, { status: 204, headers: { 'cache-control': 'no-store' } });
    }
    return fetch(request);
  },
};

<script>navigator.sendBeacon('/assets-k3/v', location.pathname)</script>

The route is example.com/assets-k3/* with a D1 binding named DB. The page sends its own path in the body. The Referer of the beacon would carry it too, but only while the site's Referrer-Policy allows it: no-referrer drops the header and origin cuts it to the host, and every view would land on /. A body that is not a path is counted as unknown. When you want sources, send document.referrer alongside it. The slice only caps what reaches D1: request.text() has already read the whole body by then, so a counter facing the open internet reads the stream itself and cancels it past a limit, as clx does at 2 KB.

Pick the path the way you would name a folder of images. A name like stats, track or beacon is what the generic rules above are written for.

Counting people without a cookie

A view counter is a sum. A visitor counter needs to know whether it has seen someone before, and the usual way to know is a cookie. The way without one is a hash of things the request already carries, salted with a random value that lives for one day: sha256(day salt | site | IP | user agent). Store the hash for the open day, count the distinct hashes, and when the day closes keep the count and delete both the hashes and the salt. The salt has to come from crypto.getRandomValues and never reach a log. After that nothing in the database can be matched to a person, including by you.

What this counts is distinct combinations of address and browser per day, which is close to people but not the same. A phone that leaves the home network for mobile data counts twice; two colleagues behind one office address with the same browser count once. Over a week the number is the sum of daily uniques, so one person reading on Monday and on Thursday counts twice. The report should say so in its label.

Short links and QR codes on the same Worker

A short link is a redirect, and a redirect runs no JavaScript, so no page script will ever see the click. Counting a click on a redirect explains why only the thing that answers the request can count it. If a Worker already counts views into D1, it can answer the links too and write the clicks into the same tables.

The links want a hostname of their own, such as k7q.example.com, with no origin behind it. Workers Custom Domains fit: "Cloudflare will create DNS records and issue necessary certificates on your behalf." The documentation only names an existing CNAME as a blocker. Measured on a live account on 11 October 2026, any existing record stops it: the API answers 409 with code 100117, "already has externally managed DNS records", so a record someone made by hand is never taken over.

Three details make the counts trustworthy:

answer with 302 and cache-control: no-store, so every click reaches the Worker instead of a cached redirect in the browser;
put a marker in the address printed in the QR code, k7q.example.com/menu?q, record it as the source qr and drop it from the redirect;
count a GET, redirect a HEAD without counting it, because link checkers and preview fetchers send those.

Rules by country and device fit in the same lookup. request.cf.country gives the country, the user agent gives mobile or desktop, the first rule that matches wins and the link's main target catches the rest.

One more thing the small answers buy. Since June 2025 Cloudflare has reported that Russian ISPs let visitors load "only the first 16 KB of any web asset" from sites behind it. A counter like this sends an inline script under 600 bytes and gets an empty 204; a link answers with headers only, under 1 KB with Cloudflare's own. Both fit far below the cut. This was measured from outside Russia, by size, not from inside it. It does not rescue a page that is itself larger than the cut: a page that never loads sends no view to count. A short link fares better, because its redirect arrives whole and the visitor goes on to wherever the target is hosted.

What it costs on the Free plan

Workers Free gives an account 100,000 requests a day and 10 ms of CPU per request. D1 on Free gives 5 million rows read and 100,000 rows written a day, 500 MB per database and 5 GB per account. The quotas reset at 00:00 UTC and are shared by every Worker in the account.

Writes run out first. Each counted event touches at least one row, more once you keep visitor hashes and per hour detail, and D1 counts every index entry as a row written. clx, the counter described below, budgets nine writes for the worst event and puts the guaranteed ceiling at about 11,000 counted events a day on Free, with a typical site several times that.

When a quota runs out the failures differ. Over the request limit Cloudflare returns Error 1027 or passes the request to the origin, depending on how the route is set to fail. Either way nothing is counted, and the short links stop answering, because their host has no origin to fall back to. Your pages are not on the route and keep loading. Over the write limit D1 "will return errors", so counting stops. Whether links keep redirecting depends on the code: the sample above awaits its write and would fail with it. clx writes a click with ctx.waitUntil() after the redirect is sent and drops a failed write, so its links keep working. Workers Paid lifts both for a minimum of $5 a month per account, with 10 million requests and 50 million D1 writes included.

Where it breaks

It is not fraud resistant. The path is in the page source, and anyone can POST to it with any Referer and user agent. Checks against the Origin and the host keep out browser noise, not a determined script.
The route must be free. If another Worker already holds a route on that pattern, Cloudflare refuses a second one. Pick another path rather than overwrite it.
Your inline script needs your CSP's permission. With script-src 'self' and no 'unsafe-inline', serve the same code as a file from the Worker's path, <script defer src="/assets-k3/a.js">, which 'self' allows. The beacon itself falls under connect-src, so a policy that starts from default-src 'none' needs connect-src 'self' as well.
Browser Integrity Check is yours. Cloudflare's zone setting can refuse some scripted clients on the link host before the Worker runs. Browsers pass. Your own monitoring script may not.
Pages' own files after the Worker are unchecked here. Whether a Pages project's _redirects and _headers still apply to requests the Worker passes on was not tested for this guide.

Doing it without writing it

The code above is a working start. Turning it into a counter with sources, countries, devices, bots, visitor hashes, day rollups, link rules, QR codes and a report is a project of its own, and that project is clx. It installs a Worker named clx-edge and a D1 database into your Cloudflare account, using a short lived bootstrap token you create, and keeps only totals on its own side, hourly for two days and daily for 400; the breakdowns stay in your account. Each site gets its own path and its own generated snippet, so two sites on clx share nothing in their page source. Links get a host per site, with a QR code for each link and up to 10 rules. The free plan covers one Cloudflare account, 10 sites and 200 links. The source is open under AGPL-3.0.

Site generators can use it without a browser. The management API connects a customer's Cloudflare account once, adds each site and returns the snippet to embed at build time; the snippet stays the same across rebuilds. Site Generator, which publishes affiliate sites to Pages, turns it on for a customer who asks its support.

When you need 301.st instead

For one site and a handful of links, the Worker above or clx is the whole answer, and both are free. 301.st is for a different job: many domains with redirects by country and device, traffic split between offers or landing pages, bots filtered before they reach them, and postbacks that tell you which click converted. It runs in your Cloudflare account the same way, and a clx short link can point at a 301.st flow when you need both.

Postbacks for a TDS: how a sale on the offer's site finds its click

301ST — Wed, 07 Oct 2026 14:01:09 +0000

The guide to the TDS on Cloudflare Workers stops at the redirect. The Worker answers the browser with a 302, the browser opens the offer, and from that moment the Worker sees nothing. The registration or the deposit happens on the network's site, on a domain you do not control, where you cannot put a pixel.

A postback is how that event comes back. It is a server to server (S2S) request: when the visitor converts, the network calls a URL you gave it and puts the conversion details into the query string. For the call to mean anything, it has to say which click it belongs to. Getting the click into the network's hands is the work of the redirect.

This article shows how the TDS in 301.st does both halves: what it adds to the offer link, what the network has to send back, what a conversion changes inside the platform, and how it gets back to the ad network that sold you the click. The TDS is the tracker here: the click, the rule and the conversion meet in one place, with nothing in between. Everything here was read from the platform's source code on 6 October 2026. The general version of this loop, built by hand on a Worker, is in the article on attribution when the conversion page is not yours.

The loop

Two things have to hold. The redirect has to put an identifier into a parameter the network keeps, and the network has to return that parameter unchanged in its postback. The rest is the settings of the postback source, described below.

What travels with the click

For every request the Worker makes a click id: 32 hexadecimal characters, the first part of which is the time of the click. On a redirect, it also builds a click token around that id. The token carries the rule that matched, the visitor's country and device, and, for a split, the page variant that was picked. It is signed with HMAC, and the signature is checked when the token comes back. A token that someone edited or made up fails that check.

The platform does not keep a table of clicks. The token is the record of the click, and that is why it is signed: everything the platform learns about a conversion, it reads out of the token the network returned. A token is 44 characters long, or 58 for a split rule, and the platform stops accepting it 90 days after the click.

Whether a rule adds the token is the setting Click key in the URL on the rule:

Choice	What the offer link gets
Don't add	nothing; the link goes out as you wrote it
301 key (_cid)	the token in a parameter named `_cid`
Source parameter	the token in the parameter your postback source names, such as `sub1`

"Don't add" is right for a white page, a bot filter, or any link that does not lead to an affiliate network. The other two are for conversions that come back to 301.st as postbacks. The third one needs a postback source picked on the rule, because the parameter name comes from it.

The Worker writes the token over any parameter of the same name already in the link. If your offer URL contains sub1=something and the source's parameter is sub1, the network gets the token. The rule editor warns about this when you save.

The token is added to an HTTP redirect and to a split. A rule that sends visitors with a meta refresh, JavaScript or an iframe gets no token, and its conversions cannot be attributed.

`{clickid}` is not the key

Target URLs take macros, and two of them matter for tracking.

{clickid} puts the raw 32 character click id into the link. It is the same id that sits inside the token, but it is not signed and it carries nothing else. A network that returns it in a postback returns a value the platform cannot match: the conversion is recorded as unmatched. Use {clickid} when a network wants your id in a field of its own, and let the token go into the parameter the postback reads.

{q.name} puts a parameter of the incoming request into the link. A visitor who arrives as go.example.com/promo?cid=AD123 can be sent on as https://network.example/offer?sub2={q.cid}, and the network receives sub2=AD123. The value is URL encoded and cut at 256 characters; a parameter that is not there becomes an empty string. This is how the ad network's own click id, or the gclid from Google Ads, rides along to the affiliate network and comes back in the postback. {q.name} works in any target URL today but is not yet in the macro list of the editor, so type it by hand.

The postback source

A postback source is one network, or one campaign of a network, as 301.st sees it. You find the list under Postbacks, Postback sources. When you add one, the platform can fill most of it for you in two ways. You can paste a postback URL the network gave you, with its macros, and the platform tries to recognize the network. Or you can save the source as a draft, ask the network to fire one test postback at the address shown, and let the platform learn the field names from that request.

The settings that decide whether conversions match:

Click parameter. The name of the parameter that carries the token, _cid if you leave it empty. Set it when the network dictates its own name, as most do: sub1, subid, data1, btag.

Macro syntax. How the network writes its macros in postback URLs: {sub1}, [SUB1], ${sub1} and so on. The platform uses it to build the URL you paste back.

Field mapping. For each field the platform understands, the name of the parameter the network sends: Click ID, Event type, Transaction ID, Gross amount and currency, Payout amount and currency, External user ID. A source without a Click ID mapping records every conversion as unmatched, and the editor shows a banner until you set it.

Event mapping. Networks name their events differently. This table translates the network's names into the ones 301.st reports on, such as registration and ftd. An event the table does not know is recorded as unknown and does not reach your numbers. A network that cannot send the event name at all gets one postback URL per event instead, each with the event written into it as event_type=ftd, as in the example below.

Then there is how the network proves it is the network. The default is a secret token in every postback URL, generated for the source. The alternatives are a list of the network's IP addresses, an HMAC signature in a header, or nothing at all. An extra IP check can sit on top of the token.

Three more settings shape what is counted. The attribution window in days, 90 by default: a conversion that arrives later than that after the click is recorded as expired. The payout currency: a postback that reports a different currency is set aside rather than added to your totals. And the program key: give several sources the same key when they are campaigns of one affiliate program, so the same transaction arriving through two of them is counted once.

When the source is saved, the platform builds the postback URLs, one per event:

https://api.301.st/tds/postback/<source_id>?token=<secret>&sub1={sub1}&event_id={event_id}&user_id={user_id}&amount={amount}&event_type=ftd

Paste each into the matching field of the network's postback form. The parts in braces are the network's own macros, which it fills in when it calls.

What happens when a postback arrives

The platform answers the network at once and stores the request. Processing starts immediately; anything left over is picked up by an hourly job. Then, in order:

The fields are read through the mapping. A macro the network failed to fill in, such as a literal {sub1}, counts as an empty field rather than as a value.
The token is checked. A valid one gives the rule, the country, the device and the split variant of the original click.
The conversion is deduplicated. With a transaction id, the same transaction and event are counted once, however many times the network retries. Without one, the platform falls back to click, event, amount and minute.
The conversion is recorded as matched, unmatched, or expired.

A matched conversion goes into hourly totals per rule, variant, country, device, event and currency. A refund or a chargeback comes in as a negative amount and is attached to the conversion it cancels.

Not every event teaches a split. The split counts acquisition events, such as a registration or a first deposit, against the clicks each page got. Later money events, deposit, revshare and ngr, add revenue to the rule but do not move the split, because they come from a player the page has already brought in. The Worker picks up the new split numbers with its next sync. Click counters travel the other way: your Worker sends them to the platform once an hour, for each hour that has ended, so a rule's click numbers run an hour or two behind its conversions.

Revenue share outlives the token. A network that pays revshare sends payments for months, long after the 90 days. If the network sends a stable id for the player, mapped as External user ID, the first matched conversion links that player to the click. For the next 365 days, payments for the same player are attributed to the same rule even without a valid token. These payments count toward the rule's revenue and, like other money events, leave the split alone.

Passing the conversion on

301.st can send each conversion on to three places, set per postback source.

A GET to the traffic source, the ad network that sold you the click. It optimizes your campaign on the conversions it is told about, against its own click id. You give a URL template with the macros {source_click_id}, {event}, {payout}, {currency} and {txid}. It is sent only for the events you list, never for negative ones, and only when the conversion carries the network's click id.

A signed POST to your own endpoint. The field Outbound target URL on the source. Each conversion is sent as JSON with an X-301-Signature header, so the receiver can check it came from the platform. This is the way into your own reports or CRM.

A GET to any other URL that takes a postback. You give a template, and the platform fills these macros: {click_id}, {source_click_id}, {event}, {payout}, {gross}, {currency}, {txid}, {conversion_id}, {rule_id}, {country}, {device}.

The two GETs have no screen in the 301.st interface yet; they are set through the API, on PATCH https://api.301.st/tds/postback-sources/<id>, as source_postback_url, source_postback_events and outbound_get_url. The same goes for the source click id mapping, source_click_id in field_map, which the next example needs. A screen for them is being built.

Templates must use https and a host name, not an IP address. Values are URL encoded, and a value the conversion does not have becomes empty. A failed delivery is retried on a server error, a timeout or a rate limit answer: six attempts in all, after waits of 30 seconds, 2 minutes, 10 minutes, an hour and 6 hours. Any other 4xx answer stops the retries, because sending the same request again will not change it.

One click, end to end

Here is the whole loop as one setup: an ad network sends the click, an affiliate network pays for the deposit, and the ad network learns which of its clicks paid off.

The ad network puts its own click id into the ad's link, as cid. The postback source for the affiliate network has the click parameter sub1. Through the API, the source maps source_click_id to sub2, lists ftd in source_postback_events, and has this template for the ad network:

https://ads.example/conversion?click_id={source_click_id}&event={event}&payout={payout}&currency={currency}

The rule redirects with the click key in the source parameter, to this target:

https://network.example/offer?sub2={q.cid}&geo={country}

The ad is clicked, and the visitor lands on https://go.example.com/promo?cid=AD123.
The TDS rule matches and the Worker answers 302 with Location: https://network.example/offer?sub2=AD123&geo=DE&sub1=<token>.
The visitor registers and deposits. The affiliate network calls the postback URL for ftd, with sub1=<token> and sub2=AD123 filled in. It has to return both.
301.st checks the token, records an ftd for the rule in Germany, and fills the template: https://ads.example/conversion?click_id=AD123&event=ftd&payout=....

The ad network now sees a deposit on its own click AD123 and can bid on it. One thing is left to you: the event arrives under 301.st's name, ftd here. If the ad network expects a name of its own, write that name into the template in place of {event}; with only ftd in the list, the template is used for nothing else.

Where it does not reach

A conversion is attributed only through the token. A network that cannot return a parameter verbatim cannot be attributed, whatever else it sends.
Rules that redirect with meta refresh, JavaScript or an iframe send no token.
A token older than 90 days is not read, and the source's attribution window can make that shorter. Revenue share is covered by the player link, if the network sends a player id.
Postbacks are stored and processed in the platform's own database, so they do not count against your Cloudflare D1 allowance. The click counters do: each click on a rule writes to your D1, which the TDS guide counts in its section on the Free plan.

If conversions do not match, check the redirect first. Open the rule's link in a browser and look at the address the offer opens with: the token has to be there, in the parameter the network keeps. Then check that the network's postback URL returns that parameter.

How a TDS on Cloudflare Workers sorts traffic before it reaches your server

301ST — Wed, 07 Oct 2026 14:00:49 +0000

My site is on a VPS in Frankfurt. How can a Cloudflare Worker send my visitors somewhere before they reach it?

The question carries an assumption. It treats the Worker as a place where the site has to live, the way a hosting account is. A Worker on a route is something else. It runs on Cloudflare's edge, on the path between the visitor and wherever your DNS points, and it sees every request to that hostname before your server does.

That position is what a traffic distribution system needs. A TDS looks at each visitor, checks a list of rules and decides where the visitor goes: to a country page, to the mobile offer, to one of three landing pages under test, or on to your server as if nothing had happened. The server can be anything: a VPS, shared hosting, a page builder, or static files on Cloudflare Pages, which is where Site Generator publishes the affiliate sites it builds. The TDS does not care, because it only ever forwards to it. Whether the TDS should sit on the site's own domain or on a subdomain for ad clicks is covered below.

This guide explains how that works on Cloudflare, using the TDS in 301.st as the worked example, read from its source code. Every Cloudflare limit below was checked against Cloudflare's documentation on 6 October 2026.

Where the Worker sits

When a DNS record in a Cloudflare zone is proxied (the orange cloud), the visitor's browser does not connect to your server. It connects to Cloudflare, which terminates TLS, applies the zone's rules and then opens its own connection to the address in the record. A Worker route plugs into that middle step. Cloudflare's documentation on routes describes what happens when the Worker passes the request on:

Calling fetch() on the incoming Request object will trigger a subrequest to your application server, as defined in the DNS settings of your Cloudflare zone.

So the Worker does not replace your server. It stands in front of it, and the server stays where the DNS record says it is.

Four conditions make this true, and each of them is a place where a setup quietly fails.

The zone is on Cloudflare. The domain's nameservers point to Cloudflare. A route can only be created inside a zone you have.

The record is proxied. Routes need "a DNS record set up for the domain or subdomain proxied by Cloudflare". A grey cloud record sends visitors straight to your server's IP, and the Worker never runs for them.

The route pattern covers the hostname. example.com/* matches example.com and every path under it, but not www.example.com. That is a separate hostname and needs its own route or a pattern like *example.com/*.

No more specific route claims the request. "When more than one route pattern could match a request URL, the most specific route pattern wins", and only that one Worker runs. A Worker you already have on example.com/api/* keeps /api/ for itself.

Your server needs nothing from this. It answers Cloudflare the way it answered before. The usual origin settings still apply: the SSL mode of the zone has to match what the server can do, or Cloudflare answers with a 525 or 526 (the article on those errors covers the fixes).

What 301.st puts in your account

The TDS does not run on our infrastructure. It runs in your Cloudflare account, and that is a deliberate choice: the requests count against your Workers quota, the rules live in your database, and the Worker keeps working if our API is unreachable.

When you connect an account, you give 301.st an API token. The token covers the whole platform, DNS and redirects included; the TDS part of it is Workers Scripts, Workers Routes, D1 and Pages read. With those, the platform creates in your account:

What	Name	What it is for
Worker	`301-tds`	the TDS itself
Worker	`301-health`	domain health checks, separate from the TDS
D1 database	`301-client`	your rules, domain settings and hourly counters
Route	`yourdomain.com/*`	one per domain that has at least one active rule

A domain without rules gets no route, so its traffic never touches the Worker. The platform will not take over a route that already belongs to another Worker.

Note the pattern. The route is created for the hostname you added, exactly as written. If visitors arrive on both example.com and www.example.com, add both as domains.

The main domain or a go subdomain

A route on example.com/* puts the Worker in front of all of the site's traffic: search visitors, direct visits, search engine crawlers, and every image, stylesheet and font they load. The ad clicks you actually want to sort are a small part of that. The rest spends the Workers quota on visitors no rule is meant for, which is how a TDS pushes a site onto the paid plan, and a mistake in a rule reaches the whole site, search engines included.

So the setup we recommend gives the ad clicks a hostname of their own:

Add go.example.com as a domain in 301.st. The platform creates a proxied placeholder record for it, since nothing is served there. Point your ads at go.example.com, give it your rules, and add one more with no conditions and the lowest priority that redirects to https://example.com/, so every visitor no other rule took lands on the site. The site and its own traffic never touch the Worker.

One thing works differently on go: when the Workers quota runs out, fail open does not help, because with the Worker skipped the request reaches the placeholder and gets an error. Only ad clicks count against the quota there, though, so it runs out far later.

A TDS on the main domain is for when you do want every visitor sorted. For a site on a server it works today. For a site on Cloudflare Pages, a custom domain of a Pages project as Site Generator sites are, 301.st does not put a route on the main domain yet: applying the rules fails with an error that suggests a subdomain. Support for it is in development; until then, use go.

One request, step by step

Here is what the 301-tds Worker does with a request, in the order the code does it.

Two paths are taken. The Worker answers /health and /_health on your hostname itself, for the platform's checks. If your site has its own page at one of those paths, visitors will get the Worker's answer instead.

Static files go straight through. Requests for stylesheets, scripts, images, fonts and similar files skip the rules entirely. They still invoke the Worker, because the route covers every path, but they never touch the database.

Rules come from your D1, cached for a minute. The Worker reads all active rules in one query and keeps them in memory for 60 seconds. The cache lives in one Worker instance, and Cloudflare runs many, so after a change different visitors may see the old and new rules for up to a minute.

Changes reach the edge when you press Apply. Editing a rule in 301.st saves a draft. Apply writes the rules into your D1 through Cloudflare's API. Once an hour the Worker also pulls the full rule set from the platform, as a backstop if a push failed.

The first matching rule wins. Rules are tried in a fixed order: rules that target bots first, then the other traffic shield rules, then SmartLink rules. Inside each group the priority you set decides, highest first. The first rule whose conditions all hold runs its action, and no other rule is looked at.

The groups come before the priority, and that matters. A rule counts as a bot rule only if it requires "bot". Suppose you run Bot Shield, which blocks every bot, and a datacenter rule with a higher priority number that sends datacenter traffic to another page. An uptime monitor from a cloud server is a bot, so Bot Shield sees it first and blocks it. The datacenter rule never gets the chance.

Nothing matched means your server. The request goes on with fetch(request), unchanged, with its method, headers, cookies and body. The visitor sees your site as if the TDS were not there. The Worker only adds one to the hourly pass counter.

What a rule can check

A rule is a set of conditions. All of them have to hold for the rule to match. A condition left empty is not checked at all, so a rule with only a country list matches every device, every browser and every hour in those countries.

Condition	What the Worker reads
Country, or countries to exclude	`request.cf.country`, set by Cloudflare from the visitor's IP
Device: mobile or desktop	the `Sec-CH-UA-Mobile` client hint, otherwise the user agent; an iPad counts as desktop
Operating system, browser	the user agent
Bot, bot category, verified, network class	the bot classifier, described in the next section
Hour and day of the week	the clock in UTC, not the visitor's local time
`utm_source`, other query parameters	the query string; a source list and a parameter list on the same rule match if either does
`utm_campaign`	the query string, as a separate condition
Path	a regular expression on the path, without the query string
Referrer	a regular expression on the `Referer` header

Hours are UTC on purpose. The counters are stored by UTC hour, and a rule in the visitor's local time would spread over every hour of the report. If you want "nights in Germany", convert to UTC yourself and remember the clock change in March and October.

The utm_source or parameter pair is the one place where a rule says "either". The Facebook preset matches utm_source=facebook or the presence of fbclid, because paid social clicks often carry fbclid and no UTM tags at all.

The TDS does not match on the visitor's IP address, a specific ASN number, the browser language or cookies. If you need one of those today, a rule in 301.st will not do it.

What a rule can do

A redirect is an answer to the browser. The Worker tells it where to go and is done; the browser then connects to the target on its own, wherever that target is hosted. The Worker does not see what happens there, which is why counting a conversion on the target needs the postback described further down.

Redirect. With the status code you choose: 301, 302, 307 or 308. A permanent code tells browsers to remember the answer, which is wrong for a TDS decision that depends on the visitor, so the presets use 302. Every redirect the TDS sends also carries Cache-Control: private, no-cache, so no shared cache stores one visitor's answer for the next.

The redirect can be sent in five ways: a plain HTTP redirect, a meta refresh page with an optional delay, a meta refresh that hides the referrer, a JavaScript location.replace(), or an iframe that keeps your address in the bar. A separate switch adds Referrer-Policy: no-referrer to any of them. Hiding the referrer is off by default, because some affiliate networks attribute by it and would stop counting without telling anyone.

The target URL can contain macros that the Worker fills from the request: {country}, {device}, {os}, {browser}, {path} and {host}. A rule that sends every country to https://example.net/{country}/ is one rule, not two hundred.

Block. The Worker answers 403 Blocked and your server never sees the request.

Split. A split rule has several target URLs and picks one for each visitor. With a fixed split you set weights, and 90 and 10 send nine visitors in ten to the first page. A weight of zero pauses a page without losing its numbers. The other three modes learn from conversions as they arrive and shift traffic toward the page that converts better: Thompson sampling, which is the default, UCB and epsilon greedy. A split can also keep separate pools of pages per group of countries, so the German traffic is tested on German pages.

A split that learns needs to know which visitor converted. That is the job of the signed click token the Worker adds to the target URL, and of the postbacks that bring the conversion back. Setting those up with an affiliate network and an ad network is covered in the article on postbacks for a TDS.

How the TDS tells bots apart

Every request goes through a classifier before any rule looks at it. The classifier puts a bot into one of five groups by its user agent: search engines, AI training crawlers, uptime monitors, ad reviewers and link preview fetchers. A user agent shorter than ten characters counts as a bot. A user agent with bot, crawl or spider in it that no table recognizes is an unverified bot of no group.

A user agent is a string anyone can send. That is why the classifier keeps a second, separate answer: verified or not. It comes only from Cloudflare. When Cloudflare has confirmed that a request really comes from the bot it claims to be, it sets request.cf.verifiedBotCategory (the field). The group comes from the user agent table, the confirmation from Cloudflare. A scraper that sends Googlebot's user agent lands in the search group and stays unverified.

The third answer is the network. If the autonomous system the request comes from belongs to a hosting or cloud provider (AWS, Google, Azure, Hetzner, OVH, DigitalOcean and similar), the request is marked as coming from a datacenter. People browse from home and mobile networks. Checkers, scrapers and review systems often run in datacenters, whatever browser they claim to be.

A rule can combine these: bot or not, which groups, verified or not, datacenter or not.

The presets

You do not have to write rules from scratch. 301.st ships these templates, each one a single rule with its priority already set.

Preset	Matches	Does
AI Guard	AI training crawlers	blocks, or redirects to a page you choose
Cloaking Standard	ad reviewers, search engines, link preview fetchers	redirects them to a page you choose (a "white page")
Datacenter Cloak	any request from a datacenter network, bot or not	redirects it to a page you choose
Bot Shield	any bot	blocks, or redirects
Geo + Mobile	mobile visitors from the countries you list	redirects
Mobile Redirect	mobile visitors	redirects
Desktop Redirect	desktop visitors	redirects
Geo Filter	visitors from the countries you list	redirects
Facebook Traffic	`utm_source` of facebook, fb, fb_ads or meta, or `fbclid`	redirects
Google Traffic	`utm_source` of google or google_ads, or `gclid`	redirects
UTM Split	the `utm_source` values you list	redirects

AI Guard leaves search engines alone on purpose. They have their own group, and blocking them to keep scrapers out would take the site out of search results.

What the two cloaking presets do, and what they cost you

Cloaking Standard and Datacenter Cloak show one page to the systems that review a site and another page to the people who visit it. That is what the word means, and we name the presets after it so nobody switches one on by accident.

Know what you are running into. Google's spam policies define cloaking as "presenting different content to users and search engines with the intent to manipulate search rankings and mislead users". Google Ads names it in its Circumventing systems policy: "showing different content on your website to different people or to Google to try to hide things that might break Google Ads' rules". The penalty is stated in the same place: accounts "will be suspended upon detection and without prior warning". Other ad platforms have rules of the same kind.

The same Google Ads page draws the line for the rest of this article. It says "It's okay to show slightly different content to different people, like showing a landing page or ad destination in different languages, having different special offers, or adjusting for geographical location". Its forbidden example is a shop that shows Google a page selling clothing while the site sells guns. A geo rule that sends each country to its own landing page for the same offer fits the first description. Which side a particular rule falls on is your decision and your risk.

Two technical facts matter if you use them. First, Cloaking Standard matches on the user agent unless you also require "verified". Without that switch, a reviewer that sends a plain browser user agent goes through to the real page, and anyone who types Googlebot into their user agent gets the white page. Second, Datacenter Cloak recognizes networks by the name of the provider that owns them. That catches the large clouds and misses a provider whose name is not on the list.

What it costs on the Free plan

A route runs the Worker on every request to the hostname: the page, and each image, stylesheet and font it loads. The static bypass described above saves database work, not invocations. The Workers Free plan allows 100,000 requests a day, reset at midnight UTC (limits).

The database has its own daily allowance. D1 on the Free plan includes 5 million rows read and 100,000 rows written a day (D1 pricing). On a domain with rules, every page request reads the domain's settings and writes at least one counter row. So on page requests the two allowances run out at about the same traffic.

What happens then is different for the two.

When D1 runs out, Cloudflare says queries stop until the reset. The TDS treats a failed rules query as "no rules" and passes every request to your server. Your site keeps working. The routing stops, and so does the counting.

When Workers run out, the route decides. A route either fails open, which "Bypasses the Worker. Requests behave as if no Worker is configured", or fails closed, which "Returns a Cloudflare 1027 error page". 301.st does not set this mode when it creates the route today. Open Workers & Pages in your Cloudflare dashboard, find the routes of 301-tds, and check the mode on each. On a TDS in front of a working site, fail open is almost always what you want: when the quota ends, visitors reach your server unsorted instead of reaching an error page.

What lifting both costs. The Workers Paid plan is $5 a month per account with 10 million requests included, then $0.30 per additional million (pricing). It has no daily request limit, and it removes the D1 daily limits as well. For a TDS on more than a few small domains, that is the plan to be on.

The article on bot analytics Workers works through the same route arithmetic with real numbers from this site.

Setting it up

Move the zone to Cloudflare if it is not there, and check that the record for the hostname is proxied. Leave it pointing at your current server.
Check the SSL mode against your server: Full (Strict) if the server has a valid certificate, Full if it has any certificate, Flexible only if it has none.
Create an API token with the permissions the 301.st connect screen lists, and connect the account. The platform creates the two Workers and the database.
Add the domain the ads point at: go.example.com with its last catch-all rule, as described above, or the main domain if you want every visitor sorted, plus www as a separate one if visitors use it.
Create a rule, from a preset or by hand, and press Apply. The route appears with the first active rule.
Set the route to fail open in the Cloudflare dashboard, unless you are on Workers Paid.
Test from outside. A user agent is the easiest condition to try:

curl -sI https://example.com/ | grep -i -E '^(HTTP|location)'
curl -sI -A "Mozilla/5.0 (iPhone; CPU iPhone OS 18_0 like Mac OS X) Mobile" \
  https://example.com/ | grep -i -E '^(HTTP|location)'

The first request should come back with your server's normal answer, the second with the redirect of a mobile rule. Rules by country need a request from that country, through a VPN or a remote browser. Allow a minute after Apply for the rule cache.

When you need a TDS at all

If all you need is one fixed condition, try Cloudflare without a Worker first. A Single Redirect rule is an expression in Cloudflare's rules language, which has fields for the visitor's country (ip.src.country) and user agent (http.user_agent), and it does not count against any request quota. The Free plan gives a zone ten of them; every way to redirect on Cloudflare lays out what each option can match and what it costs. The Worker earns its place when the decision needs something a static rule does not have: telling verified bots from claimed ones, splitting traffic and learning which page converts, counting every outcome per rule and hour, and keeping those rules the same across a portfolio of domains. That last part is the reason 301.st exists, and the TDS is the piece of it that runs in front of your server.

Bot analytics wants a Worker on every request. What it costs on Cloudflare

301ST — Wed, 30 Sep 2026 14:00:40 +0000

You want to know which bots crawl your site: which AI crawlers, how often, and which pages they get a 404 on. A tool offers to show you, and the setup screen asks for a Cloudflare API token with Workers Scripts Edit. With that token it deploys its own Worker and sets up a route that runs it on every request to your site.

Ahrefs Bot Analytics works this way, and so do Known Agents (formerly Dark Visitors), Profound and Scrunch. The Worker is short and does what it says. The route in front of it is the part that changes how your site runs, and none of these setup screens mention the cost.

This article covers what that route does on Cloudflare's Free plan, what Cloudflare already gives you without it, and how to log bots yourself in a Worker you already have. Every limit below was checked against Cloudflare's documentation on 30 September 2026, and every traffic number comes from this site, 301.sh, which runs on the Free plan.

What the Worker does

Ahrefs asks for three permissions: Account Workers Scripts Edit, Zone Workers Routes Edit and Zone Read. Its setup screen lists three steps: "Find the zone matching" your site, "Deploy the Ahrefs analytics worker", "Set up a route to run on all requests". It adds: "Your token is used once and not stored." The manual setup in its documentation uses the route pattern *yourwebsite.com/*.

The Worker passes each request through unchanged with fetch(event.request). After the response goes out, it sends a report inside event.waitUntil, so the report does not delay the page. The report carries the full URL including the query string, the visitor's IP from cf-connecting-ip, the user agent, the referer, the method, the status and the content type. It also carries three headers from Web Bot Auth: signature, signature-input and signature-agent. Those are how a signed AI agent proves who it is, and they are the most interesting part of the payload.

Known Agents and Profound publish Workers of the same shape. Profound's skips /checkout, /cart, /admin and /api before it reports (its docs). The Ahrefs one reports everything.

What the route costs

Every request becomes a Worker invocation. The Workers Free plan allows 100,000 requests a day, reset at midnight UTC (limits). A route on *example.com/* matches the page and every image, stylesheet, script and font the page loads. A page with twenty files spends twenty one requests of that quota on one visit. The report the Worker sends is a subrequest, and Cloudflare does not bill subrequests; the invocation itself counts.

Static files stop being free. If your site is Workers static assets, Cloudflare says "Requests to static assets are free and unlimited", and bills only the requests that invoke a Worker (billing). A route Worker in front makes every one of them invoke a Worker.

Here is the difference on 301.sh. In the seven days to 30 September the zone served about 19,200 requests, and our own Worker ran 2,421 times, because it runs only on page URLs and lets the static files go out without it. A route on /* would have run a Worker on all 19,200, eight times as many. This site stays far below 100,000 a day either way. A site with 10,000 page views a day and twenty files a page would not.

The route runs before your own Worker. Cloudflare's documentation on custom domains: "Any Workers running on routes before your Custom Domain can optionally call the Worker registered on your Custom Domain by issuing fetch(request)" (custom domains). So on a site that already runs its own Worker, the tool's Worker is the first code that sees each request. The documentation does not say how the pair is counted against the quota.

Know what happens at 100,000. Past the daily limit a route either fails open, which "Bypasses the Worker. Requests behave as if no Worker is configured", or fails closed, which "Returns a Cloudflare 1027 error page". The mode is a toggle on the route. The documentation does not say which one a new route gets, and the route request in the Ahrefs manual setup does not set it. Open Workers & Pages, find the route the tool created, and check it. A route that fails closed turns a traffic spike into an error page for your whole site.

A more specific route wins. "The most specific route pattern wins" (routes). If you already have a Worker on www.example.com/* or example.com/api/*, those requests go to your Worker, and the analytics tool never sees them. Nothing tells you they are missing.

Every visitor's data leaves. The route cannot tell a bot from a person before it runs, so the report goes out for people too: their IP, the page they opened, the query string with whatever your site puts in it. That makes the tool a processor of your visitors' personal data, which your privacy policy may need to say.

The token is broader than the job. The Ahrefs documentation suggests a token on All accounts and All zones, and mentions narrowing it only as an alternative. Workers Scripts Edit on an account lets the holder upload any Worker to it. Create the token for the one zone the tool needs, and delete it once the Worker is running. "Not stored" is then something you do not have to take on trust.

What lifting the quota costs

The Workers Paid plan is $5 a month per account with 10 million requests included, then $0.30 per additional million (pricing). There is no daily limit on Paid, so the fail mode stops mattering. For most sites that settles the quota question for $5. It does not change the other items above: static files are still billed as invocations, and the data still leaves.

What Cloudflare already shows you

Before adding a Worker, look at what Cloudflare already records for the zone.

Tool	Plan	What it shows
GraphQL Analytics API	all plans; on Free 31 days back, up to 30 days per query	every bot by user agent and Cloudflare's verified category, with path and response status
AI Crawl Control	all plans; referral data on paid plans	AI crawlers by operator, the most crawled paths, response status codes
Security Analytics	all plans; the last seven days on Free	sampled individual requests with their properties and scores
Bot Analytics	Business and Enterprise	bot scores and verified bot traffic
Logpush	Enterprise	every request, sent to your storage

AI Crawl Control is the dashboard answer for AI crawlers. The API answers for every bot, and it is the row we checked on our own zone.

Ask the API

On 301.sh, a Free zone, the settings node of the GraphQL API lists userAgent, verifiedBotCategory, clientRequestPath and edgeResponseStatus among the fields of httpRequestsAdaptiveGroups. That is enough to ask which verified bots got a 404 this week:

query ($zone: String!, $since: Time!, $until: Time!) {
  viewer {
    zones(filter: { zoneTag: $zone }) {
      httpRequestsAdaptiveGroups(
        limit: 50
        filter: {
          datetime_geq: $since
          datetime_lt: $until
          verifiedBotCategory_neq: ""
          edgeResponseStatus: 404
        }
        orderBy: [count_DESC]
      ) {
        count
        dimensions { verifiedBotCategory userAgent clientRequestPath }
      }
    }
  }
}

POST it to https://api.cloudflare.com/client/v4/graphql with a token that has Zone Analytics Read, the zone ID and a time range in the variables. Drop the edgeResponseStatus line to see all verified bot traffic. For the bots Cloudflare has not verified, filter on verifiedBotCategory: "" and userAgent_like: "%bot%" instead.

On our zone, over the seven days to 30 September, about 1,400 of 19,200 requests came from verified bots in nine categories. Search engine crawlers led, then AI crawlers, SEO tools and aggregators. The 404 query found two things worth fixing or knowing. DuckDuckBot asked for /favicon.ico thirteen times; the site had only /favicon.svg, and has both since this query. AI crawlers asked for addresses such as /2018-gopherconuk-slides that this site has never had.

The unverified query found something else. A client with the user agent Claude-SearchBot/1.0 asked 36 times for /api/uploads/..%2F..%2F.env, a path that tries to climb out of an upload folder to a file of secrets. Cloudflare did not verify it, and no search crawler needs that path. A tool that counts by user agent alone files those 36 requests under Anthropic.

The category values are the dashboard names with spaces, such as "AI Crawler" and "Search Engine Crawler". A filter on "AICrawler" returns nothing and no error.

What the API does not give you is history past 31 days, or the Web Bot Auth headers. For those you need your own log.

Log bots in the Worker you already have

If your site already runs a Worker for its pages, add the log there. The request already invokes that Worker, so the log costs no extra invocation, and you decide what leaves your account. 301.sh is built this way: its Worker runs first on page URLs only, set with run_worker_first in wrangler.toml, and images and styles are served as free static assets without it.

Workers Analytics Engine is on the Free plan: 100,000 data points written and 10,000 read queries a day (pricing). The Workers Paid plan at $5 a month raises that to 10 million data points a month. Bind a dataset:

# wrangler.toml
[[analytics_engine_datasets]]
binding = "BOTS"
dataset = "bot_hits"

Then record bots on the way out:

const BOT = /bot|crawl|spider|slurp|GPTBot|ClaudeBot|PerplexityBot|Bytespider|CCBot|meta-externalagent/i;

export default {
  async fetch(request, env, ctx) {
    const response = await handle(request, env, ctx); // your existing logic

    const ua = request.headers.get("user-agent") ?? "";
    const verified = request.cf?.verifiedBotCategory ?? "";
    if (verified || BOT.test(ua)) {
      env.BOTS.writeDataPoint({
        indexes: [verified || "unverified"],
        blobs: [
          ua.slice(0, 256),
          new URL(request.url).pathname,
          String(response.status),
          request.headers.get("signature-agent") ?? "",
        ],
        doubles: [1],
      });
    }
    return response;
  },
};

Three details matter.

Only bots are written. People's requests never reach the dataset, so there is nothing personal in it to disclose, and the 100,000 daily data points go to the traffic you want to study.

verifiedBotCategory is Cloudflare's check, the user agent is the bot's claim. Anyone can send GPTBot in a header. Cloudflare fills request.cf.verifiedBotCategory only for bots it has verified. Write both and compare.

writeDataPoint is not awaited. It returns at once and the runtime stores the point in the background, the same as in counting clicks on a redirect, which also covers the read side: one SQL query, and SUM(_sample_interval) rather than COUNT().

Which bots get a 404:

SELECT index1 AS category, blob1 AS agent, blob2 AS path,
       SUM(_sample_interval) AS hits
FROM bot_hits
WHERE blob3 = '404' AND timestamp >= NOW() - INTERVAL '7' DAY
GROUP BY category, agent, path
ORDER BY hits DESC
LIMIT 50

If your site has no Worker today, adding one only for this brings back the quota question. You can still narrow it: a route on the page paths rather than /* leaves images and styles alone.

Where this breaks

The regex decides what a bot is. A crawler that sends a browser user agent is not in your dataset unless Cloudflare verified it. Every tool that reads the user agent has the same limit, the paid ones included.

Analytics Engine keeps data for three months. For a year of history, export it on a schedule.

The API numbers are estimates. Cloudflare samples high volume and "returns an estimate derived from the sampled value" (sampling). Our week came back with an average sample interval of about 2.5. Good for which bots and which paths; not for exact counts of a rare event.

Thirty one days is all the API keeps on Free. Save a weekly result if you want a trend.

Web Bot Auth headers are rare today. Recording signature-agent costs nothing, and the column will fill as more agents sign their requests. Do not read an empty column as proof that no agents visit.

When 301.st is worth it

For one site you do not need us. Run the query above once a week, and if you want a longer history, add the log to your Worker.

301.st manages redirects and traffic rules across a portfolio of domains. On the domains where you give it rules, it runs a Worker in your Cloudflare account, so this is the same trade described above, taken for routing the traffic rather than only watching it. That Worker sorts each request into seven bot categories, from search engines and AI crawlers to link previews and uptime monitors, using the user agent and Cloudflare's verified bot flag. A rule checks those categories before any other rule on the domain: AI Guard blocks or diverts AI training crawlers and leaves search engines alone, and Bot Shield stops every bot on a domain that should never be crawled.

A screen that shows those bots per domain, with paths and response codes, is what we are building next.

What Cloudflare's free plan alerts you about, and what you check yourself

301ST — Wed, 23 Sep 2026 14:00:18 +0000

You have a few dozen domains on Cloudflare's Free plan, and most of them only redirect. You want to hear about a broken one before a customer does. Cloudflare can tell you some of that by email, for free, once you switch it on. It will not tell you that a redirect sends people to the wrong place, that someone changed a DNS record, or that a domain at another registrar is about to lapse. That holds on every plan, Enterprise included.

This article lists what the Free plan watches, what paying adds and for how much, and gives you a Worker that checks the redirects themselves. If you are still choosing how to redirect, start with every way to redirect on Cloudflare.

What Cloudflare watches, by plan

Checked on 23 September 2026 against Cloudflare's documentation and against the notification API of our own account.

What breaks	Free plan	What lifts it	Left uncovered
Origin unreachable	Passive Origin Monitoring, email; stayed silent in our test		low traffic domains, and `522`
Origin errors, `522` included	nothing	Origin Error Rate Alert, Enterprise only	everything below Enterprise
Active checks of a URL	nothing	Health Checks: 10 on Pro ($20 a month billed yearly), 50 on Business ($200)	anything past 10 or 50 URLs
Edge certificate (Universal SSL)	Universal SSL Alert, email
Origin CA certificate expiry	nothing	nothing	every plan
Domain at Cloudflare Registrar expiring	monthly email to the Super Administrator
Domain at another registrar expiring	nothing	nothing	every plan
DNS record or nameserver change	Audit Logs, no alert	nothing	every plan
Redirect sends people to the wrong place	nothing	nothing	every plan
Where alerts can go	email	webhooks with a paid subscription, PagerDuty from Business

Two rows need a note.

Passive Origin Monitoring is missing from the current list of available notifications, last updated 24 April 2026. The API still offers it: on our account it is listed as real_origin_monitoring, "Cloudflare is unable to reach your origin". Cloudflare's announcement from 2019 says it "is available to customers on all Cloudflare plans".

The webhook page says the feature "is only available if your account has at least one zone with a pro plan or above." Our account has two Free zones and a Workers Paid subscription, which starts at $5 a month, and the API reports webhooks as eligible. The getting started page has the rule that matches what we see: "Accounts with a paid service will additionally have access to webhooks."

Nothing is switched on until you add it

On 23 September our account had been serving this site since July. It held one notification policy: a billing budget alert that Cloudflare created by itself. Neither of the two free alerts above was there.

Add them under Notifications, then Add:

Passive Origin Monitoring. One policy covers every zone in the account.
Universal SSL Alert. Validation, issuance, renewal and expiration of the certificate visitors get.

Both go to an email address you type in. Pick one that somebody reads. A notification sent to a former colleague's inbox is the same failure as the renewal email in auto-renew was on and the domain expired anyway.

We broke a hostname twice and the free alert said nothing

Cloudflare describes the trigger of Passive Origin Monitoring in one place only, its post of July

The notification:

tells you if every request to your origin is returning a 521 error (web server down) for a full five minutes

A 521 means the server refused the connection. A domain set up the way the portfolio runbook recommends has no server to refuse anything: a proxied A record points at 192.0.2.1, an address nobody answers on, and the redirect runs at the edge. When someone deletes or narrows the redirect rule, Cloudflare forwards the request to 192.0.2.1, waits, and gives the visitor a 522, a timeout.

So we tested both on 23 September, with the notification switched on in our account.

A proxied hostname pointing at 192.0.2.1 with no redirect rule. From 08:24 to 08:44 UTC we requested it every 15 seconds. All 35 responses were 522.
The same hostname pointing at a server that refuses connections on port 443, the port Cloudflare uses in our Full SSL mode. From 08:46 to 09:06 UTC, the same schedule. All 78 responses were 521.

The account's notification history stayed empty through both runs and until 09:24 UTC, when we stopped looking. No email arrived at the address on the policy. The second run is the case the 2021 post describes, and it did not fire either. The documentation names no minimum amount of traffic, but a request every 15 seconds was not enough.

A parked domain that only redirects gets less than that. Turn Passive Origin Monitoring on, since it costs nothing, and do not read its silence as proof that anything works. The one notification documented to count 522 is the Origin Error Rate Alert, sold on Enterprise only.

Check the redirects yourself on a cron Worker

What no plan offers is a request to your domain and a look at where the answer points. A Worker on a schedule can do that, and a Worker with no route of its own runs on workers.dev, so it needs no domain.

// Each row: the URL, the status you expect, the Location you expect.
const CHECKS = [
  ['https://old-brand.com/', 301, 'https://brand.com/'],
  ['https://www.old-brand.com/', 301, 'https://brand.com/'],
  ['https://promo-brand.net/', 302, 'https://brand.com/spring/'],
];

async function probe() {
  const failures = [];
  for (const [url, status, location] of CHECKS) {
    try {
      const res = await fetch(url, { redirect: 'manual' });
      const got = res.headers.get('location');
      if (res.status !== status || got !== location) {
        failures.push(`${url} → ${res.status} ${got ?? '(no Location)'}`);
      }
    } catch (err) {
      failures.push(`${url} → ${err.message}`);
    }
  }
  return failures;
}

export default {
  async scheduled(event, env) {
    const failures = await probe();
    if (failures.length === 0) return;
    const text = failures.join('\n');
    await fetch(env.ALERT_WEBHOOK, {
      method: 'POST',
      headers: { 'content-type': 'application/json' },
      // Slack reads `text`, Discord reads `content`.
      body: JSON.stringify({ text, content: text }),
    });
  },
};

name = "redirect-check"
main = "index.js"
compatibility_date = "2026-09-01"

[triggers]
crons = ["*/30 * * * *"]

Store the webhook address as a secret with wrangler secret put ALERT_WEBHOOK, so it stays out of the code. redirect: 'manual' is the important part: the Worker gets the first answer and does not follow it, so you compare exactly what a visitor's browser receives.

We ran the probe() function from workers.dev on 23 September against our own domains, which sit on the same Cloudflare account as the Worker. The correct redirects passed without a message. A row where we deliberately expected the wrong target was reported. A domain that does not exist came back as a 530 response rather than an error, and the status check caught it just the same.

On the Free plan two limits decide how far this goes. A Worker invocation may make 50 subrequests, so one run checks 49 URLs and keeps one request for the alert. An account may have 5 cron triggers in total. Our account runs nine, seven of them for the workers that distribute this blog, so we were past the Free limit before monitoring came up. Workers Paid raises the numbers to 10,000 subrequests and 250 cron triggers, from $5 a month.

Where this breaks

The checker lives inside Cloudflare. When Cloudflare has a bad day, the Worker and the notifications have it too. From 19 June 11:35 to 23 June 02:50 UTC this year, some security and DDoS alerts were not delivered, as a community thread and the status page recorded. A monitor outside Cloudflare, such as UptimeRobot, sees what visitors see, a 522 included.

Notifications belong to the account, not the domain. You cannot mute one zone in an account wide policy, and a question asking how to do that has sat without a reply since June.

DNS changes leave a record and nothing else. Audit Logs are available on every plan and kept for 18 months, but no notification reads them. In January someone found their nameservers changed after the zone was added to a second account, and learned about it when the site went down. Polling the Audit Logs API, or resolving each domain's NS records on a schedule, is the only way to hear about it sooner.

Origin CA certificates expire in silence. Cloudflare says so directly:

Cloudflare does not currently send expiration notifications for origin CA certificates.

Certificates now expire in 200 days has a command that reads the one on your server.

Domains at other registrars are invisible. Cloudflare Registrar sends a monthly email listing domains "expiring in the next 60-90 days". A domain registered anywhere else gets nothing from Cloudflare.

When 301.st is worth it

For a handful of domains you do not need us. Switch on the two alerts, deploy the Worker with your list, and read the email.

With hundreds of domains, the gap that hurts most is the one nothing on Cloudflare covers: domains whose nameservers no longer point where the redirect rules live. 301.st resolves the NS records of the domains it manages on a loop, each domain at least twice a day, and compares them with the ones Cloudflare assigned. It rereads each zone's status from Cloudflare on a rolling schedule. When a domain with active rules stops getting traffic through them, because the nameservers moved or the zone left the account, it emails you the list.

The rest shows on one screen for the whole portfolio rather than as alerts: the VirusTotal verdict for each domain, using your own API key; Cloudflare's phishing block; a daily count of redirect responses per host that flags a drop of half, nine tenths, or to zero; and the registration expiry read from RDAP, whichever registrar holds the domain.

It does not request each redirect and compare the target with what you expected. That is the Worker above, and it is worth running next to 301.st.

The .com price rises on 1 November. Lock today's for up to ten years

301ST — Mon, 21 Sep 2026 14:00:18 +0000

On 1 November every .com renewal gets more expensive. Verisign, which runs the .com registry, announced it with its quarterly results on 23 April:

Verisign announces that it will increase the annual registry-level wholesale fee for each new and renewal .com domain name registration from $10.26 to $10.97 effective Nov. 1, 2026.

That is 71 cents per domain per year, and it is the first of up to four such steps. The same registry contract that allows the steps also gives every domain owner a way around them. Section 7.3(f) of the .com Registry Agreement:

Registry Operator shall provide no less than six months prior notice in advance of any increase for new and renewal domain name registrations and for transferring a domain name registration from one ICANN-accredited registrar to another and shall continue to offer for periods of up to ten years new and renewal domain name registrations fixed at the price in effect at the time such offer is accepted.

Until 1 November, a renewal of up to ten years is charged at today's wholesale price, at any registrar. The rest of this article is about which of your domains to do that for, how many years each one can take, and what it costs.

What the contract allows from here

The price can move once per Pricing Year, which the agreement defines as 26 October to 25 October, and only in the last four Pricing Years of each six year period. The first period started on 26 October 2018, so the current one runs to October 2030 and its four increase years start in October 2026, 2027, 2028 and 2029. Each step is capped at 7 percent. In the previous period Verisign took all four, the last one bringing the price to $10.26 in September 2024.

From	Wholesale	At Cloudflare Registrar
today	$10.26	$10.46
1 November 2026	$10.97	$11.17
26 October 2027	up to about $11.7	about $11.9
26 October 2028	up to about $12.6	about $12.8
26 October 2029	up to about $13.4	about $13.6

The rows after November are ceilings, not announcements; each one needs its own six months' notice. The Cloudflare column is the wholesale price plus ICANN's fee of $0.20 per domain year, which has applied since 1 July 2025. Cloudflare adds nothing on top, and its public domain search showed .com at $10.46 on 19 September 2026. If you see $10.44 quoted somewhere, it was computed with the old fee.

The date that sets your price is the renewal date

A domain does not renew on its expiry date. Cloudflare's documentation, updated 24 April 2026:

The first auto-renew attempt will occur approximately 30 days prior to expiration.

So a .com expiring on 15 November renews in mid October, at $10.46. One expiring on 15 December renews in mid November, at $11.17. Auto-renew keeps a domain registered; it does not lock a price for the years ahead. A manual renewal for several years does. Auto-renew has failure modes of its own too.

How many years each domain can take

The registry caps a registration at ten years from today:

Renewal registrations of Registered Names (where available according to functional specifications and other requirements) may be made in the registry for terms not to exceed a total of ten years.

A domain that expires next summer can take nine more years. One already paid up to 2033 can take three. Verisign publishes the expiry date of every .com over RDAP, so the headroom for a whole list is one loop. The script needs curl, jq and GNU date; on macOS use date -j -f '%Y-%m-%dT%H:%M:%SZ'.

#!/usr/bin/env bash
set -uo pipefail

printf '%-26s %-30s %-11s %s\n' DOMAIN REGISTRAR EXPIRES CAN_ADD

now=$(date +%s)
while read -r domain; do
  [ -z "$domain" ] && continue

  json=$(curl -s "https://rdap.verisign.com/com/v1/domain/$domain")
  expires=$(jq -r '.events[]? | select(.eventAction=="expiration") | .eventDate' <<<"$json" 2>/dev/null)
  if [ -z "$expires" ]; then
    printf '%-26s %s\n' "$domain" "not registered"
    continue
  fi
  registrar=$(jq -r '.entities[]? | select(.roles | index("registrar"))
                     | .vcardArray[1][] | select(.[0]=="fn") | .[3]' <<<"$json")

  # The registry caps a registration at ten years from today.
  left=$(( ($(date -d "$expires" +%s) - now) / 86400 ))
  if [ "$left" -lt 0 ]; then
    can_add="expired"
  else
    can_add=$(( (3652 - left) / 365 ))
  fi

  printf '%-26s %-30.30s %-11s %s\n' "$domain" "$registrar" "${expires%%T*}" "$can_add"
  sleep 0.5
done < domains.txt

A run on 19 September 2026 against some well known names:

DOMAIN                     REGISTRAR                      EXPIRES     CAN_ADD
example.com                RESERVED-Internet Assigned Num 2027-08-13  9
cloudflare.com             Cloudflare, Inc.               2033-02-17  3
google.com                 MarkMonitor Inc.               2028-09-14  8
verisign.com               CSC Corporate Domains, Inc.    2034-06-01  2
namecheap.com              NameCheap, Inc.                2027-08-11  9
godaddy.com                GoDaddy.com, LLC               2032-11-01  3
stripe.com                 SafeNames Ltd.                 2027-09-11  9
github.com                 MarkMonitor Inc.               2028-10-09  7
this-domain-does-not-exist-9f3.com not registered

The endpoint serves .com only. The REGISTRAR column matters as much as the count: it tells you where each renewal has to be clicked.

The arithmetic for one domain

Take a .com that expires in August 2027, so it can take nine years.

Renewed now at Cloudflare, nine years cost 9 × $10.46 = $94.14, paid today.
Renewed year by year, if Verisign stops after November: 9 × $11.17 = $100.53.
Renewed year by year, if Verisign takes every step at the ceilings above and none after 2030: about $118.

The saving is roughly $6 to $23 per domain over nine years, and more if the pattern repeats after 2030, which the contract allows. Against that, the $94.14 leaves your account today, and it does not come back:

All renewals are final and Cloudflare will not issue refunds.

Which domains to lock

A domain you will keep no matter what, the name of a business or a site with traffic, should take every year it can. The saving is certain and the money would have been spent anyway.

A domain that only redirects is a judgement you can make with numbers. The portfolio audit sorts domains by whether they still answer and how much authority they carry. The ones it marks as worth fixing are worth locking. The ones it marks to let lapse are the trap here: nine prepaid years on a domain you drop after two leave seven of them, $73.22, paid for nothing.

A domain with two or three years of headroom left gains little either way, because most of its term is already paid at an older price.

Doing it at Cloudflare

In the dashboard: Manage domains, the domain's Manage, then Renew/Extend Domain under Registration. The Renew for menu goes up to 10 years. The added years land after the current expiry, not after today:

When renewing a domain, additional years are always added to the current expiration date regardless of when the renewal takes place.

There is no bulk path through the API. The Registrar API searches, checks, registers and lists domains, and its one call that changes an existing registration says so plainly:

This endpoint currently supports updating auto_renew only.

For a portfolio that means the dashboard, and the documented path renews one domain at a time. Start well before 31 October. The contract fixes the price in effect when the registry accepts the order, and a renewal sits in Renewal Pending until it completes.

At other registrars the same contract applies, but the price you pay is theirs, including their markup, and what they charge after 1 November is their decision.

When 301.st helps, and where it stops

For a handful of .com names in one Cloudflare account you do not need anything else: run the script, open the dashboard, and it is ten minutes of work.

A portfolio spread across several registrars starts with a different question: which domains expire when, and where each one is registered. 301.st fills in the expiry date of every domain it manages from RDAP, and from whois for .ru, whatever the registrar, and sorts the list by it. That list is the order to work through before 31 October. It does not renew anything, and through Cloudflare's API nothing can. The clicks at each registrar are still yours.

Certificates now expire in 200 days. Find the domains you still renew by hand

301ST — Sun, 20 Sep 2026 14:00:18 +0000

If you bought a one year certificate for a domain this spring, the certificate you installed lasts 199 days, and the reissue for the rest of the year is yours to install. The rules for publicly trusted certificates changed on 15 March 2026, and DigiCert and Sectigo moved before that date: DigiCert has issued nothing longer than 199 days since 24 February, Sectigo since 12 March. A DigiCert certificate issued on 24 February ran out at the end of 10 September. One issued on 15 March for the full 200 days runs out at the end of September.

The 200 days are the first step of a schedule written into the Baseline Requirements, the rules every publicly trusted certificate authority follows. Version 2.3.0, dated 7 September 2026:

Certificate issued	Longest allowed	Domain check reusable for
before 15 March 2026	398 days	398 days
from 15 March 2026	200 days	200 days
from 15 March 2027	100 days	100 days
from 15 March 2029	47 days	10 days

The authorities are not waiting for the dates. DigiCert's own table puts its next step, 99 days, in early 2027. Let's Encrypt runs further ahead: from 10 February 2027 its default certificates last 64 days, from 16 February 2028 they last 45, and the time a domain check stays valid drops to 10 days and then to 7 hours.

The right column is the one that hurts a manual process. A certificate ordered by hand starts with proving control of the domain, by a DNS record, a file or an email, unless the last proof is recent enough. From March 2029 recent enough means ten days, so for a 47 day certificate the proof is part of every order. A domain whose certificate a person renews needs that person about twice a year now, about four times a year from 2027 and about eight times from 2029.

On a domain that only redirects, nobody has to do this at all. The rest of this article finds the domains where somebody still does. If you are still choosing how to redirect in the first place, every way to redirect on Cloudflare compares the options.

A redirect domain should have no certificate you renew

A parked domain, or one that only forwards, needs a certificate for a single reason: a visitor who types https:// has to finish the TLS handshake before your 301 can be sent. Nothing else on that domain uses it. Put the record behind Cloudflare's proxy and the certificate becomes Cloudflare's job. The documentation, updated 16 April 2026:

Universal certificates have a 90-day validity period. The auto renewal period starts 30 days before expiration.

Universal SSL is included on every plan, Free too. Its 90 days are already inside the 2026 and 2027 caps. They are longer than the 47 days of 2029, and closing that gap is not your job either:

For Universal certificates, Cloudflare controls the validity periods and certificate authorities (CAs), making sure that renewal always occur.

The setup that removes the question entirely is the one from the portfolio runbook: a proxied A record pointing at 192.0.2.1, an address reserved for documentation that no server answers on, and a redirect rule at the edge. There is no server behind the domain, so there is no server certificate. The only certificate in the path is the one Cloudflare renews.

Sort your domains by who renews them

You do not need an inventory to find the domains that do not fit that setup. The certificate each domain serves carries its own start and end dates, and the distance between them tells you a lot about how it got there. The script below needs only openssl and GNU date, the same pair the audit script uses for its certificate column. On macOS use date -j -f '%b %d %T %Y %Z'.

#!/usr/bin/env bash
set -uo pipefail

printf '%-34s %-24s %-9s %s\n' DOMAIN ISSUER LIFETIME LEFT

while read -r domain; do
  [ -z "$domain" ] && continue

  cert=$(echo | openssl s_client -servername "$domain" -connect "$domain:443" 2>/dev/null \
         | openssl x509 -noout -issuer -startdate -enddate 2>/dev/null)
  if [ -z "$cert" ]; then
    printf '%-34s %s\n' "$domain" "no certificate"
    continue
  fi

  issuer=$(printf '%s\n' "$cert" | sed -n 's/^issuer=.*O *= *\([^,]*\).*/\1/p')
  from=$(date -d "$(printf '%s\n' "$cert" | sed -n 's/^notBefore=//p')" +%s)
  until=$(date -d "$(printf '%s\n' "$cert" | sed -n 's/^notAfter=//p')" +%s)

  life=$(( (until - from + 43200) / 86400 ))
  left=$(( (until - $(date +%s)) / 86400 ))

  printf '%-34s %-24.24s %-9s %s\n' "$domain" "${issuer:--}" "${life}d" "${left}d"
done < domains.txt

The lifetime is rounded to the nearest day, because authorities pad both ends by hours. A run on 19 September 2026 against this site, our Russian host, and a few large sites for contrast:

DOMAIN                             ISSUER                   LIFETIME  LEFT
301.sh                             Google Trust Services    90d       89d
www.301.sh                         Google Trust Services    90d       89d
ru.301.sh                          Let's Encrypt            90d       72d
www.paypal.com                     DigiCert Inc             199d      176d
www.salesforce.com                 DigiCert Inc             199d      13d
www.zoom.us                        DigiCert Inc             366d      101d
www.adobe.com                      DigiCert Inc             365d      107d
this-domain-does-not-exist-9f3.com no certificate

The LIFETIME column is the one to sort by.

90 days or less. A machine issued this and a machine will replace it. Behind Cloudflare's proxy you should see 90 days from Google Trust Services, Let's Encrypt or SSL.com; 301.sh was reissued a few hours before the run. A short lifetime does not tell you whose machine it is. ru.301.sh is not behind Cloudflare at all: it is served by GitHub Pages, and GitHub renews its Let's Encrypt certificate.

199 or 200 days. The longest certificate a commercial authority issues under the new rules, the kind that comes with an order. The www.salesforce.com certificate was issued on 18 March and has 13 days left. Whoever renews it will do it again within 200 days, and from 15 March 2027 within 100.

365 days or more. Issued before 15 March 2026, and among the last of their kind. The next certificate for that domain lasts 200 days at most, or 100 if it is ordered after 15 March 2027. On these domains the renewal date moves closer and nothing announces it.

No certificate. The handshake never happened: the name does not resolve, or nothing answers on port 443. Visitors typing https:// get an error before any redirect can run.

On a portfolio where every domain is meant to sit behind Cloudflare, a lifetime over 90 days means Cloudflare is not the one serving that domain. On Business and Enterprise it can be a custom certificate you uploaded, which Cloudflare does not renew either. Everywhere else it is a record that was never proxied, or a domain whose nameservers never moved.

The certificate the script does not see

Behind the proxy, the script reads Cloudflare's certificate, the one visitors get. When Cloudflare forwards the request to your server, there is a second certificate on that connection. In SSL/TLS mode Full (Strict), Cloudflare checks it, and on the day it expires visitors get a 526 instead of your page or your redirect. No browser ever sees this certificate, so nothing warns you before that day.

To read it, connect to the server's address directly and name the domain:

echo | openssl s_client -connect 203.0.113.10:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -issuer -enddate

There are three ways to take this certificate off your calendar.

Automate it on the server. Any ACME client renews on its own. For the move to 64 days in February 2027, the advice from Let's Encrypt is one sentence: "you should verify that your automation is compatible with certificates that have shorter validity periods."
Use a Cloudflare Origin CA certificate. It is free on every plan and trusted by Cloudflare and nobody else, so the public schedule does not apply to it: the API offers validity from 7 days up to 5,475, which is 15 years. Cloudflare's own page names two conditions. The first:

Cloudflare does not currently send expiration notifications for origin CA certificates.

The second: it only works while the record stays proxied.

Site visitors may see untrusted certificate errors if you pause Cloudflare or disable proxying on subdomains that use Cloudflare origin CA certificates.

Write the expiry date down somewhere you will look, because Cloudflare will not remind you.

Take the server out of the path. If the server exists only to send a redirect, move the redirect to Cloudflare and point the record at 192.0.2.1 as above. The second certificate goes away with the server.

Where this breaks

Universal SSL has conditions. On a portfolio, each of them is a domain somewhere in the list.

The record is not proxied. A record set to DNS only gets no certificate from Cloudflare:

Cloudflare can only serve an SSL/TLS certificate for a DNS record when you set the record's proxy status to Proxied. If you do not do this, the origin server your record points to will be responsible for supporting SSL/TLS connections.

The zone is still pending. Universal SSL is issued to domains added to and activated on Cloudflare. Until the nameservers change at the registrar there is no certificate at all, and adding many zones at once runs into a limit of its own.

The name is two levels deep. On a full setup the certificate covers example.com and www.example.com, but not www.shop.example.com. The fix is Advanced Certificate Manager with Total TLS, listed at $10 a month on Cloudflare's plans page on 19 September 2026.

Cloudflare will not certify the name. From the limitations page:

Some domains are not eligible for Universal SSL if they contain words that conflict with trademarked domains.

A portfolio of names close to brands will find some of its domains here. Cloudflare's way out is a paid advanced certificate, or a custom one on Business and Enterprise.

A CAA record elsewhere in the chain. When you add CAA records to a zone with Universal SSL, Cloudflare adds the ones its authorities need. It cannot change the records of a zone you point to:

If your hostname CNAMEs to a domain whose zone has restrictive CAA records, those records take precedence — even if your own domain has no CAA records.

When 301.st is worth it

For a few domains you do not need us. Proxy the records, move the redirects to the edge, and run the script once a quarter. It takes a minute.

With hundreds of domains the setup has to happen at the moment a domain is added. 301.st builds it for every domain it adds: the apex gets a proxied A record at 192.0.2.1 and the redirect runs at the edge, so those domains have no server certificate at all. It also reads the certificate state of every zone from Cloudflare each day and shows which domains have a certificate that is pending or failing, such as one stuck on validation because of a CAA record two hops away.

It does not look at certificates installed on your own servers, and a record someone later switches to DNS only is not a certificate error in Cloudflare's eyes. The record shows up in the script's LIFETIME column, the server certificate in the openssl line from the previous section. Put both in a cron job.

The zone limit your API token hits and your Global API Key does not

301ST — Wed, 02 Sep 2026 14:00:39 +0000

Cloudflare's own guide for adding many sites by script ends with two limits. The page was last updated on 5 May 2026 and it says:

There are limitations on the number of domains you can add at a time - specifically, you can only sign up a maximum of 25 domains every 10 minutes.

In addition, if you have over 50 domains and, of those domains, more are pending than active, you will be blocked from adding more. We recommend waiting until your pending sites have been activated before adding more.

The portfolio runbook on this site reads the second one the way it is written: a ratio with a threshold. Under fifty domains there is nothing to plan around. That is also what we believed when 301.st started adding zones for the accounts it onboards, with a scoped API token, the credential Cloudflare tells you to use. This is what came back:

{
  "success": false,
  "errors": [
    {
      "code": 1118,
      "message": "You have exceeded the limit for adding zones. Please activate some zones."
    }
  ],
  "messages": [],
  "result": null
}

It came back on accounts with a handful of domains. On a fresh account it came back on the second one.

The rule that fits the evidence

The error is old and the community has been reporting it since before the guide had a number in it.

March 2019. A Cloudflare staff member closes a thread about code 1118: there is a limit on the number of pending zones at any one time, and validating pending zones is what raises it. No threshold is named.
September 2021. A poster quotes the support article of the day, which had no threshold either: you cannot have more pending sites than active sites on the account.
December 2024. Ten zones, three active, seven pending, blocked. The poster had read that the limit was fifty and asks why theirs is ten.
January 2025. A Free account with one zone. Adding the second returns 1118. The poster deletes everything and tries again: with no zones, one goes in; the next does not.

One rule fits every case, and it is the rule we see on the accounts we onboard: a new zone is refused once the account has more pending zones than active ones. The fifty domain threshold from the guide did not show up in any of them. Put plainly, you can add about as many zones as you already have active, and a new account with nothing active gets one.

That alone changes the plan for a portfolio. It is not add fifty, activate, add fifty. It is add one, activate it, add two, activate them, add four. The ceiling doubles with each round and the first rounds are the slow ones, because activation waits on a nameserver change at the registrar and on Cloudflare noticing it.

The part that depends on who is asking

Here is the piece we have not found written down anywhere.

The same account, the same list of domains, the same request to the same endpoint. With an API token, scoped as Cloudflare recommends, the block lands as soon as pending outnumbers active. With the user's Global API Key, the batch goes in. The only limits we have run into with the key are the two documented ones: 25 domains per 10 minutes, and the ratio once the account is past fifty.

Request signed with	A new zone is refused when	Source
API token, user or account owned	pending zones outnumber active ones, from the second domain on a fresh account	observed on the accounts we onboard, matches every thread above
Global API Key	over 50 domains on the account and pending outnumber active	the guide, and what we see with the key
Either	more than 25 domains in 10 minutes	the guide

Our reading is that the key acts as the user, the same principal as the dashboard, while a token is automation, and the pending cap applied to automation is the stricter one. That is a reading, not a statement from Cloudflare. Treat the whole section as observed behaviour on accounts we run, and check it on yours before you build on it.

Check your account in two requests

Count what you have. The zones endpoint filters on status and reports the total without paging through the list:

for s in active pending; do
  printf '%s: ' "$s"
  curl -s "https://api.cloudflare.com/client/v4/zones?account.id=$ACCOUNT_ID&status=$s&per_page=1" \
    -H "Authorization: Bearer $CF_API_TOKEN" | jq '.result_info.total_count'
done

If pending is already at or above active, try adding one domain you own with the token:

curl -s -X POST "https://api.cloudflare.com/client/v4/zones" \
  -H "Authorization: Bearer $CF_API_TOKEN" \
  -H "Content-Type: application/json" \
  --data "{\"name\":\"$DOMAIN\",\"account\":{\"id\":\"$ACCOUNT_ID\"},\"type\":\"full\"}" \
  | jq '.success, .errors'

A false followed by code 1118 means your account is under the rule above, not under the one in the guide. We have not found a plan that lifts it; the staff answer from 2019 names activation as the only lever. From here there are three ways forward.

Activate what is pending. Change the nameservers at the registrar, wait for the zone to go active, and the ceiling rises by one. This is the right answer and the slow one: hours per round, sometimes a day.
Add through the dashboard by hand. One at a time, which is the work you were scripting away.
Use the Global API Key for the adding step. Which raises the question of where that key is allowed to live.

Why the key must not leave your browser

Cloudflare's page on the Global API Key lists what is wrong with it:

Access to all Cloudflare resources - Global API key has access to all of a user's resources. This makes it impossible to safely use Global API key to access non-production resources when a user also has access to production resources.

Full permissions - Similarly, Global API key has the exact same permissions as the user, which means if the user can delete zones or change DNS records, so can the Global API key.

For these reasons, Global API key is not recommended for new customers. Current customers using Global API key are encouraged to migrate and use API tokens instead.

A platform that stores your key holds everything you hold. 301.st does not store it: onboarding takes a scoped token, and the quick path that accepts a key uses it once to mint a scoped token and discards it. That is the right design, and it means the server side of 301.st cannot perform the one step where the key is what gets through.

So the adding step moved to the one place where the key can stay yours: your browser. Cloudflare Tools is an extension we wrote in January 2026 for exactly this, and it is open source. You paste the key into the side panel. It is encrypted with AES-256-GCM under a random key that lives in session storage and is gone when the browser closes. Every request goes from your browser to api.cloudflare.com and nowhere else; no server of ours is in the path. Paste a domain list, run a preflight that sorts it into will create, exists, invalid and duplicate, and start. The batch runs at Cloudflare's pace, 25 per 10 minutes, backs off on a 429 with Retry-After, and resumes after a browser restart. The same panel does check and export to CSV, bulk delete and bulk cache purge.

It is our tool, not Cloudflare's, and it is not affiliated with or endorsed by Cloudflare.

What changed in 0.2.0

Version 0.2.0 shipped on 1 September 2026. It is live on Firefox Add-ons and going through review on the Chrome Web Store and Edge Add-ons, so those two links carry the previous version until it clears.

Tokens, not only the key. User tokens (cfut_) and account owned tokens (cfat_) are accepted alongside the Global API Key, and the kind is detected from the pasted secret. When your account already has active zones to spend, a token with Zone, Zone, Edit on the account is enough and the key never has to be pasted anywhere. Add Cache Purge if you purge.
Profiles. Several accounts or credentials, switched from the header. A running batch stays on the profile it started under, whatever you switch to meanwhile.
The toolbar button opens the panel directly, the UI follows the browser language in English and Russian, and the publisher news feed is opt in and off by default.

The next release, 0.3.0, closes the loop on the limit itself: when one account's pending count hits its ceiling, the rest of the list spills to the next profile. The limit is per account, so a portfolio spread over several accounts is the ceiling multiplied.

Where the extension stops

It adds zones. It does not move them from pending to active, because that happens at the registrar, and it does not tell you next month which of them are still pending, which record went grey, or which domain was supposed to point where. Its job ends when the batch is in.

Keeping the portfolio true after that is what 301.st does, and the runbook lists the steps it takes over. For the batch in front of you today, install the extension and paste the list.

Your redirect rule says Active and nothing happens

301ST — Tue, 18 Aug 2026 14:00:57 +0000

The rule is in the list. Its toggle says Active. You open the URL and the old page loads, exactly as before. Nothing in the dashboard suggests a problem, because nothing in the dashboard is wrong: Active means the rule was saved and is eligible to run. It says nothing about whether a request ever reached it.

That gap is the whole diagnosis. Four questions close it, in this order, and each one is answered by a single request rather than by another look at the configuration. We ran every check in this article against a live free-plan zone on 17 August 2026, including the ones whose answer is "the rule does not fire" — those are the useful ones. If you are still choosing a method, the comparison of every way to redirect on Cloudflare is the map; this is what to do when the method you picked appears to do nothing.

Question one: does the request reach your zone at all

Every other explanation assumes Cloudflare saw the request. Check that first, and check it with a rule rather than with a header, because a rule is the thing whose absence you are diagnosing.

Add a temporary redirect rule on a path that nothing on your site serves, matching exactly, and point it anywhere:

(http.request.uri.path eq "/zone-probe-9f3")

Then ask for it:

curl -sI "https://your-domain/zone-probe-9f3" | head -1

A 302 means your zone terminated that request and your rules run. A 404 from your own application, or anything else your origin would say, means they do not — and no amount of editing the redirect rule will change that. On our zone the probe went from 404 before the rule to 302 about three seconds after it was created, and back to 404 after it was deleted, though the deletion took longer to reach every edge server than the creation did. A first response is not evidence in either direction; ask twice.

If the probe stays negative, there are three ways to be outside your own zone, and they look identical from the dashboard.

The record is not proxied. Cloudflare states the requirement plainly:

Single Redirects and Bulk Redirects require that you proxy the DNS records of your domain (or subdomain) through Cloudflare.

A grey cloud means DNS only: visitors get your origin's address and connect to it directly. There is a warning for this, but it is narrow. The dashboard raises This rule may not apply to your traffic only when your expression names a hostname that has no proxied record. A rule written as http.request.uri.path eq "/" names no hostname, so it saves in silence.

The zone never activated. If the nameservers at the registrar were never switched, the zone sits pending and everything you configured is real but not live. That failure has its own signature and its own article on silent redirect failures.

Your host is on Cloudflare too. This is the one that fools people, because everything on your side looks right. If your hostname is onboarded to a platform that uses Cloudflare for SaaS, the arrangement Cloudflare calls Orange-to-Orange decides whose rules run, and it has exact conditions: the record must be a CNAME to the provider's target, it must be proxied in your zone, and the two zones must be in different accounts. When that holds, your zone is first in line and your rules do run. When it does not hold — an A record to the provider's address, or no zone of your own — the provider's zone is the only one applying settings, and your redirect rule is a note in a file nobody reads. There is no flag to check: Cloudflare's documentation says outright that no API field or zone setting reports whether Orange-to-Orange is active.

Two traps around this check. https://your-domain/cdn-cgi/trace proves you are behind a Cloudflare, not behind yours, so it cannot settle the question — and we confirmed the flip side, that a redirect rule matching /cdn-cgi/trace does not fire at all, leaving that endpoint honest. And zone analytics showing traffic proves the hostname resolves somewhere in your account's view, not that this request was evaluated by your ruleset.

The dashboard's own confirmation is Cloudflare Trace, in beta and on every plan. It simulates a request and lists the configurations that matched, in evaluation order. Its input has the hint built in: the URL "must include a hostname that belongs to your account". If Trace will not accept the hostname, the answer to question one is no. Note that Trace runs against your configuration, not against live traffic, so it cannot see the routing problem itself — only the probe request can. The API route for it exists, but it is scoped separately; a token that can create and delete redirect rules got Authentication error from it.

Question two: does the rule match what you are actually sending

This is where most of the time goes, and where one behaviour accounts for more of it than everything else combined.

A wildcard pattern is compared against the entire URL, query string included. Cloudflare's operator documentation says so in an example: a request to https://sub.example.com/folder2/page.html?s=value does not match *.example.com/*/page.html because "http.request.full_uri includes the query string and its full value does not match". Stated as a rule you can act on: a wildcard pattern that does not end in * will never match a request that carries a query string. Which is exactly what happens when you test the rule by adding ?v=2 to defeat your browser cache. The cache-buster defeats the rule instead, the page loads normally, and you conclude the rule is broken.

Here is that pair, measured, along with the rest of the matching behaviour worth knowing:

Rule	Request	Result
wildcard `https://301.sh/rule-probe/*.html`	`/rule-probe/x.html`	`302`
same rule	`/rule-probe/x.html?v=2`	`404`, no redirect
same rule	`/rule-probe/deep/x.html`	`302` — `*` crosses slashes
same rule	`/rule-probe/x.HTML`	`302` — `wildcard` ignores case
`http.request.uri.path eq "/Rule-Probe-Case"`	`/Rule-Probe-Case`	`302`
same rule	`/rule-probe-case`	`404`, `eq` is case-sensitive
`http.request.uri.path eq "/rule-probe-slash"`	`/rule-probe-slash/`	`404`, the slash is part of the path

The case row is worth a second look, because the two interfaces disagree. The wildcard operator is case-insensitive by documentation and by measurement; strict wildcard is the case-sensitive variant. But eq on a path compares strings, so a rule typed with capitals from a design document quietly matches nothing that visitors send.

Bulk Redirects have a different matching algorithm, and the difference cuts the other way. A bulk redirect matches on scheme, hostname and path only — the query string takes no part in matching at all, so the cache-buster that kills a wildcard rule is irrelevant here. What substitutes for it is defaults: Subpath matching and Include subdomains are both off unless you turned them on, so /blog does not cover /blog/post, and example.com does not cover www.example.com. And a list on its own does nothing. Cloudflare checks the redirects of each list "that is enabled by a Bulk Redirect Rule" — uploading a list and never creating the rule that switches it on is a complete, silent no-op.

Question three: did something answer before your rule got its turn

Rules products run in a fixed order, and a redirect is a terminating action. Cloudflare puts it without hedging:

for terminating actions (Block, Redirect, or one of the challenge actions), rule evaluation will stop and the action will be executed immediately

Three consequences, one of which we measured. Two redirect rules matching the same request: the first one wins, always — we deployed a pair pointing at different targets, and the answer carried the target of the first. Single Redirects run before Bulk Redirects in the product order, so when both have a rule for a URL, the Single Redirect is the one that answers. And Page Rules, if you still have them, lose to all of it: the modern rules products "take precedence over Page Rules". An old forwarding Page Rule is not what is fighting your new rule. It is what runs when your new rule does not match — which produces the more confusing symptom of a redirect happening to somewhere you did not configure.

The same phase order is why a redirect cannot be counted at the edge that issues it, which is its own article.

Question four: did it fire while you looked at a cached answer

A redirect that works is easy to hide. A 301 is a permanent redirect, and Cloudflare's rules send it without a Cache-Control header, so a browser may cache it heuristically and keep sending you to the old target long after the rule changed. The reverse also holds: a browser that once got a 200 for that URL can go on serving it from cache while the edge is redirecting everyone else. Test with curl -sI, which caches nothing, before you test with a browser tab.

And when you do reach for a cache-buster, remember question two: appending ?v=2 changes whether a wildcard rule matches. The standard advice for making a browser fetch fresh is the standard way to make this particular test lie. Use a private window, a different browser, or curl — not a query parameter.

When the redirect was never Cloudflare's to run

One case belongs outside the tree. If the redirect lives at your origin — a rewrite in .htaccess, a framework route — then Cloudflare has no rule to fire and nothing to trace. It forwards whatever the origin says, and the origin can be inconsistent in ways that are invisible from the dashboard. A report in July described exactly that: the same URL answering 301 when proxied through one Cloudflare datacenter and 200 when proxied through another, with the origin returning a clean 301 on a direct request every time. Whatever the cause, the fix is structural. A redirect expressed as an edge rule answers before the origin is contacted, so it cannot vary with what the origin decides to do that second.

Where this gets untidy

A rule whose target equals its source produces a loop, and Cloudflare does not stop it. We pointed a rule at its own path and followed the chain: six hops in, still redirecting to itself. A browser calls that too many redirects; a monitoring check may call it a 302 and pass.

Free zones get 10 Single Redirect rules, and the quota is per zone. Hitting it fails at creation rather than at runtime, so it is not a cause of this symptom — but it is a reason people put logic into one wildcard rule, where the query-string behaviour above starts to bite. The full quota table sits in the article on redirect limits.

Trace does not evaluate inactive rules, which is correct and occasionally misleading: a rule switched off looks the same in Trace results as a rule that did not match. And Trace reflects configuration, so a request that never reaches your zone traces perfectly while failing in production. That is why question one comes first and is answered with a real request.

What this costs across a portfolio

For one domain, this is a ten-minute job. Two curl calls and a temporary rule tell you which of the four questions is the wrong one, and the fix follows from the answer.

The arithmetic changes when the same question has to be asked of two hundred domains that nobody opened this month, because none of these failures announce themselves. A rule that stopped matching after a platform migration looks exactly like a rule that works, from the inside. That is the case for asking every domain the same question on a schedule — the loop from the audit script if you like scripts, and 301.st if you would rather the portfolio be watched continuously and tell you when a row changes. For a handful of domains, the script and a cron entry are genuinely enough.

How to audit agent readiness when the scanner cannot reach the site

301ST — Fri, 07 Aug 2026 14:00:58 +0000

Cloudflare runs a scanner that grades a domain on how ready it is for AI agents. We went through all twenty one of its checks in July: which four were worth implementing, and why eight of the failures were the right answer.

You point it at your site, get a number, and fix what it flags. Then you try to check the version that actually matters — the staging build with the change in it, the site that has not launched, the pages behind a login — and there is nothing to point the scanner at.

That is not a bug in the scanner. It runs in somebody else's datacenter, so it can only answer for origins that datacenter can reach. Both failure modes are one curl away, checked 4 August 2026:

$ curl -sS -X POST https://isitagentready.com/api/scan \
    -H 'content-type: application/json' -d '{"url":"http://localhost:3000"}'
{"error":"Invalid URL provided"}

$ curl -sS -X POST https://isitagentready.com/api/scan \
    -H 'content-type: application/json' -d '{"url":"https://staging.301.sh"}'
{"url":"https://staging.301.sh","scannedAt":"2026-08-04T18:31:38.462Z",
 "siteError":{"httpStatus":530,"statusText":"","bodyPreview":null,
 "retryAfter":null,"server":"cloudflare"}}

A local address is rejected outright. A host the scanner cannot resolve returns a site error instead of a scorecard. Not a low score: no score.

This matters more than it sounds, because of when you want the answer. Taking this site from Level 1 to Level 5 meant a batch of static files, then a /mcp server, then DNS records, and every one of those steps was a deploy to production first and a scan second. Publish, then find out. For a redirect you would never accept that loop.

The other place to run the checks is the browser, which reaches whatever you can reach. This article is about what that changes, what it costs, and the one rule that decides whether the result is worth anything.

What the browser has that the datacenter does not

Three things, and only the first one is obvious.

Reachability. localhost:5173, a staging host behind a VPN, an internal tool, a domain whose DNS is not public yet. If the tab loads, the audit runs.

A session. Your cookies are attached to the page request, so a site that shows an anonymous visitor a login wall gets graded on what a logged-in client actually receives.

An in-page runtime. Some of what an agent consumes is not an HTTP response at all. WebMCP exposes tools through document.modelContext inside the page, after scripts run. An HTTP probe from outside cannot see it; a script in the page can.

The rule that keeps a browser audit honest

The session is also the trap, and it is worth understanding before you write your own script, never mind which tool you use.

An agent readiness audit fetches two very different classes of thing. There is the page, which may legitimately live behind a login. And there are the machine files — robots.txt, the sitemap, llms.txt, everything under /.well-known/ — which are public by definition, because the client reading them has no account and never will.

Send your session to both and you grade a site that nobody but you can see. A /.well-known/ document that only answers for authenticated requests is a document an agent gets a 401 or a login page from. Passing it in your browser tells you nothing true.

So the split is per request, not per scan:

What is fetched	Credentials	Why
The page itself	`include`	It may be behind a login, and that is the case the external scanner cannot cover
`Accept: text/markdown` on the page	`include`	Same URL, same session, a different representation
`robots.txt`, `sitemap.xml`	`omit`	Public machine files — judge them as a crawler receives them
`llms.txt`, `llms-full.txt`	`omit`	Same
Everything under `/.well-known/`	`omit`	Discovery documents are read by clients with no account

Redirects follow the same logic. The probe follows hops the way a navigation does, each hop attaching its own cookies, and the response records the final URL. A check that passed on a URL you did not request is a check you want to see the address for.

What changes shape when the audit moves into a browser

Moving the audit into the browser is not a free upgrade. It trades one set of blind spots for another, and a tool that hides the trade is worse than the gap.

DNS-AID needs a different question, not a different tool. The extension APIs have no DNS resolver, which is where this write-up originally stopped — wrongly, because a resolver is not what you need. DNS-over-HTTPS is an ordinary fetch, and its JSON answer carries both halves of the verdict: the SVCB records under _index._agents, and AD, the resolver's DNSSEC judgement. That second half matters, because a site publishing records without a validated chain is failed by the scanner too. No token and no account are involved, so the answer is the same for every user. On this site it was the last check to pass — the resolver cache in front of it took about forty minutes of rescans after the records were already live.

WebMCP only works here. In-page detection returns one of three answers, and the third one is the point: detected, confirmed absent, or detection unavailable. A browser without the API, or a page where the injected script could not run, produces "unavailable" — not a failure. Not detectable is not the same as not present, and a check that scores those the same way manufactures a defect.

The MCP Server Card needs five addresses. The audit already flagged this, and it has not improved: the draft-canonical path, the IETF one, the two Cloudflare probes and the de-facto legacy file are all in play because the specification moved and the scanners did not move with it. A checker that probes one of them reports the state of that address, not the state of your server.

Where it breaks: the number is not one number

Three separate reasons a score you read today will not match a score somewhere else.

Not-applicable checks leave the denominator. The composite is passing checks over applicable ones, and a check that cannot apply is excluded rather than failed. Anything the browser genuinely cannot reach — a resolver that will not answer, an in-page runtime that never ran — drops out there and stays in from outside. Same site, same day, different arithmetic.

Cloudflare's own two surfaces disagree. On 30 July 2026 this site read 79 of 100 and Level 5 "Agent-Native" in the web interface, while /api/scan reported Level 4 for the same domain in the same hour. That is stable, not a glitch we caught mid-deploy, and it means "what level are we" has two correct answers depending on which endpoint you ask.

The check matrix itself moves. The MCP Server Card above is one example; DNS-AID is another, resting on an individual Internet-Draft that expires on 28 November 2026, probed through labels that draft does not define. And llms.txt is not a scored check in either tool: the audit measures content negotiation, so a site can publish a complete llms.txt surface and score zero on content accessibility, which is exactly how the July audit opened. What counts as readiness is being decided while you measure it.

The conclusion is not that the score is worthless. It is that the score is only meaningful against itself. What did this origin do yesterday, and what changed after the last deploy. Comparing your number to another site's number compares two arithmetics.

The extension

That is what Agent Readiness Inspector does, and shipping it is the occasion for this article. It is our own extension, it runs 22 checks in the browser against whatever origin the current tab is on, and it is free. Firefox and Edge builds are with the stores for review; today the link above is the one that works.

22 checks, versioned as data. Robots and AI crawler rules, sitemaps, Link headers, Markdown negotiation, Content Signals, Agent Skills, API Catalog, MCP Server Card, OAuth discovery, Web Bot Auth, WebMCP, plus the agentic commerce protocols as an unscored preview. The matrix carries a version and a CI job watches the upstream one for drift, because the section above is a permanent condition rather than a bad month.
Evidence per check. The response that produced the verdict, including the final URL after redirects, and a copy-ready prompt for the fix.
Saved sites and regressions. Scheduled rescans, history, and an alert when a check that used to pass stops passing. Alerts land in a local inbox first; the notification permission is optional and asked for only if you turn it on.
Local-first. Scans, history, settings and alerts live in browser storage. The optional outside comparison uses your own Cloudflare URL Scanner credentials and is off by default.

It is an independent implementation of open web standards, not affiliated with or endorsed by Cloudflare.

Which tool to use

You need	isitagentready.com	Agent Readiness Inspector
A public production site	yes	yes
Staging, localhost, pre-launch, VPN	no, site error or invalid URL	yes, if the tab loads
Pages behind a login	anonymous view only	your session, on the page probes
WebMCP in the page	no	yes, in-page detection
DNS-AID	yes	yes, over DNS-over-HTTPS
The score Cloudflare will quote at you	yes, this is the source	no, a second opinion
Rescan on a schedule, alert on regression	no	yes, on the machine it is installed on

Where the extension stops

It audits the origin of the tab you have open, on the machine it is installed on, while the browser is running. Scheduled rescans go through a bounded batch per cycle, so a watch list is a handful of sites you care about, not an inventory.

For getting a site agent-ready before you publish it, that is the whole job, and it costs nothing. The point where it stops is the point where the question changes from "is this site ready" to "are all of them still ready" — every domain in a portfolio, checked on a schedule that does not depend on someone's laptop being awake, with the alert going to whoever is on call. That is the same boundary the redirect chain recorder runs into, for the same reason, and it is what 301.st does across a portfolio. For the site in front of you, install the extension and read the evidence.

A unique click id on a free Cloudflare redirect, no Worker involved

301ST — Thu, 06 Aug 2026 14:00:21 +0000

You send paid or partner traffic through a redirect and you want every click to arrive at the destination carrying its own identifier — something to join against a conversion later. The obvious tool is a Worker, and for anything that needs to record the click, a Worker is still the only primitive that can. But if all you need is for each click to carry a unique id, there is a way to get one on the free plan, inside a plain Single Redirect, with no code in the request path at all.

We tested it on this site's zone on 30 July 2026. It works, and three of its edges bite. Here is the rule, the measurements, and the traps.

The function that is banned, and the field that is not

The ruleset expression language has uuidv4(). You cannot use it here. The documentation restricts it to rewrite expressions of Transform Rules, and the API enforces that at validation time. This is the live answer to an attempt to put it in a redirect target:

"'concat(\"https://301.sh/?click_id=\", uuidv4(cf.random_seed))' is not a valid
value for target_url because the use of field cf.random_seed is not allowed,
the use of function uuidv4 is not allowed" (code 20083)

Both the function and its seed field are named as forbidden. So the expression language cannot mint randomness in a redirect. What it can do is reuse an identifier Cloudflare has already minted for the request: cf.ray_id, the ray ID that every request through Cloudflare gets, the same value the CF-RAY response header and the dashboard logs show. Its field documentation carries no product restriction, and the validator accepts it in a redirect target.

One rule, measured

A dynamic Single Redirect. The match is ordinary; the target is an expression instead of a static URL:

Expression:  (http.host eq "301.sh" and http.request.uri.path eq "/go")
Target URL:  concat("https://destination.example/?click_id=", cf.ray_id)
Status:      302, preserve query string off

Five requests in a row through that rule, on this zone:

Location: https://301.sh/…/?click_id=a23684c8a885b183-BTS   CF-RAY: a23684c8a885b183-BTS
Location: https://301.sh/…/?click_id=a23684cbfd5a2915-BTS   CF-RAY: a23684cbfd5a2915-BTS
Location: https://301.sh/…/?click_id=a23684cf493d696b-BTS   CF-RAY: a23684cf493d696b-BTS
Location: https://301.sh/…/?click_id=a23684d2ddcf1948-BTS   CF-RAY: a23684d2ddcf1948-BTS
Location: https://301.sh/…/?click_id=a23684d64c0a46d5-BTS   CF-RAY: a23684d64c0a46d5-BTS

Three properties, all visible in the output. Every request got a different id. Each id is identical, byte for byte, to the CF-RAY header of the same response — which means the click id in your destination's logs joins directly against Cloudflare's own logs and dashboard. And the substituted value is the full form with the data center suffix (-BTS here), not just the sixteen hex characters, so parse accordingly.

The preserve_query_string trap

The obvious next step is to keep the campaign parameters the click arrived with. The rule has a switch for that, and combining it with a target expression that already carries a query is where it breaks — measured, not guessed:

Setup	Incoming request	`Location` actually sent
`preserve_query_string: true`	`/go?utm_source=tg&gclid=abc123`	`…/?utm_source=tg&gclid=abc123` — click_id gone
`preserve_query_string: true`	`/go`	`…/` — no query at all, even the target's own
manual merge, flag off	`/go?utm_source=tg&gclid=abc123`	`…/?click_id=a2368ff0…-BTS&utm_source=tg&gclid=abc123`

preserve_query_string does not merge the incoming query into your target. It replaces the target's query entirely — including when the incoming query is empty, which deletes the click_id you just built. The two features are mutually exclusive.

The working form leaves the switch off and does the merge in the expression:

concat("https://destination.example/?click_id=", cf.ray_id, "&", http.request.uri.query)

One cosmetic edge: when the incoming query is empty, the result ends in a bare &. Every query parser we care about ignores it, but it is in the URL, so know it is there before you diff logs.

A 301 will replay yesterday's id

The same rule with status 301 substitutes a fresh ray ID per request at the edge — we measured that too. The problem is in front of the edge: the 301 comes back with no Cache-Control header, and a permanent redirect without explicit freshness information is exactly what browsers are allowed to cache heuristically. A repeat visitor can then be redirected by their own cache, carrying the click id from their first visit, and the request never reaches Cloudflare at all — a duplicate id in your logs and an undercounted click. For this pattern the status you want is 302 or 307.

Where it breaks

Nothing on Cloudflare's side records the id. Redirect is a terminating action in the first request phase; no analytics product ever sees the request, and the rule cannot write anywhere. The id exists only in the Location URL. If the destination does not log its query string, the id evaporates in flight.

A ray ID is an identifier, not a secret. It is unique, but it is not random in any adversarial sense — do not use it as a token that authorizes anything. Join key: yes. Capability: no.

Every fetch gets an id, not every human. Link prefetchers, scanners and preview bots follow redirects too, and each gets its own perfectly valid click id. The rule cannot tell them apart; dedup and filtering stay the destination's job.

The quota is real but roomy. Ten Single Redirect rules per zone on the free plan — per zone, not per account — then 25 on Pro, 50 on Business, 300 on Enterprise (checked 30 July 2026). One tracking rule with a wildcard covers a whole path family, so ten goes further than it sounds. Regular expressions need Business; this pattern does not need them.

When you need more than a stamp

If the destination is yours, this rule plus your own analytics reading click_id may be the whole system: no Worker, no code, nothing to maintain, and the id joins against Cloudflare's logs by construction.

The pattern stops being enough exactly where the attribution article starts: the destination is not yours, or you need the click recorded even when the destination logs nothing, or you run this across a portfolio of domains rather than one zone. Recording at the redirect side is precisely the thing a terminating rule cannot do — that side needs to be operated, which is what 301.st is for: it owns the redirect end, mints and records the id there, and hands the same id downstream, so the join works whether or not the destination cooperates.

Every job your VPS does, and what Cloudflare's free plan does with it

301ST — Wed, 05 Aug 2026 14:00:26 +0000

The fear of leaving a VPS is rarely about any one feature. A small server quietly does ten jobs at once — serves a site, renews certificates, answers DNS, redirects old URLs, runs a cron script, forwards mail, keeps a database, stores uploads, hosts a small API, rate limits a scraper — and the migration question is really ten questions asked as one. Ask "can Cloudflare replace my VPS" and you get advocacy in both directions. Ask it per job and you get answers you can check.

So here is the job by job mapping, every number read off the live documentation on 29 July 2026, with the allowance, the price of lifting it, and the honest rows where the answer is "keep the server." At the end: two systems that already live this way, one of them a production SaaS.

The mapping

VPS job	On the free plan	The allowance	Where it bites
Serve a static site	Workers static assets	asset requests "free and unlimited"; 20,000 files, 25 MiB each	paths routed through Worker code count against 100,000 requests a day
TLS certificates	Universal SSL	90 day certs, auto renewed from 30 days out	proxied hostnames only
DNS	free, with unmetered DDoS protection	200 records per zone (zones created since September 2024; older free zones keep 1,000)	nameservers must move to Cloudflare
Redirects	Single + Bulk Redirects	10 rules; 10,000 bulk URLs	the bulk quota may lag in your account
Cron scripts	Cron Triggers on a Worker	5 per account documented, minimum interval 1 minute	see the next section
Small APIs, dynamic bits	Workers	100,000 requests a day, 10 ms CPU each	computing breaks the CPU budget; serving does not
Key value storage	Workers KV	1 GB, 100,000 reads / 1,000 writes a day	1,000 writes is less than it sounds
A real database	D1 (SQLite)	5 GB, 5 million reads / 100,000 writes a day	daily caps error out, not throttle
Object storage	R2	10 GB, free egress	free tier covers Standard storage only
Mail forwarding	Email Routing	free on all plans; 200 rules, 200 destinations	forwarding, not sending
Firewall, rate limits	WAF free tier	5 custom rules, 1 rate limiting rule	one rate limit means choosing what to protect
Request logs	Workers Logs, Analytics Engine	logs with sampling; 100,000 data points a day	Logpush is Enterprise; Workers Trace Events unlock at $5

Three of those rows deserve more than a cell.

The cron entry that should not fire, and does

The documentation says the free plan allows 5 Cron Triggers per account. The account this blog runs on executes 7, every day, across five distribution Workers — and has for a week, posting to five platforms on schedule. We did not negotiate anything; the limit simply is not enforced against this account.

That is not a loophole to build on. It is the same phenomenon we documented when the Bulk Redirects quota said 10,000 and dashboards enforced 20: Cloudflare's documented numbers and per account entitlements drift apart, in both directions, sometimes for months. Read the number, then test the number. On a migration that habit costs you an afternoon and saves you an architecture built around a limit that was never real for you — or one that assumed an allowance you do not actually have.

Certificates are the quiet argument

On a VPS the TLS routine was a yearly renewal, or a certbot timer. That era is ending on a schedule: since 15 March 2026 the CA/Browser Forum rules cap public certificates at 200 days, in March 2027 the cap drops to 100 days, and in March 2029 to 47 days with domain validation reuse down to 10 days. Manual renewal stops being a viable habit and becomes an incident generator — a portfolio of parked domains on a VPS meets that wave at its first short renewal this autumn.

Behind the proxy, Universal SSL already issues 90 day certificates and renews them starting 30 days out, which sits below every step of that schedule. Of everything in the table, this is the row where the free plan is not a cheaper version of the VPS job but a categorically better one.

The ceiling is real, and it is measurable

The 10 ms CPU budget is the free plan's one hard wall, and we have measured both sides of it on this site. A Worker that serves — our MCP server answering from static assets — spends 0 to 2 ms of the budget, because waiting on I/O does not count as CPU. A Worker that computes — the template engine we measured in the agent readiness audit — blew through the same budget by a factor of eight. That is the honest split for a migration: routing, redirecting, serving, forwarding all fit with room to spare; parsing, rendering and hashing at volume do not.

Per this site's house rule, the price of the lift sits next to the limit: the Workers Paid plan at $5 a month raises the per request cap to 30 seconds by default and includes 10 million requests and 30 million CPU milliseconds a month.

What honestly stays on the server

Long running processes. Anything that holds a socket open for hours, speaks a protocol that is not HTTP, or needs SSH. Arbitrary TCP proxying exists (Spectrum) but only as an Enterprise extra — that is not a migration, that is procurement.
Heavy compute, per the measurement above, unless $5 and 30 seconds cover it.
The paid tier gaps. Snippets are absent from Free entirely, Logpush is Enterprise, Load Balancing and Argo are paid extras. If your VPS job maps to one of these, the free plan answer is "no", not "yes with effort".
Control you did not know you had. On Cloudflare Registrar you cannot change nameservers at all, and renewal is an instruction, not a guarantee. A migration hands real levers to one vendor; that is a decision, not a detail.

And there is a bridge for the undecided: Cloudflare Tunnel is available on all plans, so the VPS can stay exactly where it is, hidden behind the edge with no open ports, while jobs migrate off it one row at a time. Nothing about this table is all or nothing.

Two systems that already live like this

This blog is the small case: six Workers — the site plus five distribution posters — seven cron firings a day, a shared KV namespace, 317 static files, an MCP server, at a running cost of exactly zero, with the measurements published as articles.

The larger case is 301.st, the platform this blog belongs to: a production SaaS for domains, redirects and traffic distribution, built as a serverless application on Cloudflare Workers with D1 as the source of truth and KV for cache and sessions. Its architecture documentation states the design goal plainly: customers do not need a paid Cloudflare plan — everything runs on free Workers, and Workers Paid is the growth path, not the entry fee. A platform whose job is other people's domains chose the same table you just read. That is as honest an endorsement of the free plan as we can offer. And where a portfolio outgrows the rows you can run yourself, taking that work over is exactly what the platform exists for.

DEV Community: 301ST

Counting visits on a Cloudflare site with no third party script and no cookies

What Cloudflare gives you for free

Where Web Analytics stops counting

The idea: a collector on a path of your own site

Counting people without a cookie

Short links and QR codes on the same Worker

What it costs on the Free plan

Where it breaks

Doing it without writing it

When you need 301.st instead

Postbacks for a TDS: how a sale on the offer's site finds its click

The loop

What travels with the click

{clickid} is not the key

The postback source

What happens when a postback arrives

Passing the conversion on

One click, end to end

Where it does not reach

How a TDS on Cloudflare Workers sorts traffic before it reaches your server

Where the Worker sits

What 301.st puts in your account

The main domain or a go subdomain

One request, step by step

What a rule can check

What a rule can do

How the TDS tells bots apart

The presets

What the two cloaking presets do, and what they cost you

What it costs on the Free plan

Setting it up

When you need a TDS at all

Bot analytics wants a Worker on every request. What it costs on Cloudflare

What the Worker does

What the route costs

What lifting the quota costs

What Cloudflare already shows you

Ask the API

Log bots in the Worker you already have

Where this breaks

When 301.st is worth it

What Cloudflare's free plan alerts you about, and what you check yourself

What Cloudflare watches, by plan

Nothing is switched on until you add it

We broke a hostname twice and the free alert said nothing

Check the redirects yourself on a cron Worker

Where this breaks

When 301.st is worth it

The .com price rises on 1 November. Lock today's for up to ten years

What the contract allows from here

The date that sets your price is the renewal date

How many years each domain can take

The arithmetic for one domain

Which domains to lock

Doing it at Cloudflare

When 301.st helps, and where it stops

Certificates now expire in 200 days. Find the domains you still renew by hand

A redirect domain should have no certificate you renew

Sort your domains by who renews them

The certificate the script does not see

Where this breaks

When 301.st is worth it

The zone limit your API token hits and your Global API Key does not

The rule that fits the evidence

The part that depends on who is asking

Check your account in two requests

Why the key must not leave your browser

What changed in 0.2.0

Where the extension stops

Your redirect rule says Active and nothing happens

Question one: does the request reach your zone at all

Question two: does the rule match what you are actually sending

Question three: did something answer before your rule got its turn

Question four: did it fire while you looked at a cached answer

When the redirect was never Cloudflare's to run

Where this gets untidy

What this costs across a portfolio

How to audit agent readiness when the scanner cannot reach the site

What the browser has that the datacenter does not

`{clickid}` is not the key