Connect your own domain

Published sites are served under one domain you control. Pick something like sites.youragency.com, and every website you publish gets its own name under it:

harbor-dental-care.sites.youragency.com
bluebird-bakery.sites.youragency.com
keller-woodworks.sites.youragency.com

You add one DNS record, once. Every site published afterwards resolves without touching DNS again — that is the whole point of the shared project described in Connect Cloudflare.

This chapter assumes a Cloudflare account is already connected. If it is not, do that first.

Choose the domain

Use a subdomain of a domain you own, not the domain itself. sites. in front of your agency domain is the convention and it keeps the record out of the way of your own website and email.

The field accepts a bare domain too, but read this before you use one:

Some names can never be used for a site. www, mail, smtp, api, app, admin, login, cdn, static, dev, staging, test, ns1 and about fifteen others are reserved, so a business whose name would produce one of them gets the next free variant instead. That is what stops a client's site from taking over mail.youragency.com.

1. Save the domain

Open Settings → Deployment. In the Publishing domain card, type the domain into Domain and press Save domain.

Enter it plain: sites.youragency.com. Not *.sites.youragency.com, not .sites.youragency.com, and not https://…. The app rejects all three rather than guessing, with That is not a domain the app can publish under. Enter it without a wildcard or leading dot, for example sites.youragency.com.

The card confirms with Sites will be published under sites.youragency.com.

2. Create the Cloudflare project

The The DNS record block appears once a domain is saved. Before the project exists it explains why and offers one button:

Every site on this domain is served from one Cloudflare project, and the wildcard record points at it. Create it to get the exact record to add — this makes a Pages project in your account and puts a placeholder page on it.

Press Create the project. The app creates the Pages project in your account, names it after the domain (sites.youragency.com becomes sites-youragency-com), deploys a placeholder page, and checks by fetching it back over HTTP that both the files and the routing worker are live. It then reports:

Created sites-youragency-com and deployed a placeholder page. Point your wildcard at sites-youragency-com.pages.dev.

That …pages.dev hostname is what your DNS record points at. The app can only show it after this step, which is why the button comes before the record.

3. Add the wildcard CNAME

The card now prints the exact record:

Type    CNAME
Name    *.sites.youragency.com
Target  sites-youragency-com.pages.dev
Proxy   off (DNS only)

Add it wherever the DNS for that domain lives — the registrar you bought it from, your web host, or a DNS provider you moved it to. Opportunora never touches DNS itself and asks Cloudflare for no permission to.

Where the record goes, by provider

Two details that catch people out whatever the provider:

• Proxy off. If your DNS is on Cloudflare, set the record to DNS only — the grey cloud, not the orange one. Proxying a hostname that Cloudflare Pages is also serving puts two Cloudflare layers in the path.
• TTL. Whatever the default is, is fine. A short TTL while you set this up means a mistake is cheaper to fix.

If your provider refuses a wildcard

A few DNS panels will not accept * in a host field. You do not have to move your domain: move only its DNS. Cloudflare's free plan will host the zone for a domain registered anywhere — you change the nameservers at your registrar and keep everything else. Every other record you have today comes across with it, so read the imported zone carefully before you switch.

4. Check it

Press Check DNS on the same card. The app looks up a random hostname under your domain against Cloudflare's public resolvers — a name nobody would ever create by hand, so an answer proves the wildcard exists rather than proving some unrelated record does.

The check only accepts a CNAME. An A record pointed at an IP address reads as Not found, because Pages has no fixed address to point at.

DNS changes usually spread in minutes, occasionally in hours. Nothing breaks while you wait — publishing works, and the site simply is not reachable at its name until the record is live.

What each site's address becomes

The name comes from the website's name in Opportunora: lowercased, accents spelled out (Bäckerei Müller becomes baeckerei-mueller), everything else turned into hyphens, and a number appended if that name is already taken.

The address is fixed at the first successful publish. Renaming the website afterwards never moves the URL, because a client already has the old one. Take a site offline and republish it later and it returns to the same address.

A hostname under your domain that no site has claimed gets a page titled No site here, served with a 404 and marked noindex. That is what a visitor sees at anything.sites.youragency.com, and it is deliberate: it should read as a spare address, not as a broken deployment.

HTTPS

Cloudflare issues the certificate. During a publish the app registers <site>.sites.youragency.com on the Pages project and then waits up to two minutes for Cloudflare to report it active. That is normally seconds.

If it takes longer, the publish still succeeds and says so:

The site is live, but harbor-dental-care.sites.youragency.com is still pending at Cloudflare. It usually goes live within a few minutes; check the wildcard record under Settings → Deployment if it does not.

Two things follow from that warning. The site really is live — the files are uploaded and the routing is in place. And the address recorded on the website in Opportunora is the Cloudflare deployment URL rather than your own hostname until you publish it again, so once the domain goes active, republish to move the recorded link over.

If Cloudflare refuses the hostname outright, the publish fails with Cloudflare could not activate … Check that the wildcard CNAME for this domain is in place. That is almost always step 3 not done, or done at the wrong zone.

Changing the domain later

Save a different domain and new publishes go to it. What does not happen automatically: sites already published keep their old hostnames attached at Cloudflare, and their recorded addresses do not change. Republish each site you want moved, and remove the old hostnames in the Cloudflare dashboard when you are done with them.

Can a client use their own domain?

Not through the app today. Every published site is served under the one publishing domain, and the routing table only answers for hostnames the app put there — pointing bakery.com at the project gets the No site here page.

Two things you can do instead:

• Hand over the files. Download files in the editor gives you the whole site as a ZIP with relative paths and every image included. It works on any static host, and it owes nobody a request afterwards. That is also the cleanest way to end an engagement.
• Redirect. Point the client's domain at their site's address with a redirect at their registrar. It is not the same as serving the site there, and the address bar will show your domain.

Next

With an account and a domain in place, publishing works. The chapter on publishing a website is what happens after you press Approve & publish.