Les structured data alourdissent-elles vos pages au point de nuire au SEO ?

Pourquoi Google évoque-t-il le poids des structured data maintenant ?

La déclaration de Martin Splitt intervient dans un contexte où les Core Web Vitals pèsent lourd dans l'évaluation UX. Beaucoup de sites empilent les markups Schema.org (Product, Article, FAQ, HowTo, BreadcrumbList, Organization, etc.) sans mesurer l'impact sur la taille HTML.

Le problème : ces données sont destinées aux machines, pas aux humains. Elles n'affichent rien à l'écran mais gonflent le code source. Un JSON-LD de FAQ détaillée peut facilement ajouter 20 à 50 Ko, et quand on multiplie les types, on dépasse vite les 100 Ko rien qu'en structured data.

Est-ce que cela impacte réellement le crawl et l'indexation ?

Oui, de deux manières. D'abord, un HTML lourd ralentit le parsing côté Googlebot — plus de ressources CPU pour extraire le contenu utile. Ensuite, si la page dépasse les seuils de taille que Google tolère (officiellement ~15 Mo, mais en pratique les problèmes commencent bien avant), certaines portions peuvent être tronquées.

Soyons honnêtes : la plupart des sites ne frôlent pas ces limites. Mais sur des pages riches (e-commerce avec variantes produit, articles longs avec FAQ et HowTo imbriqués), l'accumulation devient critique.

Que signifie « Google supporte de nombreux types de structured data » dans ce contexte ?

C'est un rappel implicite : Google offre la possibilité d'enrichir vos pages avec plusieurs dizaines de types de markup. Mais ce n'est pas parce qu'un type est supporté qu'il faut l'implémenter systématiquement.

Chaque markup doit répondre à un objectif business ou SEO précis (rich snippet, Knowledge Graph, éligibilité à un carrousel). Empiler des structured data « au cas où » est contre-productif si ça plombe la performance.

• Poids HTML : les structured data s'ajoutent au code source, invisibles pour l'utilisateur mais lues par les bots
• Arbitrage nécessaire : prioriser les markups qui génèrent réellement des features SERP (étoiles, FAQ accordéon, breadcrumb, etc.)
• Parsing Googlebot : un HTML gonflé ralentit l'extraction du contenu utile et peut impacter le crawl budget sur des gros sites
• Core Web Vitals : un HTML lourd peut indirectement dégrader le LCP si le navigateur met plus de temps à construire le DOM

Cette déclaration est-elle cohérente avec les observations terrain ?

Absolument. J'ai vu des pages e-commerce avec 5 à 7 types de structured data simultanés : Product, Offer, AggregateRating, Review, BreadcrumbList, Organization, WebSite. Résultat : 80 à 120 Ko rien qu'en JSON-LD, sur des pages qui affichent 3 lignes de texte produit.

Le paradoxe ? Ces mêmes sites se battent pour optimiser les images et réduire le JS tiers, mais laissent exploser le HTML avec des markups redondants ou mal ciblés. Google le dit poliment, mais le message est clair : faites le ménage.

Dans quels cas cette règle devient-elle vraiment problématique ?

Trois scénarios classiques. Les sites e-commerce qui dupliquent les infos produit dans plusieurs formats (Microdata + JSON-LD, ou JSON-LD Product + Offer séparés alors qu'ils pourraient être imbriqués). Les blogs qui ajoutent FAQ + HowTo + Article + BreadcrumbList sur chaque page, même quand le contenu ne justifie pas tous ces types.

Et c'est là que ça coince : les générateurs automatiques de structured data (plugins, CMS) empilent par défaut sans logique. J'ai vu des pages avec un markup HowTo vide (balises step sans contenu réel) juste « parce que le plugin le propose ».

Quelles nuances faut-il apporter à cette affirmation ?

Martin Splitt parle de « poids HTML », mais il faut distinguer deux problèmes. Le poids brut (Ko transférés sur le réseau) et la complexité du DOM (nombre de nœuds à parser). Un JSON-LD de 50 Ko bien structuré est moins problématique qu'un HTML de 50 Ko bourré de tableaux imbriqués.

Deuxième nuance : tous les types de markup ne se valent pas. Un BreadcrumbList de 2 Ko est négligeable et apporte un vrai bénéfice UX (fil d'Ariane en SERP). Un Review markup de 40 Ko avec 200 avis détaillés est questionnaire — Google n'affiche que les premiers avis agrégés de toute façon.

[A vérifier] : Google n'a jamais publié de seuil officiel « acceptable » pour la taille des structured data. On sait que le HTML total ne doit pas dépasser ~15 Mo, mais en pratique, dès 500 Ko de HTML, des symptômes apparaissent (indexation partielle, lenteur de crawl). Donc viser < 200 Ko de HTML total reste une bonne pratique, structured data comprises.

Comment auditer le poids des structured data sur votre site ?

Première étape : mesurez. Utilisez l'inspecteur réseau de votre navigateur (onglet Network, filtre Doc) pour voir la taille HTML brute de vos pages stratégiques. Ensuite, copiez le code source et isolez les blocs JSON-LD ou Microdata — un simple Ctrl+F sur application/ld+json révèle l'ampleur.

Vous pouvez scripter ça avec Screaming Frog (extraction custom via XPath) ou un crawler Python. L'objectif : identifier les pages où les structured data représentent > 20 % du HTML total. C'est souvent le signe d'un déséquilibre.

Quels markups garder, lesquels supprimer ?

Règle simple : gardez ce qui génère un affichage visible en SERP. Les étoiles produit (AggregateRating), le fil d'Ariane (BreadcrumbList), les FAQ accordéons, les recettes enrichies. Virez ce qui ne sert qu'à « nourrir le Knowledge Graph » sans retour visible — ou testez en A/B si vous avez le trafic.

Exemple concret : un site média avec Article + FAQPage + HowTo sur chaque article. Si Google n'affiche jamais le HowTo en rich snippet après 3 mois, supprimez-le. Vous gagnerez 15-30 Ko par page, soit un gain cumulé énorme sur 10 000 articles.

• Auditer la taille HTML de vos pages clés et mesurer la part des structured data
• Prioriser les markups qui génèrent des features SERP mesurables (étoiles, FAQ, breadcrumb)
• Supprimer ou condenser les markups redondants (ex : Offer et Product séparés alors qu'on peut imbriquer)
• Tester la validité avec le Rich Results Test de Google après chaque modification
• Monitorer l'évolution des Core Web Vitals (LCP notamment) après allègement du HTML
• Documenter les types de markup utilisés par template (page produit, article, catégorie) pour éviter l'empilement anarchique