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.

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.

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.

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​

The Lightsail origin answers directly on its public IP and EC2 hostname, so anyone addressing it bypasses 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, but the security bypass remains.

Closing it means restricting the Lightsail firewall to Cloudflare's published IP ranges. Check first that nothing depends on direct origin access, including monitoring, backups, and any deployment tooling.