Techniques de camouflage SEO à éviter en 2011

Publié: 2011-01-27

Le responsable de Google Web Spam, Matt Cutts, a pris du temps loin d'Ozzie et Emmy (The Matt Cutts "Catts") à la fin de 2010 pour publier une petite friandise pour les webmasters et les SEO via Twitter, ce qui, j'en suis sûr, a ajouté à la gueule de bois pour quelques Black Hats pendant la période des fêtes.

Google va [regarder] plus sur le cloaking au premier trimestre 2011. Non seulement, le contenu de la page est important ; évitez les différents en-têtes/redirections vers Googlebot au lieu des utilisateurs.

Le cloaking est la technique utilisée pour présenter différents contenus, mises en page, fonctionnalités ou en-têtes (une page complètement différente ou des composants partiels de la page, connus sous le nom de cloaking Mosaic) à une araignée de moteur de recherche qu'au navigateur Web d'un utilisateur.

Le cloaking éthique n'est pas un "chapeau noir", cependant, dans le passé, les spammeurs ont utilisé des méthodes pour manipuler les techniques de cloaking, pour plus de clarté, appelons-le cloaking-spam, pour jouer avec l'algorithme (de Google). Ce n'est pas un phénomène nouveau. Au début, la balise meta keywords a été abusée par les spammeurs et, par conséquent, n'est plus un facteur de classement et la balise <noscript> peut également être traitée avec une certaine suspicion car elle a également été abusée dans le passé (nous devrions peut-être ouvrir un refuge pour les éléments HTML abusés….)

Tout d'abord, permettez-moi de dire que, dans la mesure du possible, évitez de vous camoufler. Le cloaking est un exercice à haut risque qui, s'il doit être mis en œuvre, doit être fait de manière éthique appropriée, en respectant les consignes aux webmasters de Google, afin de garantir que votre site Web ne soit pas pénalisé ou retiré de l'index.

Malheureusement, certains webmasters peuvent ne pas comprendre les répercussions et masquer par inadvertance du contenu, des liens ou des sites Web entiers sans même s'en rendre compte. Cet article décrit certaines des fonctionnalités courantes sur site qui peuvent être (mal) interprétées comme du cloaking-spam.

Gardez à l'esprit que Google enquête activement sur les cas de cloaking-spam et bannit les sites Web de son index. Ils surveillent également la détection des liens masqués et non naturels avec des notifications aux webmasters via les outils pour les webmasters. Google s'améliore de plus en plus dans la détection algorithmique du spam de camouflage , même la livraison IP n'est pas infaillible et bien sûr, Google encourage toujours vos concurrents à utiliser le rapport de spam s'ils détectent quelque chose de louche sur votre page.

L'identification algorithmique du cloaking-spam nécessite qu'un moteur de recherche compare une seule page Web obtenue via deux ou plusieurs mécanismes (par exemple, deux ou plusieurs plages d'adresses IP, des identifiants d'agent utilisateur ou différents niveaux de fonctionnalité HTML/JavaScript). Microsoft a déposé un brevet fin 2006 revendiquant un système qui facilite la détection d'une page Web masquée.

Naturellement, cela conduit à la question suivante : comment un moteur de recherche pourrait-il rassembler et analyser les deux exemples d'une page Web à des fins de comparaison ? Certaines méthodes peuvent inclure :

  • Différenciation partielle du contenu, à l'aide de l'analyse des sujets de contenu, de la segmentation des pages, de l'analyse sémantique latente (LSA), de l'utilisation des mots clés, des liens sur la page et d'autres facteurs sur la page
  • Différentes adresses IP / plages IP ou proxys distincts pour analyser le spam Web
  • Différents agents utilisateurs (par exemple, utilisez un agent utilisateur de navigateur pour vérifier le contenu masqué)
  • Rapports de spam de la communauté des webmasters
  • Tests utilisateurs
  • Analyse de plus de 5 redirections enchaînées pour vérifier le cloaking (limitant peut-être l'indexation et le flux de PageRank, l'autorité, la confiance, etc., via 5 redirections enchaînées)
  • Amélioration de l'interprétation du code JavaScript (évaluation spécifique des fonctions JavaScript complexes et/ou encodées contenant des liens ou des redirections)
  • Mécanisme d'acceptation des cookies (éventuellement en conjonction avec l'analyse JavaScript et de redirection ci-dessus)

Bien sûr, la collecte de données pourrait être sous-traitée à une société distincte pour éviter le problème de la livraison IP

Il existe des cas où une entreprise peut souhaiter fournir des informations différentes ou supplémentaires à ses utilisateurs. Par exemple:

  • Géo-ciblage
  • Utilisateurs connectés (expérience de page d'accueil personnalisée, etc.)
  • Suivi des références - par exemple, fournir des commentaires à l'utilisateur en fonction de sa requête de moteur de recherche, par exemple en mettant en surbrillance les mots sur une page qui correspondent à la requête
  • Masquage d'appareils pour téléphones mobiles et appareils tactiles
  • Optimisation pour des navigateurs spécifiques ou pour la rétrocompatibilité
  • Optimisation de l'affichage (bien que cela puisse généralement être contrôlé via CSS)
  • Premier clic gratuit – Ou cinq premiers clics gratuits
  • Tests A/B ou multivariés
  • URL personnalisées (masquage de liens)
  • Afficher la vérification de l'âge (www.bacardi.com utilise une combinaison de détection d'agent utilisateur et de cookies pour afficher une page d'accueil de vérification de l'âge aux utilisateurs, mais permet aux moteurs de recherche d'accéder au site Web. Même si Google n'a que 14 ans)
  • L'équilibrage de charge
  • Remplacement de la police (via une technologie telle que sIFR ou Cufon) - Remarque : peut mais pas optimal pour Google Preview (à partir de décembre 2010)
  • Objet SWF

Assurez-vous de prendre en compte les implications SEO lorsque vous utilisez l'une des méthodes ou fonctionnalités mentionnées ci-dessus, car une mauvaise configuration peut entraîner des spams masqués ou peut ne pas être optimale pour le référencement.

D'accord, ce n'est donc pas un tutoriel sur la façon de se camoufler; il s'agit d'une « liste interdite de cloaking-spam 2011 » ou à tout le moins, un avertissement des techniques à éviter ou des problèmes à résoudre au début de 2011.

Certaines formes de cloaking sont délibérées (telles que la livraison IP ou le cloaking d'agent utilisateur), mais de nombreuses formes de cloaking-spam peuvent être accidentelles. Les types accidentels de cloaking-spam qui vous font bannir par inadvertance de Google sont les plus préoccupants, car le webmaster peut ne pas être au courant du problème. Même les grandes entreprises se trompent parfois.

Nous étudierons ci-dessous certaines des techniques de dissimulation de spam les plus courantes afin d'éduquer et de garantir que les webmasters et les référenceurs peuvent s'assurer qu'ils ne les ont pas sur leur site Web.

Les webmasters dissimulent généralement le contenu des utilisateurs ou des moteurs de recherche de trois manières :

  1. Livraison IP
  2. Analyse de l'agent utilisateur (vous pouvez vérifier la dissimulation de l'agent utilisateur à l'aide du vérificateur gratuit de dissimulation SEO de Bruce Clay.
  3. Exploitation des comportements connus des moteurs de recherche tels que l'exécution de JavaScript ou de redirections, et l'indexation ou la capacité d'araignée de divers éléments HTML

Fournir un contenu différent en fonction de l'adresse IP du navigateur Web demandeur ou de l'araignée du moteur de recherche. [La livraison IP est couverte plus en détail ici.]

DNS inverse et DNS direct

Les recherches DNS inversées et DNS directes ne sont pas une forme de dissimulation, mais peuvent être utilisées pour interroger les enregistrements DNS d'une adresse IP demandeuse. Google fournit des détails sur la façon de vérifier que Googlebot est bien celui qu'il prétend être.

Fournir un contenu différent en fonction de l'agent utilisateur du navigateur Web demandeur ou de l'araignée du moteur de recherche. Par exemple, Googlebot/2.1 (+http://www.google.com/bot.html) ou Mozilla/5.0 (Windows ; U ; MSIE 7.0 ; Windows NT 6.0 ; en-US)

Google peut indexer une page contenant du JavaScript mais ne pas suivre la redirection JavaScript, mais nous constatons des améliorations significatives dans l'interprétation du code JavaScript par Google (par exemple, le générateur d'aperçu Google affiche JavaScript, AJAX, CSS3, les cadres et les iframes).

Les webmasters utilisent parfois des redirections JavaScript lorsqu'ils ne peuvent pas implémenter une redirection côté serveur, laissant par inadvertance Googlebot sur la première page et envoyant le navigateur Web (qui suit la redirection JavaScript) vers une deuxième page contenant un contenu différent, et est donc signalé comme cloaking-spam.

Recherchez le code suivant :

<script type="text/javascript"> window.location="http://www.votresite.com/second-page.html" </script>

Une balise ajoutée à la section d'en-tête de la page HTML pour rediriger les utilisateurs vers une autre page après une période définie. La balise meta refresh n'est pas considérée comme un camouflage lorsqu'elle est utilisée seule, mais elle peut être combinée avec JavaScript, des cadres ou d'autres techniques pour envoyer un utilisateur vers une page différente des moteurs de recherche.

Recherchez le code suivant :

<meta http-equiv="refresh" content="0;url=http://www.votresite.com/second-page.html">

Rafraîchissements méta doubles/multiples ou masquage de référents

Plusieurs méta-actualisations peuvent être utilisées pour masquer le référent des sites Web affiliés. Évitez d'enchaîner plusieurs redirections de toute sorte, car cela peut avoir des impacts négatifs sur le référencement et peut même aller à l'encontre des conditions d'utilisation (TOS) de vos partenaires affiliés

Meta refresh en JavaScript ou la balise <noscript>

OK, maintenant nous entrons dans le domaine du "chapeau noir". Il est peu probable qu'un webmaster combine une méta-actualisation avec JavaScript à moins qu'ils ne soient pas bons.

Ceci est facile à détecter pour un moteur de recherche. Ne le faites pas.

Les moteurs de recherche peuvent ne pas suivre plusieurs redirections enchaînées (conformément aux directives de la spécification HTML, le nombre recommandé a été fixé à 5 redirections). Google peut suivre environ 5 redirections enchaînées. Les navigateurs Web peuvent suivre davantage.

Plusieurs redirections consécutives (en particulier la combinaison de différents types de redirections 301, 302, meta refresh, JavaScript, etc.) ont un impact sur les temps de chargement des pages, peuvent avoir un impact sur le flux de PageRank (même les redirections 301 peuvent voir une certaine dégradation du PageRank) et pourraient être considérées comme du cloaking- Spam.

Je n'ai trouvé aucune donnée sur le nombre de redirections qu'un navigateur Web suivra, j'ai donc créé un script de redirection enchaîné rapide pour tester certains des navigateurs installés sur ma machine et fournir des statistiques sur le nombre approximatif de redirections suivies (par type de redirection) . J'ai limité le script à un maximum de 5000 redirections chaînées.

Navigateur Web Version Nombre approximatif de 301 redirections Nombre approximatif de 302 redirections Nombre approximatif de redirections Meta Refresh Nombre approximatif de redirections JavaScript
Google Chrome 8.0.552.224 21 21 21 Plus de 5000
(limite inconnue)
Internet Explorer 8.0.6001.18702IC 11 11 Plus de 5000
(limite inconnue)
Plus de 5000
(limite inconnue)
MozillaFirefox 3.5.16 20 20 20 Plus de 3000
(limite inconnue, car le navigateur s'est arrêté après 3000 redirections JS)
Safari 3.1.2 (525.21) 16 16 Plus de 5000
(limite inconnue)
Plus de 5000
(limite inconnue)

Au fur et à mesure de l'écriture du script, nous avons pensé exécuter un test supplémentaire et soumettre l'URL de redirection à Google. Nous avons également lié au script de Twitter. Les résultats sont dans le tableau ci-dessous.

Moteur de recherche IP de l'hôte de l'agent utilisateur Nombre approximatif de 301 redirections suivies
Microsoft *Supposé basé sur la plage IP
Mozilla/4.0 (compatible ; MSIE 7.0 ; Windows NT 6.0)
65.52.17.79 25
Google
Mozilla/5.0 (compatible ; Googlebot/2.1 ; +http://www.google.com/bot.html)
66.249.68.249 5
Yahoo
Mozilla/5.0 (compatible ; Yahoo! Slurp ; http://help.yahoo.com/help/us/ysearch/slurp)
67.195.111.225 4
Twitter
Twitterbot/0.1
128.242.241.94 3
LinkedIn
LinkedInBot/1.0 (compatible ; Mozilla/5.0 ; Jakarta Commons-HttpClient/3.1 +http://www.linkedin.com)
216.52.242.14 1
PostRank
PostRank/2.0 (postrank.com)
204.236.206.79 0

Bien que Googlebot n'ait exploré que 5 des redirections permanentes dans ce cas, il peut être juste de supposer que Google peut implémenter une vérification basée sur l'exploration pour tester les redirections au-delà de la limite de 5 bots de redirection dans la même veine que Microsoft ci-dessus qui suit environ 25 redirections enchaînées. Remarque : nous avons supposé qu'il s'agissait d'une adresse IP appartenant à Microsoft sur la base des informations IP Whois de Domain Tools.

Les cadres permettent à un webmaster d'intégrer un autre document dans une page HTML. Les moteurs de recherche n'ont traditionnellement pas réussi à attribuer le contenu encadré à la page parent permettant à un webmaster d'empêcher les moteurs de recherche de voir tout ou partie du contenu d'une page.

Les cadres et les iFrames sont des éléments HTML légitimes (même s'ils ne sont pas souvent les meilleures pratiques d'un point de vue SEO), mais ils peuvent également être combinés avec d'autres techniques pour tromper les utilisateurs.

Cadres avec une redirection JavaScript

L'intégration d'un cadre avec une redirection JavaScript peut laisser les moteurs de recherche sur la première page et rediriger sournoisement les utilisateurs avec JavaScript activé vers la deuxième page "cachée".

Je ne peux pas penser à une raison légitime de "chapeau blanc" pour laquelle vous choisiriez d'utiliser cela. Cela peut entraîner une pénalité ou une interdiction. Vérifiez le code source de vos documents encadrés, supprimez ce code ou implémentez une redirection conviviale SEO appropriée.

La balise <noscript> a été conçue pour fournir un équivalent non-JavaScript pour le contenu JavaScript afin que les navigateurs et les moteurs de recherche en texte seul puissent interpréter des formes de contenu plus avancées. La balise <noscript> peut être traitée avec une certaine méfiance car elle a été abusée par des spammeurs dans le passé.

Construisez la fonctionnalité JavaScript/AJAX avec une amélioration progressive à l'esprit afin que le contenu soit adapté à tous les utilisateurs et ne nécessite pas l'utilisation de la balise <noscript>. Si votre site Web utilise la balise <noscript> et que vous ne pouvez pas mettre à jour le code, vérifiez que tous les textes, liens et images contenus dans la balise <noscript> décrivent avec précision le contenu JavaScript, AJAX ou Flash qu'il représente de manière précise, claire et concise. manière.

Si la page ou le site Web incriminé a des problèmes d'indexation, envisagez de réviser le code <noscript> dans le cadre d'un audit SEO approfondi du site Web.

Les réseaux de diffusion de contenu (CDN) permettent aux entreprises de distribuer leur contenu statique sur plusieurs emplacements géographiques afin d'améliorer les performances pour les utilisateurs finaux. Selon la configuration du CDN, il existe plusieurs façons d'acheminer la demande du client vers la meilleure source disponible pour diffuser le contenu. Les CDN sont un domaine complexe, généralement mis en œuvre par des entreprises mondiales qui ont besoin de servir le contenu des utilisateurs dans les plus brefs délais.

Si vous utilisez un CDN, assurez-vous qu'il permet à un moteur de recherche d'accéder au même contenu et aux mêmes informations que les utilisateurs voient et assurez-vous qu'il n'y a rien qu'un moteur de recherche puisse interpréter comme trompeur.

Les pirates ont utilisé des exploits sur des CMS courants pour générer du trafic vers des sites Web tiers moins éthiques. Un exemple est le WordPress Pharma Hack qui a utilisé le cloaking pour présenter le contenu pharmaceutique aux moteurs de recherche mais cacher ce contenu au webmaster.

Assurez-vous que votre CMS, votre serveur Web et votre système d'exploitation exécutent les dernières versions et qu'ils ont été sécurisés. Certains des exploits les plus courants sont des mots de passe médiocres, des logiciels ou des scripts non sécurisés, des employés mécontents et des astuces d'ingénierie sociale.

Les en-têtes HTTP envoient des informations supplémentaires sur la page demandée à l'araignée du moteur de recherche ou au navigateur Web. Par exemple, le statut de la page, les informations mises en cache/d'expiration, les informations de redirection, etc.

L'envoi d'en-têtes différents à un moteur de recherche dans le but de tromper peut entraîner une pénalité. Par exemple, remplacer un bon contenu sur une page de haut rang par un formulaire d'inscription et modifier les en-têtes d'expiration et/ou de contrôle du cache dans le but de tromper les moteurs de recherche pour qu'ils maintiennent la version de haut rang avec le bon contenu ne fonctionnera pas.

Googlebot peut périodiquement télécharger le contenu indépendamment des en-têtes d'expiration et de contrôle du cache pour vérifier que le contenu n'a effectivement pas changé.

Vous pouvez vérifier l'état des en-têtes de réponse de votre serveur à l'aide de l'un de nos outils de référencement gratuits.

Pour citer Google :

"Les pages de porte sont généralement de grands ensembles de pages de mauvaise qualité où chaque page est optimisée pour un mot clé ou une expression spécifique. Dans de nombreux cas, les pages de porte sont écrites pour classer une phrase particulière, puis dirigent les utilisateurs vers une seule destination »

Source : http://www.google.com/support/webmasters/bin/answer.py?hl=fr&answer=66355

Matt Cutts a une diatribe sur les pages Doorway ici.

Les outils de test multivariés tels que l'Optimiseur de Site Google vous permettent d'améliorer l'efficacité de votre site Web en testant les modifications apportées au contenu et à la conception de votre site Web pour améliorer les taux de conversion (ou d'autres mesures importantes mesurées).

Les tests multivariés sont une utilisation éthique du cloaking, cependant, déclare Google :

"Si nous trouvons un site exécutant une seule combinaison non originale à 100 % pendant un certain nombre de mois, ou si la page d'origine d'un site est chargée de mots clés qui ne sont pas liés aux combinaisons présentées aux visiteurs, nous pouvons supprimer ce site. de notre index ».

Pas nécessairement le cloaking-spam en soi, mais une technique d'appât et de commutation, qui 301 redirige des domaines non liés (généralement des domaines qui sont à vendre ou qui ont expiré mais qui ont toujours un PageRank ou des liens externes importants) vers un domaine malveillant ou non lié sur un sujet complètement différent .https://www.youtube.com/watch?v=70LR8H8pn1Mhttps://searchengineland.com/do-links-from-expired-domains-count-with-google-17811

Ceci est trompeur pour les utilisateurs car ils peuvent s'attendre à un site Web différent et peuvent transmettre un texte d'ancrage sans rapport avec votre domaine.

De plus, ne vous attendez pas à un crédit pour l'enregistrement de domaines expirés avec des liens externes dans l'espoir d'un RP ou d'un renforcement des liens.

Historiquement, les moteurs de recherche ont eu du mal à interpréter et à indexer efficacement le contenu Flash, mais ils s'améliorent tout le temps.

Les webmasters ont dû prendre en compte les utilisateurs et les moteurs de recherche qui n'avaient pas de navigateurs compatibles Flash et ont soit construit un site Web HTML standard "dans les coulisses" pour les moteurs de recherche, utilisé une balise <noscript>, JavaScript ou une méthode similaire pour indexer leur contenu textuel. Malheureusement, cela peut être identifié par inadvertance comme un camouflage par les moteurs de recherche si le contenu indexé à partir du contenu Flash ne correspond pas au contenu textuel.

Construire un site Web entier en Flash n'est toujours pas une bonne idée du point de vue du référencement, mais si vous avez du contenu Flash, envisagez d'implémenter SWFObject ou une technique similaire pour vous assurer que Flash se dégrade gracieusement pour les utilisateurs et les moteurs de recherche.

Les divs popover et les publicités seules ne sont pas masquées. Lorsque les annonces interstitielles ou les divs popover ne peuvent pas être fermés (par exemple, à moins que l'utilisateur ne s'enregistre), vous pouvez alors présenter du contenu aux moteurs de recherche et un formulaire d'inscription à vos utilisateurs.

Assurez-vous que les utilisateurs peuvent fermer ou ignorer les publicités interstitielles, les pop-ups, les popovers, les divs superposés, les boîtes lumineuses, etc. et afficher le contenu disponible

AJAX (Asynchronous JavaScript And XML) est une forme de JavaScript qui permet à une page Web de récupérer du contenu dynamique à partir d'un serveur sans recharger une page. Il est devenu très populaire au cours des deux dernières années et est souvent (sur)utilisé dans de nombreuses applications Web 2.0.

AJAX peut être utilisé de manière trompeuse pour présenter un contenu différent à un utilisateur et à un moteur de recherche - Ne le faites pas.

De plus, le revers de la médaille, dans une approche de "masquage négatif", l'utilisateur peut voir le contenu mais pas un moteur de recherche car il ne peut pas exécuter les appels JavaScript qui récupèrent le contenu dynamique du serveur. Quelque chose à vérifier.

Bon nombre des techniques décrites dans cet article peuvent être combinées, hachées ou manipulées dans une tentative futile de tromper les moteurs de recherche.

Un tel exemple est la combinaison de JavaScript et de cookies pour masquer le contenu. Si la fonction JavaScript ne peut pas écrire ou lire un cookie (comme une araignée de moteur de recherche), alors affichez un contenu différent de celui d'un utilisateur standard avec les cookies activés. Il existe également quelques exemples de scripts JQuery qui permettront à une personne peu scrupuleuse de le faire.

Le masquage de lien fait référence à l'envoi d'un utilisateur vers une URL différente de celle sur laquelle il a cliqué en utilisant une redirection d'une certaine forme. Les redirections peuvent être utilisées pour le meilleur et pour le pire, comme nous l'avons vu ci-dessus. Le masquage de liens est souvent utilisé à des fins d'analyse ou de maintenance. Il y a plusieurs raisons pratiques de le faire, par exemple :

  • Pour maintenir un lien vers un affilié dans un PDF syndiqué ou une application. Utiliser une URL personnalisée similaire et une redirection ci-dessus pour vous assurer que si l'affilié met à jour sa structure d'URL, vous pouvez mettre à jour la redirection sur l'URL personnalisée et ainsi vous assurer que les liens dans les livres électroniques et le contenu syndiqué fonctionnent toujours
  • URL personnalisées utilisées sur les supports marketing et publicitaires, plus faciles à mémoriser que la version standard de l'URL

Bien sûr, cela peut être utilisé pour induire en erreur et tromper, comme déguiser un lien d'affiliation (par exemple, remplacer le lien par http://mysite.com/vanity-url et le rediriger vers http://affiliate.com/offer.html ?=mon-code-affilié).

Modification du texte d'ancrage ou des attributs de lien avec JavaScript ou un mécanisme similaire pour tromper ou tromper les utilisateurs. Il s'agit d'une forme de camouflage qui ne modifie qu'un petit élément de la page pour tromper un utilisateur.

  • Détourner l'événement onClick pour envoyer un utilisateur vers une URL différente vers les moteurs de recherche
  • Ajouter un rel="nofollow" attribut aux liens affichés aux moteurs de recherche et le supprimer du code affiché aux utilisateurs
  • Modification du texte d'ancrage des liens pour inclure des mots-clés dans le texte d'ancrage envoyé aux moteurs de recherche et afficher quelque chose de différent aux utilisateurs

Évitez le détournement de liens pour tromper les utilisateurs, car cela pourrait entraîner des pénalités pour les moteurs de recherche ou l'interdiction de votre site Web.

Il existe des formes éthiques de cette technique pour s'assurer que les utilisateurs et les moteurs de recherche peuvent voir votre contenu AJAX en utilisant HiJAX comme recommandé sur le blog Google.

Masquer du texte est contraire aux conditions d'utilisation et aux directives aux webmasters de Google. Il s'agit d'une forme de camouflage, car un moteur de recherche peut voir le contenu textuel, mais pas l'utilisateur. Évitez les types de texte masqué suivants :

  • Texte indiscernable sur le fond (par exemple gris foncé sur noir)
  • Définir la taille de la police sur 0
  • Styliser le texte d'ancrage riche en mots clés comme le corps du texte standard afin que les utilisateurs ne réalisent pas qu'il s'agit d'un lien
  • Affichage des feuilles de style en cascade (CSS): aucun
  • Texte derrière les images. Un sujet toujours délicat et souvent sujet à débat parmi les référenceurs. Si le texte derrière l'image est une représentation précise et juste d'une image (par exemple un en-tête avec une police personnalisée), vous "devriez être bien" pour citer Matt Cutts. La solution ultime dépendra de votre situation particulière, mais consultez ces ressources pour obtenir des conseils : n'apparaissent pas dans Google Preview depuis décembre 2010.)

Si le trafic des moteurs de recherche est important pour vous, assurez-vous de tenir compte des éléments suivants en ce qui concerne le cloaking :

  • Assurez-vous de bien connaître les formes évidentes et moins évidentes de dissimulation ci-dessus et de savoir comment elles sont utilisées sur votre site pour éviter toute sanction potentielle.
  • Si vous mettez en œuvre une forme de camouflage, assurez-vous qu'elle est correctement examinée du point de vue du référencement pour éviter d'éventuelles pénalités.