Skip to main content

Cloudflare

Cloudflare sits in front of the WordPress origin as DNS provider, CDN, and WAF. The zone is nutritionistpro.com on the free plan.

Dashboard: dash.cloudflare.com > nutritionistpro.com.

Two different Cloudflare uses

This zone proxies the WordPress marketing site. Cloudflare Pages separately hosts the two Docusaurus documentation sites, which is a different product and a different configuration. See Documentation for those.

DNS​

The domain uses full setup, meaning the nameservers are delegated to Cloudflare rather than Cloudflare running in partial or CNAME mode:

harmony.ns.cloudflare.com
anton.ns.cloudflare.com

The apex record proxies to the AWS Lightsail origin. www.nutritionistpro.com returns a 301 to the apex, so the apex is canonical. The nameservers were moved here from GoDaddy on 2026-06-27; the registrar, the full record inventory (including the Microsoft 365 mail records and the Nexgen V3 subdomains), and who may change what are on Domain and DNS.

The axxya.com zone is a separate site in the same account. It carries the SPF, DKIM, and DMARC records for the noreply@axxya.com sender the apps use; see Nexgen V3 outgoing email.

The /docs Worker route​

The product documentation at nutritionistpro.com/docs is not served by WordPress. A Cloudflare Worker bound to the route nutritionistpro.com/docs* forwards the request, path and query string unchanged, to the docs Pages project at nutritionistpro-public-docs.pages.dev, and every other path falls through to the WordPress origin. The Worker is the reason the zone had to move to Cloudflare: DNS cannot route a path, and an Apache reverse proxy on the origin was ruled out.

The Worker's code lives only in the Cloudflare dashboard (Workers & Pages); the reference copy is in the deploy-docs skill in the Axxya-Systems/docs repo. The Docusaurus site keeps baseUrl: '/docs/', so no docs change is needed when the origin moves, and the Worker is unaffected by a change to the apex A record. See Documentation for the docs site itself.

curl -sI https://nutritionistpro.com/docs/ | head -1

A 200 confirms the route. A WordPress 404 page at that URL means the route or the Worker is gone.

SSL and TLS​

The encryption mode under SSL/TLS > Overview must be Full (strict).

Flexible mode causes redirect loops

In Flexible mode Cloudflare sends plain HTTP to Lightsail. WordPress then sees an insecure request while serving hardcoded HTTPS URLs, and canonical redirects can bounce between the two schemes indefinitely. The HTTP_X_FORWARDED_PROTO guard in WordPress configuration defends against this, but Full (strict) is the correct setting regardless. Bitnami installs a valid certificate that supports it.

Edge certificate is ECDSA only​

Since Cloudflare reissued the zone's Universal SSL certificate on October 23, 2026 (Google Trust Services, nutritionistpro.com and *.nutritionistpro.com), the zone presents an ECDSA certificate only. Browsers are unaffected, but any client that offers only RSA ciphers, or connects without SNI, fails the TLS handshake on every proxied nutritionistpro.com host, including app. and trial.. The axxya.com zone in the same account still offers RSA.

Chargebee's webhook client is one of those clients: its webhooks to app.nutritionistpro.com failed with "The SSL communication has failed" until they were moved to the backend's .net host. Machine-to-machine callers should use the api.*.nutritionistpro.net hosts, which go straight to the AWS load balancer. See Chargebee webhooks.

To check whether the zone offers RSA again, run this. It prints Cipher is (NONE) while RSA is refused:

echo | openssl s_client -connect app.nutritionistpro.com:443 -servername app.nutritionistpro.com -tls1_2 -cipher ECDHE-RSA-AES128-GCM-SHA256 2>&1 | grep -oE "Cipher is [^ ]+"

Getting an RSA edge certificate back needs an Advanced certificate under SSL/TLS > Edge Certificates, which is a paid add-on on top of the free plan.

Always Use HTTPS is currently off​

http://nutritionistpro.com/ returns a 302, issued by the origin rather than by Cloudflare. With SSL/TLS > Edge Certificates > Always Use HTTPS enabled, Cloudflare would answer with a 301 at the edge instead. That is preferable on two counts: a permanent redirect consolidates ranking signals properly, and the request never reaches the origin. Worth enabling, and it is a single toggle.

There is also no Strict-Transport-Security header on responses. Enabling HSTS is optional hardening. Treat it with care, because it is difficult to reverse once browsers have cached the policy.

Crawler and AI bot controls​

Two settings on the zone overview under "Manage AI bot access" have been deliberately set:

  • Block AI training bots: "Do not block (allow crawlers)". This is a Cloudflare-managed WAF rule, and it is the one that genuinely blocks requests at the edge.
  • Manage your robots.txt: the Cloudflare-managed robots.txt is disabled.

While the managed robots.txt was enabled, it injected Content-Signal directives plus Disallow: / rules for ClaudeBot, GPTBot, CCBot, Google-Extended, Bytespider, Amazonbot, Applebot-Extended, meta-externalagent, and CloudflareBrowserRenderingCrawler into the served file. Both were turned off in July 2026 so AI crawlers are permitted.

These settings never affected Google Search

Google-Extended governs Gemini and AI training only, and Googlebot was never blocked. If AI crawler rules are raised as a suspected cause of a Google indexing problem, that is a dead end. See Google Search Console.

The distinction between the two settings matters: robots.txt is advisory and a badly behaved crawler can ignore it, whereas the WAF rule enforces at the edge. Keep them consistent so the stated policy matches the enforced one.

Custom WAF rules​

The zone has one custom rule under Security > WAF > Custom rules (the free plan allows five): Block xmlrpc except Jetpack, added 2026-10-21 after an XML-RPC flood of about 28,500 requests in an hour reached the origin. It blocks any request whose path contains xmlrpc.php unless the source is in Jetpack's address ranges, which Jetpack needs for its connection to WordPress.com. The expression and the background are on PHP security stopgap (October 2026). Cloudflare's own managed rules for the October 2026 PHP vulnerabilities are on by default and need no configuration.

Caching​

HTML is not cached. Responses from the homepage, sitemaps, and robots.txt return cf-cache-status: DYNAMIC or BYPASS, so every request reaches WordPress. This is the default for a WordPress origin with no page-cache rule, and it means Cloudflare is not a suspect when stale content appears.

Stale content is usually WordPress, not Cloudflare

Because HTML is not edge-cached, stale sitemaps or pages almost always come from Yoast's transient cache in the database. Clear it with sudo wp --path=/opt/bitnami/wordpress transient delete --all rather than purging the Cloudflare cache. See SSH access.

To confirm which layer served a response, check the cf-cache-status header and add a cache-busting query string. If the content is identical either way, the cache is server side:

curl -sI https://nutritionistpro.com/sitemap_index.xml | grep -iE 'cf-cache-status|cache-control'
curl -s "https://nutritionistpro.com/sitemap_index.xml?cb=$RANDOM" | grep -o '<loc>[^<]*' | head -3

Open hardening item​

Closed. Until 2026-10-21 the Lightsail origin answered directly on its public IP and EC2 hostname, so anyone addressing it bypassed Cloudflare entirely, along with the WAF and the AI bot rules described above. The SEO consequence was closed in July 2026 when the WordPress URL constants began forcing a redirect to the canonical domain. The security bypass was closed on 2026-10-21, first on the old instance by restricting its Lightsail firewall to Cloudflare's published IP ranges (the procedure is on PHP security stopgap (October 2026)), and then by building the replacement instance with that firewall from the start; see Hosting and deployment. Keep it that way: any new instance, and any firewall edit, must admit only Cloudflare on 80 and 443. The origin certificate is now a Cloudflare Origin CA certificate, which only Cloudflare trusts, so a direct request would fail the TLS check even if the firewall let it through.