Le mot "LOST" est formé de plusieurs petits mots noirs qui répètent "FOUND" sur un fond blanc, évoquant le contraste entre être perdu et retrouvé - un peu comme corriger les images perdues dans WordPress.

WordPress : corriger les images qui ont perdu leur chemin

par · Lecture: 14 minutes

Sur WordPress, une image peut disparaître alors que le fichier existe encore sur le serveur. L’article affiche une icône cassée, la bibliothèque de médias semble confuse, et l’URL générée ne mène nulle part. Bref, l’image n’a pas disparu. Elle a juste perdu son chemin. Ambiance GPS en forêt.

Le cas classique : WordPress stocke un mauvais chemin dans la base de données. Parfois, il mélange une URL publique avec un chemin serveur privé. Parfois, il garde l’ancien domaine après une migration. Parfois, il pointe vers un dossier qui n’existe plus. Dans tous les cas, il faut diagnostiquer avant de corriger.

Kinsta: Premium Managed WordPress hosting

Symptômes : images cassées dans WordPress

Le problème peut apparaître de plusieurs façons :

  • les images ne s’affichent plus dans les articles ;
  • la bibliothèque de médias affiche des vignettes cassées ;
  • certaines images fonctionnent, mais pas les anciennes ;
  • les URLs contiennent encore l’ancien domaine ;
  • les URLs contiennent un chemin serveur comme /home/public_html/ ;
  • les miniatures sont manquantes après un changement de thème ;
  • Google Search Console signale des images introuvables ;
  • le navigateur retourne une erreur 404 ou 403 sur les fichiers image.

Avant de lancer une requête SQL, ouvrez une image cassée dans un nouvel onglet. Regardez l’URL exacte. C’est souvent elle qui donne le diagnostic.

Comprendre où WordPress stocke le chemin d’une image

Quand vous ajoutez une image dans WordPress, elle devient généralement un contenu de type attachment. WordPress stocke ensuite plusieurs informations dans la base.

  • wp_posts contient l’entrée média, avec le type attachment.
  • wp_postmeta contient le chemin du fichier dans la meta _wp_attached_file.
  • wp_postmeta contient aussi les métadonnées d’image dans _wp_attachment_metadata.
  • post_content peut contenir des balises <img> avec des URLs absolues.
  • postmeta, options ou des données de constructeur peuvent aussi contenir des URLs d’images.

La meta _wp_attached_file doit généralement contenir un chemin relatif au dossier uploads, par exemple :

2026/05/image.jpg

Elle ne devrait pas contenir un chemin système complet comme :

/home/example/public_html/wp-content/uploads/2026/05/image.jpg

Elle ne devrait pas non plus contenir une URL complète comme :

https://www.example.com/wp-content/uploads/2026/05/image.jpgLangage du code : JavaScript (javascript)

Quand cette valeur devient incohérente, WordPress construit de mauvaises URLs. Les images existent peut-être encore, mais WordPress ne sait plus les retrouver.

Kinsta: Premium Managed WordPress hosting

Commencer par sauvegarder la base

Avant toute correction en base, exportez une sauvegarde SQL. C’est non négociable, surtout si vous touchez wp_postmeta.

wp db export "backup-before-media-path-fix-$(date +%F-%H%M%S).sql"Langage du code : JavaScript (javascript)

Vérifiez que le fichier existe :

ls -lh backup-before-media-path-fix-*.sqlLangage du code : CSS (css)

Sur un site client ou un gros site éditorial, travaillez d’abord sur staging. Si vous devez corriger plusieurs centaines de médias, testez la procédure sur une copie avant de toucher la production.

Pour mettre en place une méthode de sauvegarde plus régulière, vous pouvez aussi lire l’article sur les sauvegardes de fichiers et bases de données avec cron.

Auditer les chemins stockés dans _wp_attached_file

Pour afficher les chemins médias stockés dans WordPress, utilisez WP-CLI :

wp db query "
SELECT post_id, meta_value
FROM wp_postmeta
WHERE meta_key = '_wp_attached_file'
ORDER BY post_id DESC
LIMIT 50;
"Langage du code : PHP (php)

Pour repérer les chemins serveur absolus, cherchez les valeurs qui contiennent /home/, /var/www/ ou public_html :

wp db query "
SELECT post_id, meta_value
FROM wp_postmeta
WHERE meta_key = '_wp_attached_file'
AND (
	meta_value LIKE '%/home/%'
	OR meta_value LIKE '%/var/www/%'
	OR meta_value LIKE '%public_html%'
);
"Langage du code : PHP (php)

Pour repérer les URLs complètes stockées à tort dans _wp_attached_file :

wp db query "
SELECT post_id, meta_value
FROM wp_postmeta
WHERE meta_key = '_wp_attached_file'
AND (
	meta_value LIKE 'http://%'
	OR meta_value LIKE 'https://%'
);
"Langage du code : PHP (php)

Si ces requêtes retournent des lignes, vous avez trouvé une cause probable.

Kinsta: Premium Managed WordPress hosting

Ancienne solution SQL : corriger directement wp_postmeta

Dans mon cas historique, les chemins contenaient un bout de chemin privé inutile, du type :

/home/public_html/images/

La correction SQL consistait à supprimer cette portion dans _wp_attached_file :

UPDATE wp_postmeta
SET meta_value = REPLACE( meta_value, '/home/public_html/images/', '' )
WHERE meta_key = '_wp_attached_file';Langage du code : JavaScript (javascript)

Cette méthode peut encore dépanner, mais elle doit rester ciblée. Ne lancez pas un UPDATE large sans vérifier les lignes concernées avant.

Commencez toujours par la version de contrôle :

SELECT post_id, meta_value
FROM wp_postmeta
WHERE meta_key = '_wp_attached_file'
AND meta_value LIKE '%/home/public_html/images/%';Langage du code : JavaScript (javascript)

Si le résultat correspond bien au problème, vous pouvez corriger. Sinon, posez le clavier. La base vient de vous sauver d’une bêtise.

Méthode recommandée : utiliser wp search-replace

Pour une correction plus sûre, utilisez wp search-replace. Il sait gérer les données sérialisées, ce qu’une requête SQL directe ne fait pas correctement.

Commencez par un test sans modification :

wp search-replace '/home/public_html/images/' '' wp_postmeta --include-columns=meta_value --dry-runLangage du code : PHP (php)

Si le rapport est cohérent, lancez la vraie correction :

wp search-replace '/home/public_html/images/' '' wp_postmeta --include-columns=meta_valueLangage du code : PHP (php)

Pour limiter la correction à une table précise, on cible wp_postmeta. Pour limiter la colonne, on utilise --include-columns=meta_value. C’est plus propre qu’un remplacement global dans toute la base.

Si votre préfixe de table n’est pas wp_, remplacez wp_postmeta par le bon nom. Vous pouvez le vérifier avec :

wp db prefix
Kinsta: Premium Managed WordPress hosting

Corriger les anciennes URLs après migration

Autre cas fréquent : après une migration, les images pointent encore vers l’ancien domaine. Exemple :

https://ancien-site.example/wp-content/uploads/2020/04/image.jpgLangage du code : JavaScript (javascript)

Alors que le site actuel utilise :

https://www.example.com/wp-content/uploads/2020/04/image.jpgLangage du code : JavaScript (javascript)

Testez d’abord le remplacement :

wp search-replace 'https://ancien-site.example' 'https://www.example.com' --dry-run --skip-columns=guidLangage du code : JavaScript (javascript)

Puis appliquez-le :

wp search-replace 'https://ancien-site.example' 'https://www.example.com' --skip-columns=guidLangage du code : JavaScript (javascript)

Le paramètre --skip-columns=guid évite de modifier la colonne guid. Pour les contenus, options et métadonnées, le remplacement suffit généralement à corriger les images cassées après changement de domaine.

Si vous avez beaucoup d’URLs à exporter ou vérifier après correction, le guide sur la liste des articles publiés avec WP-CLI complète bien cette procédure.

Corriger HTTP vers HTTPS

Si les images existent mais sont bloquées par le navigateur, vérifiez aussi le contenu mixte. C’est fréquent après un passage de HTTP à HTTPS.

Testez d’abord :

wp search-replace 'http://www.example.com' 'https://www.example.com' --dry-run --skip-columns=guidLangage du code : JavaScript (javascript)

Puis appliquez :

wp search-replace 'http://www.example.com' 'https://www.example.com' --skip-columns=guidLangage du code : JavaScript (javascript)

Ensuite, vérifiez une page affectée dans le navigateur. Ouvrez les outils de développement, puis regardez l’onglet Console ou Sécurité. Les erreurs de contenu mixte indiquent souvent l’URL exacte à corriger.

Vérifier si les fichiers existent vraiment

Une URL cassée peut venir de la base. Mais elle peut aussi venir d’un fichier absent. Vérifiez donc le dossier uploads.

ls -lh wp-content/uploads/2026/05/image.jpg

Pour chercher une image par nom :

find wp-content/uploads -type f -iname '*image*'Langage du code : JavaScript (javascript)

Si le fichier original n’existe plus, aucun remplacement en base ne le fera revenir. Il faudra restaurer une sauvegarde, récupérer le fichier depuis l’ancien serveur, ou remplacer l’image dans WordPress.

Si le fichier existe mais renvoie une erreur 403, le problème n’est pas le chemin en base. Consultez plutôt l’article sur les images WordPress qui renvoient une erreur 403. Dans ce cas, on parle plutôt de permissions, propriétaire Unix, nginx, Apache ou protection CDN.

Tester les URLs avec curl

Pour vérifier rapidement si une image répond correctement :

curl -I https://www.example.com/wp-content/uploads/2026/05/image.jpgLangage du code : JavaScript (javascript)

Résultat attendu :

HTTP/2 200Langage du code : HTTP (http)

Si vous obtenez 404, l’URL pointe probablement vers un fichier inexistant. Si vous obtenez 403, le fichier existe peut-être, mais le serveur refuse l’accès. Si vous obtenez 301 ou 302, suivez la redirection et vérifiez où elle mène.

curl -IL https://www.example.com/wp-content/uploads/2026/05/image.jpgLangage du code : JavaScript (javascript)

Régénérer les miniatures WordPress

Si l’image originale existe mais que certaines tailles sont manquantes, régénérez les miniatures avec WP-CLI :

wp media regenerate --only-missing --yes

Cette commande régénère uniquement les tailles manquantes. Elle est souvent préférable à une régénération complète sur un gros site.

Pour régénérer toutes les miniatures :

wp media regenerate --yes

Pour préserver les anciennes tailles générées, notamment si elles sont encore référencées quelque part :

wp media regenerate --skip-delete --yesLangage du code : JavaScript (javascript)

Après un changement de thème, de tailles d’images ou de formats WebP/AVIF, cette étape peut corriger beaucoup d’affichages cassés.

Inspecter les métadonnées d’une image

Pour voir les métadonnées d’un fichier attaché, récupérez d’abord son ID. Vous pouvez chercher par titre ou par nom de fichier :

wp post list --post_type=attachment --s=image --fields=ID,post_title,guid --format=tableLangage du code : PHP (php)

Puis inspectez les metas :

wp post meta list 123Langage du code : PHP (php)

Pour afficher uniquement _wp_attached_file :

wp post meta get 123 _wp_attached_fileLangage du code : JavaScript (javascript)

Pour afficher les métadonnées d’image :

wp post meta get 123 _wp_attachment_metadata --format=jsonLangage du code : JavaScript (javascript)

Remplacez 123 par l’ID du média concerné.

Corriger un seul média manuellement

Si un seul média est touché, inutile de sortir l’artillerie lourde. Corrigez directement la meta avec WP-CLI :

wp post meta update 123 _wp_attached_file '2026/05/image.jpg'Langage du code : JavaScript (javascript)

Ensuite, régénérez les miniatures de ce média :

wp media regenerate 123

Cette approche est plus sûre si le problème touche une poignée d’images. La correction massive doit être réservée aux motifs clairement identifiés.

Vérifier les images intégrées dans post_content

Parfois, _wp_attached_file est correct, mais les articles contiennent encore de vieilles URLs dans les balises <img>. C’est fréquent sur les anciens articles, les imports, les migrations ou les contenus passés par un éditeur visuel tiers.

Pour chercher un ancien domaine dans le contenu des articles :

wp db query "
SELECT ID, post_title
FROM wp_posts
WHERE post_status IN ('publish', 'draft', 'future')
AND post_content LIKE '%ancien-site.example%';
"Langage du code : PHP (php)

Pour le remplacer proprement :

wp search-replace 'https://ancien-site.example' 'https://www.example.com' wp_posts --include-columns=post_content --dry-runLangage du code : PHP (php)

Puis :

wp search-replace 'https://ancien-site.example' 'https://www.example.com' wp_posts --include-columns=post_contentLangage du code : PHP (php)

Pour auditer ensuite les articles affectés, vous pouvez vous appuyer sur l’audit des articles WordPress courts. Les vieux contenus courts sont souvent ceux qui gardent des balises images historiques ou des URLs codées en dur.

Attention aux constructeurs de pages

Elementor, WPBakery, Divi, Beaver Builder et d’autres constructeurs peuvent stocker des URLs d’images dans des metas, des options ou des structures sérialisées. C’est exactement le genre de cas où wp search-replace est préférable à une requête SQL brute.

Pour chercher un ancien domaine dans toute la base, commencez par un dry-run global :

wp search-replace 'https://ancien-site.example' 'https://www.example.com' --dry-run --skip-columns=guidLangage du code : JavaScript (javascript)

Si le rapport indique des changements dans les tables du constructeur, vérifiez ensuite quelques pages en front. Les constructeurs aiment bien cacher leurs données au fond de tiroirs sérialisés. Charmant.

CDN, cache et optimisation d’images

Si les chemins en base sont bons, les fichiers existent, mais les images restent cassées, regardez le CDN et les plugins d’optimisation d’images.

  • purgez le cache WordPress ;
  • purgez le cache serveur ;
  • purgez le CDN ;
  • vérifiez les réécritures WebP ou AVIF ;
  • désactivez temporairement le lazy loading agressif ;
  • testez sans plugin d’optimisation d’images ;
  • vérifiez si l’URL cassée pointe vers le domaine CDN ou vers le domaine principal.

Si vous utilisez des formats modernes, vérifiez aussi que les URLs, les types MIME et les fichiers générés correspondent vraiment. Pour les migrations WebP/AVIF, une petite incohérence en base peut suffire à casser l’affichage.

Vérifier avec Google Search Console

Google Search Console peut révéler des images cassées que vous ne voyez pas au quotidien. C’est d’ailleurs comme cela que j’avais repéré le problème initial.

Regardez notamment :

  • les pages avec erreurs d’exploration ;
  • les ressources introuvables ;
  • les URLs d’images qui répondent en 404 ;
  • les pages importantes dont les images ne chargent plus ;
  • les anciennes URLs encore découvertes par Google.

Après correction, testez les pages concernées dans Search Console, puis demandez une nouvelle exploration si nécessaire.

Script WP-CLI : lister les médias avec chemins suspects

Voici un petit script WP-CLI pour exporter les médias dont _wp_attached_file contient un chemin suspect.

<?php
/**
 * List WordPress attachments with suspicious _wp_attached_file values.
 *
 * Usage:
 * wp eval-file audit-media-paths.php > suspicious-media-paths.csv
 */

declare(strict_types=1);

global $wpdb;

$rows = $wpdb->get_results(
	$wpdb->prepare(
		"
		SELECT post_id, meta_value
		FROM {$wpdb->postmeta}
		WHERE meta_key = %s
		AND (
			meta_value LIKE %s
			OR meta_value LIKE %s
			OR meta_value LIKE %s
			OR meta_value LIKE %s
			OR meta_value LIKE %s
		)
		ORDER BY post_id ASC
		",
		'_wp_attached_file',
		'%/home/%',
		'%/var/www/%',
		'%public_html%',
		'http://%',
		'https://%'
	),
	ARRAY_A
);

$handle = fopen( 'php://output', 'w' );

if ( false === $handle ) {
	WP_CLI::error( 'Unable to open output stream.' );
}

fputcsv( $handle, array( 'attachment_id', 'title', 'attached_file', 'attachment_url' ) );

foreach ( $rows as $row ) {
	$attachment_id = absint( $row['post_id'] );

	fputcsv(
		$handle,
		array(
			$attachment_id,
			get_the_title( $attachment_id ),
			$row['meta_value'],
			wp_get_attachment_url( $attachment_id ),
		)
	);
}

fclose( $handle );Langage du code : HTML, XML (xml)

Lancez-le ainsi :

wp eval-file audit-media-paths.php > suspicious-media-paths.csvLangage du code : CSS (css)

Vous obtenez un CSV avec les médias suspects, leur ID, leur titre, la valeur stockée et l’URL générée par WordPress.

Script WP-CLI : vérifier si les fichiers attachés existent

Voici un autre script utile : il vérifie si les fichiers référencés par _wp_attached_file existent réellement dans le dossier uploads.

<?php
/**
 * List WordPress attachments whose original file is missing from uploads.
 *
 * Usage:
 * wp eval-file audit-missing-media-files.php > missing-media-files.csv
 */

declare(strict_types=1);

$uploads = wp_get_upload_dir();

if ( empty( $uploads['basedir'] ) ) {
	WP_CLI::error( 'Unable to determine uploads base directory.' );
}

$attachments = get_posts(
	array(
		'post_type'              => 'attachment',
		'post_status'            => 'inherit',
		'posts_per_page'         => -1,
		'fields'                 => 'ids',
		'no_found_rows'          => true,
		'update_post_meta_cache' => false,
		'update_post_term_cache' => false,
	)
);

$handle = fopen( 'php://output', 'w' );

if ( false === $handle ) {
	WP_CLI::error( 'Unable to open output stream.' );
}

fputcsv( $handle, array( 'attachment_id', 'title', 'attached_file', 'expected_path', 'attachment_url' ) );

foreach ( $attachments as $attachment_id ) {
	$attached_file = (string) get_post_meta( $attachment_id, '_wp_attached_file', true );

	if ( '' === $attached_file ) {
		continue;
	}

	$expected_path = trailingslashit( $uploads['basedir'] ) . ltrim( $attached_file, '/' );

	if ( file_exists( $expected_path ) ) {
		continue;
	}

	fputcsv(
		$handle,
		array(
			$attachment_id,
			get_the_title( $attachment_id ),
			$attached_file,
			$expected_path,
			wp_get_attachment_url( $attachment_id ),
		)
	);
}

fclose( $handle );Langage du code : HTML, XML (xml)

Lancez-le avec :

wp eval-file audit-missing-media-files.php > missing-media-files.csvLangage du code : CSS (css)

Ce fichier permet de distinguer les mauvais chemins en base des fichiers réellement absents. C’est une étape importante : on ne corrige pas une absence de fichier avec un remplacement d’URL.

Checklist de correction

  • Ouvrir l’image cassée dans un nouvel onglet.
  • Noter l’URL exacte générée par WordPress.
  • Tester l’URL avec curl -I.
  • Vérifier si l’erreur est une 404, une 403 ou une redirection.
  • Sauvegarder la base avec wp db export.
  • Auditer _wp_attached_file dans wp_postmeta.
  • Repérer les chemins serveur absolus comme /home/ ou /var/www/.
  • Repérer les anciennes URLs de domaine.
  • Tester les remplacements avec wp search-replace --dry-run.
  • Corriger uniquement les tables et colonnes nécessaires.
  • Vérifier que les fichiers existent dans wp-content/uploads.
  • Régénérer les miniatures si besoin.
  • Purger les caches WordPress, serveur et CDN.
  • Revalider les pages dans Google Search Console.

Commandes utiles à garder

Sauvegarder la base :

wp db export "backup-before-media-fix-$(date +%F-%H%M%S).sql"Langage du code : JavaScript (javascript)

Auditer les chemins suspects :

wp db query "
SELECT post_id, meta_value
FROM wp_postmeta
WHERE meta_key = '_wp_attached_file'
AND (
	meta_value LIKE '%/home/%'
	OR meta_value LIKE '%/var/www/%'
	OR meta_value LIKE '%public_html%'
	OR meta_value LIKE 'http://%'
	OR meta_value LIKE 'https://%'
);
"Langage du code : PHP (php)

Tester un remplacement :

wp search-replace '/home/public_html/images/' '' wp_postmeta --include-columns=meta_value --dry-runLangage du code : PHP (php)

Appliquer le remplacement :

wp search-replace '/home/public_html/images/' '' wp_postmeta --include-columns=meta_valueLangage du code : PHP (php)

Régénérer les miniatures manquantes :

wp media regenerate --only-missing --yes

Purger le cache WordPress :

wp cache flush

Conclusion

Quand des images WordPress “perdent leur chemin”, le réflexe ne doit pas être de tout remplacer à l’aveugle. Commencez par identifier où le chemin est cassé : _wp_attached_file, post_content, métadonnées de constructeur, fichiers absents, miniatures manquantes, CDN ou permissions serveur.

La requête SQL directe peut encore dépanner dans un cas très ciblé. Mais pour une correction moderne, préférez wp search-replace avec --dry-run, une sauvegarde, puis une correction limitée aux tables et colonnes nécessaires.

Ensuite, régénérez les miniatures si besoin, purgez les caches, puis vérifiez les URLs dans Google Search Console. Les images retrouveront leur chemin. Et vous, votre calme.

Sources

Report a typo Report icon

PinLinkedIn
Demandez à l'IA son opinion
ChatGPTPerplexityClaudeMistralGeminiGrok
Gravatar for Matt Biscay

Je suis Matt Biscay, développeur WordPress & WooCommerce certifié chez Codeable, administrateur système et enseignant.

J’aide les entreprises à créer, optimiser et fiabiliser leurs sites WordPress avec une approche technique propre : performance, sécurité, maintenance, développement sur mesure et résolution de problèmes complexes.

Sur Skyminds, je partage des tutoriels WordPress, WooCommerce, Linux et administration système, avec des solutions testées sur des cas réels et pensées pour durer.

Découvrez mes services WordPress et WooCommerce.

👔 Portfolio 📨 Me Contacter

2 réflexions au sujet de “WordPress : corriger les images qui ont perdu leur chemin”

Laisser un commentaire