Si la page s'affiche et que les images sont cassées, le HTML va bien et quelque chose dans les requêtes d'images ne va pas. Ouvrez le panneau réseau, rechargez, et lisez la colonne de statut à la lumière des quatre causes ci-dessous.

404 — le chemin est faux

curl -sSI https://yourdomain.com/img/rack.webp | head -1
ls -la /var/www/site/public/img/rack.webp

Sous Linux, le nom de fichier distingue les majuscules. Rack.webp et rack.webp sont deux fichiers différents : c'est pourquoi un site développé sous Windows ou macOS perd ses images à l'instant même du déploiement.

403 — elle existe et ne peut pas être lue

sudo -u www-data test -r /var/www/site/public/img/rack.webp && echo readable || echo NOT readable
namei -l /var/www/site/public/img/rack.webp

namei parcourt chaque répertoire du chemin. Un seul répertoire parent sans droit d'exécution bloque tout ce qui se trouve en dessous, alors que le fichier lui-même paraît parfaitement correct.

Bloquée, ou contenu mixte

Une image demandée en http sur une page https est bloquée par le navigateur et signalée dans la console comme contenu mixte. Voir Le contenu mixte après le passage à HTTPS. Un bloqueur de publicités écarte lui aussi tout ce dont le chemin contient des mots comme ads ou banner.

200 et toujours pas affichée

  • Le fichier n'est pas du format que son nom annonce — une page d'erreur HTML enregistrée en .jpg, par exemple.
  • Un CDN a renvoyé une erreur mise en cache. Purgez ce chemin et redemandez-le.
  • L'image est bien là et a une hauteur nulle : c'est du CSS, pas le fichier.
file /var/www/site/public/img/rack.webp
curl -sS https://yourdomain.com/img/rack.webp | head -c 20 | xxd | head -2
Si tout ce qui précède va bien en local mais casse à travers un proxy, interrogez l'origine directement avec --resolve et comparez. Cela coupe le problème en deux en une seule commande.