SEO berSZerkers

Les afficionados du tout-en-Flash sont souvent dépités devant les maigres performances du référencement de leur site.

Nous pouvons tenter de déblayer le terrain pour les aider à optimiser ce référencement.

Nous avons vu dans un précédent billet que les moteurs de recherche sont parfaitement capables d’explorer les fichiers .swf et d’en extraire la substantifique moelle : le texte et les liens.
La cause est entendue : ils peuvent le faire.
Mais aiment-ils cela ?

1. L’avis d’un moteur : évitons le Flash.

Les communicateurs de GG donnent souvent les caps à suivre.
Tout le monde connaît le nom et la bouille sympathique de Matt Cutts, pour ma part je guette plus volontiers les interventions de Vanessa Fox.

Et que dit Vanessa Fox au sujet des Flash-based sites ?

Vanessa Fox (source)

It’s not only Googlebot who doesn’t watch a 20 second video load before the home page comes into view. A lot of users don’t either.
Some users don’t want to wait that long; other users don’t have Flash installed. If all of your content and menus are in Flash, search engines may have a harder time following the links. If you feel strongly about using Flash, just make an HTML version of the page available as well. The search engine bots will thank you. Your users will thank you. Feel free to block the Flash version from the crawlers with a robots.txt file, since you don’t need your pages indexed twice. If your home page is Flash, put the navigation outside of the Flash content. You could offer a choice on the home page so users can choose either the HTML version or the Flash version of the site. (You might be surprised at what users choose.)

Le conseil (l’injonction ?) est on ne peut plus clair :
- il faut doubler le .swf avec du html standard;
- il faut permettre à l’internaute de choisir l’une ou l’autre des versions; donc : pas de remplacement automatique du .swf par du html;
- il faut cacher le .swf au moyen d’un robots.txt pour éviter le duplicate content.

Conclusion : GG préférerait ne pas avoir à traiter les .swf … mais il le fait puisqu’il y a un risque de duplication de contenu (dixit Vanessa Fox).

GG pourrait ignorer les .swf, qu’ils soient indépendants ou assis sur un socle html et cela règlerait la question.
S’il les examine, et il le fait, on peut imaginer que c’est pour proposer des supports de contenu toujours plus variés (son but est l’exhaustivité) et aussi pour monter la barre face à ses concurrents (comment désormais lancer un moteur qui serait incapable de traiter les .swf ?).

Explorer les .swf serait une manière de rouler des mécaniques

2. Le potentiel du .swf sur les requêtes concurrentielles

Un .swf peut-il se retrouver positionné correctement sur une requête concurrentielle voire très concurrentielle ?

La réponse est : Oui.

Exemple livré par disette

Requête : ‘telephone’
26ème position pour le fichier : lexiquefle.free.fr/telephone.swf (positionnement bigdaddy avec 489 millions de résultats retournés et 56 918 requêtes formulées en novembre 2006 - chiffres réseau Overture).

Il ne s’agit pas d’un cas exceptionnel ou isolé.

3. Référencer le .swf et non pas la page html qui le porte

Si l’on suit les suggestions de Vanessa Fox, on élude la question du référencement du fichier .swf.

On se retrouve à référencer les pages html prévues comme contenu alternatif au .swf.
Il n’est même plus question d’optimiser le support html du .swf ou le .swf lui-même mais bien au contraire, il faudrait l’écarter du chemin des robots par un robots.txt.

Ce scénario est confortable pour tous les routiniers, webmasters comme robots.
C’est un compromis qui donne des résultats normaux et prévisibles.

Mais cette méthode éclipse l’intérêt du .swf en tant que document autonome, elle le réduit au rôle de fichier accessoire voire de gadget alors qu’on peut le considérer comme aussi honorable et autosuffisant qu’un fichier .pdf, qu’un fichier .doc … ou qu’un site Web

De plus, il faut disqualifier le fichier .swf pour éviter le duplicate content et pour ceux qui n’ont guère confiance dans le robots.txt, la tentation est grande d’inclure le .swf par l’intermédiaire d’un Javascript … ce qui interdit de proposer une alternative en html placée ainsi qu’il convient de le faire c’est-à-dire juste avant la balise </object>.

Note : Il est possible que GG soit capable d’accéder au .swf intégré par Javascript; dans ce cas et si l’on craint les doublons de contenu, mieux vaut systématiquement disqualifier le .swf par robots.txt.

4. De l’impérieuse nécessité d’un contenu alternatif

A la lumière des points précédents, la recommandation de Vanessa Fox prend tout son sens : SI vous proposez un contenu alternatif à votre site en Flash, il convient de le proposer de manière explicite (un choix proposé à l’internaute sur la page d’accueil plutôt qu’un remplacement automatique).

Exit donc les détections du plugin (parfois hasardeuses).
Exit le contenu alternatif placé juste avant le </object>.
Exit le <noembed> (mais il faut l’éviter de toute manière).

La question : un contenu alternatif est-il indispensable ?

La réponse est Oui.

Trois raisons à cela :
- il est nettement plus facile et plus rapide de référencer les liens et le contenu en html que dans un Flash;
- la fréquence d’examen des fichiers .swf est bien plus faible que celle des pages html;
- l’accessibilité.

En effet, les capacités d’accessibilité du Flash sont tellement minuscules et difficiles à mettre en oeuvre qu’il est inutile de s’y atteler dans l’espoir d’un bon résultat.

Un site en html s’impose donc en plus du site en Flash.

MAIS il s’agit de bien se comprendre sur le sens de site alternatif.

Il s’agira en fait du site proposé en standard aux internautes.
Il comportera un lien vers le .swf non embeddé dans une page html.
Son contenu sera assez différent de celui du .swf pour éviter tout risque de duplicate content.
Il n’est pas nécessaire de présenter des contenus identiques, il suffit qu’ils soient équivalents.

Le .swf comportera un lien vers le site en html.

Cette technique à l’envers permettra de référencer les deux versions du site et d’augmenter sa visibilité.

Il ne s’agit plus de proposer un faux site en full-Flash (un .swf inclus dans une page html) avec un lien vers son équivalent en html mais de proposer l’inverse :

- un site html (full-accessible tant qu’à faire);
- plus un .swf indépendant.

Le .swf pourra très bien être positionné de manière à être exploité en priorité par l’internaute.
Nous allons voir comment.

5. Les handicaps sémantiques du .swf

On n’y trouve ni <title> ni balises <hn>.
Le .swf ne comporte aucun balisage sémantique.

Dans l’état actuel de l’art, il faut renoncer à tenter d’expliquer par balises aux moteurs ce qui, dans le .swf, fait office de titre, de sous-titre, de description …

Il faut s’y prendre autrement et tout d’abord réaliser que dans un .swf, l’unité documentaire n’est pas la page comme en html mais le fichier tout entier.

En conséquence, pour bien référencer un site full-Flash, il faut le diviser par un chapitrage.

6. Référencer plusieurs .swf pour un seul site

Un site en Flash, cela ne signifie pas un seul .swf.
Un seul fichier .swf pour un site, c’est comme si vous trouviez normal qu’un site html comporte une seule page.

Un site en full-Flash doit être organiquement structuré au même titre qu’un site en html.
Il ne s’agira pas de pages mais de sections (chapitres) : un .swf par section.
Ceci permettra de doter chaque section d’un titre et d’une description propres.

Chaque section aura sa propre chance d’être référencée.
Dans les SERPs, cela peut multiplier l’impact du site par le nombre de chapitres.

Un menu commun permettra la navigation d’une section à l’autre quelle que soit la section par laquelle l’internaute a commencé.

Une structure intelligente permet de preloader en background les .swf les plus susceptibles d’être appelés au départ d’un .swf donné (c’est le b a BA du Flash).

Morceler un fichier de 5 Mo en sections de 100 Ko permet aussi d’éviter la lassitude du robot comme celle de l’internaute (relisez ce qu’en dit Vanessa Fox).
Les robots pourraient bien avoir moins de patience encore que les internautes, avec pour conséquence qu’un .swf léger serait parsé plus souvent qu’un .swf lourd (cela reste à étudier).

Le strict minimum espéré dans les SERPs pour chaque swf-chapitre du site full-Flash, c’est le titre et la description.

Faute d’un balisage sémantique, comment faire comprendre ces informations au robot ?
Ces textes doivent être inscrits dans la toute première frame du .swf.

7. La première frame du preloader.

Un .swf commence habituellement par un preloader.
Le preloader est une boucle qui répète inlassablement un certain affichage (et parfois une barre qui montre l’avancement du chargement) tant que telle frame de telle scène n’a pas été chargée.
Quand c’est fait, on passe la main à la scène suivante et l’exploitation du .swf par l’internaute peut commencer.

Que trouve-t-on comme texte dans le preloader ?

La plupart du temps, c’est du texte dynamique généré par script.
Et seulement ce type de texte.

Prenons par exemple le fichier 2000edwardes.swf trouvé sur cette page.

La SERP livre :
now loading edwardes lake park - please wait 2000 DOWNLOAD PDF

Parsons :

DOWNLOAD PDF
DOWNLOAD PDF
DOWNLOAD PDF
2000
2000harbouresplanade.html 2000digitalharbour.html 2000.html
now loading edwardes lake park
…

Le robot aurait-il su éviter par filtre les termes non-pertinents les plus courants ainsi que les liens du menu ?
La possibilité qu’il existe un filtre n’est pas à écarter mais il est infiniment plus probable que le robot considère les données externes comme des variables dynamiques et qu’il n’en tient pas compte.

Il a pris comme titre la première chaîne statique rencontrée au-delà de ces termes.
Dommage qu’elle ne soit pas plus explicite …

L’observation d’un nombre important de .swf référencés permet d’avancer que le robot prend généralement en priorité la première chaîne statique qu’il rencontre dans le .swf.

En conséquence, on pourrait utilement placer titre et description dans deux zones textes successives qui apparaîtront sur l’écran de preload sans alourdir le fichier.
Ces zones devront précéder toute indication utilitaire (Download …) dans la toute première frame du fichier .swf.

Ces deux textes serviront de titre et de description pour le .swf parsé par le moteur.
Ils seront optimisés comme le title et la description d’une page html, ni plus ni moins.

A ceci près : compte tenu que GG identifie la taille des polices, il pourrait bien se révéler utile d’adopter des tailles plus grandes pour la police de ces textes.

Premier texte statique : le titre dans la plus grande taille de police utilisée pour le .swf et utilisée seulement là.
Texte suivant : la description dans une taille immédiatement inférieure et qu’on ne retrouve pas ailleurs dans le .swf.

Ce serait l’équivalent pour le .swf d’un balisage sémantique minimal permettant de contrôler les mentions destinées à apparaître dans les SERPs.

Cependant, il ne faut pas s’en tenir là.
De nombreux exemples montrent que tout comme pour les pages html, GG peut aller chercher le sniplet descriptif n’importe où dans le fichier.

En conséquence : outre ces suggestions de titre et de description faites au moteur, il convient de placer du texte cohérent dans le corpus.

C’est d’autant plus nécessaire que les éléments du titre et de la description affichés dans les SERPs ne sont pas les seuls à être pris en compte par GG pour positionner le fichier sur une requête (ils ne le sont même parfois pas du tout).

Un .swf, pour être correctement référençable et positionnable, devra donc contenir du texte, hé oui.

8. Référencer un .swf non encore parsé

Pour qu’un robot parse un .swf, il faut qu’il le trouve.
De manière classique, on fait pointer un BL vers la page html qui porte le .swf.

Il paraît beaucoup plus efficace de faire pointer le lien directement sur le fichier .swf.
On observe que dans ce cas, le titre dans la SERP est le contenu textuel de l’anchor du BL.

Exemple : alphabet.

(Descendez sur la page pour trouver le fichier Flash).
Le titre est le texte de l’anchor qui a conduit GG à ce fichier.

Voilà qui est ennuyeux si on ne peut contrôler le texte de l’anchor …
Il conviendrait de référencer le .swf par des BL qui porteraient toujours le même titre contenant les mots-clés voulus, l’idéal étant que ce titre soit le même que celui indiqué dans la première frame du preloader ainsi que dit plus haut.

9. Des questions intéressantes

Une question intéressante qu’on ne manquera pas de se poser : modifier le texte d’un BL changerait-il le titre du .swf dans la SERP ?
La réponse est positive et il est donc possible d’externaliser le titre du .swf dans la SERP.

Autre question : le texte du BL prendrait-il le pas sur le résultat parsé ?
L’examen d’un certain nombre de .swf permet de répondre par l’affirmative mais il serait subjectif d’en tirer une règle, compte tenu qu’il y a peut-être un paramètre de pertinence (par exemple si le texte du BL est plus cohérent que ce qui se trouve dans le .swf).

Autre question : le titre du .swf dans la SERP est-il fixé par le premier BL exploité par GG ?
Par le BL le plus pesant ?
La vitesse avec laquelle GG aligne ses DC rend l’expérimentation difficile à ce niveau et cette question reste donc ouverte.

Une méthodologie pour vérifier les hypothèses des observations pourrait être celle-ci :

1. Trouver un .swf qui présente des titres différents sur au moins 2 DC.
Pour ce faire, on pourra introduire le nom du .swf en requête dans cet outil de WebRankInfo : Outil d’analyse des data centers de Google.
2. Sur les deux DC retenus, tester une requête comportant une partie du titre contenu dans une anchor et absent du corpus du .swf.
3. Voir si le positionnement change.

10. Huit conclusions provisoires

Il vaut mieux référencer un .swf bien construit qu’une page qui le porterait.

Le chapitrage d’un site full-Flash en plusieurs .swf augmente le potentiel du référencement.

Un fichier .swf n’est pas parsé tous les deux jours par le robot.
Autant le construire de manière durable, au moins en ce qui concerne le titre et la description.

Il n’est pas improbable que GG préfère parser les .swf légers correctement et solidement linkés.

Le texte des BL qui pointent vers le .swf est capital.

Un .swf doit contenir du texte.

Les liens et le contenu sont plus facilement référençables en html qu’enterrés dans un .swf (d’où la nécessité d’un site équivalent en html).

Un site html alternatif au .swf doit être présenté en priorité (le site full-Flash doit être en option).

Quoi qu’il en soit, voilà de quoi occuper durant quelques heures les partisans du full-Flash

Cet article a été publié le Samedi 23 décembre 2006 à 5:51 et est classé dans Rebonds. Vous pouvez suivre les réponses reçues par cet article grâce au fil RSS 2.0. Vous pouvez laisser un commentaire, ou faire un trackback depuis votre site.