I metadati canonici non cambiano correttamente nell'app Discourse quando non vengono caricati da un webcrawler

C’è un bug nell’applicazione Discourse relativo all’aggiornamento dell’elemento meta <link rel="canonical"> nella sezione <head> del DOM di Discourse.

In pratica, quando un client browser accede all’applicazione e questa viene caricata per la prima volta, l’elemento <link rel="canonical" href=""> viene impostato in base a quel caricamento iniziale; ma quando un utente interagisce nell’app (comportamento normale dell’utente), senza ricaricare manualmente la pagina, il link <link rel="canonical"> non si aggiorna.

Ho testato questo bug e lo ho riprodotto sul sito meta:

Fig 1. Accesso a meta dalla home page: il link canonico è corretto, così come l’elemento title.

Fig 2. Visita di un argomento. L’elemento title cambia correttamente, ma il link canonico non è corretto (non si aggiorna come dovrebbe).

Fig 3. Visita di un altro argomento. L’elemento title cambia correttamente, ma il link canonico non è corretto (non si aggiorna come dovrebbe).

Implicazioni per la SEO

Questo bug potrebbe influire negativamente sulla SEO perché, quando Google indicizza la pagina, se Googlebot non esegue un “hard reload” su ogni pagina, le informazioni canoniche risulteranno errate per ciascuna pagina (come mostrato nelle sequenze di immagini sopra).

Riproducibilità

Ho riprodotto questo bug in modo coerente sia sul sito meta che sul nostro sito.

Note

Ho già riscontrato questo tipo di problemi relativi al ciclo di vita node.js (SPA) con altri framework web (non solo Ember), in cui gli elementi del DOM non vengono aggiornati a causa dei hook del ciclo di vita (di Ember e di altri framework SPA) all’interno del framework dell’applicazione web.

1 Mi Piace

Questo non accadrà mai, poiché non serviamo la SPA a Googlebot. Puoi impostare il tuo User Agent su GoogleBot UA per vedere come funziona.

4 Mi Piace

Ciao @Falco

Grazie per la tua risposta.

Sì, non è un problema quando l’UA è impostato su GoogleBot (appena confermato).

Sono d’accordo che potrebbe non essere un problema per la SEO, dato che non servi la SPA a GoogleBot, ma rimane comunque un bug nella SPA.

Inoltre, devo riflettere sulle implicazioni del non servire la SPA a GoogleBot.

Grazie per avermi fatto notare quel “piccolo fatto”…:slight_smile:

(Nota: non sapevo che “Argomenti suggeriti” non venissero serviti a GoogleBot, ma ora lo so… grazie per l’informazione).

1 Mi Piace

Serviamo un documento completamente diverso per i crawler, poiché non tutti i crawler possono eseguire JavaScript e vogliamo che Discourse sia accessibile anche per questi client, anche se ricevono funzionalità ridotte, possono comunque accedere a tutti i contenuti.

5 Mi Piace

Grazie mille per avermelo fatto sapere.

Ora mi rendo conto che alcune discussioni precedenti su SPA, “scroll infinito” e altri problemi relativi alla SEO erano completamente errate, poiché la SPA non viene servita a GoogleBot.

Questo cambia il mio approccio ad alcuni codici personalizzati che ho scritto di recente; e ora so di dover verificare usando l’User Agent di GoogleBot nella console.

Grazie ancora per questo, @Falco! Molto apprezzato.

Domanda:

Qual è il modo migliore per aggiungere un singolo file JavaScript personalizzato all’HTML che viene renderizzato per GoogleBot?

Esiste un “modo standard” per modificare l’HTML servito ai bot?

Il motivo per cui chiedo è che abbiamo del codice personalizzato creato in un plugin che ho scritto (destinato ai bot); ma ho verificato usando l’User Agent di GoogleBot nella console (grazie ancora per avermi detto che dovevo farlo), e nessuno di quel codice personalizzato del plugin viene utilizzato da GoogleBot.

1 Mi Piace

Nel frattempo, poiché non riesco a realizzare ciò che desidero in un plugin (basato su Handlebars) per l’HTML servito ai crawler, abbiamo deciso di rimuovere semplicemente i tag canonical da Discourse, una soluzione parziale per il momento, finché non riuscirò a capire come modificare il tag canonical con qualche script JavaScript per i crawler web.

Discourse offre un ottimo meccanismo per questo tipo di modifiche nei file yml del container, ed è proprio questo che ho fatto oggi.

Sono molto grato a Discourse meta per aver sottolineato che l’app Discourse servita ai crawler (identificati) non è la stessa delle pagine servite agli utenti.

Si prega di notare che non sto raccomandando questa “soluzione provvisoria” ad altri amministratori di sistema di Discourse. Sto semplicemente condividendo ciò che ho deciso di fare, al momento, e come l’ho fatto (finché non troveremo una soluzione più interessante).

2 Mi Piace