Vercel + Cloudflare Domain Setup Checklist

Domain cutovers fail for boring reasons: the wrong Cloudflare proxy setting, SSL left on Flexible, apex and www fighting each other, or half the DNS still pointing at an old host. This checklist is the sequence DAOL Consulting uses when we put a client site on Vercel + Cloudflare hosting — so the marketing site does not go dark on launch day.

Preflight before DNS moves

Do not touch nameservers or records until this is green:

1. Vercel project is production-ready — latest deploy succeeds; main/production branch is what you intend to serve.
2. Environment variables — production secrets exist in Vercel (not only on your laptop). Preview and Production are separate.
3. Domain added in Vercel — both example.com and www.example.com (or your chosen pair) are added so Vercel can issue certificates.
4. Ownership of DNS — confirm who can edit Cloudflare (or the registrar). Split ownership (“marketing has Cloudflare, IT has the registrar”) is the #1 delay.
5. Rollback owner named — one person who can revert DNS within minutes if something is wrong.
6. Smoke URLs ready — list 5 pages to hit after cutover (home, contact, one service, one blog, robots/sitemap if relevant).

Print or share this list in the launch chat. Verbal “we’re good” is how weekends get ruined.

Exact DNS records for Vercel behind Cloudflare

Exact targets change over time — always copy the values Vercel shows under Project → Settings → Domains. The shape is usually:

Rules of thumb:

• Change only the web records you intend to move. Leave MX and SPF alone unless email is in scope.
• If you use Cloudflare for email routing or other products, document those records before edit day.
• After saving, wait for propagation — do not flip five settings every two minutes.

Orange cloud vs DNS-only (proxy on/off)

Cloudflare’s orange cloud means traffic proxies through Cloudflare. Grey cloud means DNS-only (clients resolve straight to Vercel).

Common failure: turn orange cloud on immediately with SSL mode Flexible. Browsers show HTTPS to Cloudflare, but Cloudflare talks HTTP to origin — Vercel expects HTTPS. Symptoms include redirect loops, mixed trust, and “it works on my phone but not the office Wi‑Fi.”

Practical order: grey → confirm Vercel HTTPS → set SSL to Full (strict) → then orange if you need proxy features.

SSL/TLS modes (do not use Flexible)

In Cloudflare → SSL/TLS:

Vercel terminates TLS with valid certificates. Full (strict) matches that model. Flexible is a launch landmine.

Also check:

• Always Use HTTPS — on, once Full (strict) works
• Automatic HTTPS Rewrites — usually fine
• HSTS — enable only after you are sure HTTPS is stable (hard to undo for browsers that cached it)

Apex vs www strategy and redirects

Pick one canonical host and redirect the other. Example DAOL pattern: prefer www and redirect apex → www (or the reverse — consistency matters more than which one).

Do this in one place when possible:

1. Vercel domain redirects / primary domain setting, or
2. Cloudflare Redirect Rules / Bulk Redirects

Avoid stacking both systems with conflicting rules. Double redirects waste crawl budget and confuse canonical tags.

Test after cutover:

• http://example.com → https + canonical host
• http://www.example.com → https + canonical host
• https:// non-canonical → 301 to canonical

Your HTML canonical tags should match the host you chose (see site-wide metadata). A fast, stable domain only pays off if people find you — pair this with how to rank on Google Maps when the business is local.

Cutover timeline (hour-by-hour style)

Adapt times to your change window; the order matters more than the clock.

T−24h

• Confirm preflight checklist
• Screenshot current DNS
• Lower Cloudflare DNS TTL on records you will change (e.g. 5 minutes) if they were high
• Deploy a final production build on Vercel

T−1h

• Put the team on a shared call/chat
• Disable aggressive page rules that might cache the old origin
• Confirm rollback DNS values are written down

T0 — change records

• Update A/CNAME/TXT to Vercel values
• Keep proxy grey initially
• Set SSL to Full (strict)

T+15–60m

• Hit smoke URLs from phone LTE and office network
• Check certificate in browser padlock
• Verify apex/www redirects once
• Submit key URLs in Search Console if this is a domain move

T+2–24h

• Watch Vercel logs / Cloudflare analytics for spikes of 4xx/5xx
• Only then consider orange cloud + WAF rules
• Restore longer TTLs if you shortened them

Rollback plan

If the site is wrong after cutover:

1. Revert DNS records to the screenshot from T−24h
2. Keep SSL mode changes documented — reverting Flexible mistakes may still need a purge
3. Purge Cloudflare cache if proxy was on
4. Do not “fix forward” with random CNAMEs while clients are live-testing

Rollback is a first-class step, not an admission of failure.

Common failure modes

1. Split DNS — registrar NS still point elsewhere while you edit a Cloudflare zone that is not authoritative.
2. Cached old site — orange cloud + old Cache Everything rules serving yesterday’s HTML.
3. ACME / certificate failures — domain not verified in Vercel, TXT missing, or proxy on too early.
4. Email breaks — someone deleted MX while “cleaning DNS.”
5. Canonical war — site metadata says www, redirects say apex.
6. Env mismatch — production site boots without NEXT_PUBLIC_* or API keys that existed only in Preview.

Soft CTA

If you want this done without a weekend war room, DAOL runs Vercel and Cloudflare hosting as part of launches for Calgary and remote clients. Hosting is one line in a bigger budget — the rest is in website maintenance cost per month. Building guest-ops tools on the same stack? See our bilingual wedding RSVP → Google Sheets guide.