DEV Community: 301ST

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.

An MCP server on Cloudflare's free plan, measured against the 10 ms CPU limit

301ST — Tue, 04 Aug 2026 14:00:54 +0000

Two things happened this week that turn "can I run an MCP server for free" from a compromise into a plain yes, with one measurable condition. Today the Model Context Protocol shipped its 2026-07-28 revision, and the headline change is that the protocol core went stateless: sessions, the Mcp-Session-Id header, and the initialize handshake are gone. The release post states the consequence outright:

Any request can now land on any server instance behind a plain round-robin load balancer without needing shared storage.

And yesterday, one day ahead of the release, Cloudflare's own documentation flipped. The McpAgent class — the official path that backed every MCP server with a Durable Object because the transport needed somewhere to keep its session — is now marked deprecated and feature frozen, with a stateless request handler as the recommended replacement for new servers.

Those two moves close the same gap from both ends. A Worker on the free plan was always a natural place for a small MCP server except for one thing: the transport demanded state, and state meant a Durable Object and a sticky instance. Now the protocol itself promises that every request is self contained. What remains is the free plan's one hard ceiling — 10 ms of CPU per request — and whether a real server fits under it is not a question you argue about. It is a question you measure. So we built one, on this site, and measured it.

What the revision actually removed

The old lifecycle opened every connection with an initialize round trip, minted a session id, and required the client to carry it on every call. All of that is deleted. Version, client identity, and capabilities now travel inside each request's _meta fields, and the one thing a server must implement is server/discover, which reports its supported versions and capabilities to anyone who asks.

The transport got stricter in exchange. Every POST must carry an MCP-Protocol-Version header that matches the version inside the body, plus an Mcp-Method header mirroring the JSON-RPC method — and Mcp-Name on tool calls — so load balancers and gateways can route without parsing bodies. A mismatch is a hard 400. Batching stays gone, ping is removed entirely, an unknown method is now an HTTP 404, and the 2024 era HTTP+SSE transport is formally classified as deprecated. A server that never pushes messages may answer every request with plain JSON and refuse the streaming path with a 405.

For a server that only reads, the protocol surface left over is small: server/discover, tools/list, tools/call, and the header discipline. That is the whole list.

The server this site now runs

This blog already publishes an agent surface — Markdown mirrors of every article and a posts.json feed. The MCP server is those same files behind two tools: list_articles returns the feed, get_article returns an article's full Markdown. It lives at https://301.sh/mcp on the same Worker that does the site's content negotiation, with zero dependencies — after the revision, the remaining protocol surface is short enough to write out by hand. Cloudflare ships an SDK route for the same job (createMcpHandler plus the protocol SDK), which is the right answer the moment you need resources, prompts, or elicitation; a two tool read only server does not.

The dispatch, condensed to its shape:

switch (message.method) {
  case 'server/discover':
    return reply(id, { resultType: 'complete', supportedVersions: ['2026-07-28'],
      capabilities: { tools: {} }, ttlMs: 3_600_000, cacheScope: 'public' });
  case 'tools/list':
    return reply(id, { resultType: 'complete', tools: TOOLS, ttlMs: 3_600_000,
      cacheScope: 'public' });
  case 'tools/call': {
    // Mcp-Name header must equal params.name, or 400 + HeaderMismatch.
    const mirror = await env.ASSETS.fetch(new URL(`/${slug}.md`, origin));
    return reply(id, { resultType: 'complete',
      content: [{ type: 'text', text: await mirror.text() }], isError: false });
  }
  default:
    return fail(id, 404, -32601, `Method not found: ${message.method}`);
}

Nothing in it computes. Every answer is an already deployed static asset fetched through the assets binding, and that choice is exactly what the measurement rewards.

The measurement

Cloudflare's definition of the limit is the part most people skip past:

CPU time measures how long the CPU spends executing your Worker code. Waiting on network requests (such as fetch() calls, KV reads, or database queries) does not count toward CPU time.

So the 10 ms budget is spent on parsing, validating, and assembling JSON — not on fetching the article body. We sent 40 requests at the production endpoint and read the per invocation cpuTime that Workers Logs record:

Method	CPU, ms (min / median / max)	Wall, ms (min / median / max)
server/discover	0 / 0 / 1	0 / 1 / 2
tools/list	0 / 0 / 0	0 / 1 / 2
list_articles	0 / 1 / 1	10 / 13 / 23
get_article, largest article	0 / 1 / 2	6 / 10 / 88

The worst case spends 2 ms of the 10 ms budget, and the slowest response — 88 ms of wall time serving the longest article on the site — is almost entirely waiting on the asset fetch, which the meter ignores. A serving tool runs at a fifth of the free ceiling with room to spare, and the free plan's other number, 100,000 requests a day, is a different class of problem entirely for an endpoint agents call a few times per conversation.

Where 10 ms actually bites

The ceiling is real; it just lives somewhere else than the transport. When we audited this site's agent surface, we measured a template engine we considered exposing as a service, and it blew through the same 10 ms by a factor of eight. That is the honest division: a tool that serves bytes costs one or two milliseconds; a tool that computes — parses documents, renders templates, hashes at scale — eats the budget almost immediately. Cloudflare does allow occasional overruns ("Each isolate has some built-in flexibility"), but a Worker that exceeds the limit consistently is terminated with error 1102, and burst tolerance is not a plan.

The lift has a price tag, and per this site's house rule it belongs next to the limit: the Workers Paid plan at $5 a month raises the per request cap to a default of 30 seconds (configurable up to 5 minutes) and includes 30 million CPU milliseconds and 10 million requests a month. If your tools compute, that is the number to compare against, not the free tier's 10 ms.

Try it, and what this does not need

The endpoint is live, and one request shows the whole new shape of the protocol:

curl https://301.sh/mcp -X POST \
  -H 'Content-Type: application/json' \
  -H 'MCP-Protocol-Version: 2026-07-28' \
  -H 'Mcp-Method: server/discover' \
  -d '{"jsonrpc":"2.0","id":1,"method":"server/discover",
       "params":{"_meta":{"io.modelcontextprotocol/protocolVersion":"2026-07-28"}}}'

No session to open, no state to hold, no Durable Object on the bill. If your site already publishes Markdown mirrors or a feed — and after the agent readiness audit ours did — the distance from "static files" to "MCP server" is one route on a Worker you may already be running. The spec finally matches what a small read only server always wanted to be: a plain HTTP endpoint that answers questions about content you have already built. The free plan carries that easily. It is the computing tools that were never going to be free, and now you know the number that decides.

The conversion fires on someone else's domain. Here is how to attribute it.

301ST — Mon, 03 Aug 2026 14:00:53 +0000

You buy the traffic, the sale happens on a domain you cannot touch. An affiliate offer, a product page on a marketplace, a partner's checkout, any program where the "thank you" page belongs to the platform. You cannot place a pixel there, and the ad platform is optimizing blind: the network dashboard shows dozens of conversions, the ad account registers a handful, and the algorithm steers toward clicks, because clicks are all it can see.

The question surfaces in PPC and affiliate communities year after year, asked about Meta traffic to marketplaces, about ClickBank offers, about white label programs, and the public answers have not moved in a decade. They come in two kinds: "you cannot implement anything on their side", which is true, and "buy a tracker", which starts at three figures a month. At least one asker gave up and publicly put a €100 bounty on any working idea. Nobody collected.

The fallback everyone lands on instead is counting clicks on the outbound link as stand in conversions. It rots, because a click is not a sale and bots click too — that €100 was in fact offered for a way to filter bots out of exactly this surrogate metric. Money on the symptom, because the cure was not written down anywhere.

The "nothing on their side" answer is correct, and it is also not the end. Everything you need can live on yours, in the one place every click still passes through: a redirect hop you own. That pattern is what this article builds — with what it costs, where it breaks, and what the ad platforms allow, checked against their live documentation on 27 July 2026.

The loop: click_id out, postback in

The mechanics have been standard in affiliate networks for a decade. What is missing in every one of those threads is someone laying the loop out end to end.

The click leaves your page through a redirect you host: /go. The hop generates a click_id, stores it alongside everything you know about the click — the gclid from the ad, the source, the timestamp — and sends a 302 to the network link with the click_id in the network's subid parameter.
The network carries your subid through to the sale. When the conversion happens on their side, their system fires a postback: a server to server request to a URL you registered, carrying the subid back, usually with a payout amount.
Your postback endpoint looks the click_id up, and now the conversion is joined to the exact click, campaign, and creative that produced it — on your infrastructure, from server logs, with no pixel anywhere.

Note what this does not depend on. No JavaScript on the conversion page, because you have no JavaScript there. No cookies surviving anything, because the join key travels inside URLs and server calls. No consent banner in the path, because nothing runs in the visitor's browser beyond the redirect itself. The hop is server side by construction, which is also why ad blockers never see it: the click is a request to your own host before the browser goes anywhere else.

Why the hop must not be your ad's final URL

The tempting shortcut is to point the ad directly at /go and skip the landing page. On Google Ads that shortcut is closed twice over, and knowing exactly how saves you a policy strike.

First, tracking templates do not carry the user anymore. Parallel tracking is mandatory for Search, Shopping, Display, Video, and Performance Max, and Google's description of it is unambiguous:

Parallel tracking sends customers directly from your ad to your final URL while click measurement happens in the background (without sending them to the tracking URLs first).

The template URL still gets requested — as a background ping from the browser — so a hop in the tracking template can count the click. But it cannot route the visitor, rewrite where they land, or hand the network a subid on the visit that actually converts.

Second, making the hop the final URL is a listed policy violation. Google's destination requirements name it directly: "Redirects from the final URL that take the user to a different domain" is a destination mismatch. That is the rule that gets affiliate accounts suspended for direct linking.

So the compliant shape on Google Ads is a bridge: the final URL is a real page on your domain, and the hop is the outbound link on that page. Make sure the page passes its own query string through to the hop link — the gclid arrives on the landing page URL thanks to auto tagging, and a redirect that drops it ends attribution before it starts. Meta does not run parallel tracking, but the same bridge shape is where community answers converge for Meta traffic too: a page you own, your pixel on it, subids outbound.

Closing the loop back into the ad platform is the step everyone skips. On Google Ads it has an official name: offline conversion import. You stored the gclid next to the click_id at hop time; when the postback lands, you upload the conversion keyed by that gclid. Google retains a gclid for 90 days for this purpose, auto tagging is the only prerequisite, and the feature is current, not legacy. The campaign stops optimizing toward clicks and starts optimizing toward the sales your postbacks confirm.

Building the hop on Cloudflare's free plan

A redirect rule cannot do this job, and it is worth being precise about why. Single Redirects are a terminating action in the first request phase — nothing downstream ever sees the click, and the rule itself cannot write anything anywhere. The expression language cannot even mint an id: uuidv4() exists, but the documentation restricts it to rewrite expressions of Transform Rules. Among every way to redirect on Cloudflare, the only primitive that can mint, store, and answer postbacks is a Worker.

The whole hop is one Worker with two routes and a D1 table:

export default {
  async fetch(req, env) {
    const url = new URL(req.url);

    if (url.pathname === '/go') {
      const id = crypto.randomUUID();
      await env.DB.prepare(
        'INSERT INTO clicks (id, gclid, src, ts) VALUES (?1, ?2, ?3, ?4)',
      )
        .bind(id, url.searchParams.get('gclid') ?? '', url.searchParams.get('src') ?? '', Date.now())
        .run();
      const target = new URL(env.OFFER_URL);
      target.searchParams.set('subid', id);
      return Response.redirect(target.href, 302);
    }

    if (url.pathname === '/postback') {
      if (url.searchParams.get('key') !== env.POSTBACK_KEY) {
        return new Response(null, { status: 403 });
      }
      await env.DB.prepare(
        'UPDATE clicks SET payout = ?2, converted = ?3 WHERE id = ?1',
      )
        .bind(url.searchParams.get('subid'), url.searchParams.get('payout') ?? '', Date.now())
        .run();
      return new Response('ok');
    }

    return new Response(null, { status: 404 });
  },
};

The free plan quotas fit this comfortably, all checked live on 27 July 2026: Workers allows 100,000 requests a day, D1 writes 100,000 rows a day and reads five million — a click and a postback are one row each. Outgrowing them is a billing decision, not a redesign: the Workers Paid plan at $5 a month moves Workers to 10 million requests and D1 to 50 million written rows a month. The one storage choice to get right: this is a lookup workload, not a counting workload, which is why the table is D1 and not Workers KV — KV writes cap at 1,000 a day on Free, a limit that has misled people before. Registering the postback URL with the network is one form field on their side: your /postback address with the key and their subid macro in it.

Where it breaks

The hop is the reliable half of the loop. The other half belongs to the network, and when the join fails, it fails in one of five recurring ways — this list is assembled from a decade of affiliate forum threads asking why the postback never came:

Failure	What it looks like	Check
Token name mismatch	Network expects `{clickid}`, you sent `{click_id}`	Their macro list, character for character
Reserved subids	`sub1` is taken by the network's own tracking	Ask which slot is passthrough
Offer strips subids	Clicks arrive, subid column is empty	Test link, then check their reporting
Postback registered late	Conversions before registration are gone for good	Register before the first paid click
Never tested by hand	Everything "configured", nothing verified	Open your postback URL in a browser with a fake subid

The last row is the one that catches people who did everything else right. A postback URL you have never fired manually is a guess, not a setup: request it once yourself and watch the row update before any money is spent.

Two structural limits are worth naming too. If the program offers no postback and no subid reporting at all, no hop can conjure the loop — the join needs their half, and your fallback is reconciling their dashboard against your click log by time and creative, which is exactly the manual matching those community threads end up settling for. And the offline conversion window is real: a sale confirmed more than 90 days after the click cannot be imported against its gclid, which matters for products with long approval cycles.

When the Worker is enough, and when it stops being

For one offer and one traffic source, the Worker above genuinely closes the €100 question: every click logged with its gclid, every conversion joined server side, the ad platform fed real sales instead of proxy clicks. Run it and stop paying for attribution you can build in an afternoon.

The pattern stops being an afternoon when it multiplies. Ten offers mean ten target URLs and ten postback registrations; three traffic sources mean the hop has to split by source; a dead offer means rerouting yesterday's links without breaking yesterday's subids. At that point the hop is not a script anymore, it is a routing layer with a database behind it — which is the thing 301.st already is: streams that route each click by rules, click_id minted and logged on every hop, postbacks received and matched as the default path, not as your weekend project. For a single campaign, keep the Worker. It is honest work and it is yours.

How to see the redirect chain your browser actually followed

301ST — Sun, 02 Aug 2026 14:00:53 +0000

A link lands somewhere it should not, and you need to know what happened between the click and the final page. The standard first move is curl, and it is the right one: the 60 second gclid test on this site is built on curl -sIL, and for server redirects it tells the truth. Then the chain looks clean in the terminal while the browser still ends up somewhere else, and the tool has quietly run out.

The reason is that only some redirects live in HTTP responses. The rest happen inside the page, or inside the browser itself, and no amount of -L will surface them. This article is about seeing a chain, not building one; every way to create a redirect on Cloudflare is its own comparison.

Three redirects curl cannot show you

A JavaScript redirect is a 200. The server answers with a normal page, the page runs location.replace() or sets location.href, and the browser navigates. curl prints HTTP/2 200, reports no redirect at all, and exits. Every interstitial, every tracking hop built on a script, every "checking your browser" page falls in this class.

A meta refresh is also a 200. <meta http-equiv="refresh" content="0;url=..."> sits in the HTML body, and curl does not parse HTML. Same clean status line, same silent navigation in the browser.

An HSTS upgrade never leaves the browser. After one visit to a site that sends Strict-Transport-Security, the browser rewrites http:// to https:// before any request is made. DevTools shows it as 307 Internal Redirect, a response the server never sent. curl keeps no HSTS state by default, so it hits the http:// URL fresh every time and shows you the server's 301, a hop your returning visitors stopped taking long ago.

On top of the mechanics there is the session. curl carries no cookies, so a chain that branches on login state, a consent cookie, or an A/B assignment sends curl down a different path than the person who reported the problem. The chain you tested is not the chain they followed, even when both are real.

DevTools shows it, if you hold it right

The browser obviously knows the full chain, and the Network panel will show it, with ceremony. Preserve log has to be on, otherwise the panel clears itself on every navigation and the hop you care about erases its own evidence. The Doc filter cuts the noise from the hundred subrequests a modern page makes. Server hops then appear as separate rows with their 301 and 302 statuses.

The client side hops are there too, but unlabeled. A JavaScript redirect is just another document request; nothing in the row says "this was a redirect", and connecting it to the page that triggered it means reading the Initiator column. A meta refresh looks the same. Do this once and it is five minutes of archaeology. Do it for every report and you start wanting the browser to just keep the record.

A recorder instead of a stakeout

That is what Redirect Inspector does. It is our own open source extension (Apache 2.0, code on GitHub), and version 2.3 shipped as its largest update yet, which is the occasion for this article. The extension listens to the browser's own request pipeline and records every chain as you browse: server hops with their status codes, client side navigations (a script or a meta refresh) marked with a JS badge, and the browser's internal upgrades marked HSTS. Chains are grouped by browsing session, tracking pixels and ad beacons are filtered out by default, and each card carries the total chain time with per hop timing in the analysis drawer.

What 2.3 added, briefly:

Check a URL without visiting it. Paste a URL into the dock at the bottom of the panel; it opens in an invisible background tab, the chain is captured through the normal pipeline, and the tab closes itself. The suspicious link from the report gets traced without ever taking over your screen.
Export that fits a bug report. Copy a clean summary, download the raw chain as JSON, or copy a ready curl command that reproduces the server side of the chain, which closes the loop back to the terminal where the investigation started.
A side panel instead of a popup on Chrome and Edge, so the chain list stays open while you browse. Firefox keeps the popup.
Local analysis. Nine checks per chain: loops, hops that bounce back and forth, chain length, mixed redirect types, auth bounces, consent hops, tracking noise, CDN detection, final outcome.
Search across all captured URLs, an undoable Clear, keyboard shortcuts, and full UI translations in seven languages.

The part that matters for a tool watching your traffic: everything runs locally. No accounts, no analytics, no telemetry, and by default no network requests at all; captured chains live in browser storage and never leave the machine. It is on the Chrome Web Store, Firefox Add-ons, and Edge Add-ons.

Which tool sees what

You need	curl -sIL	DevTools Network	Redirect Inspector
Server hops (301, 302, 307, 308)	yes	with Preserve log on	yes, recorded as you browse
HSTS upgrade	no, sees the server 301 every time	shown as 307 Internal Redirect	labeled HSTS
JS and meta refresh	no, both are a 200	an unlabeled document request	captured, marked as a client redirect
The chain your session gets (cookies, login)	no	yes	yes
Timing	one total with `-w`	per request, spread across rows	total per chain, delta per hop
A record you can search and export later	no	cleared when the panel closes	sessions, search, JSON and curl export

Online redirect checkers are missing from the table on purpose: they request the URL from their own datacenter, so a chain that branches on country, language, or cookies shows you the datacenter's version, which is the same blind spot curl has plus somebody else's IP.

Where the extension stops

The extension records what your browser was sent. A chain that branches by geography still shows you the branch for your country and nobody else's, and what Googlebot sees on the same URL is a different question entirely. The URL check is a real navigation in an inactive tab, so your cookies apply and the visit lands in your history; it is a convenience, not an isolation chamber. And it can only look at chains one browser at a time, on the machine where it is installed.

For debugging the link in front of you, that is the whole job, and the extension is free. The point where it stops is the point where the question changes from "what happened to this click" to "which of my domains are redirecting wrong right now". Answering that means sending the same probe to every domain on a schedule and comparing against yesterday, which no browser tool can do. The audit script is the manual version of that answer, and 301.st is the version that runs continuously, across the portfolio, with an alert when a chain changes. For the tab you have open, install the extension and read the chain.

Redirecting domains you own to one site, without tripping Google's spam rules

301ST — Sat, 01 Aug 2026 14:00:16 +0000

You own a small pile of domains — an old brand you moved away from, a couple of typo variants you grabbed so nobody else would, a name from a project that folded — and you want them all pointing at your current site. Then you read that redirecting domains is a spam signal now, that Google's latest update torched sites for doing exactly that, and you stop with your hand on the button.

Two different things are being run together under one scary headline. One of them Google is actively penalizing. The other Google names, in its own policy, as a legitimate reason to redirect. The whole question is which one you are doing — and the line is clearer than the headlines make it sound. This is the SEO side of the parked-domain runbook and of every way to redirect on Cloudflare: the same 301, and whether Google honours it.

What Google actually went after

The thing that got hit has a name in Google's spam policies:

Expired domain abuse is where an expired domain name is purchased and repurposed primarily to manipulate search rankings by hosting content that provides little to no value to users.

That is the play: buy a dropped domain that still carries ranking signals from its old life, point it at your site, and inherit authority you never earned. Google's March 2026 spam update did not invent a rule for this — expired domain abuse was codified back in 2024 — it enforced the existing one harder and faster. The market felt it. The advice in the expired-domain trade has visibly moved from hunting aged domains to starting fresh ones, and the sites that leaned hardest on authority-by-redirect are the ones that lost traffic. If the plan was to buy a stranger's old authority and 301 it into your rankings, that plan is done.

What Google still blesses

Now the other thing. Redirecting a domain you own to a site you own, because the two belong together, is not on any spam list. It is the opposite: Google's own policy on sneaky redirects lists consolidating pages among the legitimate reasons to redirect, right next to moving to a new address. What makes a redirect sneaky is intent.

When examining if a redirect is sneaky, consider whether or not the redirect is intended to deceive either the users or search engines.

There is no deception in sending an old brand's domain to that brand's current home. The mechanics agree: a 301 to a topically related destination still passes its signals, the way it has for years. Where it stops working is relevance. A 301 from an unrelated domain gets treated like a soft 404, and Google ignores the equity rather than handing it over. That is the tell for the whole distinction — a relevant consolidation is a redirect Google honours, an unrelated authority grab is a redirect Google declines.

Which one are you doing

The line, as a handful of questions:

	Consolidation — do it	Authority grab — dead
Whose domain	yours, related to the target	bought for its old rankings
The link between them	same brand, product, or topic	unrelated to your site
What the redirect is for	keeping your own traffic and name	inheriting a stranger's authority
Where it points	the page that replaces the old one	your homepage, to pass equity
Google's verdict	legitimate, passes signals	expired domain abuse, or ignored

If every answer sits in the left column, you are doing the thing Google's policy names as fine, and the spam update is not about you.

Doing it cleanly on Cloudflare

Being on the right side of the line is most of the job. Doing it cleanly is the rest, and a few Cloudflare-specific choices keep a legitimate consolidation from reading like a lazy one.

Point each old URL at the page that replaces it, not at your homepage. A blanket redirect of everything to the root is what muddies your anchor-text profile and looks like a link grab even when it isn't; where the old domain had real pages, map them to their real equivalents. The parked-domain runbook has the Cloudflare pattern for a domain with no server behind it — a proxied A record on 192.0.2.1 and a redirect rule — and Bulk Redirects is where a whole portfolio lives: one account-level list across every domain, rather than a rule per zone.

Keep it a single 301. Redirect chains — the old domain to a second domain to the site — leak signal at every hop and are slower for the visitor, and there is no reason to build one when the destination is fixed. One permanent hop, straight to the relevant page.

One honest aside, for the case this guide is not about: if what you actually want is to take over a dropped domain's ranking, a redirect was always the fragile way to do it, and Google just made it fragiler. The durable version is a real site on that domain, standing on its own. That is a different project from this one, which is about domains that already belong to you.

Where this is less tidy than it looks

A domain's past comes with it. If the name you own spent an earlier life inside a link scheme, a 301 carries that history into your site too, and a clean consolidation can still inherit a dirty reputation — worth reading the backlink profile of an acquired domain before you wire it up.

Relevance is not binary either. A domain only loosely related to your site sits in the grey zone where Google may pass some of the signal, all of it, or none, and no dashboard tells you which ahead of time. The safe reading is that an unrelated 301 is a waste rather than a punishment: the equity you hoped to move never arrives, while the redirect sits there doing nothing for anyone. The Google policy wording here was checked on 25 July 2026.

What one setup does not give you

For a handful of domains you own, the whole job is the runbook and one Bulk Redirects list, pointed at the right pages and checked once. That is genuinely all of it, and you should start there.

At the scale where a portfolio is dozens of names funnelling into one site, the work is staying on the right side of the line continuously: every redirect relevant, every one a single hop to a live page, and none quietly turned into a chain or a homepage dump as the site changes underneath them — plus a re-check each time Google tightens the screws. That standing watch across the whole portfolio is the part 301.st runs for you. For a few owned domains, a Bulk Redirects list and the runbook are enough.

Auto-renew was on and the domain expired anyway

301ST — Fri, 31 Jul 2026 14:00:17 +0000

The domain is on auto-renew. You set it years ago and stopped thinking about it, which was the whole point. Then one morning it returns NXDOMAIN, and everything riding on it is gone at once: the site, the email on that domain, and every redirect pointed through it. Auto-renew was the one thing that was supposed to make this impossible.

It isn't, and it fails people who register domains for a living, not only the careless. The setting sits there looking healthy while the three things it quietly depends on rot out of your sight. Knowing where the net has holes — and what actually catches a domain falling through them — is the difference between finding out on a schedule and finding out from a customer.

Auto-renew is a standing instruction, not a guarantee

Auto-renew is one sentence: charge this card, file this renewal, on this date. It inherits every way those two things quietly rot.

The card expires or is declined. Auto-renew is a card on file for a domain you registered in 2019, and a card from 2019 has almost certainly been reissued since. The instruction is intact; the payment behind it is not.

The notification you were counting on never arrives. It goes to an address you no longer read, or a filter files it under a tab you never open, or it is simply misrouted to spam. The single message that would tell you the charge failed is the message you don't see, and its absence looks exactly like everything being fine.

And you have stopped looking. Renewals you automate are renewals you take off your desk — that is the appeal and also the failure. You might have renewed the domain's TLS certificate in the spring and half-filed the registration under the same mental heading, so the date never stood out. The domain drops out of your attention on the day you trust a machine to hold it, and when the machine misses there is no second reader.

What Cloudflare Registrar actually does

Cloudflare Registrar is better than most on the mechanics, and it is worth knowing the real schedule instead of assuming a single make-or-break charge. From its documentation:

Cloudflare Registrar enrolls your domain to auto-renew by default.

Cloudflare attempts to renew these domains automatically 30 days before their expiration date. Several more attempts are made if the first attempt fails. The last attempt to renew is made on the day before expiration.

That is a month of retries, not one roll of the dice. And if every attempt in that window fails:

If you do not renew your domain before the expiration date, your domain will enter a Redemption Grace Period (RGP) for 30 days.

So a Cloudflare-registered name that lapses is not gone the next morning. It can be restored during redemption. For domains actually on Cloudflare Registrar this is a genuine net, and it costs nothing — checked against Cloudflare's documentation on 25 July 2026.

Where the net has holes

The schedule is good. The things it still depends on are the same three that rot out of sight.

It still needs a card that works. Thirty days of retries against a declined card end where a single failed charge does — on the day before expiration — and then you are counting redemption days instead of holding a domain. The retries buy time only if someone notices them.

It only covers domains registered with Cloudflare. A portfolio is rarely all in one place. Names accrete over years across three or four registrars, each with its own renewal timing and its own notification habits, most of them worse than Cloudflare's. The one you forgot you owned is the one no auto-renew setting is watching.

And renewed is not the same question as resolving. NXDOMAIN is what a lapsed registration returns, but it is also what a zone hold, a nameserver that drifted to an account nobody can find, or a never-activated zone returns. "Did it renew?" is answered in a billing page you have to remember to open. "Is it resolving?" is answered only by asking the domain.

What actually catches it

The lesson is not "check your card." It is that every signal pointing inward — the charge, the email, your own memory — can fail quietly and at the same time. The only signal that can't is the one pointing at the result: does the name still resolve, and did that answer change since yesterday.

Line up the failures against the things that might catch each one, and only one column is filled all the way down:

What fails	Auto-renew	Registrar email	A reminder you keep	Probing the domain
Card declined	✗	if you read it	the date, not the failure	✓
Notification misrouted or ignored	✗	✗	✓	✓
Domain at a registrar you forgot	✗	✗	✗	✓
Renewed, still `NXDOMAIN`	—	—	✗	✓

The last row is the one no renewal-tracking method can catch by definition: the registration is fine and the domain still does not answer. A spreadsheet with =DATEDIF() counting down to a renewal date — the advice that has not changed in ten years — tracks the date you typed in, not the domain. If the name lapses early because a charge failed, or the date in the sheet was wrong, the sheet stays green while the domain is dead.

Probing the domain is the same loop as the audit script, with the one column that matters here: whether a name that resolved last time returns NXDOMAIN now. Run it on a schedule, compare each answer to the last, and a name that quietly lapsed raises a flag while it is still inside the redemption window, instead of after a customer emails to say the site is down.

When this is worth setting up, and when it isn't

For domains on Cloudflare Registrar, the free path is genuinely good: auto-renew by default, a month of retries, and a redemption window if all of them miss. Turn it on, keep a working card, and for a handful of names that is the whole job — a calendar reminder you control, kept somewhere other than the registrar's own email, covers the rest.

Where it runs out is a portfolio spread across registrars, where no single renewal setting sees all of it and the only thing that does is a probe asking every domain, on every registrar, whether it is still there — and comparing today's answer to yesterday's. That cross-registrar watch, on a loop, with an alert when a name changes, is the part 301.st runs for you. Auto-renew keeps the domains it owns; this keeps track of the ones nobody remembered to look at. For a dozen names at one registrar, auto-renew and a reminder on your own calendar are genuinely enough.