J’ai quelques pages en double sur mon domaine. Je dois faire référence à la balise canonical des pages en double vers la page originale en utilisant JavaScript. (Supprimer les pages en double n’est pas une option car elles génèrent un trafic considérable.)
Quelqu’un pourrait-il suggérer comment mettre à jour une balise href en utilisant JavaScript dans Discourse ?
Voilà @KranthiKiranGude, voici comment modifier l’attribut href en JavaScript. Tout d’abord, vous sélectionnez l’élément du DOM, puis vous modifiez l’attribut.
<script>
var uC = document.querySelectorAll("link[rel='canonical']")[0];
var newURL = "https://my.coolforum.com/newlink";
uC.setAttribute("href", newURL);
</script>
Bien sûr, vous aurez besoin d’une logique adaptée à la page sur laquelle vous souhaitez opérer.
Exemple de logique générique :
<script>
if("l_url_ou_id_de_la_page_réelle" == "mon_url_ou_id_de_page_intéressant")
{
var uC = document.querySelectorAll("link[rel='canonical']")[0];
var newURL = "https://my.coolforum.com/newlink";
uC.setAttribute("href", newURL);
}
</script>
J’espère que cela vous aidera.
Bonjour @neounix,
J’ai essayé votre code, mais au lieu de mettre à jour le href, une nouvelle balise script a été générée :
J’ai mis à jour ce script dans la section “/head”.
Bonjour @KranthiKiranGude,
Veuillez publier le code exact que vous avez utilisé et l’endroit précis où vous l’avez ajouté, y compris une capture d’écran de l’entrée dans la section <head> que vous avez mentionnée.
Merci !
Il est normal d’avoir un nouveau JavaScript généré lorsque vous ajoutez du JavaScript.
Vous devrez vérifier le DOM dans la console de développement web (les éléments), et non dans le code source de la page, d’ailleurs.
Je comprends.
Au fait, il vous manque une guillemet ouvrant dans votre instruction conditionnelle de script…
Bonjour @neounix,
Cela a fonctionné dans la console de développement. Cependant, dans le code source de la page, il fait toujours référence à l’URL réelle.
Si je ne me trompe pas, les moteurs de recherche se basent sur le code source de la page et non sur les éléments du DOM. Corrigez-moi si je me trompe.
Pour être honnête, je ne suis pas sûr de cela. Je pensais auparavant que les moteurs de recherche modernes (GoogleBot) lisaient le DOM, mais en y réfléchissant, il est logique qu’ils ne lisent que le code source et non le DOM.
Mais… quand j’ai cherché sur Google pour vérifier cela, il est indiqué :
Les signaux SEO dans le DOM (titres de page, méta-descriptions, balises canoniques, balises meta robots, etc.) sont pris en compte. Le contenu inséré dynamiquement dans le DOM est également crawlable et indexable. De plus, dans certains cas, les signaux du DOM peuvent même prévaloir sur des affirmations contradictoires dans le code source HTML. Cela nécessitera plus de travail, mais c’était le cas pour plusieurs de nos tests.
Référence :
https://searchengineland.com/tested-googlebot-crawls-javascript-heres-learned-220157
Bonjour @neounix,
Un grand merci pour votre aide. Je vais également faire des recherches sur cette partie. Mais vraiment, je vous suis très reconnaissant.
Bienvenue !
N’hésitez pas à revenir vers nous pour nous faire part des résultats de vos recherches.
Une autre méthode, sur laquelle je travaille récemment dans mon temps libre, consiste à modifier directement ce fichier de la bibliothèque Ruby de Discourse :
Vous pourriez envisager une approche similaire si la technique de manipulation du DOM en JavaScript ne vous donne pas satisfaction, @KranthiKiranGude
Bonjour @neounix,
J’ai testé la page à l’aide de l’outil d’inspection des URL. Google reconnaît bien l’URL mise à jour.
Parfait… ravi d’apprendre que cela a fonctionné.
Merci d’avoir testé et de nous avoir tenu au courant.
PS : Cette méthode JS DOM est bien plus simple que de manipuler canonical_url.rb 
Je ne suis pas sûr que la surcharge de la balise canonical via JavaScript fonctionnera, car cela relève davantage du niveau de l’araignée (c’est-à-dire la partie qui récupère et collecte les données) que du niveau de l’indexeur (la partie du bot qui interprète les données et les stocke dans l’index de recherche).
Conseil non sollicité : vous voudrez peut-être lire ce sujet afin de pouvoir placer ces surcharges dans un plugin :
Oui, moi non plus. La question reste encore en suspens.
Cependant, les recherches Google sur ce sujet sont très fructueuses : beaucoup de personnes le font, et beaucoup affirment que Google respecte les modifications du DOM (d’autres disent le contraire, il n’y a donc pas de consensus fort et écrasant sur le sujet). Voir par exemple :
Si je devais le faire, je (1) supprimerais la balise canonique originale de la source de la page, puis (2) j’insérerais une nouvelle balise canonique dans le DOM via JavaScript.
Ensuite, avec le temps, nous pourrons simplement consulter la Google Search Console pour voir quelle balise canonique Google a sélectionnée.
Voir également :
Comme beaucoup de personnes considèrent cela important pour le référencement (SEO), j’ai revérifié ce point, à la lumière de cette confirmation par @KranthiKiranGude.
Selon developers.google.com, Comprendre les bases du SEO pour JavaScript :
Googlebot prend en charge les composants web. Lorsque Googlebot rend une page, il aplatit le contenu du shadow DOM et du light DOM. Cela signifie que Googlebot ne peut voir que le contenu visible dans le HTML rendu. Pour vous assurer que Googlebot peut toujours voir votre contenu après son rendu, utilisez le test Mobile-Friendly ou l’outil d’inspection des URL et examinez le HTML rendu.
Puisque (1) @KranthiKiranGude a utilisé son outil d'inspection des URL lors de ses tests et (2) qu’il a confirmé que la balise canonique avait été modifiée comme prévu de cette manière, il s’ensuit que, selon Google, GoogleBot « voit » et enregistre bien ce changement de contenu du DOM après le rendu de la page.
Référence :
Oui, je soutiens tout à fait l’idée que Google aplatisse le contenu du DOM de cette manière lors de l’indexation.
Cependant, certains ou la plupart des balises meta ont leur sémantique au niveau du protocole HTTP plutôt qu’au niveau du protocole HTML, malgré le fait qu’elles soient présentes dans le HTML. J’ai mis l’accent sur « lors de l’indexation » car je ne suis pas certain que Google aplatisse le DOM de cette manière et prenne en compte l’URL canonique mise à jour lors du crawl.
(Autrement dit, je ne suis pas sûr que le contenu du DOM inclue également les « métadonnées intégrées dans le contenu ». Bien qu’il les voit de cette façon, je ne suis pas certain qu’il les utilise de cette manière).
Peut-être que cet article l’explique mieux : How Google Crawls Your Website and Indexes Your Content
Lorsque Google doit crawler des sites JavaScript, une étape supplémentaire est nécessaire, ce que le contenu HTML traditionnel n’exige pas. Il s’agit de l’étape de rendu, qui prend un peu plus de temps. L’étape d’indexation et l’étape de rendu sont des phases distinctes, ce qui permet à Google d’indexer d’abord le contenu non JavaScript
.
Pas vraiment, désolé. Cet article de www.hillwebcreations.com ne mentionne même pas le DOM, comment inspecter le DOM, etc., et à mon sens, il se lit comme « daté et subjectif » (ni actuel ni factuel).
Personnellement, je préfère ces deux références bien rédigées, toutes deux plus autoritaires, factuelles et bien documentées, selon moi :
et la première, où ils ont effectivement testé (et cela bien avant que GoogleBot ne passe à un noyau Chromium capable de lire le DOM (JavaScript) encore mieux) :
Après mes recherches, j’ai tendance à être d’accord avec les développeurs de Google : ils indexent (et obtiennent leurs signaux SEO) ce qui est trouvé en utilisant l’outil d’inspection des URL. C’est à partir de là que nous pouvons « juger » des signaux SEO et du contenu. La discussion de Google est claire, factuelle, autoritaire et non spéculative.
Puisque @KranthiKiranGude a confirmé que son lien canonique a été mis à jour à l’aide de l’outil d’inspection des URL, que Google, en tant qu’autorité, a déclaré être « tout ce dont vous avez besoin » pour voir comment Google perçoit une page d’un point de vue SEO.
Résumé technique
Puisque Google utilise les signaux SEO de ce qui peut être vu via leur outil d’inspection des URL ; et le fait que les développeurs de Google aient clairement indiqué que leurs signaux SEO peuvent être directement analysés via l’outil d’inspection des URL ; et le fait que les modifications JS apportées par @KranthiKiranGude au DOM soient visibles dans l’outil d’inspection des URL, cela est « plus que suffisant », à mon avis.
J’espère que cela vous aide.
Oui, cet article indique clairement qu’ils ont vu des balises canoniques insérées dynamiquement se comporter exactement de la même manière que si elles étaient dans le code source. Vous avez raison (et j’aurais dû lire cela plus attentivement la première fois que vous l’avez posté).
Bien que trois des quatre pages auxquelles vous faites référence dans ce sujet, y compris celle qui nous a donné la réponse, soient encore plus anciennes que l’article que j’ai posté 
Au fait @RGJ, désolé pour la confusion concernant “pas actuel”…
Quand j’utilise les termes “daté” ou “pas actuel”, je parle de concepts et d’idées, et non de la date physique d’un article.
Certaines personnes écrivent des articles avec des dates d’“aujourd’hui” mais dont les concepts sont “datés” (et erronés), tandis que d’autres ont écrit des articles il y a 10 ans qui restent très pertinents aujourd’hui.
C’est ce que j’entends par “daté” ou “pas actuel” : cela repose sur les “concepts” et non sur les dates physiques écrites sur papier ou dans un article web. Désolé pour toute confusion causée par l’utilisation de ces termes de cette manière dans ma réponse.
Ce qui est important, du moins à mon avis, c’est que nous ayons fourni une solution à @KranthiKiranGude, qu’il a confirmé fonctionner, et que, suite à votre message sceptique, nous ayons tous deux effectué des recherches supplémentaires sur ce sujet.
Nous avons vérifié (1) que cette méthode, qui consiste à modifier le lien canonique via JavaScript, est valide ; (2) que les développeurs de Google l’ont confirmé ; et (3) que nous avons un moyen de le confirmer en tant qu’utilisateurs, grâce à l’outil d’inspection des URL (comme l’a fait @KranthiKiranGude et partagé avec nous).
Meilleurs vœux et merci beaucoup pour cet “échange” sur ce sujet intéressant et pour avoir contribué à rendre la solution encore plus valide et solide.
Je passe à d’autres tâches (je lutte toujours pour apprendre Ruby on Rails après plus d’une décennie de codage en PHP) ; ce sujet est désormais pleinement “mission accomplie”
À la prochaine… tous mes vœux !
