Ho alcune pagine duplicate sul mio dominio e devo impostare il tag canonical delle pagine duplicate sulla pagina originale utilizzando JavaScript. (Eliminare le pagine duplicate non è un’opzione, poiché ricevono un traffico considerevole)
Qualcuno può suggerire come aggiornare un tag href utilizzando JavaScript in Discourse?
Ecco a te @KranthiKiranGude, ecco come puoi modificare l’attributo href in JavaScript. Prima selezioni l’elemento DOM, poi modifichi l’attributo.
<script>
var uC = document.querySelectorAll("link[rel='canonical']")[0];
var newURL = "https://my.coolforum.com/newlink";
uC.setAttribute("href", newURL);
</script>
Ovviamente, avrai bisogno di una logica specifica in base alla pagina su cui vuoi operare.
Esempio generico di logica:
<script>
if("the_actual_page_url_or_id" == "my_interesting_page_url_or_id")
{
var uC = document.querySelectorAll("link[rel='canonical']")[0];
var newURL = "https://my.coolforum.com/newlink";
uC.setAttribute("href", newURL);
}
</script>
Spero che questo ti sia d’aiuto.
1 Mi Piace
Ciao @neounix,
Ho provato il tuo codice, ma invece di aggiornare l’href è stato generato un nuovo tag script:
Ho aggiornato questo script nella sezione “/head”.
1 Mi Piace
Ciao @KranthiKiranGude
Per favore, pubblica il codice esatto che hai utilizzato e dove esattamente l’hai inserito, includendo uno screenshot della voce nella sezione </head> che hai menzionato.
Grazie!
È normale che venga generato nuovo JavaScript quando aggiungi altro JavaScript.
Per inciso, dovrai controllare il DOM nella console per lo sviluppo web (gli elementi), non nel codice sorgente della pagina.
1 Mi Piace
1 Mi Piace
Capisco.
A proposito, nel tuo script manca una virgoleta di apertura nella condizione dell’istruzione…
1 Mi Piace
Ciao @neounix,
Ha funzionato nella Dev Console. Tuttavia, nella Page Source fa ancora riferimento all’URL effettivo.
Se non sbaglio, i motori di ricerca indicizzano la Page Source e non gli elementi DOM. Correggetemi se sbaglio.
1 Mi Piace
Onestamente, non ne sono sicuro. Prima pensavo che i moderni motori di ricerca (GoogleBot) leggessero il DOM, ma ora che ci penso, ha senso che i motori di ricerca leggano solo il sorgente e non il DOM.
Tuttavia… quando ho cercato su Google per verificare questo, ho trovato:
I segnali SEO nel DOM (titoli di pagina, meta descrizioni, tag canonici, tag meta robots, ecc.) vengono rispettati. I contenuti inseriti dinamicamente nel DOM sono anche indicizzabili e indicizzabili. Inoltre, in alcuni casi, i segnali DOM possono persino avere la precedenza su dichiarazioni contraddittorie nel codice sorgente HTML. Questo richiederà più lavoro, ma è stato il caso per diversi dei nostri test.
Riferimento:
https://searchengineland.com/tested-googlebot-crawls-javascript-heres-learned-220157
1 Mi Piace
Ciao @neounix,
Grazie mille per il tuo aiuto. Farò anche delle ricerche su questa parte. Ma sono davvero grato a te.
1 Mi Piace
Benvenuto!
Ti preghiamo di rispondere e farci sapere i risultati delle tue ricerche.
Un altro metodo, su cui ho lavorato nel mio tempo libero ultimamente, è modificare direttamente questo file della libreria Ruby di Discourse:
Potresti considerare qualcosa di simile se non ottieni risultati con la tecnica JS di manipolazione del DOM, @KranthiKiranGude
1 Mi Piace
Ciao @neounix,
Ho testato la pagina utilizzando lo strumento di ispezione URL: Google ha riconosciuto l’URL aggiornato.
2 Mi Piace
Perfetto… sono contento di sapere che ha funzionato.
Grazie per il test e per il feedback.
PS: Quel metodo JS DOM è molto più semplice rispetto alla manipolazione di canonical_url.rb 
1 Mi Piace
Non sono sicuro che l’override del canonical tramite JavaScript funzioni, poiché si tratta di qualcosa che riguarda più il livello dello spider (ovvero la parte che recupera e raccoglie i dati) rispetto al livello dell’indicizzatore (la parte di un bot che interpreta i dati e li archivia nell’indice di ricerca).
Consiglio non richiesto: potresti voler leggere questo argomento in modo da poter inserire questi override in un plugin:
2 Mi Piace
Sì, anch’io. La questione è ancora in discussione.
Tuttavia, le ricerche su Google relative a questo argomento offrono molti risultati: molte persone lo fanno e molte affermano che Google rispetta le modifiche al DOM (mentre altre sostengono il contrario, quindi non sembra esserci un consenso forte e schiacciante sull’argomento). Si veda, ad esempio:
Penso che, se dovessi farlo, procederei così: (1) rimuovendo il tag canonical originale dal codice sorgente della pagina e (2) inserendo un nuovo tag canonical nel DOM tramite JavaScript.
Successivamente, nel tempo, potremo semplicemente consultare la Google Search Console per verificare quale versione Google ha selezionato come canonical.
Vedi anche:
1 Mi Piace
Poiché molte persone ritengono questo aspetto importante per la SEO, ho ricontrollato la questione alla luce di questa conferma da parte di @KranthiKiranGude:
Secondo developers.google.com, Comprendere le basi della SEO per JavaScript:
Googlebot supporta i componenti web. Quando Googlebot renderizza una pagina, appiattisce il contenuto del shadow DOM e del light DOM. Ciò significa che Googlebot può vedere solo il contenuto visibile nell’HTML renderizzato. Per assicurarsi che Googlebot possa ancora vedere il contenuto dopo il rendering, utilizzare il test di compatibilità mobile o lo strumento di ispezione URL ed esaminare l’HTML renderizzato.
Poiché (1) @KranthiKiranGude ha utilizzato il suo strumento di ispezione URL durante i test e (2) ha confermato che il canonical è stato modificato come previsto in questo modo, ne consegue che, secondo Google, Googlebot “vede” effettivamente e registra questa modifica del contenuto del DOM dopo il rendering della pagina.
Riferimento:
1 Mi Piace
Sì, sostengo pienamente l’idea di Google di appiattire i contenuti del DOM in questo modo durante l’indicizzazione.
Tuttavia, alcuni/molti tag meta hanno la loro semantica a livello del protocollo HTTP piuttosto che a livello del protocollo HTML, nonostante siano presenti nell’HTML. Ho enfatizzato “durante l’indicizzazione” perché non sono sicuro che appiattisca il DOM in questo modo e tenga conto dell’URL canonico aggiornato durante la scansione.
(Per dirla in altro modo, non sono sicuro che i contenuti del DOM includano anche i “metadati incorporati nel contenuto”. Sì, li vede in quel modo, ma non sono sicuro che li utilizzi in quel modo).
Forse questo articolo lo spiega meglio: How Google Crawls Your Website and Indexes Your Content
Quando Google deve scansionare siti JavaScript, è necessaria una fase aggiuntiva che il contenuto HTML tradizionale non richiede. È nota come fase di rendering, che richiede un tempo aggiuntivo. La fase di indicizzazione e la fase di rendering sono fasi separate, il che permette a Google di indicizzare prima il contenuto non JavaScript
.
1 Mi Piace
Non proprio, scusa. Quell’articolo di www.hillwebcreations.com non menziona affatto il DOM, come ispezionarlo, ecc. e almeno per me sembra “datato e opinabile” (non aggiornato né fattuale).
Personalmente, preferisco questi due riferimenti ben scritti, entrambi più autorevoli, fattuali e ben documentati, a mio avviso:
e il primo, dove hanno effettivamente testato (e ciò avveniva molto prima che GoogleBot passasse a un core Chromium in grado di leggere il DOM (JavaScript) anche meglio):
Abbiamo testato come Googlebot esegue la scansione di JavaScript e ecco cosa abbiamo imparato
Dopo la mia ricerca, tendo a concordare con gli sviluppatori di Google sul fatto che indicizzeranno (e ricaveranno i segnali SEO) ciò che viene rilevato utilizzando lo Strumento di ispezione URL, ed è da questo che possiamo “valutare” i segnali SEO e i contenuti. La discussione di Google è chiara, fattuale, autorevole e non speculativa.
Poiché @KranthiKiranGude ha confermato che il suo link canonico è stato aggiornato utilizzando lo Strumento di ispezione URL, che Google, in quanto autorità, ha dichiarato essere “tutto ciò che serve” per vedere come Google visualizza una pagina dal punto di vista SEO.
Riepilogo tecnico
Poiché Google utilizza i segnali SEO da ciò che può essere visto tramite lo Strumento di ispezione URL; e il fatto che gli sviluppatori di Google abbiano chiaramente dichiarato che i loro segnali SEO possono essere analizzati direttamente tramite lo Strumento di ispezione URL; e il fatto che le modifiche JS apportate da @KranthiKiranGude al DOM siano visibili nello Strumento di ispezione URL, questo è “più che sufficiente”, a mio avviso.
Spero sia utile.
1 Mi Piace
Sì, quell’articolo afferma chiaramente che hanno visto i tag canonical inseriti dinamicamente comportarsi esattamente come se fossero nel codice sorgente. Hai ragione (e avrei dovuto leggerlo più attentamente la prima volta che l’hai pubblicato).
Sebbene tre delle quattro pagine a cui ti riferivi in questo argomento, inclusa quella che ci ha fornito la risposta, siano persino più vecchie di quell’articolo che ho pubblicato 
A proposito, @RGJ, scusa per la confusione riguardo a “non attuale”…
Quando uso i termini “datato” o “non attuale”, mi riferisco a concetti e idee, non alla data fisica di un articolo.
Alcune persone scrivono articoli con la data di “oggi” ma i concetti sono “datati” (e sbagliati), mentre altre hanno scritto articoli dieci anni fa che sono ancora altamente rilevanti oggi.
È questo che intendo per “datato” o “non attuale”: si basa sui “concetti”, non sulle date fisiche scritte su carta o in un articolo web. Scusa per qualsiasi confusione causata dall’uso di questi termini in questo modo.
Ciò che è importante, almeno secondo me, è che abbiamo fornito una soluzione a @KranthiKiranGude, che ha confermato che funziona. Inoltre, in base al tuo post scettico, abbiamo entrambi condotto ulteriori ricerche su questo problema.
Abbiamo verificato (1) che questo metodo, ovvero modificare il link canonico tramite JavaScript, è valido; (2) che gli sviluppatori di Google lo hanno confermato; e (3) che abbiamo un modo per confermarlo come utenti, utilizzando lo Strumento di ispezione URL (come ha fatto e condiviso con noi @KranthiKiranGude).
Tanti auguri e grazie mille per il “dibattito” su questo argomento interessante e per aver contribuito a rendere la soluzione ancora più valida e solida.
Ora passo ad altri compiti (sto ancora lottando per imparare Ruby on Rails dopo oltre un decennio di programmazione in PHP) ; dato che questo argomento è completamente “missione compiuta”
Fino alla prossima volta… tanti auguri!
1 Mi Piace