XSLT et référencement ?

[MagicYoyo]

En fait si, il y a un intéret à faire cela.
Réduire les balises au strict minimum, et focaliser uniquement sur le contenu.

Je doute fortement. Il n'a jamais été montré qu'une page épurée rankait mieux.
En revanche, une page bien structurée sémantiquement, oui. Et là, comme Sébastien, je dis que tu perds tout le contexte sémantique de ton contenu en abandonnant les balises HTML.


EDIT : manquait un verbe.

[French Dread]

En effet si uniquement le contenu comptait alors les référenceurs feraient des sites en .txt

[ED.]

Absolument. Mais avec interprétation côté serveur.
Le XSLT peut être interprété par le client également. C'est le cas des flux RSS feedburner par exemple.

Le parsing de XML est super gourmand. Faut faire très attention avec ca. Il vaut sans doute mieux faire la transformation XSLT coté serveur.

Je te conseille de regarder :

http://eu.wowarmory.com/

Ce que du XML/XSLT et ca fait crasher les navigateurs une fois sur deux.

M'enfin au vue du contenu je vois pas comment faire d'autres et simplement.
Bases de données de personnages, d'objets, liste assez importantes etc....
Chaque liste est mise a jour quotidiennement.

[Elvis]

Je pense aussi qu'avec des balises custom, le contenu ne peut qu'être mal / pas indexé par les moteurs.

J'ai déjà réalisé des pages, et un site, construits en XML / XSLT, avec transformation côté serveur et j'ai trouvé le concept très intéressant pour intervenir rapidement sur l'affichage des données d'une part, et permettre la rédaction de pages sur un même modèle par des personnes qui n'avaient aucune compétence dans les langages du web ( je pense au HTML / CSS ). Une simple explication sur la signification des balises, un exemple, et c'était tout.

Côté perf, pour autant que je m'en souvienne la transformation était rapide.

[Kilu]

ça c'est du déterrage de topic ! c'est en fait un sujet intéressant, mais en ce qui concerne des utilisateurs ne connaissant pas les langages du web, j'en suis venu à la conclusion (pas trop fait chauffer les méninges sur ce coup !) qu'il était plus facile d'utiliser un cms, surtout ceux avec une bonne structure pour le ref, avec un panneau d'administration simple et robuste

[hibou57]

Bonsoir,

Sujet de « haute voltige »...

Je comprend que le XSLT soit une solution techniquement exitante, mais la question du référencement, doit laisser seuls les moteurs de recherche peser dans la balance.

Concernant l'idée de réduire le nombre de balises pour privilégier le contenu : les balises, qui architecturent le contenu, s'opposeraient donc au contenu ? Peut-être tout le contraire, justement... alors pourquoi en avoir peur ? La source d'un document en XML, peut même contenir encore plus balisages que son pendant publiable en HTML (parce que les balises ajoute du sens)

Concernant la question de savoir si les moteurs indexeront le fichier : oui, il l'indexeront, mais en XML, qu'ils indexeront comme du texte. J'ai déjà rencontré le cas. De même que lorsqu'il découvre un code source, un fichier texte, ou même du texte qu'ils auront trouvé dans un fichier executable en téléchargement !

Concernant la question de savoir s'ils indexeront la version transformé : probablement pas. Internet Explorer et Opera, pour ne citer qu'eux, n'ont pas la même idée du XSLT. Alors comment un robot pourrait savoir qu'elle idée du XSLT il devra mettre en oeuvre ? D'ailleurs est-ce que les moteurs de recherche font les substitution d'entités non-standard quand ils en rencontre dans des documents SGML au sens large ? Probablement pas.

Que fait un robot d'indexation : il fait le plus souvent de l'extraction... et non pas de la transformation. Il extraira donc, comme du texte, avec peut-être le risque de voir apparaitre les balises dans la page de résultat de recherche du moteur, ou peut-être encore qu'il y reconnaitra du XML, et préférera extraire le texte en en-retirant les balises au préalable.

Alors je serait tenté de répondre que oui, les moteurs indéxeront, mais pas la version transformée.

Si la version transformée ajoute du texte calculé automatiquement, ou issu d'une inclusion automatique, ces fragments de texte là, seront probablement perdus au yeux du robot d'indexation. Mais si ces fragment ne font pas partie du document lui-même, est-ce bien grave ? De la même manière qu'il est préférable d'utiliser du texte en toute lettre plutôt que de compter sur des substitution d'entité, il faudra seulement prendre soin de s'assurer que tout ce qui fait partie du document, est effectivement inclus dans le fichier source du document, sous une forme explicite.

Dans tous les cas, quel différence devrait-on attendre d'un indexation en HTML produit plutôt qu'en XML ? Dans une page de SERP, on ne voit rien du format effectif du document. Ce n'est qu'un simple fragment de texte. Alors aprés tout, et en dehors du cas du problème substitution ou inclusion automatique de contenu, qu'un document soit indéxé en XML, HTML ou produit d'une transformation XML, quelle différence ?

La question principale que j'y vois n'est pas celle de l'indexation, mais plutôt de l'allure des extraits dans les SERP (si du balisage vient la polluer, ça ne va pas être trés avenant, mais si les balises sont filtrées, alors ça peut être présentable).

p.s. partout je dis « probablement », parce que je ne peux pas l'affirmer formellement. Mais c'est que je crois devinder à la vue de ce que je connais des moteurs de recherche en général. Ils extraient... ce qu'ils peuvent extraire.

[WebRankInfo]

Merci hibou pour ce message très intéressant

[Mumuri]

Si vous voulez référencer vos sites web en xslt , la meilleur solution reste de compiler la feuille de style au niveau serveur (comme cité plus haut), de façon à en produire une version html à servir à google bot et autres bots de moteur de recherche.

Vous aurez alors un gros "if" dans votre code

Code: Tout sélectionner

SI (estGoogleBot())
ALORS
  RENVOYER convertirPageDeXMLaHTML(xsll,xml)
SINON
RENVOYER xml
FinSI


Pour compléter, Voir article sur leurs groupes de discussions. Le support de cette techno n'a pas l'air d'être dans leurs priorités.

JohnMu Employé Google

Hi Hamed
While XSLT is a great technology, it's most likely not something that
search engines will support in the near future. There is a lot of
processing involved in using XSLT to generate HTML that can be
analyzed properly, so this is not something that is easily scalable. I
too would recommend that you do this processing on the server side, as
it can not only help search engines, but it can also help other,
simpler clients and possibly speed up the rendering in general.

Hope it helps!
John

http://groups.google.fr/group/Google_Webmaster_Help-Indexing/browse_th ... 2b5ae26b0a

Notes: Le "SI estGoogleBot" cité plus haut devrait plutot être un "SI supporteXSL" . Pour infos, IE supporte xsl (du moin la version 7.0).

[Mumuri]

Double post

[Vincentb85]

Re-déterrage de topic qui m'intéresse également !

Nous voilà en 2011 (bonne année), XSLT est de nos jours supporté par tout les navigateurs :
- Internet Explorer depuis sa version 6 (2001)
- Mozilla Firefox depuis la 1er version (2004)
- Opera depuis la version 9 (2006)
- Google Chrome depuis le début
- Apple Safari depuis la version 2 (2005) et même sa version mobile pour iPhone l'interprète parfaitement !
Je pense que les autres navigateurs pour SmartPhone comme Firefox Mobile (Fennec) ou autres sont également compatibles ? A voir...

Je rappelle également que XSLT 1.0 est une Recommandation du W3C depuis 1999 tout comme HTML 4.01 !

D'après hibou57 "Yahoo reconnait les feuilles XSLT" (http://forum.webrankinfo.com/yahoo-reconnait-les-feuilles-xslt-t130530.html) mais je pense que de toute façon cela n'a pas d'importance pour un moteur de recherche de connaitre la structure HTML après transformation du XML car tout le contenu intéressant devrait se trouver dans ce dernier, les balises reste inutile en XML comme en HTML pour les robots de référencement (excepté pour certaines entre <HEAD> comme <TITLE> par exemple).

L'intérêt du XSLT pour un site c'est que l'on peut générer des templates coté client (votre serveur vous remerciera) !!
Au pire si ont veut absolument avoir du HTML on peut générer à l'avance des pages statiques avec un processeur XSLT à partir de XML/XSL pour ensuite les envoyer sur le site.

Alors pourquoi s'en priver ?

[Leonick]

Alors pourquoi s'en priver ?

non, la question devrait être inverse : pourquoi le faire, quel en serait l'intérêt ? en dehors, évidemment, de se la jouer genre "ouai, MOI je maitrise XML/XSLT"
avantages ?? baisse de charge du serveur ? en quoi si on utilise un cache de serveur ?
moins d'accès serveur ? mais ça voudrait dire qu'il faudrait envoyer la totalité d'une bdd au cas où l'internaute ait envie de changer de filtrage
inconvénients : augmentation substantielle de la charge au niveau du navigateur de l'internaute, surtout pour ceux qui naviguent avec leur smartphone
les navigateurs les reconnaissent, soit, mais le font-ils bien ? quand on voit comment les css sont reconnues différemment selon les navigateurs, mais aussi selon les versions

franchement, pour diminuer les aller/retour d'infos sans intérêt avec le serveur, rien ne vaut une bonne appli ajax

[hibou57]

[…] "Yahoo reconnait les feuilles XSLT" (Yahoo reconnait les feuilles XSLT !) mais je pense que de toute façon cela n'a pas d'importance pour un moteur de recherche de connaitre la structure HTML après transformation du XML car tout le contenu intéressant devrait se trouver dans ce dernier, les balises reste inutile en XML comme en HTML pour les robots de référencement (excepté pour certaines entre <HEAD> comme <TITLE> par exemple).

Pas dans tous les cas. Comme je l’expliquais dans le fil en question, XSLT, c’est XSL Transform, et les transformations XSLT peuvent être employées pour interpréter des données XML brutes et les mettre sous forme lisible. Par exemple les sources XML que j’utilise ne donne pas directement les relations entre les pages, mais contiennent une référence à un fichier, qui lui contient les relations que plusieurs partage entre elles (chaque page contient une référence à un groupe auquel elle appartient). C’est XSLT qui ensuite répercute ces relations dans la version HTML, en créant plusieurs liens HTML standards.

Une source XML, est bien une source, mais n’est pas toujours une source qui convient à une consultation publique, car elle ne fait sens que dans un système donné. Il en va de même avec un robot, il se trouve dans le cas d’une consultation publique : à moins d’utiliser un modèle de document que le robot connait et sait interpréter, il ne pourra pas interpréter la source XML correctement.

C’était justement la raison qui m’a fait « sauter de joie » en découvrant que Yahoo! le magnifique reconnait les références à XSLT, parce que c’est le signe pour moi qu’il se donne le moyen d’interpréter correctement. Mais ce n’est pas si simple, parce qu’une transformation s’effectue dans un contexte, et c’est un processus qui est assez comparable à celui de la compilation d’une application : un environnement, un système, sont mis en place à cette fin, mais je ne vais pas dériver sur cette question qui irait trop loin dans les détails.

L'intérêt du XSLT pour un site c'est que l'on peut générer des templates coté client (votre serveur vous remerciera) !!
Au pire si ont veut absolument avoir du HTML on peut générer à l'avance des pages statiques avec un processeur XSLT à partir de XML/XSL pour ensuite les envoyer sur le site.

Alors pourquoi s'en priver ?

Là je suis de l’avis de Léonick [*] : pour l’instant je trouve ça trop risqué. Un renvoie en statique de la forme HTML des documents qui ne changent pas, avec une compression gzip, des attributs de cache raisonnable dans l’entête de la réponse, et le tout est suffisamment léger autant pour le serveur que pour le navigateur.

XSLT de nos jours, c’est comme CSS à la fin des années 1990s : encore trop marginal.

… peut-être que dans 10 ou 15 ans il en sera autrement (et ce n’est même pas sûr).


[*] Excepté sur le point que les gens qui l’utilisent, c’est pour « pour se la jouer ».

[Vincentb85]

@ Leonick :
L'intérêt comme expliqué dans mon post précédent c'est d'utiliser des templates coté client.
C'est à dire que sur un site qui possède des parties générique (se répétant sur plusieurs pages) comme :
- un menu
- un pied de page
- une entête
- de la publicité
- etc...

Quand le template est généré coté serveur on écrit une fois le code des parties générique puis le serveur rassemble le tout pour l'envoyer au navigateur sous forme d'une seul et unique page HTML.
Chaque page sera mise en cache sur le serveur et dans le navigateur.

Quand le template est généré coté client on écrit une fois le code des parties générique dans un .xsl et le reste dans le .xml puis le serveur envoie 2 fichier (XML+XSL) statique que le navigateur va interprété lui même.
Le serveur n'a besoin d'aucun système de cache (ni même de PHP ou autres)
Le fichier XSL sera mis en cache par le navigateur qui n'aura plus qu'a télécharger uniquement les XML des pages suivantes.

Etant donné que le XML ne contient que les partie unique (non générique), sa taille est ridicule comparé aux pages HTML qui contiendront à chaque fois l'ensemble !

Avantages :
- pas besoin de cache serveur
- pas besoin de serveur dynamique non plus
- utilisation de la bande passante réduite au minimum (uniquement le contenue qui change, comme AJAX)
- possibilité de combiné avec une (pré)compression GZIP

Inconvénient, le référencement peut être ?

Quelques petit rappel que tu semble avoir oublié :
- AJAX nécessite que JavaScript soit actif sur le navigateur.
- JavaScript n'est pas interprété de la même façon selon les navigateurs.
- JavaScript peut être désactivé, contrairement à XSLT.
- AJAX et XSLT n'ont pas le même but et peuvent donc s'utiliser simultanément.
- CSS 2.1 est toujours à l'état de brouillons (W3C working draft) alors que XSLT est une recommandation depuis 99 et reconnus par tout les navigateur depuis 2001


Donc je repose la question dans le bon sens: pourquoi s'en priver ?

[Vincentb85]

@ hibou57 :
De toutes façon aucun bot ne comprend les balises qui sont dans ton XML contrairement au <a href> du HTML.
Donc dans tout les cas il faudra aider le bot car il ne trouvera que du texte brut dans le XML (sauf pour Yahoo apparament).

Alors pourquoi ne pas utiliser un sitemap.xml ?
Et pourquoi ne pas le généré à partir des XML + XSL !


Par contre je n'est pas compris ce que tu trouvais trop risqué dans ma citation ?

XSLT de nos jours, c’est comme CSS à la fin des années 1990s : encore trop marginal.

Alors là par contre c'est moi qui ne suit pas d'accord avec toi !
XSLT est reconnu par tout les navigateur depuis maintenant 10 ans et interprété de la même façon partout, c'est juste que personne ne l'utilise et je ne comprend pas pourquoi ? (peut être à cause du référencement et encore que...)
CSS fut partiellement implémenté par Internet Explorer 3 dès 1996 alors qu'il était encore en cour de formulation et il à été adopté et même réclamé par tous les webmasters !

[Leonick]

Etant donné que le XML ne contient que les partie unique (non générique), sa taille est ridicule comparé aux pages HTML qui contiendront à chaque fois l'ensemble !

ça c'est peut être vrai quand on ne sait pas faire du "bon" code html, en externalisant la mise en page dans les css externes

XSLT est reconnu par tout les navigateur depuis maintenant 10 ans et interprété de la même façon partout,

l'as-tu vérifié personnellement ? combien de navigateurs différents as-tu installés sur ton oi pour pouvoir le vérifier. Quand on voit comment les css sont reconnues de façons très différentes, il y a de forts risques que pour le xslt/css ça soit pareil.
Car si on utilise du xslt pour refaire une mise en page sous forme de <table>, l'intérêt devient bien léger