How to solve “page cache is not detected but the server response time is ok” in WordPress Site Health.

If you don’t use any of the popular caching plugins (e.g. WP-Rocket, W3 Total Cache, WP Super Cache…), but instead deploy Nginx FastCGI cache for (server side) Full Page Caching, you will probably see the message “page cache is not detected but the server response time is ok” when you run the “Site Health” checker you find in the WordPress tools section of the admin dashboard.

Much has been said and written about this problem, but it can generally be assumed that it is a glitch or imperfection in the “Site Health” checker script that will hopefully be fixed in one of the upcoming WordPress releases. However, it is possible with a small tweak in the Nginx configuration to prevent the warning from appearing and thus get a good score when running the Site Health checker.

The “Site Health” script looks for one of the known active page cache plugin, or three of the following response headers: cache-control, expires, age, last-modified, etag, x-cache-enabled, x-cache-disabled, x-srcache-store-status, x-srcache-fetch-status.

Nginx (with FastCGI cache) does not set any of these headers by default, so it is necessary to add the appropriate headers yourself to the “location” block for “.php$”.

Open the Nginx configuration file for the domain in question.

vi /etc/nginx/sites-enabled/example.com

Add headers “Cache-Control “no-cache” and x-cache-enabled “true“” to the “php” location within the “location” block for “your domain”.php$”.

    location ~ \.php$ {
      fastcgi_pass unix:/run/php/php8.2-fpm.sock;
      include global/fastcgi-php.conf;
      fastcgi_cache_bypass $skip_cache;
      fastcgi_no_cache $skip_cache;
      fastcgi_cache example.com;
      fastcgi_cache_valid 404      1m;
      fastcgi_cache_valid 60m;
      add_header X-FastCGI-Cache $upstream_cache_status;
      add_header Cache-Control "no-cache";
      add_header x-cache-enabled "true";
      include snippets/security-headers.conf;
    }

Note that Nginx does not inherit anything from previous blocks (e.g., http, server) if the same directive is used within a location block. In this case, we use “add_header” within the “location” block for “.php” which will cause all previously set directives to expire and thus need to be reset. So we need to add the security headers again by adding the “security-headers.conf”.

If you have not yet created the “security-headers.conf” snippet you can do so with the following code.

vi /etc/nginx/snippets/security-headers.conf

Which should have the following code:

add_header X-Frame-Options "SAMEORIGIN";
add_header 'Referrer-Policy' 'strict-origin';
add_header X-XSS-Protection "1; mode=block";
add_header X-Content-Type-Options "nosniff" always;
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload";
add_header Content-Security-Policy "default-src https: data: 'unsafe-inline' 'unsafe-eval'" always;
add_header Permissions-Policy "accelerometer=(), camera=(), geolocation=(), gyroscope=(), magnetometer=(), microphone=(), payment=(), usb=()";