Tous les articles pour SEO

  • Comment faire du routage strict avec Vue Router et Vue Server Renderer ?

    L'URL www.example.com/foo n'est pas la même URL que www.example.com/foo/. Or, si cela n'est pas gênant dans une application monopage (plus loin SPA pour « Single Page Application »), cela devient critique pour de l'optimisation de moteur de recherche (plus loin SEO pour « Search Engine Optimization ») dès lors que le contenu est généré côté serveur.

    Côté serveur, les routeurs comme celui d'Express possèdent un mode strict pour que l'adresse /foo ne soit pas la même que l'adresse /foo/. Mais qu'en est t-il de Vue Router ? Et surtout, comment faire concorder le routage client et le routage serveur pour que l'hydratation (la prise en main côté client d'un rendu côté serveur) concorde ?

    Je vous le donne en mille : de base, là où Express en mode strict vous renverra une page 200 pour /foo/ et une page 404 pour /foo, Vue Router lui, en mode strict, vous renverra exactement l'inverse !

    Comment dans ce cas utiliser Vue Router et Vue Server Renderer pour du routage strict dont les moteurs de recherche sont si friand pour une SEO à toute épreuve ? La réponse à la fin !

    Cependant, afin que ce billet soit utile également pour ceux n'ayant pas (encore) ce problème et qui souhaitent découvrir par l'exemple comment fonctionne du SSR avec Vue (et de facto, qu'est-ce que c'est réellement), je vais élaborer un code pour vous accompagner dans cette compréhension, pas à pas. Seulement ensuite nous mettrons en évidence notre problème avant de le résoudre.


  • Vue + NodeAtlas : de l'art du SSR ou Rendu Côte Serveur avec JavaScript

    Nous allons voir dans cet article comment faire du rendu côté serveur ou SSR (Server-Side Render) avec le framework JavaScript client MVVM (Modèle Vue Vue-Modèle) Vue couplé au framework JavaScript serveur MVC(2) (Model View Controller) NodeAtlas !

    Alors ce titre parle peut-être aux habitués des architectures clientes MVVM qui ont des difficultés avec le référencement et semble peut-être barbare pour d'autres. Lançons nous dans une petite explication histoire de rendre cet article intéressant également pour les néophytes : comprenons le problème et trouvons la solution à travers cette page.

    Quel est le problème traité dans cet article ?

    Le problème avec les frameworks MVVM client est qu'ils construisent le site à partir de rien. Fouillez la source du code de la réponse HTTP de la page courante, celle lue par les indexeurs de contenus ou les navigateurs sans JavaScript ; il n'y a rien. Aussi, si je créé une liste d'actions futures pour la roadmap de ma super App, et que je souhaite pouvoir manipuler aisément (ajout et retrait) ses éléments grâce à un coupleur de données vue-modèle ; le revers de la médaille sera que les informations utilisées pour cette construction proviendront de fichier JavaScript ou morceau de HTML qui ne veulent rien dire pour les indexeurs où même les validateurs de page. Vos sites sont donc souvent « SEO merdique » et « W3C bancale ».

    Quel solution ?

    Le SSR ou Rendu Côté Serveur. Voyons ça au travers de cette page exemple avec Vue et NodeAtlas !


  • Outil Munchkin : Listez, Mélangez, Classez, Triez et Créez vos Jeux !

    Je suis fan de Munchkin depuis des années maintenant ! Mais j'ai un assez gros problème depuis quelques temps avec le Munchkin : plus les extensions augmentes et plus j'ai des difficultés à pouvoir jouer avec des jeux équilibrés. Vous avez peut-être le même sentiment et si vous vous êtes déjà confronté aux problèmes listés ci-après, cette page peut vous être utile !

    Elle va vous permettre de :


  • Utiliser AngularJS en respectant les recommandations W3C et SEO

    AngularJS est un régale pour toute création d'Application Web de petite et moyenne taille. J'entends par là, des ensembles d'interfaces web ou l'utilisateur est sollicité à participer au remplissage de contenu par l'intermédiaire de champs, listes, boutons, etc.

    AngularJS

    Le principe est le suivant : sortir le contenu utile du HTML pour le ranger dans un scope JavaScript afin de le manipuler plus aisément et parsemer le HTML de référence à ce scope de contenu. L'avantage est que le contenu a sa propre vie, et n'est plus figé dans le HTML et surtout toute mise à jour de contenu dans le JavaScript entraîne sa mise à jour dans le HTML, bien pratique.

    Le revers de la médaille est que la source HTML mangée par les moteurs de recherche pour le référencement ne ressemble plus qu'à un ensemble de variables, et les balises et attributs HTML rencontrés font pâlir n'importe quel validateur W3C.

    C'est parti pour un tutoriel vous expliquant comment contenter le W3C pour pouvoir correctement implémenter vos recommandations SEO avec AngularJS.


  • Les balises h1 multiples autorisées en HTML5

    C'est suite à plusieurs conversations m'invitant à ne pas utiliser de multiples balises h1 dans mes intégrations HTML (et plus récemment une demande « insistante » sur le fait de ne pas le faire) que je me vois forcé de marcher sur les pas de Raphaël Goetter -qui avait déjà abordé le sujet- pour expliquer pourquoi : en plus d'être tout à fait valide, cette pratique est bénéfique.

    Tout document HTML5 dispose de cloison de contenu (Sectionneur de contenu) que sont article, aside, nav et section. Ces zones de contenu peuvent chacune contenir une balise header et footer (ne cloisonnant pas elles-mêmes le contenu) et de multiple éléments de titrage (Titre en HTML) allant de h1 à h6.

    Bien que l'utilisation de plus d'une balise h1 ai pu rationnellement laisser à débattre (même si techniquement les standards ne l'interdise pas), les recommandations et même l'interdiction d'une telle pratique ne sont plus pertinentes et rationnelles à l'heure du HTML5.