XSLT et référencement ?
- Auteur de la discussion dmathieu
- Date de début
kazhar a dit:
Je ne peux pas répondre à ta question, mais j'en ai une à te poser :wink:
Je suis en train de lire Développer en Ajax de Michel Plasse, et il introduit ça, donc ce que tu utilises pour apprendre le XSLT m'intéresse, je n'ai pas trouver de truc simple pour le moment.
WRInaute occasionnel
Mon site atiki.com utilise cette techno, regarde un des flux proposés il est mis en forme par xsl (mais il faut regarder avec internet explorer, depuis les dernières versions de firefox le navigateur outrepasse ma feuille de style)
Côté référencement... pas top d'après moi!
Côté référencement... pas top d'après moi!
WRInaute discret
Ben je crois que la première question c'est: est-ce que les moteurs vont faire la transformation ou indexer directement (et peut-être ignorer?) la source XML?
J'avoue que je n'en sais rien. Mais il me semble probable qu'ils ne réaliseront pas la transformation (sinon, bonjour le cout de traitement pour les robots... mais c'est peut-être une erreur de ma part?).
Une discussion qui date de 2004 et qui vaut le détour (voir notamment les interventions de Laurent Denis):
http://forum.alsacreations.com/topic-6- ... ement.html
On notera juste, par rapport à cette discussion, qu'Opera 9 supporte XSLT (mais pas XSL-FO), ce qui n'était pas le cas de la version 7.6. À voir cependant du côté d'autres navigateurs, notamment Safari:
http://developer.apple.com/internet/saf ... l#anchor21
À voir aussi pour les versions mobiles des navigateurs (Opera, Safari, autres navigateurs pour smartphones et PDA): la limitation des ressources a peut-être conduit à écarter le support de XSLT?
J'avoue que je n'en sais rien. Mais il me semble probable qu'ils ne réaliseront pas la transformation (sinon, bonjour le cout de traitement pour les robots... mais c'est peut-être une erreur de ma part?).
Une discussion qui date de 2004 et qui vaut le détour (voir notamment les interventions de Laurent Denis):
http://forum.alsacreations.com/topic-6- ... ement.html
On notera juste, par rapport à cette discussion, qu'Opera 9 supporte XSLT (mais pas XSL-FO), ce qui n'était pas le cas de la version 7.6. À voir cependant du côté d'autres navigateurs, notamment Safari:
http://developer.apple.com/internet/saf ... l#anchor21
À voir aussi pour les versions mobiles des navigateurs (Opera, Safari, autres navigateurs pour smartphones et PDA): la limitation des ressources a peut-être conduit à écarter le support de XSLT?
WRInaute discret
Il faut voir alors comment les moteurs indexent les contenus XML en général:
- tous ignorés?
- tous indexés?
- au cas par cas?
Pour mon site perso, je fil RSS n'est pas indexé par Google semble-t-il, tandis que la version Atom est indexée. Pourtant, les pages pointent depuis belle lurette vers le RSS uniquement. Serait-ce un filtre sur le format RSS, qui ne s'appliquerait pas à l'Atom?
De plus, la version indexée par Google date un peu (aout 2007).
Est-ce qu'on a des résultats RSS dans les recherches classiques sur les moteurs? Ça ne m'a en tout cas pas sauté aux yeux.
- tous ignorés?
- tous indexés?
- au cas par cas?
Pour mon site perso, je fil RSS n'est pas indexé par Google semble-t-il, tandis que la version Atom est indexée. Pourtant, les pages pointent depuis belle lurette vers le RSS uniquement. Serait-ce un filtre sur le format RSS, qui ne s'appliquerait pas à l'Atom?
De plus, la version indexée par Google date un peu (aout 2007).
Est-ce qu'on a des résultats RSS dans les recherches classiques sur les moteurs? Ça ne m'a en tout cas pas sauté aux yeux.
l'affichage dans les pages de résultats n'est pas top, car la feuille de style xslt n'est pas appliquée par les moteurs, de même que dans les lecteurs de flux RSS (TB, IE7, ...).
En plus, si on sauvegarde un fichier modifié en xslt, la sauvegarde sera faite avec le contenu fourni et non celui transformé.
A part si on veut effectuer de petites traitements sur une page, genre changer l'ordre de tri, autrement il n'y a aucun intérêt à pomper des ressources au navigateur distant, d'autant plus qu'il faut être sur que cette couche d'abstraction supplémentaire ne va pas introduire d'autres problèmes de compatibilité. :cry:
En plus, si on sauvegarde un fichier modifié en xslt, la sauvegarde sera faite avec le contenu fourni et non celui transformé.
A part si on veut effectuer de petites traitements sur une page, genre changer l'ordre de tri, autrement il n'y a aucun intérêt à pomper des ressources au navigateur distant, d'autant plus qu'il faut être sur que cette couche d'abstraction supplémentaire ne va pas introduire d'autres problèmes de compatibilité. :cry:
voir https://www.google.fr/search?hl=fr&q=inurl%3Arss.xml mais les versions en cache :cry:
WRInaute passionné
Je n'ai pas d'experience sur ce sujet mais la question est interesante : en XML tu définis toi même tes balises c'est bien ça ? genre <produit>, <description> etc...
Dans ce cas tu perd le benefice d'une structuration avec les balises HTML standard et il est douteux que les moteurs cherchent à interpreter le sens de balises propriétaires. Je pense donc que ton XML sera référencé à la manière d'un fichier texte, càd uniquement le contenu. Il s'agit là d'une reflexion abstraite, je n'ai pas de données concrètes pour appuyer mes dires.
Dans ce cas tu perd le benefice d'une structuration avec les balises HTML standard et il est douteux que les moteurs cherchent à interpreter le sens de balises propriétaires. Je pense donc que ton XML sera référencé à la manière d'un fichier texte, càd uniquement le contenu. Il s'agit là d'une reflexion abstraite, je n'ai pas de données concrètes pour appuyer mes dires.
kazhar a dit:
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.
WRInaute passionné
En effet si uniquement le contenu comptait alors les référenceurs feraient des sites en .txt 
kazhar a dit:
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.
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.
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.
ç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
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.
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.
Merci hibou pour ce message très intéressant
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
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.
Notes: Le "SI estGoogleBot" cité plus haut devrait plutot être un "SI supporteXSL" . Pour infos, IE supporte xsl (du moin la version 7.0).
Vous aurez alors un gros "if" dans votre code
Code:
SI (estGoogleBot())
ALORS
RENVOYER convertirPageDeXMLaHTML(xsll,xml)
SINON
RENVOYER xml
FinSIPour 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.
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).
Nouveau WRInaute
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" (https://www.webrankinfo.com/forum/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 ?
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" (https://www.webrankinfo.com/forum/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 ?
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"Vincentb85 a dit:
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
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.Vincentb85 a dit:
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à 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.Vincentb85 a dit:
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 ».
Nouveau WRInaute
@ 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 ?
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 ?
Nouveau WRInaute
@ 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 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 !
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 ?
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 !
ç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 externesVincentb85 a dit:
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.Vincentb85 a dit:
Car si on utilise du xslt pour refaire une mise en page sous forme de <table>, l'intérêt devient bien léger
En tous les cas, mais je n’ai pas re-testé avec IE8, Internet Explorer a des particularités avec XSLT, il reconnait certaines expressions non-standards, n’en reconnait pas d’autres qui le sont, …Leonick a dit:
@Vicent: quand je disais que c’est trop risqué parce que peu supporté, je parlais en pratique, pas en théorie.
CSS dans IE3 en 1996 ? Le CSS ne s’est vraiment imposé qu’en 2003 environ. La quasi totalité des sites n’utilisaient pas le CSS avant cette date approximative, au moins dans le web francophone. J’en suis certain, parce que j’enregistrais des pages sur disquettes depuis des point d’accès internet publiques pour les lire chez moi (je n’avais pas le net chez moi), et je me souviens qu’environ en 2003/2004 seulement, j’ai commencé à avoir des drôles de trucs bizarres que je n’avais vu avant… ces fameux fichiers CSS que je ne connaissais pas, et des pages illisibles dans mon navigateur (qui était pourtant IE4 ou IE3). Avant, toutes les pages que j’enregistrais étaient mises en forme sans CSS.
Un site en XML, je ne m’attendrais qu’à des problèmes. Et puis tu cumulerais les incompatibilité CSS au incompatibilité XSLT ? Tu imagine le cumule des deux ? Et comment tu ferais la détection du navigateur de manière fiable ? Pas de commentaires conditionnels ou quoique que ce soit du genre en XSLT.
Un navigateur est conçu pour lire des présentations, autant lui renvoyer des présentations.
Nouveau WRInaute
http://www.easycode.fr/new/index.xml
Ce site encore en construction est entièrement en XML/XSLT.
Les seul action coté serveur s'effectuent avec les pages ASP (qui renvoie toujours du XML)
Qu'en pensez-vous ?
Ce site encore en construction est entièrement en XML/XSLT.
Les seul action coté serveur s'effectuent avec les pages ASP (qui renvoie toujours du XML)
Qu'en pensez-vous ?
Ben ça passe bien sous Opera et IE8, rien à redire sur ce point. Mais tu pourrais tout aussi bien faire la transformation côté serveur et renvoyer le HTML au navigateur, parce que là, en l’état, je ne sais pas que la plupart des moteurs de recherche vont en faire, et si tu est trop extrémiste avec l’application de cette technique, ça va être une catastrophe pour le référencement.Vincentb85 a dit:
je viens de vérifier : aucun des principaux moteurs de recherche, Yahoo, Exlead, Bing, Google, aucun n’ont indexé ta page XML, et les seules pages indexées que je retrouve, sont des pages HTML standard.
Tu vois où est la question :wink:
Ben ça passe bien sous Opera et IE8, rien à redire sur ce point. Mais tu pourrais tout aussi bien faire la transformation côté serveur et renvoyer le HTML au navigateur, parce que là, en l’état, je ne sais pas ce que la plupart des moteurs de recherche vont en faire; et si tu est trop extrémiste avec l’application de cette technique, ça va être une catastrophe pour le référencement.Vincentb85 a dit:
je viens de vérifier : aucun des principaux moteurs de recherche, Yahoo, Exlead, Bing, Google, aucun n’ont indexé ta page XML, et les seules pages indexées que je retrouve, sont des pages HTML, standards.
Tu vois où est la question ?
Nouveau WRInaute
Pour le référencement c'est normal que ces pages ne soient actuellement pas indexées dans les moteurs de recherche, étant donné qu'il s'agit d'une version non finalisée je l'ai séparée dans un dossier "new" qu'aucune page du site en ligne (http://www.easycode.fr/) ne pointe.
Donc c'est logique qu'aucun bot n'est trouvé les xml, mais à terme il remplacera le site à la racine.
Mais liens <a> reste valide même sans transformation dans les XML mais je compte ajouter en plus un "sitemap.xml" qui fera double emploi (à voir si c'est possible...) :
- pour les différent bot qui recherche toujours si un "sitemap.xml" se trouve à la racine
- transformer "sitemap.xml" avec une feuille XSL+CSS pour le lien "Plan du site" (en pied de page) et l'intégrer au reste du site
Pour ce qui est du future référencement même si je ne comprends pas pourquoi c'est si extrême de publier une version XML/XSL brut (coté client) j'ai envie de tester comme ça pour voir ce que ça donne... (après tout c'est bien le sujet de ce post)
Et de toute façon je considère que ce n'est pas aux moteurs de recherche de définir les standards à utiliser ou non !
Pour le choix entre "application/xml" & "text/xml" y a t'il des problèmes de compatibilité que vous connaissez avec les différents navigateurs ?
Donc c'est logique qu'aucun bot n'est trouvé les xml, mais à terme il remplacera le site à la racine.
Mais liens <a> reste valide même sans transformation dans les XML mais je compte ajouter en plus un "sitemap.xml" qui fera double emploi (à voir si c'est possible...) :
- pour les différent bot qui recherche toujours si un "sitemap.xml" se trouve à la racine
- transformer "sitemap.xml" avec une feuille XSL+CSS pour le lien "Plan du site" (en pied de page) et l'intégrer au reste du site
Pour ce qui est du future référencement même si je ne comprends pas pourquoi c'est si extrême de publier une version XML/XSL brut (coté client) j'ai envie de tester comme ça pour voir ce que ça donne... (après tout c'est bien le sujet de ce post)
Et de toute façon je considère que ce n'est pas aux moteurs de recherche de définir les standards à utiliser ou non !
Pour le choix entre "application/xml" & "text/xml" y a t'il des problèmes de compatibilité que vous connaissez avec les différents navigateurs ?
oui : un mauvais codage va faire planter l'affichage. Mais, l'avantage, c'est que si on arrive à l'envoyer en application/xml on sera sur que c'est ok.Vincentb85 a dit:
du xhtml ou xml envoyé en text/--- est moins bon que du html4 strict, alors quitte à faire des essais, autant qu'ils servent à quelque chose
Nouveau WRInaute
Leonick a dit:
Exemple du trafic réseau produit par 30 visiteurs/mois :
20 pages XML de 3Ko = 60Ko
transform.xsl = 4Ko (en cache)
style.css = 5Ko (en cache)
TOTAL = 30visites x (60Ko + 4Ko + 5Ko) = 2070Ko
les même pages en HTML :
20 pages HTML de 6Ko = 120Ko
style.css = 5Ko (en cache)
TOTAL = 30visites x (120Ko + 5Ko) = 3750Ko
Conclusion:
La taille de mes pages sont ridicule et je ne compte que des visites uniques mais pourtant j'ai réduit de presque la moitié mon trafic réseau !
Si tu veux te la jouer "AJAX power" jusqu'au bout, explique moi maintenant comment tu aurais fait avec l'exemple ci-dessus pour avoir un meilleur résultat autrement qu'avec des pavé de HTML contenant à chaque fois l'ensemble des menus, pied page et autre éléments qui reste identiques d'une page a l'autre ?
Nouveau WRInaute
Autre petit avantage: je ne prends pas la tête à mon serveur juste pour faire des templates.
Et quand tu parlai d'augmentation substantielle de la charge au niveau du navigateur de l'internaute c'est quand même quelques millisecondes en plus que je n'arrive même pas à déceler sur un pauvre iPhone 3G[sans S]...
Et quand tu parlai d'augmentation substantielle de la charge au niveau du navigateur de l'internaute c'est quand même quelques millisecondes en plus que je n'arrive même pas à déceler sur un pauvre iPhone 3G[sans S]...
ton html, il suffit d'utiliser le DOM pour modifier juste le contenu nécessaire et ne pas toucher aux éléments de présentation, qui ne seront ainsi pas rechargés, ainsi donc aucun appel au serveur pour vérifier si les différents éléments sont à recharger ou non. D'où trafic réseau diminué :1 appel ajax au lieu de 8 appels serveur classiques pour, au final, ne charger qu'un fichier. Donc surcharge possible du serveur et moins bon service au client, qui doit recharger l'intégralité de la page et la recalculer.Vincentb85 a dit:
Nouveau WRInaute
Tu marque un demi-point pour l'optimisation (moins de requêtes) mais :
- Que ce passe t'il si JavaScript est désactivé ?
- Comment sa ce passe pour le référencement avec AJAX ?
- Donc il faudrait que je me tape 2 versions (avec ou sans JS)
Un demi-point seulement car il ne faut pas oublier comment fonctionne le cache d'un navigateur :
- Que ce passe t'il si JavaScript est désactivé ?
- Comment sa ce passe pour le référencement avec AJAX ?
- Donc il faudrait que je me tape 2 versions (avec ou sans JS)
Un demi-point seulement car il ne faut pas oublier comment fonctionne le cache d'un navigateur :
http://www.mnot.net/cache_docs/
WRInaute accro
Pas besoin: https://www.webrankinfo.com/forum/passer-ajax-pour-des-liens-possible-t1194 ... l#p1139992Vincentb85 a dit:
essaie de lire ta page avec js désactivé http://www.easycode.fr/new/index.xmlVincentb85 a dit:
Nouveau WRInaute
Oui ça fonctionne très bien sur tous les navigateurs même sans JavaScript et alors ?Leonick a dit:
C'est normal y a pas de JS sur mes pages, que du XSL + CSS...
Au fait, je tout déplacé à la racine http://www.easycode.fr/ mais je dois encore modifier les types MIME "text/*" comme tu m'a suggéré...
Sinon j'ai ajouté le "sitemap.xml" que l'on peut voir en cliquant sur "Plan du site" (en pied de page) que je vais tenter de rendre lisible comme les autres pages en la transformant mais est-ce que quelqu'un sait si ça pose problème pour ce protocole si je rajoute :
<?xml-stylesheet type="application/xml" href="transform.xsl"?>
comme sur les autres XML ?
Nouveau WRInaute
C'est normal car si tu regarde dans les options de NoScript > Onglet "Avancé"
Tu pourra trouver "Interdire XSLT" (qui n'a rien à voir avec JavaScript)
Tu pourra trouver "Interdire XSLT" (qui n'a rien à voir avec JavaScript)
Bonjour,
Je pensais à une réponse à une question. Quelques personnes ici ont émis des doutes sur l’utilité de diffusé en XML directement, les avantages pas évidents, etc; et j’ai trouvé une raison basique pour laquelle ça pourrait être avantageux : une diffusion XML pourrait permettre d’aller encore plus loin que le CSS en permettant non pas seulement de changer le thème de couleur d’une page, les images de fond, etc, mais aussi en permettant d’y accéder de différente manière, via des feuilles XSLT alternatives. Si des modèles de documents devenaient assez standards, on pourrait même avoir des feuilles XSLT prédéfinies par les navigateurs, de même qu’il existe des feuilles CSS prédéfinies par les navigateurs.
Cela pourrait aussi ouvrir des perspectives intéressantes concernant l’accessibilité ! C’est encore une fois, un des effets bénéfiques d’un format sémantique, mais dont les avantages ici s’exprimeraient non-plus seulement en amont, lors de l’édition et avant publication, mais aussi maintenant en aval, au niveau de l’utilisateur final (en espérant que je m’exprime suffisamment clairement).
Concernant XML+XSLT et les moteurs de recherche, l’expérience dont je parlais et que je n’avais pas commencé, est finalement maintenant en cours : https://www.webrankinfo.com/forum/t/xml-xslt-et-les-robots-dindexation.139465/
C’est un petit test simple, mais raisonnablement fiable (voir la page de l’expérience pour les détails). Si les résultats sont suffisamment intéressants, j’en reparlerai ici, sinon, je me contenterai du café, là où le sujet a été posté. J’attends quelques temps, au moins deux semaines avant de faire les requêtes de test.
Je pensais à une réponse à une question. Quelques personnes ici ont émis des doutes sur l’utilité de diffusé en XML directement, les avantages pas évidents, etc; et j’ai trouvé une raison basique pour laquelle ça pourrait être avantageux : une diffusion XML pourrait permettre d’aller encore plus loin que le CSS en permettant non pas seulement de changer le thème de couleur d’une page, les images de fond, etc, mais aussi en permettant d’y accéder de différente manière, via des feuilles XSLT alternatives. Si des modèles de documents devenaient assez standards, on pourrait même avoir des feuilles XSLT prédéfinies par les navigateurs, de même qu’il existe des feuilles CSS prédéfinies par les navigateurs.
Cela pourrait aussi ouvrir des perspectives intéressantes concernant l’accessibilité ! C’est encore une fois, un des effets bénéfiques d’un format sémantique, mais dont les avantages ici s’exprimeraient non-plus seulement en amont, lors de l’édition et avant publication, mais aussi maintenant en aval, au niveau de l’utilisateur final (en espérant que je m’exprime suffisamment clairement).
Concernant XML+XSLT et les moteurs de recherche, l’expérience dont je parlais et que je n’avais pas commencé, est finalement maintenant en cours : https://www.webrankinfo.com/forum/t/xml-xslt-et-les-robots-dindexation.139465/
C’est un petit test simple, mais raisonnablement fiable (voir la page de l’expérience pour les détails). Si les résultats sont suffisamment intéressants, j’en reparlerai ici, sinon, je me contenterai du café, là où le sujet a été posté. J’attends quelques temps, au moins deux semaines avant de faire les requêtes de test.
Nouveau WRInaute
Par contre Internet Explorer 6, 7 et 8 n'accepte que "text/xsl" pour interpréter les stylesheet.xsl...
Bonjour,Vincentb85 a dit:
Là, la question sort du cadre de ce topic, il faudrait peut-être la reformuler ailleurs. Pour y répondre rapidement : si, je confirme le support de XSLT au moins pour IE8 et IE7. De mémoire, je suis presque sûr pour IE6 également.
Si tu le veux bien, ouvre un topic dédié, envoie moi un MP quand c’est fait, et on en reparle.
Nouveau WRInaute
Ce n'était pas une question mais une affirmation en réponse au conseil de Leonick pour remplacer :
<?xml-stylesheet type="text/xsl" href="transform.xsl"?>
par
<?xml-stylesheet type="application/xml" href="transform.xsl"?> (qui ne fonctionne pas avec IE)
A moins qu'il ne parlai du type renvoyé dans l'en-tête HTTP pour index.asp... ?
<?xml-stylesheet type="text/xsl" href="transform.xsl"?>
par
<?xml-stylesheet type="application/xml" href="transform.xsl"?> (qui ne fonctionne pas avec IE)
A moins qu'il ne parlai du type renvoyé dans l'en-tête HTTP pour index.asp... ?
Nouveau WRInaute
Salut tout le monde !
Je revient vite fait sur ce post car, depuis le temps, Google est passé sur la nouvelle version XML/XSLT du site que j'avais présenté précédemment et donc toutes mes pages semblent bien référencées.
Dites moi ce que vous vous en pensez car je ne suis pas un pro du référencement...
Je revient vite fait sur ce post car, depuis le temps, Google est passé sur la nouvelle version XML/XSLT du site que j'avais présenté précédemment et donc toutes mes pages semblent bien référencées.
Dites moi ce que vous vous en pensez car je ne suis pas un pro du référencement...
➡️ Offre MyRankingMetrics ⬅️
pré-audit SEO gratuit avec RM Tech (+ avis d'expert)
coaching offert aux clients (avec Olivier Duffez ou Fabien Faceries)
Voir les détails ici
Discussions similaires
