Plus tôt cette année à SMX Advanced, j’ai présenté les résultats de notre laboratoire de test Peak Ace. Ces tests ont mis en lumière plusieurs points techniques de mise en œuvre et comment Googlebot les traiterait.
L’un de mes tests préférés a examiné l’indexation par Google des URL iFramed et de leur contenu. Dans ma présentation SMX Advanced, j’ai abordé divers scénarios pouvant amener Google à indexer le contenu d’un iFrame, tout en « attribuant » ce contenu à son URL parent.

L’URL parent peut, dans certains cas, classer le contenu qui n’existe que dans l’URL iFramed et non dans l’URL parent.

Naturellement, cela a excité les gens – et toutes sortes de questions de suivi se sont posées. En voici quelques-uns avec mes réponses.
Dans le test iFrame, le contenu iFramed provenait-il du même domaine ou d’un domaine différent ?
Mon exemple a montré deux URL qui vivent sur le même domaine : domain.com/test.html
serait iFrame domain.com/tobeframedA.html
pour que test.html
pourrait se classer pour le contenu qui n’existe que dans tobeframedA.html
.
La même chose fonctionne aussi pour externaldomain.com/tobeframedB.html
– ce qui peut encore causer test.html
pour classer le contenu uniquement présent dans tobeframedB.html
, ainsi que pour les iFrames résidant sur des sous-domaines. Nous avons testé toutes les combinaisons auxquelles nous pouvions penser et avons conclu que cela ne faisait aucune différence là où le contenu iFrame était hébergé.
Si vous souhaitez empêcher quelqu’un de charger (et de classer) votre contenu dans un iFrame, ce serait une bonne idée de regarder dans l’en-tête X-Frame-Options. Cela indique si un navigateur doit être autorisé à rendre une page dans un iFrame.
Si nous devions utiliser des iFrames avec une page de contenu non indexée, la page parent serait-elle toujours classée pour le contenu répertorié dans le but d’améliorer la vitesse de la page ?
Dès que l’URL iFramed contient une directive noindex meta robots, l’URL parent ne pourra pas se classer pour le contenu de l’URL iFramed.

Il en va de même si vous iFramez une URL qui serait servie avec une directive d’en-tête X-Robots noindex ou qui est activement bloquée à l’aide de robots.txt.
En ce qui concerne la vitesse de la page, les iFrames prennent en charge le loading="lazy"
, qui retarderait le chargement des iFrames hors écran jusqu’à ce qu’un utilisateur défile à proximité. Il s’agit d’une solution élégante pour accélérer les temps de chargement des URL qui dépendent du contenu iFramed.
Google accorde-t-il toute sa valeur au contenu semi-caché (contenu qui vient généralement après « En savoir plus ») ?
Il ne semble pas y avoir trop d’amour pour l’utilisation de la fonctionnalité « En savoir plus » dans les rangs de Google. John Mueller a enregistré plusieurs fois ici et ici, remettant en question l’utilisation de la fonctionnalité dans son intégralité. Mueller a ajouté : « Je ne pense pas que vous verriez un changement notable et direct dans le référencement, […]”.
Lorsque nous l’avons testé, le but du test était de comprendre quelle différence la mise en œuvre technique pouvait potentiellement faire – et si, en général, le contenu derrière un « En savoir plus » serait indexé (s’il était correctement configuré).
La réponse courte : qu’il soit visible ou non, le contenu serait indexé, trouvé et renvoyé.
Cependant, le contenu qui était invisible lors du chargement n’a pas été mis en surbrillance dans l’extrait de code. L’implémentation technique n’a pas fait de différence (tant que le contenu faisait partie du DOM HTML au chargement), vous laissant libre d’utiliser display:none
, opacity:0
, visibility:hidden
, etc.
Cela dit, à mon avis, il est impossible – en raison de divers facteurs indépendants de notre volonté – de créer une configuration de test qui (y compris les résultats) pourrait fournir une réponse précise concernant la partie « pleine valeur » de la question.
Avez-vous mentionné que la duplication dans certaines zones du contenu peut être corrigée par l’implémentation CSS puisqu’elle n’est pas indexée ?
J’ai présenté un comportement que je trouve assez intéressant concernant les sélecteurs CSS. Ce qui se passe techniquement, c’est que des sélecteurs tels que ::before
crée un pseudo-élément qui est le premier enfant de l’élément sélectionné. En pratique, cela est souvent utilisé pour ajouter du contenu cosmétique à un élément HTML.
Cela pourrait également être utile d’un point de vue SEO, car Googlebot semble traiter cela de la même manière qu’il traiterait Chrome sur ordinateur de bureau/smartphone. Le DOM rendu reste inchangé (ce qui est normal puisqu’il s’agit d’une pseudo classe). Par conséquent, le contenu de ces sélecteurs ne sera pas indexé.

Ainsi, en fin de compte, vous pouvez l’utiliser pour empêcher l’indexation de certains contenus sans empêcher leur affichage sur le site Web. Peut-être devez-vous afficher certains contenus qui sont classés comme « passe-partout » (par exemple, des informations d’expédition ou des informations légales) ou vous souhaitez créer une certaine empreinte de contenu. Cela ouvre de nombreuses possibilités à explorer davantage.
Regardez : Tests techniques de référencement en 2022 : séparer les faits de la fiction
Ci-dessous la vidéo complète de ma présentation SMX Advanced.
Les opinions exprimées dans cet article sont celles de l’auteur invité et pas nécessairement Search Engine Land. Les auteurs du personnel sont répertoriés ici.