DEV Community

Mandar Gokhale
Mandar Gokhale

Posted on

Helping a friend connect his BigRock domain to Cloudflare pages

A friend of mine needed a simple one-page website for his business. Nothing fancy — just something professional that could go live quickly. I figured Cloudflare Pages was the best option: free hosting, blazing-fast CDN, and automatic SSL.

I knew the basics: if I could point the domain from BigRock to Cloudflare using CNAMEs, we’d be in business. At least, that’s what I thought.


BigRock’s Old vs New UI Problem

The first hurdle was BigRock’s interface. They have an “old” UI and a “new” UI — and they don’t behave the same way.

  • In the old UI, I could actually delete BigRock’s default nameservers and replace them with Cloudflare’s nameservers (as required).
  • In the new UI, the old nameservers kept showing alongside the new ones, which was confusing.

So if you’re stuck, pro tip: use the old BigRock UI to make clean changes to nameservers.


Domain Mapping and CNAME Setup

Once the domain was delegated to Cloudflare, the next step was setting up DNS records inside Cloudflare. This is where the domain mapping happens — it’s how your friendly business domain (example.com) gets connected to the special .pages.dev address Cloudflare Pages gives you.

The correct setup looks like this:

Type Name Target (Content) Proxy
CNAME @ <your-project>.pages.dev Proxied (orange cloud)
CNAME www <your-project>.pages.dev Proxied (orange cloud)
  • @ represents the root domain (example.com).
  • www is the subdomain (www.example.com).
  • Both must point to the Cloudflare Pages project’s .pages.dev domain.

This part I got right — but the site still wouldn’t load.


Debugging with dig

After switching nameservers and adding CNAMEs, I expected things to work right away. But no — the website kept throwing gateway timeouts and later 522 errors.

That’s when the dig command became my best friend:

dig www.example.com CNAME
Enter fullscreen mode Exit fullscreen mode

This command showed me whether the DNS records were actually resolving. For a long time, dig returned nothing, which told me the changes hadn’t propagated or weren’t set correctly.


The Missing Piece: Custom Domains in Cloudflare Pages

Here’s the part that tripped me up the most.

Even though I had the CNAME records pointing correctly, I didn’t realize that Cloudflare Pages also requires you to register the domain inside the project itself.

To fix this:

  • Go to Cloudflare → Workers & Pages → Your Pages Project → Custom Domains.
  • Add both the root domain (example.com) and the www domain (www.example.com).
  • Cloudflare then validates the DNS setup and issues SSL certificates.

Until you do this, you’ll keep getting 522 errors, because Pages doesn’t yet know the domain belongs to your project.


SSL and the Final Wait

Once I finally added the custom domains in Cloudflare Pages, everything clicked into place. DNS validated, Cloudflare started issuing SSL, and after 10–30 minutes the status showed Active.

My friend’s one-page site was finally live on his BigRock domain — fast, secure, and free.


What I Learned

  • BigRock UI quirks: sometimes only the old UI lets you remove their default nameservers.
  • CNAMEs are essential: you must map both root and www to your Pages project’s .pages.dev domain.
  • dig is your friend: it confirms if DNS is actually resolving.
  • Custom Domains in Pages are required: DNS records alone are not enough.
  • SSL takes time: don’t panic if you see errors while it’s still provisioning.

Common Errors & Fixes

  • Gateway Timeout (504 / 522) → Usually means your CNAME records are missing or incorrect. Make sure both root and www point to your Pages project.

  • Error 522 after CNAMEs are correct → You likely forgot to add the domain inside Cloudflare Pages → Custom Domains. Add both root and www.

  • SSL Pending or Invalid Certificate → Normal after adding a custom domain. Wait 10–30 minutes; Cloudflare will provision SSL automatically.

  • Old Nameservers Still Showing → Use BigRock’s old UI to delete default nameservers, and wait for propagation (24–48 hours). Confirm with dig or dnschecker.org.

  • Site works on www but not root (or vice versa) → Add a redirect rule in Cloudflare so one version forwards to the other (better for SEO).


Why I’ll Use Cloudflare Pages Again

Despite the confusion, Cloudflare Pages is a fantastic platform:

  • No servers to manage.
  • Free global CDN and SSL.
  • Smooth Git integration for deployments.

Now that I know the “gotchas” — BigRock’s UI quirks, CNAME domain mapping, and the hidden Custom Domains step — the process is much smoother.

And most importantly: my friend’s site is online, looking professional, and loading fast.

Top comments (0)