Cloudflare O2O: How to Set Up ConveyThis Workers (Orange-to-Orange)

Summarize this post with: 9 min read

ChatGPT Perplexity Grok Google AI

Cloudflare O2O (Orange-to-Orange) is a routing setup where a request passes through two Cloudflare zones: your zone first, then the zone of a SaaS provider you point to. You turn it on by adding a Proxied (orange-cloud) CNAME record that targets the provider’s hostname. Cloudflare applies your zone’s settings first and the provider’s second, so your WAF and rules keep working.

ConveyThis uses O2O to serve translated pages for sites that are already on Cloudflare, without a nameserver change. This guide explains how O2O works, how to set it up with ConveyThis step by step, and what to check when it doesn’t behave.

Key takeaways

• O2O applies only when you point a Proxied CNAME at a Cloudflare for SaaS provider, and only when the two zones belong to different Cloudflare accounts.
• Your zone’s settings run first. Security rules, bot settings and page rules you already have still see the request.
• A grey-cloud (DNS only) record or an A record does not take the O2O path.
• With ConveyThis, you add Proxied CNAMEs to fallback.conveythis.net, wait for the certificates to turn Active, and translated pages are served by a Cloudflare Worker at the edge.
• O2O is optional. The standard ConveyThis DNS setup stays available.

What Cloudflare O2O is, in plain terms

Many SaaS products (site builders, e-commerce platforms, translation proxies) run on Cloudflare for SaaS. Their customers connect a custom domain by adding a CNAME record that points at the provider.

If that customer’s domain is also on Cloudflare, the request meets two Cloudflare zones on its way to the page. Cloudflare’s O2O documentation defines this as “a specific traffic routing configuration where traffic routes through two Cloudflare zones: the first Cloudflare zone is owned by customer 1 and the second Cloudflare zone is owned by customer 2, who is considered a SaaS provider.”

Three facts from that page decide whether O2O applies to you:

1. Record type. You need “a proxied DNS record matching the custom hostname with a CNAME target defined by the SaaS Provider.”
2. Order. “The settings configured in your Cloudflare zone will be applied to the traffic first, and then the settings configured in the SaaS provider’s zone will be applied to the traffic second.”
3. Accounts. “O2O only applies when the two zones are part of different Cloudflare accounts.” It also “does not apply when an A record is used.”

The provider can see that a request came through O2O: Cloudflare adds the header cf-connecting-o2o: 1 in the provider’s zone.

Why O2O matters for website translation

A translation proxy has to sit between the visitor and your site so it can return translated HTML. The classic way is to point DNS for the translated hostnames at the proxy.

That’s awkward when your domain already lives on Cloudflare. Your team relies on the zone’s TLS, WAF and caching, and nobody wants to move DNS or turn off the orange cloud just to add languages. O2O avoids that trade-off: the request enters your zone as usual, then continues to ConveyThis’s Cloudflare for SaaS zone, where a Worker produces the translated page.

ConveyThis detects that the domain is on Cloudflare and offers the Workers (O2O) option.

Before you start

• Your domain’s nameservers are Cloudflare’s, and you can edit its DNS records.
• You have a ConveyThis account with the domain added. The sub-folder and sub-domain URL structures are available on the Business plan and above (pricing).
• You know which URL structure you want. Sub-folder gives example.com/de/, sub-domain gives de.example.com. Our comparison of subdirectories vs. subdomains for multilingual SEO covers the SEO side, and the help article on sub-domain vs. sub-directory covers platform limits.

How to set up ConveyThis Cloudflare Workers (O2O)

Step 1: Add the domain and confirm the Cloudflare detection

When you add the domain, ConveyThis checks its nameservers. If they belong to Cloudflare, setup shows a notice that the domain is on Cloudflare and unlocks Cloudflare Workers (O2O) for the sub-folder and sub-domain structures.

Step 2: Choose the URL structure and switch the serve method to O2O

Pick Sub-folder or Sub-domain, then choose Cloudflare Workers (O2O) as the serve method. The standard DNS proxy remains available on the same screen if you’d rather use it.

Standard DNS proxy stays available. O2O is the Cloudflare-native option when the zone is detected.

Step 3: Add the Proxied CNAME records in Cloudflare

ConveyThis prints the exact records for your domain. They point at fallback.conveythis.net:

• Sub-folder: typically @ and www, plus an origin record when your setup needs one.
• Sub-domain: one record per language host (for example de, fr), plus an origin record so the Worker can reach your real site without looping back through itself.

Add them in your Cloudflare DNS dashboard and leave the cloud orange on every record. This is the one rule you can’t bend: a DNS-only record doesn’t route through O2O.

Verify DNS: Proxied @ / www toward fallback.conveythis.net, plus the origin record for the real server.

Step 4: Wait for SSL to turn Active

Cloudflare for SaaS issues the certificates for your hostnames. ConveyThis uses HTTP validation, so you don’t add validation (TXT) records or upload anything to your server. Refresh the status table until every certificate shows Active. In our test run this took a few minutes.

When status is Active, the translated hostnames are ready.

Step 5: Open a translated URL

Load a translated page, such as example.com/de/ or de.example.com. You should see your normal layout with translated text and the language switcher.

A translated page served through Cloudflare Workers (O2O).

What happens to each request

Here is the path a visitor’s request takes, based on how the ConveyThis edge Worker is built:

1. The visitor requests a translated URL. The request enters your Cloudflare zone, and your rules apply.
2. The Proxied CNAME hands it to ConveyThis’s Cloudflare for SaaS zone (O2O).
3. The Worker looks up your domain’s settings, works out the target language from the sub-folder or sub-domain, and fetches the original page from your origin.
4. As the HTML streams through, the Worker swaps in translations from a stored dictionary for your site. It also points internal links, the canonical tag and og:url at the same language version, and sets the page’s lang attribute.
5. The translated page goes back to the visitor. Text that has no translation yet is sent for translation in the background, so it appears in the dictionary for the next view.

Some details worth knowing:

• Caching. Translated pages are cached at the edge. The cache key includes a fingerprint of your translations, so when you edit a translation, the next request gets a fresh page without a manual purge.
• Logged-in visitors. Requests that carry cookies skip the shared page cache, so one visitor never sees another visitor’s personalized page.
• Excluded content. Text inside script, style, code, pre and textarea is never translated, and neither is anything marked translate="no".
• Loop protection. If a misconfigured record sends the Worker’s own request back to itself, it stops with an error instead of looping.

Troubleshooting

The translated URL doesn’t load or shows your original site. Check that every routing record is still Proxied. Someone switching a record to DNS only “for debugging” is the most common cause.

Certificates stay on “Issuing”. Give it a little longer and re-check. Don’t switch records to grey cloud to speed things up. O2O needs them Proxied, so you’d only create a second problem to undo.

Error about a loop, or pages that never finish loading. The Worker can’t reach your real site. Make sure the origin record ConveyThis listed exists, is correct, and points at your actual server or platform.

Your own firewall blocks the translated pages. Because your zone runs first, a strict WAF rule or bot setting can block requests before they reach ConveyThis. Check your security events for the translated hostnames.

Some text stays in the original language. If it’s brand-new text, reload after a moment. If it persists, check whether the element has translate="no", or edit the translation in your ConveyThis dashboard.

Should you use O2O or the standard DNS setup?

Use Cloudflare Workers (O2O) if your domain already uses Cloudflare nameservers and you want to keep your zone’s security and control while adding translated sub-folder or sub-domain URLs.

Use the standard DNS setup if your domain isn’t on Cloudflare, or if you’d rather not manage Proxied records in the Cloudflare dashboard. For non-Cloudflare domains, follow the CNAME setup guide.

Either way, check a translated page after setup with “View source”: the lang attribute and the canonical should match the translated URL, and if you rely on hreflang, confirm every language version is listed. The multilingual SEO features page explains what ConveyThis adds for search engines.

FAQ

What does O2O stand for in Cloudflare? Orange-to-Orange: traffic that passes through two Cloudflare zones, yours and a SaaS provider’s, via a Proxied CNAME.

Do I need to change my nameservers for ConveyThis O2O? No. O2O is for domains that are already on Cloudflare. You only add Proxied CNAME records in your existing zone.

Does O2O work with an A record? No. Cloudflare’s documentation says O2O “does not apply when an A record is used.” Use the CNAME records ConveyThis shows you.

Do my Cloudflare WAF and page rules still apply? Yes. Your zone processes the request first, then the provider’s zone.

Can I switch back to the standard DNS proxy? Yes. O2O is opt-in and you can change the serve method in your domain’s URL settings.

Do I need a CMS plugin? No. The Worker translates the HTML your site already sends, so it works regardless of how the site is built.

Already on Cloudflare? Create a ConveyThis account, add your domain and choose Cloudflare Workers (O2O) on the URL structure step.