Images WordPress en erreur 404 après migration : réparer les fichiers et leurs adresses

Reconnaître une image introuvable après le déplacement

Le site s’ouvre à sa nouvelle adresse, mais certaines photos ont disparu. Dans le navigateur, leurs requêtes renvoient une erreur 404. Le résultat recherché est de retrouver les fichiers attendus à leurs adresses correctes, en conservant les médias existants et les pages qui les utilisent.

Une réponse 404 indique que le serveur ne fournit pas la ressource demandée à cette adresse. Elle ne démontre pas à elle seule que l’original a été effacé. Après une migration, le navigateur peut demander l’ancien domaine, un dossier déplacé, une variante non copiée ou une adresse transformée par un service d’images. Commencez donc par une image témoin et son URL exacte.

Ce parcours concerne les images publiées en erreur après déplacement. Si seule la grille de la médiathèque reste vide, utilisez le diagnostic de cette bibliothèque. Si le navigateur bloque une ressource HTTP dans une page HTTPS, vérifiez le contenu mixte. Si toutes les pages internes échouent mais que les fichiers d’images s’ouvrent, examinez plutôt les liens permanents.

Gardez l’ancienne copie ou la sauvegarde de migration jusqu’à la fin des contrôles. Ne réimportez pas immédiatement toutes les images dans Médias : cela peut créer de nouveaux identifiants et laisser les anciennes références cassées. Une récupération ciblée du fichier ou de son adresse préserve souvent bien mieux l’organisation existante.

Relever l’adresse demandée, la réponse et la page d’origine

Ouvrez une page qui présente le défaut, puis les outils de développement du navigateur. Dans Réseau, rechargez cette page et repérez la requête de l’image en échec. Consultez son adresse complète et son statut. Copiez l’URL dans une note privée avec la page, le nom du fichier et l’heure du contrôle.

Ouvrez cette adresse dans un nouvel onglet. Vérifiez que vous consultez le fichier et non une page de pièce jointe entourée du thème. Un statut 200 accompagné du contenu HTML d’une page d’erreur ne constitue pas une image récupérée. De même, une redirection vers une page d’accueil ne valide pas le média.

Comparez domaine, protocole, dossier, nom, extension et éventuelle casse. Ces exemples sont différents : un ancien domaine demande une correction de référence ; un domaine correct avec un sous-dossier absent demande d’examiner le transfert. Une URL comportant un nom de taille tel que photo-768x512.jpg peut désigner une variante, distincte de l’original.

Faites ce relevé sur deux ou trois images de périodes différentes. Si elles ne suivent pas le même schéma, conservez plusieurs diagnostics au lieu de chercher un remplacement universel. Cette étape est une lecture seule. Elle doit produire une comparaison vérifiable entre ce qui est demandé et ce qui existe, avant toute écriture dans les fichiers ou la base.

Préparer le bon accès et une restauration utilisable

Sur WordPress autohébergé, l’édition d’une page, l’accès SFTP aux fichiers et l’administration de la base sont trois pouvoirs différents. Pour restaurer un fichier, utilisez le compte du nouvel hébergement et le dossier de cette installation. Pour remplacer des adresses en nombre, prévoyez une sauvegarde récente de la base et un moyen confirmé de la rétablir.

Une copie de travail permet de vérifier un remplacement avant sa reprise sur le site public. Elle doit avoir des médias représentatifs et rester protégée des visiteurs. Si elle peut envoyer des courriels ou lancer des commandes externes, faites neutraliser ces effets avant toute expérimentation. L’essai d’un remplacement ne doit pas déclencher d’opérations métier.

Choisissez la première approche si l’adresse attendue est cohérente mais que le fichier manque sur le nouveau serveur. Choisissez la seconde si le fichier existe à une nouvelle adresse vérifiée et que les contenus gardent l’ancienne. Si seuls certains formats ou certaines tailles échouent, examinez la variante ou le service intermédiaire avant un remplacement de domaine.

En multisite, impliquez l’administrateur réseau : chaque sous-site possède son contexte et peut utiliser une autre arborescence. Sur une offre gérée telle que WordPress.com, employez les accès réellement disponibles ou demandez la récupération ciblée à la plateforme. Ne déduisez pas du rôle administrateur WordPress que vous pouvez modifier tous les fichiers du serveur.

Approche 1 : restaurer le fichier manquant au chemin attendu

Ce parcours convient lorsque l’URL actuelle est correcte et que le fichier correspondant manque dans la nouvelle copie. Il demande un accès aux fichiers autorisé, une source de restauration connue et la confirmation du répertoire des médias de cette installation. Dans un cas habituel, il se trouve sous wp-content/uploads, mais une personnalisation ou un réseau peut changer cette organisation.

Avec votre client SFTP ou le gestionnaire de fichiers de l’hébergement, ouvrez le dossier du site cible puis celui correspondant à l’URL relevée. Comparez le nom exact avec la sauvegarde, y compris extension et majuscules. Par exemple, une image attendue sous uploads/2025/04 ne sera pas réparée si vous la déposez seulement à la racine de uploads.

Copiez d’abord un seul fichier confirmé absent, dans son sous-dossier d’origine, sans écraser un fichier existant. Si le transfert annonce un conflit, annulez et comparez les deux fichiers avant de décider. Ne renommez pas un original pour lui donner le nom d’une miniature : cela fausserait les dimensions et le rôle du fichier.

Rouvrez exactement l’URL en échec, puis la page qui l’utilise. Le résultat attendu est le bon fichier, avec son contenu réel et une réponse normale, pas une nouvelle fiche de média. Si cette restauration ne résout rien, conservez la preuve du fichier ajouté et faites vérifier l’association entre le domaine et le dossier servi. Pour annuler l’essai, retirez seulement cette copie ajoutée après avoir vérifié qu’elle n’a pas reçu un nouvel usage.

Si le fichier existe déjà, examiner le dossier servi et les intermédiaires

Un fichier présent sur le serveur mais introuvable à son URL demande une vérification de correspondance. Assurez-vous que le domaine ouvre bien la nouvelle installation, et non un ancien dossier ou une copie de travail. Deux dossiers portant le même nom de site peuvent coexister dans un compte ; un transfert réussi vers le mauvais ne change pas le résultat public.

Comparez également la casse, les espaces encodés et l’extension effective. Une migration entre environnements différents peut rendre visible une différence de nom auparavant tolérée. Corrigez la source de la référence ou restaurez le nom attendu après confirmation, plutôt que de modifier tous les noms de la bibliothèque.

Si l’URL utilise un CDN, c’est-à-dire un service qui distribue les images depuis une copie intermédiaire, comparez l’adresse configurée et son origine. Une réponse 404 mémorisée peut persister après restauration. Purgez alors uniquement la ressource ou le périmètre concerné avec l’outil déjà en place, après avoir vérifié l’origine. Une purge ne remplace pas le transfert d’un original absent.

Si une règle serveur masque le chemin, fournissez au prestataire le fichier physique confirmé et l’URL exacte. Ne remplacez pas tout le fichier de configuration du serveur ni les règles de sécurité pour cette seule observation. Les liens permanents WordPress traitent principalement les routes des contenus ; les réenregistrer n’est pas une réparation générale des fichiers statiques manquants.

Comparer l’accent stocké, l’adresse demandée et le fichier transféré

Une image peut sembler porter le même nom avant et après migration, alors que le chemin reçu par le serveur diffère. Le suivi WordPress documente un signalement de médias devenus introuvables après un transfert, avec des accents combinés sur le disque et une autre forme affichée dans l’administration. Le signalement ne suffit pas à attribuer toutes les 404 à Unicode. Sur le site déplacé, établissez d’abord trois valeurs pour la même image. Relevez le chemin stocké par WordPress, l’adresse exacte demandée par le navigateur et le nom du fichier dans le dossier de destination.

Par exemple, le nom visuellement identique café.png peut contenir un seul caractère U+00E9, ou la lettre e suivie de l’accent combiné U+0301. Les formes NFC et NFD peuvent donc produire deux segments différents. Le premier exemple donne caf%C3%A9.png dans l’URL. Le second donne cafe%CC%81.png. Le serveur décode normalement le segment de l’URL pour chercher un fichier selon ses propres règles. Un système qui compare les noms sans normaliser Unicode peut trouver l’un et répondre 404 pour l’autre. L’apparence dans un gestionnaire de fichiers ne tranche pas. Ne retirez aucun accent avant cette comparaison.

Avec le tableau de bord seul, ouvrez la fiche du média dans Médias > Bibliothèque et relevez son identifiant et son adresse. Dans les outils réseau du navigateur, récupérez la requête qui échoue. Vérifiez si elle vise l’original, une miniature dont le nom porte des dimensions ou une variante sur un autre hôte. Demandez au responsable des fichiers de vérifier le même dossier. La valeur « URL du fichier » de la fiche peut être filtrée par une extension, et elle ne remplace pas la lecture du champ enregistré.

Avec un terminal autorisé, lisez la valeur sans la modifier avec wp --path="/chemin/recette" --url="https://recette.example.test" post meta get 123 _wp_attached_file. Remplacez 123 par l’identifiant du média. Dans une installation ordinaire, cette valeur est relative au dossier des téléversements, par exemple 2024/08/café.png. Vérifiez séparément le dossier année et mois et le chemin de base du site ou du stockage. Pour une miniature, relevez également le nom dérivé demandé par le navigateur et les tailles décrites dans les métadonnées du média. Comparer l’original à une miniature ne permet pas de conclure que le transfert de l’original est fautif.

Placez le script ci-dessous dans un dossier de travail et exécutez-le avec Python. Donnez-lui le dossier de destination déjà vérifié, le chemin stocké et l’URL de la requête qui échoue. Par exemple, utilisez python verifier-nom-media.py "/chemin/uploads/2024/08" "2024/08/café.png" "https://recette.example.test/wp-content/uploads/2024/08/caf%C3%A9.png". Sur un stockage distant, demandez l’inventaire des noms à l’opérateur ou téléchargez une copie de ce seul dossier avec un outil qui conserve les noms. Vérifiez que l’outil de copie ne les a pas normalisés. Le script lit le dossier choisi et compare les derniers segments. Il ne contacte pas l’URL.

Le script décode les pourcentages une seule fois. Si le résultat contient littéralement %C3%A9, il peut y avoir un double encodage, sauf si le nom sur disque contient ces caractères littéraux. Un signe + dans un chemin reste un signe plus. Le champ UTF-8 montre les octets de la chaîne encodée pour la comparaison. Il ne décrit pas le format interne du disque. Le rapprochement NFC et la casse servent à repérer des candidats. Les champs « exact » comparent les chaînes originales et aident à choisir le nom à vérifier. Si plusieurs candidats ressortent, comparez leur contenu ou une empreinte avant toute correction.

import argparse
import json
from pathlib import Path, PurePosixPath
from unicodedata import normalize
from urllib.parse import quote, unquote, urlsplit

parser = argparse.ArgumentParser()
parser.add_argument("dossier", type=Path)
parser.add_argument("chemin_stocke")
parser.add_argument("url")
args = parser.parse_args()

stocke = PurePosixPath(args.chemin_stocke).name
segment = urlsplit(args.url).path.rsplit("/", 1)[-1]
try:
    demande = unquote(segment, encoding="utf-8", errors="strict")
except UnicodeDecodeError:
    parser.error("Le dernier segment ne se decode pas en UTF-8.")
if not demande or "/" in demande or "\\" in demande:
    parser.error("Utilisez l'URL du fichier, avec un dernier segment valide.")

def cle(nom):
    return normalize("NFC", nom).casefold()

def fiche(nom):
    return {
        "nom": nom,
        "points": [f"U+{ord(c):04X}" for c in nom],
        "utf8": nom.encode("utf-8").hex(" "),
        "segment_encode": quote(nom, safe=""),
    }

candidats = sorted(
    chemin.name for chemin in args.dossier.iterdir()
    if chemin.is_file() and cle(chemin.name) in {cle(stocke), cle(demande)}
)
print(json.dumps({
    "stocke": fiche(stocke),
    "demande": fiche(demande),
    "stocke_egale_demande": stocke == demande,
    "stocke_exact_sur_disque": stocke in candidats,
    "demande_exacte_sur_disque": demande in candidats,
    "candidats": [fiche(nom) for nom in candidats],
}, ensure_ascii=True, indent=2))

Corriger une seule divergence confirmée

Si la requête décodée et la référence stockée correspondent, mais que le fichier transféré porte une autre forme, privilégiez la récupération de l’original sous le nom exact attendu dans le dossier de recette. Conservez une copie des deux formes si elles existent et vérifiez qu’elles ne désignent pas des images différentes. Rétablir le nom attendu peut éviter une modification du média et de toutes ses références. Si le serveur de destination ne peut pas conserver ce nom, créez une copie avec un nom stable via la médiathèque ou la méthode approuvée pour le stockage, puis remplacez les références identifiées. Gardez l’ancien média jusqu’à ce que les liens et les variantes soient vérifiés.

Si le nom exact existe sur disque mais que l’adresse publique en demande une autre, corrigez d’abord la source de cette URL. Le défaut peut se trouver dans le bloc, une variante du cache, un constructeur de pages ou une réécriture du CDN. Une adresse en %25 peut être le résultat d’un second encodage. Le renommage du fichier sur disque déplacerait alors le problème. Vérifiez le domaine, la base des téléversements et le chemin réel avant d’éditer les données. Si l’original s’affiche mais qu’une taille précise donne 404, traitez la variante et contrôlez sa présence dans les métadonnées. Ne remplacez pas toutes les occurrences du nom dans la base pour résoudre un seul témoin.

1. Sur la copie, notez le champ enregistré, le chemin envoyé et les octets du nom trouvé. Conservez le fichier d’origine et les références qui le désignent.
2. Rétablissez un seul fichier ou corrigez une seule référence. Vérifiez la réponse du navigateur et le contenu de l’image sur l’original et sur une taille dérivée réellement utilisée.
3. Si une correction ne rétablit pas ces deux témoins, remettez le fichier ou la référence précédente. Reprenez la comparaison à l’origine et au niveau du cache avant d’élargir le traitement.

Approche 2 : corriger une référence isolée dans l’éditeur

Cette approche convient lorsque quelques blocs pointent encore vers l’ancienne adresse et que le bon média existe déjà dans la nouvelle bibliothèque. Elle demande le droit d’éditer les contenus concernés. Notez la page, l’ancienne URL et le média choisi avant modification ; gardez aussi les textes alternatifs, la légende et un éventuel lien appliqué à l’image.

Dans Pages ou Articles, ouvrez le contenu puis sélectionnez le bloc Image concerné. Utilisez Remplacer → Médiathèque pour sélectionner le média vérifié. Dans les interfaces récentes, le panneau Contenu du bloc propose aussi le choix du média. Prévisualisez le résultat avant d’enregistrer. Ce remplacement porte sur ce bloc : il ne corrige pas automatiquement les autres pages utilisant la même ancienne adresse.

Vérifiez le cadrage, la résolution, le texte alternatif et la destination du clic après remplacement. Un visuel semblable n’est pas nécessairement le même document, notamment dans un catalogue ou un portfolio. Si le média n’est pas dans la bibliothèque mais que ses fichiers ont été copiés, examinez les données de migration avant de créer une nouvelle fiche.

Pour revenir en arrière, rétablissez la référence et les réglages conservés, ou la révision de contenu appropriée sans perdre d’autres modifications récentes. Si des centaines de pages gardent le même ancien préfixe, arrêtez les corrections manuelles répétitives et préparez un remplacement ciblé. Le choix entre les deux méthodes dépend du nombre de références et de leur origine, pas du seul nombre d’images visibles.

Approche 3 : préparer un remplacement d’anciennes adresses en nombre

Ce parcours convient à de nombreuses références qui partagent un ancien préfixe confirmé. Il ne répare pas des fichiers absents. Avant de l’utiliser, ouvrez plusieurs adresses de destination dans le nouvel environnement et vérifiez les fichiers. La transformation doit avoir un sens identique pour tout le périmètre retenu.

Par exemple, rechercher https://ancien.exemple/site/wp-content/uploads/ et remplacer par https://nouveau.exemple/wp-content/uploads/ peut convenir si cette correspondance a été confirmée. Ces domaines sont fictifs. Adaptez les deux chaînes entières, y compris un éventuel sous-dossier et la barre finale. Une recherche du seul mot « ancien » pourrait modifier des textes sans rapport.

WordPress peut conserver des valeurs sous une forme sérialisée, avec des longueurs enregistrées. Un remplacement SQL naïf ou une édition globale du fichier exporté peut casser ces données. Utilisez un outil qui comprend cette structure, puis vérifiez le résultat. Cela ne garantit pas qu’une chaîne mal choisie soit sans conséquence.

Identifiez également les tables concernées. Les contenus et les réglages d’une extension ne se trouvent pas nécessairement dans la même table. Ne sélectionnez pas toutes les bases du compte par commodité. Si vous ne pouvez pas justifier la liste, faites-la établir sur la copie de travail par la personne chargée de la migration. Une sauvegarde restaurable doit précéder toute écriture réelle.

Simuler avec Better Search Replace dans l’administration

Sans terminal, Better Search Replace de WP Engine fournit ce remplacement compatible avec les données sérialisées. La version gratuite 1.4.11 demande WordPress 6.2 et PHP 8.1 au minimum ; sa fiche est déclarée testée jusqu’à WordPress 7.1.4. Vérifiez les prérequis de la version effectivement proposée. Cette fonction gratuite suffit au parcours décrit.

Installez l’extension depuis Extensions → Ajouter une extension, en confirmant le nom et l’auteur, puis ouvrez Outils → Better Search Replace. Le menu de l’édition gratuite ne porte pas le suffixe Pro. Sur un réseau, faites intervenir l’administrateur pour sélectionner les bonnes tables et le sous-site concerné.

La simulation indique des correspondances et des totaux. Elle ne fournit pas dans l’édition gratuite l’aperçu détaillé avant/après réservé à Pro. Un nombre plausible ne valide donc pas chaque changement. Faites contrôler le contenu représentatif sur la copie, avec le périmètre préparé.

1. Dans Search for, collez le préfixe ancien exact ; dans Replace with, collez sa destination vérifiée.
2. Dans Select tables, choisissez seulement les tables validées. Utilisez Ctrl-clic sous Windows ou Cmd-clic sous macOS pour une sélection multiple.
3. Laissez Case-Insensitive décoché pour préserver la distinction de casse de cet essai ciblé.
4. Laissez Replace GUIDs décoché : les identifiants permanents ne sont pas les liens d’image à réécrire.
5. Gardez Run as dry run coché puis lancez Run Search/Replace. Conservez le rapport et examinez les tables où des correspondances ont été trouvées avant de décider d’une écriture.

Appliquer la simulation validée et prévoir un vrai retour arrière

Si la simulation ne trouve rien, n’élargissez pas immédiatement la recherche au domaine entier. La référence peut être dans un fichier CSS, un réglage de constructeur, une forme encodée ou le cache d’une page. Revenez à la requête et à son origine. Si le rapport touche des tables inattendues ou un volume disproportionné, corrigez le périmètre sur la copie.

Après validation sur cette copie, reprenez exactement les chaînes et les tables retenues sur le site visé. Vérifiez une dernière fois le domaine du tableau de bord et la fraîcheur de la sauvegarde. Décochez seulement Run as dry run, puis lancez le remplacement. Attendez le compte rendu et notez tout échec ou arrêt partiel avant une nouvelle tentative.

Le résultat attendu est la demande de la nouvelle adresse et l’affichage du fichier sur les pages témoins. Une opération terminée sans erreur ne prouve pas que toutes les variantes ou références d’un constructeur sont corrigées. Examinez ces cas séparément au lieu de répéter automatiquement le remplacement.

Pour annuler une écriture incorrecte, utilisez la restauration préparée du périmètre concerné. Un remplacement inverse n’est pas un retour arrière fiable : il peut toucher des valeurs qui étaient déjà correctes avant votre intervention. Une restauration de base peut aussi écraser de nouveaux contenus ou commandes ; faites coordonner son moment et sa portée si le site reçoit des écritures. Désactiver ensuite Better Search Replace n’annule aucun changement de base déjà enregistré.

Alternative avec WP-CLI si un accès SSH existe déjà

Cette alternative au même remplacement demande WP-CLI installé, un accès autorisé et le répertoire de la bonne installation. Elle n’est pas nécessaire au parcours dans l’administration. L’exemple simule uniquement une recherche littérale dans deux tables illustratives ; remplacez les URL et les noms de tables par le périmètre validé, dont le préfixe peut différer de wp_.

--dry-run empêche l’écriture. --skip-columns=guid préserve les colonnes d’identifiants ; --report-changed-only réduit le rapport aux champs concernés. La commande gère les données sérialisées. Elle ne corrige pas des fichiers CSS ni un stockage absent.

Ne retirez --dry-run qu’après validation sur copie et préparation du retour arrière décrit précédemment. Sur un réseau, faites sélectionner explicitement le sous-site avec --url et ses tables ; ne généralisez pas avec --network ou toutes les tables du serveur. Conservez le rapport dans un emplacement privé et contrôlez ensuite les pages.

wp search-replace 'https://ancien.exemple/site/wp-content/uploads/' 'https://nouveau.exemple/wp-content/uploads/' wp_posts wp_postmeta --skip-columns=guid --report-changed-only --dry-run

Vérifier les variantes, les fonds et les images externalisées

Une image peut fonctionner sur ordinateur et échouer sur téléphone parce que le navigateur choisit une autre taille. WordPress peut produire plusieurs URL candidates dans srcset. La propriété currentSrc d’une image indique la candidate choisie, sans garantir que son chargement réussit. Le statut réseau et le contenu de la réponse restent nécessaires.

Rechargez donc la page à plusieurs largeurs et comparez les requêtes réellement effectuées. Si l’original fonctionne mais qu’une variante manque, ne remplacez pas toutes les URL par celle de l’original. Vérifiez d’abord si la variante a été transférée, puis suivez la génération ciblée des tailles manquantes à partir d’une source disponible. Conservez les anciennes tailles encore utilisées avant tout nettoyage.

Une image de fond peut provenir d’une feuille CSS, et non d’un bloc Image. Si la requête révèle une ancienne adresse dans ce fichier, corrigez le réglage qui le génère ou le fichier personnalisé identifié, avec sa copie préalable. Un remplacement en base ne modifie pas automatiquement un fichier statique. Régénérez ensuite les fichiers dérivés seulement avec la procédure du composant déjà utilisé.

Pour un stockage externe, la présence du fichier local n’établit pas celle de l’objet distant ou de ses variantes. Faites vérifier le bon espace, le chemin et les droits prévus par l’intégration. Ne recopiez pas toute une bibliothèque vers un nouveau service simplement parce qu’un domaine intermédiaire répond 404. Vous risqueriez de changer l’architecture sans corriger la correspondance initiale.

Contrôler les pages témoins avant de clore la migration

Après une correction, vérifiez la page d’accueil, un ancien article, une page récente et une page contenant plusieurs tailles d’image. Ouvrez les fichiers témoins directement, puis leur rendu dans les pages à plusieurs largeurs. Sur un contenu destiné au public, comparez aussi une session déconnectée sans contourner les protections de médias privés.

Contrôlez le statut et le contenu réel de chaque réponse. Une page qui paraît réparée grâce au cache du navigateur ne démontre pas que la nouvelle origine fournit les fichiers. Rechargez avec les outils réseau ouverts et, si nécessaire, le cache navigateur désactivé le temps du contrôle. Cela ne purge pas les caches serveur ou CDN.

Gardez une liste des corrections retenues : fichiers récupérés, préfixes remplacés, tables concernées et réglages d’origine modifiés. Notez aussi les cas restant en échec. Si la panne touche uniquement des variantes ou un composant externe, transmettez ce périmètre précis au responsable concerné avec les URL et heures de contrôle.

Conservez la sauvegarde de migration jusqu’à validation de cet échantillon et des usages importants. Ne supprimez pas l’ancien hébergement tant qu’il représente votre seule source récupérable de médias. Après résolution, incluez dans vos prochains contrôles de migration des fichiers anciens et récents, les tailles adaptatives et les fonds CSS : une vérification de la seule page d’accueil peut manquer une partie du défaut.