This process applies when the customer retains its own authoritative Cloudflare account.
O2O request flow
Visitor
↓
Customer-owned Cloudflare zone
↓
SiteCare Cloudflare for SaaS zone
↓
CoreSpeed origin
↓
WordPressO2O requires the customer and SiteCare zones to exist in different Cloudflare accounts. It is activated through a proxied CNAME, not an A record.
SiteCare preparation
SiteCare will:
- Confirm the hostnames to be onboarded.
- Create the corresponding custom hostnames in the SiteCare Cloudflare for SaaS zone.
- Configure the fallback or custom origin.
- Configure certificate and TLS behavior.
- Provide the required CNAME target.
- Confirm the customer account has granted SiteCare Super Administrator access.
Hostnames commonly include the apex domain and www, but SiteCare will provide the exact list for each implementation.
Customer-zone DNS configuration
For each hostname:
- Remove conflicting
A,AAAA, orCNAMErecords. - Create the SiteCare-provided
CNAME. - Set its proxy status to Proxied.
- Preserve unrelated DNS records.
- Avoid creating an A record as a substitute.
Example:
Type: CNAME
Name: www
Target: <SiteCare-provided target>
Proxy status: ProxiedFor an apex hostname, Cloudflare’s CNAME flattening allows the root record to use a CNAME while still returning flattened IP responses.
O2O does not activate when an A record is used to point directly to the provider.
Activation behavior
Cloudflare does not expose a zone-level switch showing that O2O is enabled. It is determined per request.
When the request reaches the SiteCare provider zone through O2O, Cloudflare adds:
cf-connecting-o2o: 1SiteCare can inspect this header at the provider layer to confirm that the O2O path is active.
Certificate validation
O2O custom hostnames cannot use Cloudflare’s normal prevalidation methods. Activating the proxied CNAME begins routing traffic, so SiteCare and the customer should coordinate the DNS change during an approved implementation window.
Comments
0 comments
Please sign in to leave a comment.