An agent audited 42 Cloudflare zones. Here is what it changed, and what it refused to touch.

Most small portfolios end up on Cloudflare one domain at a time. Each zone gets whatever defaults existed the day it was added, and nobody goes back. We pointed an agent at one such account, 42 domains with a mix of Workers, Pages and parked sites, and asked it to audit every zone, propose fixes and change only what we approved.

Status, October 14, 2026. Every number below comes from two audits run about an hour apart. Domain names are replaced with placeholders in the screenshots. This is a configuration result, not a traffic or ranking result.

The checks

The audit reads each zone's settings and DNS through the Cloudflare API, then requests each site over HTTP and HTTPS the way a visitor would:

• Does http:// redirect to https://?
• Is the minimum TLS version 1.2 or higher, and is TLS 1.3 on?
• Does the SSL mode validate the origin certificate (Full (strict))?
• Is there one canonical host, or do both www and the bare domain serve the page?
• Does any root URL redirect to a literal placeholder such as /:path*?
• Do domains that never send mail publish SPF and DMARC records that stop spoofing?
• Are HSTS and DNSSEC on?

Before

The first audit returned 326 findings across 42 zones, 87 of them high severity:

Check	Zones affected
Plain http:// served a page instead of redirecting	16
Always Use HTTPS off	32
TLS 1.0 still accepted	34
SSL mode not Full (strict)	34
Both www and the bare domain serve the page	20
No DMARC record	35
HTTPS not working at all	3
Root redirects to a literal placeholder	2

What the agent was allowed to change

We split every finding into two groups before touching anything.

Safe to apply with one approval: Always Use HTTPS, minimum TLS 1.2 and TLS 1.3. These are edge settings: Cloudflare terminates TLS for the visitor, so they rarely depend on how each origin is built. The known exception is an origin that redirects HTTPS back to HTTP, which creates a redirect loop, so we checked for loops afterward. The agent recorded the previous value of each setting before changing it.

Report only: SSL mode, HSTS, DNSSEC, canonical-host redirects and email records. Each can break something if the assumption behind it is wrong. Full (strict) fails if an origin has no valid certificate. HSTS is cached by browsers and is hard to undo. A p=reject DMARC record silently drops mail from any tool you forgot was sending it. These need a person who knows each site.

One rule was added during the run. Three zones could not serve HTTPS at all, and forcing HTTPS there would make them completely unreachable. The audit now refuses to mark "Always Use HTTPS" as safe on any zone whose HTTPS check fails.

That left 68 approved changes: Always Use HTTPS on 30 zones, minimum TLS 1.2 on 34 and TLS 1.3 on 4. All 68 succeeded.

After

The second audit, run immediately afterward:

Measure	Before	After
Zones serving a page over plain http://	16	0
Zones accepting TLS below 1.2	34	0
High-severity findings	87	40
All findings	326	241

We then requested every domain over http:// and followed the redirects. Thirty-eight reached a working page with no redirect loop. The other four had already failed before the change: the three zones without working HTTPS and one retired site that returns 403.

One fix arrived for free. A root URL that redirected to a literal /:path* stopped doing so: Cloudflare now upgrades the request to HTTPS before the broken rule runs. The same placeholder bug remains on another domain's www host. :path* is framework redirect syntax, so that fix most likely belongs in the application's code rather than in Cloudflare.

What is still open

The remaining 241 findings are mostly the report-only group: 34 SSL modes to review origin by origin, 35 missing DMARC records, 30 domains without a no-mail SPF record, 20 duplicate hosts, and HSTS and DNSSEC everywhere. They are slower because each needs a fact the API cannot see: does this domain send email, does this origin have a certificate, which host should be canonical.

Use the same checks with your agent

The checklist is now a RankPropel playbook. Agents connected to the RankPropel MCP service can call get_playbook with edge-https to get the steps, each linked to Cloudflare's or Google's documentation. Pair it with the agent's own Cloudflare access and approval rules like the ones above.

If you would rather have someone run the review, the audit and baseline sprint covers technical access and indexing for one website.