I run a small site that was originally on Jimdo, a German website builder. I wanted it on my own infrastructure - a Cloudflare Worker with an Astro frontend. The migration was straightforward: build the site, deploy the Worker, add both the apex and www as custom domains in the wrangler config, point the nameservers to Cloudflare.
Except the apex domain kept redirecting to Jimdo.
www served the new site correctly. The apex returned a 301 to example.jimdoweb.com with x-jimdo-wid - Jimdo’s internal website identifier. That header is Jimdo-specific and shouldn’t appear in responses from my zone.
Investigation
Worker custom domains auto-manage DNS, so there are no user-facing A/AAAA/CNAME records to misconfigure. Both hostnames resolved to the same Cloudflare anycast IPs:
The Workers API confirmed both custom domains as active:
No Page Rules, no Bulk Redirects. Same IPs, same cert, same Worker. One hostname works, one doesn’t.
The zone API confirmed the nameservers were moved from Jimdo months ago:
{
"original_name_servers": ["ns14.jimdo.com", "ns13.jimdo.com"],
"name_servers": ["alexis.ns.cloudflare.com", "mona.ns.cloudflare.com"],
"activated_on": "2026-01-26T12:01:36Z"
}Then I tried the same request without a browser User-Agent:
A 403 instead of a 301. The response body was a Cloudflare challenge page - but not from my zone. With a browser UA: a 301 with Jimdo headers. Without: a 403 from someone else’s WAF. Two different failure modes, neither from my Worker.
Something between Cloudflare’s edge and my Worker was intercepting the requests.
Cloudflare for SaaS
Jimdo uses Cloudflare for SaaS (formerly SSL for SaaS) to serve their customers’ domains. This lets SaaS providers register their customers’ hostnames as “custom hostnames” in the provider’s own Cloudflare zone. When the site was on Jimdo, they registered the apex as a custom hostname.
After migrating, that custom hostname claim was never removed. Cloudflare’s internal routing gives SaaS custom hostnames priority over the domain owner’s own zone configuration. Requests to the apex hit Cloudflare’s edge, matched Jimdo’s stale claim, and got routed to Jimdo’s origin instead of my Worker.
The www subdomain was either never part of Jimdo’s SaaS setup or had been released. The 403 for non-browser UAs was Jimdo’s WAF rules, running in their Cloudflare zone - which explained why it wasn’t my challenge page.
Why this matters
The former provider has full control over the HTTP response. Jimdo happens to redirect, but there’s nothing preventing them from serving arbitrary content on my domain. The browser sends cookies scoped to the apex with every request, so the provider receives them before even responding.
None of this is visible in the domain owner’s Cloudflare dashboard. No warning, no conflict indicator. The stale claim doesn’t expire and can’t be overridden. The only tell is provider-specific headers in the response.
Workaround
Until Cloudflare addresses the underlying routing priority:
- Contact the old provider and ask them to remove the custom hostname.
- Open a Cloudflare support ticket referencing the routing conflict.
There’s no self-service override from the domain owner’s side.