Follow one visitor from browser to WordPress
Suppose a visitor enters your domain into a browser. DNS first helps determine where that request should go. When the website's supported DNS records are proxied through Cloudflare, the browser connects to Cloudflare's network rather than simply being handed the public origin route.
At the Cloudflare layer, applicable security controls can inspect the request, firewall rules can act, cached content may be served, and legitimate requests can be forwarded to the hosting server. The response then travels back to the visitor. All of that normally happens fast enough that the visitor never thinks about it.
DNS is the address system
The Domain Name System translates human-friendly names into the technical destinations computers use. When Cloudflare is authoritative for a domain's DNS, its nameservers answer those DNS queries and its dashboard becomes the place where you manage records.
DNS deserves care because it can affect much more than the website. MX, TXT and other records may support email, domain verification and third-party services. Moving DNS without first recording the existing configuration is an easy way to fix the website while accidentally breaking something else.
Orange cloud versus DNS only
Proxied
Supported web traffic passes through Cloudflare. This enables applicable edge security, caching and performance features and normally keeps the origin IP out of ordinary DNS responses.
DNS Only
DNS resolves directly to the destination. Cloudflare's HTTP proxy protections do not sit in that request path. Some mail and specialized service records need this behaviour.
A common mistake is assuming every DNS record should be orange-cloud proxied. It should not. Proxy the web records Cloudflare supports and that you intend to protect; leave records for services that require direct DNS resolution configured according to those services' documentation.
HTTPS has two legs when Cloudflare is in front
With Cloudflare proxying a secure website, think about encryption in two stages: the visitor communicates securely with Cloudflare, and Cloudflare communicates securely with the origin. For most production WordPress sites with a valid certificate on the server, Full (Strict) is the sensible target because the origin connection is encrypted and its certificate is validated.
Flexible can create the appearance of HTTPS at the browser while leaving the Cloudflare-to-origin leg unencrypted, so it is generally not the configuration we want for a properly configured production site. Full encrypts the origin connection but does not provide the same certificate validation as Full (Strict).
A sensible starting configuration
Exact Cloudflare menus and plan features change over time, so do not treat screenshots or old menu names as permanent. The principles are more important than a particular dashboard location.
Mistakes I see repeatedly
Leaving the main website record DNS-only means Cloudflare never gets a chance to filter that traffic. Using Flexible SSL unnecessarily weakens the origin leg. Missing DNS records can break mail. Aggressive caching can interfere with logged-in or dynamic WordPress behaviour. And the biggest conceptual mistake is assuming Cloudflare alone makes WordPress secure.
Cloudflare is the front gate. You still need a secure building behind it.
How to test the setup
After DNS or TLS changes, load the site over HTTPS and check both the www and non-www version according to your canonical setup. Confirm redirects land on one preferred URL. Review browser certificate information. Check Cloudflare security events and response behaviour. Then test the parts of the business website that actually matter: forms, checkout, bookings, logins and transactional email.
DNS changes can also take time to propagate through caches, so avoid making five unrelated changes while troubleshooting one problem.
Common questions
Does Cloudflare replace a WordPress security plugin?
No. Cloudflare can stop or challenge traffic before it reaches WordPress, while a WordPress security tool can see application-level activity after the request reaches the site. They protect different layers.
Does proxying completely hide my origin?
It reduces ordinary exposure, but an origin address may be discovered through historical DNS, another service, server behaviour or configuration mistakes. Part 3 deals specifically with that problem.
Will Cloudflare automatically make every site faster?
It can improve delivery and reduce origin load, but performance depends on caching strategy, page weight, hosting, WordPress configuration and what the visitor is requesting.
Next: protect the server behind Cloudflare
Once traffic is supposed to pass through Cloudflare, the next question is important: what happens if somebody discovers the origin server and tries to go around Cloudflare?