Une page vide avec un statut 200, c'est PHP tombant sur une erreur fatale alors que display_errors est désactivé. L'erreur existe ; elle a été écrite dans un journal plutôt qu'à l'écran. Rien n'est cassé sans remède, et le journal nommera le fichier et la ligne.

Lisez le journal, n'activez pas display_errors

Activer les erreurs dans le navigateur montre vos chemins de fichiers à quiconque charge la page. Le journal contient les mêmes informations et ne les montre à personne.

tail -40 /var/log/php8.3-fpm.log
# or, if the site sets its own:
tail -40 /path/to/site/error_log

Si le journal est vide

C'est que PHP n'est jamais allé assez loin pour en écrire un. Deux causes, par ordre de probabilité :

  1. La mémoire — Un script qui dépasse memory_limit est tué avant d'avoir pu journaliser. Relevez-le le temps de voir la vraie erreur : memory_limit = 512M
  2. Une erreur de syntaxe dans un fichier inclus — php -l le nomme : php -l wp-config.php

Sur WordPress en particulier

Neuf fois sur dix, c'est une extension ou un thème mis à jour quelques minutes plus tôt. Renommez le répertoire des extensions : le site revient avec toutes les extensions désactivées, et les renommer une à une trouve la coupable.

mv wp-content/plugins wp-content/plugins.off
# site loads? rename back and re-enable one at a time
Ajoutez define("WP_DEBUG_LOG", true); dans wp-config.php. L'erreur part dans wp-content/debug.log et non à l'écran.