O2O Compatibility and Customer-Zone Configuration

In an O2O configuration, requests pass through both the customer’s Cloudflare zone and SiteCare’s Cloudflare zone.

Cloudflare generally applies customer-zone settings first. Customer settings can override or affect the provider-zone behavior.

This makes configuration coordination important.

HTML caching

Cloudflare specifically discourages caching HTML in the customer zone when a SaaS provider also performs caching.

Two independent HTML caches can create:

• Stale content
• Conflicting purge behavior
• Difficult cache diagnostics
• Unexpected cache keys
• Different responses between locations
• Delays after WordPress updates

CoreSpeed performs its page caching in SiteCare’s provider layer. Customer-zone Cache Rules should therefore bypass HTML unless SiteCare has reviewed and approved the configuration.

Static assets may still be cached in the customer zone, but overlapping behavior should be reviewed.

Workers and routing rules

Customer-zone Workers, redirects, Transform Rules, or origin rules can change a request before it reaches SiteCare.

Before onboarding, identify any rules that apply to:

• The apex hostname
• www
• All paths
• Login or administrative paths
• Query parameters
• Cookies
• Headers
• Redirects
• Origin selection

Do not add new Worker routes to the CoreSpeed hostnames without coordinating with SiteCare.

Security settings

WAF, Bot Management, Access, and related controls can run in both zones, subject to Cloudflare’s product compatibility rules.

Customer-zone controls may block traffic before it reaches SiteCare. When troubleshooting a 403, challenge, redirect, or missing request, both Cloudflare zones may need to be reviewed.

Argo and other services

Some Cloudflare products are supported in only one layer or have special O2O behavior. For example, Cloudflare’s compatibility table indicates that Argo Smart Routing should run in the SaaS provider zone for O2O traffic.

Review compatibility before enabling account-level performance or security services that will affect CoreSpeed hostnames.

Recommended change process

Before changing a CoreSpeed-related setting in the customer zone:

1. Document the reason for the change.
2. Identify the hostnames and paths affected.
3. Notify SiteCare.
4. Test the change.
5. Confirm caching and origin behavior.
6. Record the rollback steps.

Related Cloudflare documentation

• O2O product compatibility
• Customizing cache behavior with Workers
• Cloudflare proxy behavior