Vous exportez toutes les images d’un site WordPress de trois façons, selon votre accès. Par FTP, en récupérant le dossier wp-content/uploads où WordPress range les fichiers. Par l’API REST, qui liste les médias en données structurées. Ou par un crawl du frontend, qui télécharge les images réellement affichées avec leur texte alternatif. Cette dernière voie dépanne quand vous n’avez pas d’accès FTP ou que l’export intégré plante. Quelle que soit la méthode, deux réflexes comptent : récupérer le texte alternatif, pas seulement les fichiers, et conserver les URLs des images après la migration, pour ne pas perdre le référencement d’images. WPBuildAI parcourt le site et renvoie toutes les images avec leur texte alternatif, ordonnées.

Pourquoi le téléchargement manuel ne suffit pas

Enregistrer les images une par une depuis le navigateur paraît simple, mais ne tient pas à l’échelle. Vous y perdez un temps fou, vous oubliez fatalement des fichiers, et surtout vous ne récupérez pas le texte alternatif, qui n’est pas dans l’image mais dans la base de WordPress. Or une image sans son texte alternatif est une image appauvrie côté référencement. Il faut donc une méthode qui prenne d’un coup tous les fichiers et les informations qui vont avec, plutôt qu’un clic droit répété. C’est tout l’objet d’un export ou d’un crawl structuré.

Trois façons d’exporter la bibliothèque de médias

  • FTP. Récupérez le dossier wp-content/uploads : vous obtenez tous les fichiers, mais pas le texte alternatif, stocké à part dans la base.
  • L’API REST. L’API REST de WordPress liste les médias avec leurs informations, en données structurées.
  • Crawl du frontend. Un crawl télécharge les images affichées avec leur texte alternatif, sans accès FTP, comme dans extraire toutes les images d’un site.

Pour une migration, le crawl ou l’API a l’avantage de rapprocher chaque image de son texte alternatif et de la page qui l’utilise.

N’oubliez pas le texte alternatif

Le texte alternatif est la partie qu’on oublie le plus, et la plus précieuse pour le référencement. Il décrit l’image pour la recherche d’images et pour l’accessibilité, et vous l’avez parfois rédigé pour des centaines de fichiers. Comme il est stocké dans la base, et non dans le fichier image, un simple téléchargement par FTP le laisse derrière. Récupérez-le donc avec les images, via l’API ou le crawl, et réimportez-le dans la nouvelle plateforme. Sans cela, vos images repartent muettes et perdent leur visibilité dans la recherche d’images.

Les tailles d’images générées par WordPress

Un détail technique utile : WordPress ne stocke pas une seule image par envoi, mais plusieurs versions redimensionnées (miniature, moyenne, grande), en plus de l’originale. Le dossier uploads contient donc bien plus de fichiers que d’images réelles. À l’export, vous voulez en général l’originale de chaque image, et vous laissez la nouvelle plateforme générer ses propres tailles. Un crawl du frontend a l’avantage de prendre les images telles qu’elles sont affichées, ce qui évite de trier des dizaines de variantes inutiles. Le Web Almanac 2024 (HTTP Archive) rappelle le poids des images dans une page, d’où l’intérêt de ne garder que l’utile.

Garder les images référencées après la migration

Les images aussi ont des URLs, et ces URLs peuvent ranker dans la recherche d’images. Si la migration change l’adresse des images sans redirection, vous perdez ce trafic, exactement comme pour les pages, selon le guide de Google sur le déplacement avec changement d’URL. Le trafic étant concentré, comme le montre l’étude d’Ahrefs, quelques images bien positionnées valent la peine d’être préservées. Conservez donc les URLs d’images quand c’est possible, ou redirigez-les, et la méthode de redirection est la même que pour les pages, détaillée dans faire un plan de redirection 301.

Étapes

  1. Recensez les images affichées et leurs URLs.
  2. Choisissez la méthode : FTP, API REST, ou crawl du frontend.
  3. Téléchargez les originales avec leur texte alternatif.
  4. Réimportez dans la nouvelle plateforme, texte alternatif compris.
  5. Conservez les URLs d’images quand c’est possible, sinon redirigez en 301.
  6. Vérifiez que les images s’affichent sur les nouvelles pages.

Exemple : un blog riche en images

Prenons un blog de 300 articles, riche en illustrations, sans accès FTP au serveur. Un crawl du frontend télécharge les images affichées dans les articles, chacune avec son texte alternatif, et note sur quelle page elle apparaît, comme dans récupérer le contenu sans admin. On obtient les originales, sans les dizaines de variantes redimensionnées inutiles. À la reconstruction, les images sont réimportées avec leur texte alternatif, les URLs d’images conservées là où c’est possible, et les rares qui changent redirigées. La recherche d’images continue d’envoyer du trafic, parce que les images sont arrivées complètes, texte alternatif inclus.

Les erreurs à éviter

  • Télécharger les images une par une et y perdre un temps fou.
  • Récupérer les fichiers par FTP mais oublier le texte alternatif.
  • Exporter toutes les variantes redimensionnées au lieu des originales.
  • Changer les URLs d’images sans redirection, et perdre la recherche d’images.
  • Réimporter les images sans vérifier qu’elles s’affichent sur les nouvelles pages.

Ce qu’il faut retenir

Vous exportez toutes les images d’un site WordPress par FTP (dossier wp-content/uploads), par l’API REST, ou par un crawl du frontend qui prend les images affichées avec leur texte alternatif. Le crawl dépanne sans accès FTP ou quand l’export plante. Récupérez le texte alternatif, pas seulement les fichiers, gardez plutôt les originales que les variantes, et conservez ou redirigez les URLs d’images pour ne pas perdre le référencement d’images. WPBuildAI parcourt le site et renvoie toutes les images avec leur texte alternatif, ordonnées. Envoyez l’adresse de votre site pour une analyse gratuite.

Sans affiliation avec WordPress, Lovable, Webflow, Shopify, Wix ou Squarespace.