Pour travailler les images de ses articles, elle doit examiner ce qui sort réellement du site : le fichier proposé, son cadrage et les instructions qui autorisent son aperçu. Ce contrôle peut améliorer la préparation des pages. Il ne permet pas de réserver une place dans Discover, ni de prévoir les visites que le média en recevra.
La méthode proposée ici part d’un petit ensemble d’articles représentatifs. Elle sert à répartir le travail entre la rédaction et la personne qui maintient le CMS, puis à distinguer les corrections constatées des résultats encore inconnus.
L’image choisie dans le CMS et le fichier proposé à Google
Google rend automatiquement éligibles à Discover les contenus indexés qui respectent ses règles, sans exiger de balisage spécial. L’éligibilité ne garantit pas l’apparition. Conditions décrites par Google.
Cette distinction évite une mauvaise entrée dans le diagnostic. Un article sans visites Discover n’a pas nécessairement un problème d’image. Une rédaction peut néanmoins vérifier son fichier, comme elle vérifierait un lien dans un post : parce que cet élément doit être correct, quel que soit le volume de diffusion obtenu ensuite.
Dans notre exemple fictif, la photothèque contient un original de 2 400 pixels de large, mais les informations de partage désignent une miniature de 600 pixels. Les deux collègues qui examinent le dossier peuvent donc avoir raison : l’un voit une grande image dans le CMS, l’autre constate une petite image à l’adresse proposée. Ils ne regardent pas le même fichier.
La demande au responsable du site gagne à contenir l’adresse exacte de l’article, la photo attendue et le fichier actuellement déclaré. « Discover ne marche pas » laisse trop de causes possibles. « Cette page propose cette miniature alors que nous avons retenu cet original » permet de retrouver le défaut. Il reste ensuite à déterminer si la correction concerne cet article seul ou tout un modèle de page.
Pour constituer l’échantillon, une rédaction peut retenir un reportage photographique, une interview avec portrait et un article dont le visuel est fourni par un partenaire. Ce sont des cas de travail proposés, pas un échantillon statistique. Leur intérêt est de faire apparaître plusieurs chemins de production : fichier original, recadrage éditorial, image déjà préparée ailleurs.
Des dimensions suffisantes, avec un cadrage qui raconte le bon sujet
La documentation Discover recommande au moins 1 200 pixels de largeur, plus de 300 000 pixels au total et un ratio 16:9. Elle conseille une image représentative, peu chargée en texte, plutôt qu’un logo générique. Google peut recadrer le visuel ; le fichier désigné par og:image ou par les données structurées peut influencer son choix de vignette. Spécifications des images pour Discover.
Ces indications donnent des critères de préparation, sans former une recette de classement. Pour connaître le nombre total de pixels, on multiplie la largeur par la hauteur : un fichier de 1 280 par 720 atteint 921 600 pixels. Ce calcul valide une dimension. Il ne dit pas si la photographie explique le sujet, si elle est nette ou si le recadrage conserve ce que l’auteur voulait montrer.
Imaginons un article consacré à la restauration d’un théâtre. Sur la photographie originale, l’échafaudage occupe un côté de la scène ; le cadrage serré ne montre plus que le décor rénové. Le lecteur peut croire que les travaux sont terminés alors que l’article explique ce qui reste à faire. Agrandir le fichier ne résout pas ce problème. Une autre sélection, ou un cadrage moins serré, peut mieux accompagner le texte.
Le portrait pose une autre difficulté : une personne identifiable dans la verticale peut devenir presque absente d’un export horizontal. Il vaut mieux examiner cet export avant de le retenir que demander au CMS de couper systématiquement toutes les images de la même façon. Si le cliché ne se prête pas à l’usage prévu, le dossier photographique peut offrir une alternative. À défaut, la rédaction doit accepter les limites de ce qu’elle possède.
L’examen à petite taille est utile ici. Il permet de constater qu’un détail disparaît, qu’une expression change de portée ou que plusieurs personnes ne sont plus distinguables. Il ne simule pas exactement l’affichage futur de Discover. Le résultat attendu reste une décision éditoriale sur le fichier choisi, accompagnée d’une légende exacte dans l’article.
Une carte sociale peut avoir une autre fonction
Un média peut fabriquer pour Instagram une carte qui reprend une phrase de l’entretien. Le même article peut utiliser sur le site le portrait de la personne interrogée. Ces deux images répondent à des usages différents ; rien n’oblige la rédaction à les confondre dans sa préparation.
La distinction doit toutefois être claire pour ceux qui déposent les fichiers. Si le champ destiné à l’image de l’article reçoit par habitude la dernière carte sociale produite, un visuel très chargé peut se retrouver proposé ailleurs. Le problème vient alors du circuit éditorial : le nom du fichier, le champ rempli ou la consigne transmise ne permet pas de savoir quelle version sert à quoi.
Une note dans la fiche article peut suffire. Elle identifie la photographie retenue pour la page, sa légende et, lorsqu’il existe, le visuel préparé séparément pour un réseau. Le degré de détail dépend de l’organisation. Une petite rédaction n’a pas besoin d’un nouvel outil pour distinguer deux fichiers ; elle a besoin que la personne qui prend la suite retrouve le choix sans demander à son auteur.
Cette préparation aide aussi à isoler les incidents. Un mauvais aperçu sur Facebook ou LinkedIn demande son propre diagnostic : quelle page a été consultée, quelle information de partage y figurait et quel rendu demeure visible ? Le guide Corriger un aperçu de lien sur Facebook et LinkedIn détaille ce parcours. Un aperçu corrigé sur l’un de ces réseaux ne constitue pas une preuve d’apparition dans Discover.
EditoRelay intervient dans la préparation et la diffusion des relais sociaux d’un article. Il ne règle pas les images déclarées par votre CMS à Google et ne pilote pas Discover. Son périmètre produit permet de situer ce travail : la vérification du site reste à organiser avec la personne qui le maintient.
L’autorisation d’un grand aperçu se vérifie sur la page servie
La directive max-image-preview:large autorise un grand aperçu. Les valeurs standard et none limitent autrement cet affichage. Cette autorisation ne fabrique pas une image de meilleure résolution et ne force pas Google à sélectionner le fichier. Référence Google des directives robots.
Le responsable du site peut vérifier les instructions effectivement présentes sur les pages choisies. Il lui appartient aussi de repérer d’éventuelles règles contradictoires : Google explique que plusieurs restrictions peuvent se combiner et que certaines instructions passent par les en-têtes HTTP. Le nom d’une option dans le CMS ne remplace donc pas l’examen de ce que le serveur renvoie. Interprétation des règles combinées.
Pour la rédaction, le livrable peut rester très simple : l’adresse examinée, le fichier retenu, le défaut trouvé et la correction constatée. Elle n’a pas à apprendre la configuration du serveur pour fournir les bons exemples. En revanche, elle doit signaler si une photo ne peut pas être utilisée dans ce contexte, au lieu de laisser une validation technique tenir lieu de décision sur le visuel.
La recette mérite de couvrir les modèles réellement utilisés. Corriger le modèle « article » ne prouve pas que le modèle « dossier » expose les mêmes informations. Après une modification commune, un article déjà en ligne et un nouvel article permettent de vérifier deux chemins : la mise à jour d’une page existante et la création depuis le CMS. Cette proposition de contrôle ne vaut pas audit exhaustif du site.
Le même raisonnement s’applique aux fichiers remplacés. Si l’équipe fournit une nouvelle photo, le compte rendu doit préciser quelle adresse la désigne désormais. Une capture du CMS montre ce qui a été saisi ; l’ouverture de la page et du fichier déclaré montre ce qui est accessible au moment du contrôle. Les deux observations sont utiles, mais elles ne prouvent pas la même chose.
Ce que les données Discover permettront d’observer
Le rapport Discover de Search Console devient visible après un minimum d’impressions. Ses données par page sont attribuées à l’URL canonique, et les valeurs les plus récentes peuvent être provisoires. Le trafic de cette surface est aussi moins prévisible que celui de la recherche par requête. Périmètre et limites du rapport Discover.
Si le rapport n’est pas disponible, la rédaction peut terminer le contrôle des fichiers sans inventer de bilan d’audience. Elle saura quelles images ont changé et quelles pages ont été vérifiées. Elle ne saura pas déduire de cette absence un verdict individuel sur chaque article.
Lorsque les données existent, la date de modification devient un repère utile. Encore faut-il noter ce qui a changé : image seule, titre également, contenu enrichi, nouvel événement autour du sujet. Une hausse observée après un recadrage ne permet pas d’attribuer cette hausse au recadrage si plusieurs conditions ont évolué. Même en ne modifiant qu’une image, cette observation ne constitue pas une expérience contrôlée.
Un bilan de travail peut associer les URL corrigées aux périodes entièrement disponibles dans le rapport. Les impressions indiquent une exposition comptabilisée ; les clics ne décrivent pas à eux seuls la lecture qui suit. Pour les autres canaux, le guide Mesurer le trafic envoyé vers ses articles aide à conserver des périmètres de mesure distincts.
Le compte rendu peut d’abord confirmer les fichiers et les instructions trouvés sur les pages retenues. Les données de diffusion viennent ensuite, lorsqu’elles existent. Si un modèle de page produit encore une miniature inadaptée, la prochaine action est déjà connue, même sans courbe Discover à commenter.
Sources officielles
Documents utilisés pour vérifier les points techniques de cet article.