On observe ici un antipatron de configuration très répandu : un développeur ajoute un shortcode [organization_schema] dans le fichier footer.php d’un thème, pensant simplifier la maintenance du balisage structuré de l’entreprise. Ce shortcode génère un bloc <script type="application/ld+json"> décrivant l’organisation — nom, logo, adresse, réseaux sociaux — et fonctionne parfaitement… sur chaque page du site, sans distinction. Une fiche produit, un article de blog, une page de contact : chacune reçoit une copie strictement identique de ce même balisage.
Pourquoi c’est un problème : le balisage Organization a vocation à décrire une entité unique, l’entreprise elle-même, et non à être répété page après page. Le répéter sur des dizaines de milliers d’URL n’apporte aucune information supplémentaire à Google — l’entité reste la même — mais alourdit chaque page de plusieurs centaines d’octets de code inutile, et complique l’analyse du site par les outils de test de données structurées, qui remontent alors des dizaines de milliers de blocs identiques au lieu d’un seul.
Comment le shortcode a été construit
Le code du shortcode, enregistré via add_shortcode( 'organization_schema', 'generer_balisage_organisation' ), appelait une fonction qui construisait un tableau PHP puis l’encodait avec wp_json_encode() avant de l’échapper dans une balise script. Rien, dans cette fonction, ne vérifiait le contexte d’appel : elle produisait sa sortie identique quel que soit le gabarit qui l’invoquait.
Le vrai souci ne résidait donc pas dans le shortcode lui-même, correctement écrit sur le plan technique, mais dans son placement : un footer global inclus par get_footer() sur l’intégralité des templates du thème, ce qui garantissait son exécution sur chaque requête, y compris sur les pages de résultats de recherche interne et les archives d’auteur.
Pourquoi ce n’est pas un balisage Product mal placé
Ce cas se distingue clairement d’une erreur de balisage Product injecté par erreur sur des pages non marchandes : ici, le balisage est correctement typé et cohérent avec son sujet, l’organisation. Le défaut ne porte pas sur le contenu du balisage mais sur sa fréquence de répétition, une nuance qui échappe souvent à un audit rapide limité au test de résultats enrichis.
Ce qu’il fallait faire
Le balisage Organization ne devait être injecté qu’une seule fois par chargement de page, et de préférence uniquement sur les gabarits où il a une utilité réelle pour le moteur de recherche :
- Conditionner l’appel avec
is_front_page()pour ne générer le bloc que sur la page d’accueil, seul endroit où l’entité globale du site mérite d’être réaffirmée. - Retirer l’appel du fichier
footer.phpglobal et le déplacer dans le fichier de gabarit spécifique à la page d’accueil. - Vérifier après correction, avec l’outil de test de résultats enrichis de Google, qu’une seule occurrence du bloc
Organizationsubsiste sur le site.
Mesurer l’ampleur avant de corriger
Un simple export du sitemap combiné à une requête sur un échantillon de pages permet d’estimer le volume concerné avant toute intervention :
curl -s https://exemple.fr/sitemap.xml | grep -c '<loc>'
Sur le site concerné, ce comptage annonçait environ quarante mille URL, autant d’occurrences potentielles du même bloc JSON-LD répété sans variation.
Un balisage structuré correct sur le fond peut rester un antipatron sur la forme. Se demander une seule fois « où » suffit souvent à corriger ce que le test de validation ne signale jamais comme une erreur.
Notre verdict
Le balisage Organization se pense au niveau du site, pas au niveau du gabarit. Un footer global reste le pire endroit possible pour l’injecter, précisément parce qu’il s’exécute partout sans discernement. Limiter sa présence à la page d’accueil suffit à préserver sa valeur sans alourdir inutilement le reste du site.
