Conversation
supportDoes it work with cache enabler? should it be used with another caching plugin as it doesnt provide those html cache features right?
Yes, Cacheability works great alongside Cache Enabler (or any other caching plugin). Cacheability is not a caching plugin itself — it improves how well your existing caching setup works by fixing WordPress’s HTTP behavior: Soft 404 fix — WordPress returns HTTP 200 for empty search/tag/category pages. Google flags these as “soft 404” errors. Cacheability returns proper 404 status codes so your cache doesn’t store these broken pages. Smart cache headers — Adds s-maxage headers that tell proxy caches (Varnish, NGINX, CDNs) how long to cache content, without affecting browser caching. So yes, use it alongside Cache Enabler — they complement each other.
Thanks. I like the pro version if I can try with the cache warmer, is it local or running in the cloud/edge with possibility to warm edge cache? Soft 404 fix — WordPress returns HTTP 200 for empty search/tag/category pages. Google flags these as “soft 404” errors. Cacheability returns proper 404 status codes so your cache doesn’t store these broken pages. Can you show example of this? search yeah correct wp do return 200 which is a way to take a server down as its not cached all random ?search=random queries.
Cache Warmer The cache warmer runs on your WordPress server. After a page is purged, it fetches the URLs so your origin cache (Varnish, NGINX FastCGI cache, etc.) is re-populated before the next visitor arrives. Whether it also warms a CDN edge depends on your server’s DNS setup. If your server has an /etc/hosts entry pointing your domain to 127.0.0.1 or a local Varnish IP (which is common), the warming requests go directly to Varnish and bypass the CDN. If there’s no such override, requests go through the CDN and will warm the nearest edge node too. You can check it out here: https://www.getpagespeed.com/cacheability-pro Soft 404 Example Without Cacheability: yoursite.com/?s=xyzrandom → WordPress returns HTTP 200 with a “No results found” page → Google flags it as a “soft 404” in Search Console. With Cacheability: same URL → WordPress returns HTTP 404 → Google treats it correctly as not found. Search Query Caching You’re right that random search queries can hammer a server. Cacheability helps here too — it adds s-maxage=3600 to all search and 404 pages. This tells your proxy cache (Varnish, CDN, etc.) to cache each search URL for 1 hour. So ?s=randomstuff won’t hit WordPress again for the next hour. For truly massive attacks with unique queries, you’d pair this with rate limiting at the proxy level, but the caching alone handles the typical abuse.
Yes, Cacheability works great alongside Cache Enabler (or any other caching plugin). Cacheability is not a caching plugin itself — it improves how well your existing caching setup works by fixing WordPress’s HTTP behavior: Soft 404 fix — WordPress returns HTTP 200 for empty search/tag/category pages. Google flags these as “soft 404” errors. Cacheability returns proper 404 status codes so your cache doesn’t store these broken pages. Smart cache headers — Adds s-maxage headers that tell proxy caches (Varnish, NGINX, CDNs) how long to cache content, without affecting browser caching. So yes, use it alongside Cache Enabler — they complement each other.
Thanks. I like the pro version if I can try with the cache warmer, is it local or running in the cloud/edge with possibility to warm edge cache? Soft 404 fix — WordPress returns HTTP 200 for empty search/tag/category pages. Google flags these as “soft 404” errors. Cacheability returns proper 404 status codes so your cache doesn’t store these broken pages. Can you show example of this? search yeah correct wp do return 200 which is a way to take a server down as its not cached all random ?search=random queries.
Cache Warmer The cache warmer runs on your WordPress server. After a page is purged, it fetches the URLs so your origin cache (Varnish, NGINX FastCGI cache, etc.) is re-populated before the next visitor arrives. Whether it also warms a CDN edge depends on your server’s DNS setup. If your server has an /etc/hosts entry pointing your domain to 127.0.0.1 or a local Varnish IP (which is common), the warming requests go directly to Varnish and bypass the CDN. If there’s no such override, requests go through the CDN and will warm the nearest edge node too. You can check it out here: https://www.getpagespeed.com/cacheability-pro Soft 404 Example Without Cacheability: yoursite.com/?s=xyzrandom → WordPress returns HTTP 200 with a “No results found” page → Google flags it as a “soft 404” in Search Console. With Cacheability: same URL → WordPress returns HTTP 404 → Google treats it correctly as not found. Search Query Caching You’re right that random search queries can hammer a server. Cacheability helps here too — it adds s-maxage=3600 to all search and 404 pages. This tells your proxy cache (Varnish, CDN, etc.) to cache each search URL for 1 hour. So ?s=randomstuff won’t hit WordPress again for the next hour. For truly massive attacks with unique queries, you’d pair this with rate limiting at the proxy level, but the caching alone handles the typical abuse.