7.4 : Vers la normalisation des raccourcis rewrités
Presque un mois est passé depuis la sortie de la version 7.4 de Yacs. Tout ou presque a été optimisé pour offrir aux utilisateurs de Yacs un site digne d'un prestataire de service SEO...
Mais il reste encore quelques optimisations qui resiste, encore et toujours, à l'envahisseur Yacsien !
Objet : Raccourci balises YACS incorrect :
Le raccourci
Même constat pour le raccourci GO qui renvoit toujours vers l'ancienne écriture.
En l'état actuel de l'organisation de Yacs en matière d'optimisation SEO, il est impératif que tous les liens renvoient vers le même url.
Présence connue : Balise "article", Balise "go"
Solution : Aligner le rendu de cette balise
Ajout : Objet : Raccourci balises YACS incorrect :
Le raccourci [*toc] renvoyé par les raccourci yacs [*title] et [*subtitle] pourraient renvoyer vers des raccourci interne (ancre) portant le nom du title et non un numéro. Toujours dans l'idée qu'un lien, quelque qu'il fut, doit comporter une maximum d'indication textuelle... Difficulté : Remplacer les espaces par des tirets, mais je crois que gnapz est déjà sur le coup Solution : Indiquer le titre et non le numéro.
Objet : Lien vers la raçine du site
Les retours vers la page d'accueil en "index.php" sont à proscrire. Pour google, il existe deux pages : www.333monsite.fr/ et www.333monsite.fr/index.php avec un contenu identique.
C'est ce que l'on appel du "duplicate content". Ces pages peuvent être potentiellement pénalisées par les algorithmes des moteurs de recherches. La cause : Du contenu identique dupliqué sur plusieurs url.
Présence connue : Header (raccourci image), Menu, tabs
Solution : supprimer les retours vers index.php et toujours renvoyer vers la raçine.
Dans l'immédiat seul l'url de la page d'accueil est concerné. Mais à terme, c'est toutes les relations aux index.php (sections, articles, etc...) qui sont à proscrire pour la même raison.
Objet : Layout à actualiser
L'ensemble des Layouts ne fonctionnent toujours pas correctement. En n'indiquant pas le numéro de section, il y a des risques de "duplicate content"
Présence connue : Home_layout
Solution : Aligné le rendu des liens des home_layout sur ceux de article_layout qui fonctionnent parfaitement.
Ajout 2: Objet : Liens de renvoi des étiquettes incorrectes dans les articles.
Dans un article qui à fait l'objet d'un "étiquetage" les liens qui renvoient, en haut de la page de l'article, aux étiquettes (catégories) correspondant ne contiennent pas le numéro de section (format incorrect)
Je pense que cela est modifiable dans les layouts ?
Présence connue : étiquettes de sections, catégories. Solution : Indiquer le numéro de section.
Objet : URL rewriting dans les catégories
L'ensemble des liens des catégories et sous catégories ne sont toujours pas rewrité.
Présence connue : Catégories, sitemap
Solution : Rewriter les liens et retour de liens des catégories selon le format standard :
../45/nom_categorie
A coté de ces quelques points encore en cours d'amélioration, Yacs fait un véritable "bon" à chaque nouvelle version.
La carte sitemap, outil incontournable pour le référencement, en particulier avec Google, est quasiment parfaite, les liens contextuels sont tous rewrités, l'ensemble des liens présents dans une propulsion Yacs fonctionnent tous grâce à un renommage d'une simplicité enfantine (il suffit de donner un surnom à une page pour que celle ci soit AUTOMATIQUEMENT rewrité, si votre configuration serveur le permet.).
Vous ajoutez à cela des balises "title" qui s'adaptent au titre de vos pages, une Gestion des erreurs 404 et une amélioration systématique au cous des versions et vous obtenez une solution qui n'a rien à envier aux plus grandes !
Objet : Raccourci balises YACS incorrect :
Le raccourci
[/article=nom de l'article] renvoi vers l'url sans le numéro de section : ../../nomdusite/nom-de-atricle au lieu de ../../nomdusite/44/nom-de-atricle.Même constat pour le raccourci GO qui renvoit toujours vers l'ancienne écriture.
En l'état actuel de l'organisation de Yacs en matière d'optimisation SEO, il est impératif que tous les liens renvoient vers le même url.
Présence connue : Balise "article", Balise "go"
Solution : Aligner le rendu de cette balise
- - - - - - - - - - - - - - - - - - - -
Ajout : Objet : Raccourci balises YACS incorrect :
Le raccourci [*toc] renvoyé par les raccourci yacs [*title] et [*subtitle] pourraient renvoyer vers des raccourci interne (ancre) portant le nom du title et non un numéro. Toujours dans l'idée qu'un lien, quelque qu'il fut, doit comporter une maximum d'indication textuelle... Difficulté : Remplacer les espaces par des tirets, mais je crois que gnapz est déjà sur le coup Solution : Indiquer le titre et non le numéro.
Objet : Lien vers la raçine du site
Les retours vers la page d'accueil en "index.php" sont à proscrire. Pour google, il existe deux pages : www.333monsite.fr/ et www.333monsite.fr/index.php avec un contenu identique.
C'est ce que l'on appel du "duplicate content". Ces pages peuvent être potentiellement pénalisées par les algorithmes des moteurs de recherches. La cause : Du contenu identique dupliqué sur plusieurs url.
Présence connue : Header (raccourci image), Menu, tabs
Solution : supprimer les retours vers index.php et toujours renvoyer vers la raçine.
Dans l'immédiat seul l'url de la page d'accueil est concerné. Mais à terme, c'est toutes les relations aux index.php (sections, articles, etc...) qui sont à proscrire pour la même raison.
Objet : Layout à actualiser
L'ensemble des Layouts ne fonctionnent toujours pas correctement. En n'indiquant pas le numéro de section, il y a des risques de "duplicate content"
Présence connue : Home_layout
Solution : Aligné le rendu des liens des home_layout sur ceux de article_layout qui fonctionnent parfaitement.
- - - - - - - - - - - - - - - - - - - - - - - - -
Ajout 2: Objet : Liens de renvoi des étiquettes incorrectes dans les articles.
Dans un article qui à fait l'objet d'un "étiquetage" les liens qui renvoient, en haut de la page de l'article, aux étiquettes (catégories) correspondant ne contiennent pas le numéro de section (format incorrect)
Je pense que cela est modifiable dans les layouts ?
Présence connue : étiquettes de sections, catégories. Solution : Indiquer le numéro de section.
Objet : URL rewriting dans les catégories
L'ensemble des liens des catégories et sous catégories ne sont toujours pas rewrité.
Présence connue : Catégories, sitemap
Solution : Rewriter les liens et retour de liens des catégories selon le format standard :
../45/nom_categorie
A coté de ces quelques points encore en cours d'amélioration, Yacs fait un véritable "bon" à chaque nouvelle version.
La carte sitemap, outil incontournable pour le référencement, en particulier avec Google, est quasiment parfaite, les liens contextuels sont tous rewrités, l'ensemble des liens présents dans une propulsion Yacs fonctionnent tous grâce à un renommage d'une simplicité enfantine (il suffit de donner un surnom à une page pour que celle ci soit AUTOMATIQUEMENT rewrité, si votre configuration serveur le permet.).
Vous ajoutez à cela des balises "title" qui s'adaptent au titre de vos pages, une Gestion des erreurs 404 et une amélioration systématique au cous des versions et vous obtenez une solution qui n'a rien à envier aux plus grandes !
Comments
Un point de détail, il faut penser aux confusions sur une base url/surnom car au bout on a quoi, une section, une catégorie, un article, un fichier, un lien, une image, etc ?
Articles, fichiers, images et liens sont du contenu alors j'obterais pour 3 solutions (à terme):
- un rewriting url/section/sous-section/contenu
- Un module de recherche de doublons en javascript (auto-completion) qui interdirait la saisie d'un surnom déjà utilisé.
- Rendre le champ surnom aussi visible et important que le titre (car ce sera le cas).
Je suis sur un bout de code pour générer un surnom codifié à partir du titre ... mais je bute sur des pb stupides qui n'ont rien à voir avec le boulot: impossible de récupérer le titre et le nick_name d'un article dans articles/edit.php !!! Gros nul quand même ! Pour ceux qui y arrivent, je pars sur le principe suivant:
- utilisation de preg_replace
- suppression des codes yacs et autres balises html
- suppression des caractères de contrôle php (:control:)
- suppression de la ponctuation (:punct:)
- remplacement des espaces par des soulignements (_)
- remplacement des caractères accentués par des universels.
C'est pas compliqué, quelques boucles d'analyses et remplacement des caractères ... mais j'arrive pas à récupérer ces 2 champs titre et nick_name !!! Dingue, ça !
GnapZ :
url/section/sous-section/contenu
Cela pourrait-être la seconde étape de ce grand chantier du rewriting.
En espérant qu'à terme, plus aucun numéro ne sera affiché, mais seulement les surnoms des section/categorie/page etc...
View.php devra disparaitre lui aussi pour que tout soir parfait.
Ca me laisse le temps de poster pas mal de message à chaque nouvelle version d'ici là
Un module de recherche de doublons en javascript (auto-completion) qui interdirait la saisie d'un surnom déjà utilisé
C'est l'un des avantages de la numérotation. Elle permet d'éviter d'arriver à des doublons trops facilement. Mais c'est vrai que ce que tu proposes est une excellente idée.
Rendre le champ surnom aussi visible et important que le titre (car ce sera le cas)
Si tu arrives à finaliser ton script pour la reprise du titre dans l'url, ce ne sera même plus utile
Bien que le surnom puisse permettre de fournir une url différente du titre. Pratique pour éviter les apostrophes et autres caractères spéciaux.
En attendant, c'est vrai que l'on pourrait rendre le champs "surnom" beaucoup plus visible lors de la création d'une page... Ca serait un premier pas intéressant.
Très très intéressant cette discussion.
Juste une remarque en passant :
" Un module de recherche de doublons en javascript (auto-completion) qui interdirait la saisie d'un surnom déjà utilisé
C'est l'un des avantages de la numérotation. Elle permet d'éviter d'arriver à des doublons trops facilement. Mais c'est vrai que ce que tu proposes est une excellente idée. "
Je trouve l'idée excellente, c'est aussi un point que nous avons abordé pour un de nos projets. Attention toutefois : il me semble important de pouvoir autoriser des doublons de surnom, et en particulier pour les langues : une même page en anglais, français et italien par exemple devrait pouvoir avoir le même surnom et renvoyer après, selon les préférences du visiteur, vers la page localisée de son choix.
En dehors de cela, c'est vrai qu'un "catalogue dynamique" des termes déjà utilisés serait un vrai plus. Et j'irai même plus loin en adoptant cette fonctionnalité pour la création de catégories par mots clés sur le même principe, ou encore pour le choix des mots-clés à utiliser pour les pages et sections.
-----
Agnès
Il n'y a pas de problèmes, que des solutions.
Pour Agnès : A voir La valse des étiquettes Je ne sais pas si c'est l'idée que tu avançais au sujet des catégories, mais qui sais ? :p
Un petit ajout :
Objet : Raccourci balises YACS incorrect :
Le raccourci [*toc] renvoyé par les raccourci yacs [*title] et [*subtitle] pourraient renvoyer vers des raccourci interne (ancre) portant le nom du title et non un numéro. Toujours dans l'idée qu'un lien, quelque qu'il fut, doit comporter une maximum d'indication textuelle... Difficulté : Remplacer les espaces par des tirets, mais je crois que gnapz est déjà sur le coup :p
Autre petit ajout, avant l'arrivé de la 7.5 !
Objet: Liens de renvoi des étiquettes incorrectes dans les articles.
Dans un article qui à fait l'objet d'un "étiquetage" les liens qui renvoient, en haut de la page de l'article, aux étiquettes (catégories) correspondant ne contiennent pas le numéro de section (format incorrect)
Je pense que cela est modifiable dans les layouts ?
Présence connue : étiquette de section, catégories Solution : Indiquer le numéro de section.
Je suis toujours sur ce script (délaissé quelques jours) pour les nick_names.
Pour l'url-rewriting final, ne serait-il pas mieux d'intégrer la langue en premier comme on le voit dans tous les grands sites internationnaux ?
"htttp://www.yetanoz.com/fr/section/article.php"
Bien sûr, je parle de l'idée finale ...
GnapZ :
Oui, ça serait une excellente idée.
Mais comme tu le dit, il va y avoir quelques étapes avant d'arrivé à cela.
Pour rappel on est parti de :
-http://www.cecicela.yacs/section/view.php/33
puis
-http://www.cecicela.yacs/section/view.php/article
Actuellement on est sur :
-http://www.cecicela.yacs/section/view.php/33/article
Et par étape ont devrait arriver progressivement a :
-http://www.cecicela.yacs/section/33/article
(suppression du view.php)
-http://www.cecicela.yacs/section/nom_section/article
(remplacement du numéro par le nom de la section/catégorie parente) - QUI RESTE A DÉBATTRE !
-http://www.cecicela.yacs/nom_section/article
(suppression du paramètre section (ou article, ou comment)
Pour atteindre l'optimisation optimale :
-http://www.cecicela.yacs/fr/nom_section/article
(ajout du paramètre de langue)
Le débat reste ouvert sur l'objectif final à atteindre et le risque de doublonnage des articles/sections... De toute façon, il est plus sage de procéder par touches successives afin de tester l'ensemble des urls et vérifier le bénéfice des évolutions.
Je ne sais pas si je vais dire une bêtise mais vu l'activité de l'internationalisation actuelle, je pencherais pour placer la langue dans l'url en priorité.
On pourrait se baser sur la langue de l'article final (visé par l'url) suivant le choix effectué dans la liste en bas d'article.
Je pense en effet qu'en évolution vers le professionalisme tel que nous sommes, c'est un point primordial. De plus, cela implique sûrement une restructuration de l'arborescence des sections et donc du site.
Pour le reste, je pense qu'il vaut mieux déjà vérifier que toutes les url respectent la même structure, ce qui n'est pas encore le cas je crois.
C'est juste mon avis ... qu'en pensez-vous tout le monde ?
GnapZ: Je réagis vite, sans avoir vu tout le fil de discussion, juste pour témoigner que la norme HTTP, comme leur implémentation dans Apache, privilégient la négociation du contenu plutôt que leur détermination dans une adresse web. En clair, la tendance normative serait plutôt d'éviter les 'fr' et autres gracieusetés dans les URLs... Je vous invite à regarder ce qui a été fait pour Apache 1.3 VF, par exemple
When I last did some SEO work (a few years ago), search engines liked article/view.php/342 as much as /view.php/234/MyArticle ...
Has this changed ?
Also, a problem I know of with using the title - nick name in the url is, if the title changes, this reduces the URL's effectiveness.
Google might be better at handling this now ?
Cheers, Nick
-----
Nick
Rate this page
Posted by ThierryP on May 21 2007, commented by GnapZ on Jul. 4 2007, (popular)
