Does Cloudflare affect SEO?
Not by being there. Once the DNS records are proxied, the orange cloud in the dashboard, every request reaches Cloudflare before it reaches the WordPress server, Googlebot's included. Cloudflare then decides whether to answer from its cache, forward, redirect or challenge the request. That's why it can speed a site up, and why one wrong setting can turn a speed fix into a crawl problem nobody sees on their own screen.
Cloudflare's Improve SEO page lists what doesn't affect a domain's SEO. Using Cloudflare's nameservers doesn't. Server location isn't important for SEO, according to Google. Search engines don't generally penalize domains on shared IP addresses unless several of those sites are malicious or spammy. And its caching doesn't create duplicate content, rewrite URLs or add subdomains. The same page's troubleshooting section is the part I act on: WAF custom rules, rate limiting rules and bot settings have to allow Verified Bots.
Cloudflare's documentation says the CDN caches by file extension, not by content type, and doesn't cache HTML or JSON by default. So a fresh setup speeds up images, CSS and JavaScript, while pages still come from WordPress until a cache rule or APO says otherwise. None of it touches a record set to DNS only, because the proxy status decides whether traffic for a record goes through Cloudflare at all.
| Layer | Default | What I check |
|---|---|---|
| HTML pages | Not cached unless a cache rule or APO caches them | Which rule caches them, and what bypasses it |
| Images, CSS and JavaScript | Cached by file extension | That a purge follows every theme or plugin update |
| robots.txt | Cached by default | That an edited file is live at the edge, not just on the server |
| 301 responses with no cache headers | Cached for 120 minutes | That a corrected redirect isn't still served from cache |
| Bots and crawlers | Whatever the security settings allow | That verified crawlers get the page, not a challenge |
How do I set up Cloudflare on WordPress?
Cloudflare's onboarding guide has four stages, and I add a fifth. The best Cloudflare settings for WordPress, from the search side, are these plain ones.
- Step 01
Add the domain and pick a plan
In the dashboard I choose Onboard a domain and type the bare domain, like example.com, without www. The Free plan is enough to start, and a plan can change later.
- Step 02
Check every DNS record it imported
Cloudflare's guide says its quick scan isn't guaranteed to find all existing records. I compare the list with the old DNS host line by line: the root and www records, then the mail records, which stay DNS only.
- Step 03
Switch the nameservers at the registrar
Cloudflare assigns two nameservers, and they go in at the company the domain was bought from. If DNSSEC is on, Cloudflare says to turn it off at the registrar first, because changing nameservers with it active can make the domain unreachable.
- Step 04
Set SSL to Full (strict)
Cloudflare recommends Full (strict) whenever possible. It needs a valid certificate on the server that matches the hostname, or visitors get a 526 error, so I check the host's certificate before switching. Flexible is the mode I never leave on, for the redirect loop reason below.
- Step 05
Install the plugin only for APO
I add the Cloudflare WordPress plugin when the site will use APO, which needs it, and check it isn't fighting a second cache plugin over the same pages.
Before the nameserver switch I record the status and response time of five or six key URLs, for a real before and after.
Which Cloudflare SEO settings can hurt a WordPress site?
These are the settings I open first on any WordPress site behind Cloudflare. Each one's useful in the right place, and each one can quietly change what Google gets back.
- i.
Bot Fight Mode
It challenges traffic that matches known bot patterns, and Cloudflare's documentation says it can't be bypassed with WAF custom rules or Page Rules. If Security Events show it challenging a crawler I care about, the fix is turning it off, or moving to Super Bot Fight Mode, which does support Skip rules.
- ii.
Challenge rules with no crawler exception
A rule that challenges a country, a network or the whole site catches Googlebot too unless it says otherwise. I add
not cf.client.botto challenge rules. Cloudflare sets that field for known good bots and crawlers, so verified crawlers skip the challenge and impostors don't. - iii.
Under Attack mode left on
It shows visitors an interstitial page, and Cloudflare describes it as one of the last resorts when a zone is under attack. It isn't a standing setting, so I check it's off.
- iv.
A cache everything rule with no bypass
A rule that caches every page without bypassing logged-in and cart cookies can hand one visitor a page built for another, or keep serving an old version. The bypass has to cover the admin, the login page, previews and any session cookie.
- v.
Flexible SSL on a server that forces HTTPS
In Flexible mode Cloudflare talks to the server over plain HTTP. If WordPress or the host redirects HTTP to HTTPS, the request loops, and Cloudflare's troubleshooting page names this as a common cause of
ERR_TOO_MANY_REDIRECTS. - vi.
Redirect rules that copy WordPress
When Cloudflare forces HTTPS, a redirect rule adds www and a WordPress plugin adds a trailing slash, one old URL can take three hops. I give each job to one layer, so every old address reaches its page in one hop.
- vii.
Cached robots.txt and cached redirects
Cloudflare caches robots.txt by default, and a 301 without cache headers stays in its cache for 120 minutes. So a fixed Disallow line or a corrected redirect can keep being served from the edge after the server's already right. I purge after changing either one, then fetch it again.
Rather have me do this? One person, whole job.
Book a call on UpworkIs Cloudflare APO worth it for WordPress?
Automatic Platform Optimization is Cloudflare's WordPress product for caching the HTML itself. Its documentation says it caches dynamic content like HTML at the edge, which removes trips to the server and improves time to first byte. With the Cloudflare plugin installed, Cloudflare updates the edge copy when content changes in WordPress.
The part that matters for search is what it won't cache. APO bypasses the cache for logged-in and administrator users, for cookies that start with wp-, wordpress, comment_ or woocommerce_ among others, for excluded paths like checkout and feeds, and for most query strings. Marketing parameters such as utm_source and gclid are on its allowlist, so a tagged link still gets the cached page.
So is it worth it? When a page fails LCP and the server's slow to answer, APO is often the first thing I test, because it moves the HTML closer to the visitor without touching the theme. That's the kind of problem I look at on sites failing Core Web Vitals on real devices. It isn't the right fit on a multisite install, which Cloudflare says the APO plugin doesn't support, and an existing cache plugin can return stale responses, so I clear and check the other cache first.
Afterwards I look for the three headers Cloudflare lists: cf-cache-status, cf-apo-via and cf-edge-cache. If they're missing, APO isn't working, whatever the toggle says.
What happens when more than one cache rule matches?
Cloudflare's order and priority page says cache rules are stackable: every rule that matches a request applies, in order, and when several set the same thing, the value in the last matching rule wins. That includes bypass cache against eligible for cache.
Here's how it goes wrong on WordPress. Rule 1 bypasses the cache for /wp-admin/, the login page and the logged-in cookie. Rule 2, added later, caches everything on the hostname. A logged-in request matches both, rule 2 runs last, and the bypass is gone. I fix it by moving the bypass rule to the bottom, or better, by excluding the bypass condition inside the broad rule's own expression, so moving a rule later can't undo it.
| When these overlap | Which one wins | What I do about it |
|---|---|---|
| Two cache rules setting the same value | The last matching rule | Put bypass rules last, or exclude them inside the broad rule |
| A cache rule and a Page Rule on the same path | The cache rule | Move old Page Rules into cache rules so there's one list to read |
| Two redirect rules | The first matching rule, whose redirect is the one used | Keep one redirect for each source URL |
| Single Redirects and Bulk Redirects | Single Redirects, which run first | Keep redirects in one product, not two |
So cache rules and redirect rules run in opposite directions: the last cache rule wins, the first redirect rule wins.
How do I test Cloudflare SEO settings over HTTP?
My own browser is logged in, cached and isn't Googlebot, so these run from a terminal after every rule change.
- Step 01
List the URLs that matter
The homepage, a post, a page, a category archive, robots.txt, the sitemap and three old URLs that should redirect. On a store I add a product, the cart and the checkout.
- Step 02
Read the headers as a browser would
curl -sI -H 'accept: text/html' https://example.com/returns the status code and thecf-cache-statusheader. Cloudflare's own APO test sends the same accept header, so the request's treated like a browser asking for a page. - Step 03
Repeat with a logged-in cookie
The same request with
-H 'Cookie: wordpress_logged_in_test=1'has to come back as BYPASS or DYNAMIC. A HIT means a cached page is going to someone who should get a fresh one. A path can bypass for an unrelated reason, so I always test with the cookie too. - Step 04
Follow every redirect to the end
curl -sIL http://example.com/old-page/prints each hop. I want one 301 to a page that returns 200. It's the same one-hop test I run on launch day of a platform move. - Step 05
Check what Google gets
The live test in URL Inspection fetches the page as Google. If it fails where a browser doesn't, I find the request in Security Events and check the IP the way Google documents it: a reverse DNS lookup that ends in googlebot.com, google.com or googleusercontent.com, then a forward lookup that returns the same IP. A real Google IP means my rule's wrong.
- Step 06
Purge, then test again
After a rule change I purge the cache and run the list once more. Google's documentation says indexed URLs that return a 4xx are removed from the index, and that 5xx and 429 errors make its crawlers slow down, so I'd rather catch a bad answer in the terminal.
If you'd rather one person set up the Cloudflare side of your WordPress site and test it against what Google actually gets back, that's part of the speed work I do, fully remote, with a fixed scope set before any work starts.
Book a call on Upwork
