Non sto dicendo di rimuovere le informazioni sull’ora, ma solo che sarebbe meglio inviare solo il timestamp leggibile dalla macchina per il post principale. Dal punto di vista del posizionamento di una pagina nei risultati di ricerca, un argomento del forum è fondamentalmente un articolo (post principale) con una serie di commenti. Per un motore di ricerca non importa quando sono stati fatti i commenti.
Modifica: un altro modo per passare la data a Google per un commento (a differenza dell’intera pagina) è tramite il markup schema.org.
Certo, /8 punta all’ottavo post, ma dal punto di vista di un bot e di Google, è esattamente lo stesso contenuto e URL. Se vuoi che Google sappia che /8 dovrebbe essere trattato esattamente allo stesso modo dell’argomento nei risultati di ricerca, allora il sito probabilmente non dovrebbe inviare un segnale intenzionale che sono diversi. Solo l’utente umano ha bisogno di sapere che i timestamp sono diversi, e tali informazioni sono stampate nel testo della pagina.
Se qualcuno di Google deve prendere decisioni su quando sovrascrivere gli URL canonici definiti dal sito, una di quelle eccezioni potrebbe essere qualcosa come “due timestamp diversi nei metadati intenzionali significano pagine diverse – quindi sovrascrivi l’URL canonico”.
Spesso è difficile per i programmatori pensare a tutti i casi limite a meno che non abbiano esperienza nell’incontrare quella cosa, quindi potrebbe essere inconcepibile per i programmatori di Google che pagine identiche possano avere due timestamp diversi, anche se è facile per gli utenti di Discourse capire perché ciò potrebbe accadere.
Lavoravo in un’azienda in cui parte del mio lavoro era far rimuovere i siti dal ban di Google. (Non facevano nulla di losco, ma c’erano solo problemi tecnici.) Poiché nessuno sapeva esattamente come funziona la tecnologia di posizionamento di Google, e cambia regolarmente, il punto di partenza era cercare di pensare come un ingegnere di ricerca e rimuovere qualsiasi cosa potesse essere ambigua o confusa per le macchine. Non ho mai potuto dire esattamente quale cosa abbia funzionato, ma ha sempre funzionato dopo un po’ di tempo di correzione sistematica di cose del genere.
[quote=“Falco, post:5, topic:209648”]aggiungere un’intestazione X-Robots-Tag: noindex al payload della risposta di quelle pagine.
[/quote]
Questo è incluso. Se si desidera abilitare questa funzionalità sperimentale, è necessario impostare il valore sull’impostazione del sito nascosta SiteSetting.allow_indexing_non_canonical_urls.
Al momento Google sta utilizzando correttamente gli URL canonici:
Possiamo supervisionarlo tramite Google Search Console con il report “Indice” → “Copertura” → “Pagina alternativa con tag canonico corretto”
Informazioni su Pagina alternativa con tag canonico corretto:
“Questa pagina è un duplicato di una pagina che Google riconosce come canonica. Questa pagina punta correttamente alla pagina canonica, quindi non devi fare nulla.”
Non ho idea di come i link /X per ogni risposta influiscano sulla SEO, e generalmente cerco di evitare di assecondare i capricci di Google. Ma da un punto di vista pratico, sto vedendo che Google non sta indicizzando nuove risposte in molti argomenti di lunga durata sul mio forum Discourse, mentre indicizza rapidamente la maggior parte dei nuovi argomenti. E quando indicizza una nuova risposta, il link non va alla risposta specifica ma piuttosto a /XXXX?page=YY. Non ho idea se questo sia un bene per la SEO, ma sicuramente non è un bene per gli utenti umani che cercano qualcosa di specifico.
Questo argomento è rimasto in silenzio per un bel po’. Ero curioso: qualcuno ha testato questa funzionalità sperimentale? Ora che sono passati oltre due anni, mi piacerebbe sapere se è ancora considerata un esperimento o se qualcuno può confermare che risolve il problema?
Con mia grande gioia, Google NON mi ha mostrato un lungo elenco di risposte individuali nei risultati! Gli unici risultati erano l’argomento stesso e poi la categoria in cui si trova! Questo è un OTTIMO segno!
Tuttavia, quando faccio la stessa ricerca che @RGJ ha fatto nel novembre '21, il problema persiste con quella specifica ricerca.
Ho anche eseguito una nuova ricerca di test con un altro argomento su questa community forum di Discourse e ho riscontrato un problema simile, con più risultati provenienti dallo stesso argomento.
È fantastico vedere che questo problema non esiste sempre con tutti i forum di Discourse… ma non capisco perché il problema si risolva con il forum Python mentre persiste nel forum Discourse.
Qualcuno ha qualche idea su come far sparire questo problema?
Sto pensando di migrare un forum esistente da NodeBB a Discourse, ma prima di farlo, devo sapere che c’è un modo per risolverlo in modo che non crei un incubo SEO per il nostro dominio.
Quella ricerca restituisce un piccolo numero di link all’argomento, ma l’argomento ha 58 post, quindi ci si aspetterebbe di vedere 58 risultati individuali se gli URL /nn venissero tutti indicizzati. È possibile che il crawler stia vedendo link a post nell’argomento in altri post, quindi indicizza quelle singole pagine?
Detto questo, disattivare /nn sarebbe un incubo per il mio forum. Ci sono spesso lunghe discussioni su come risolvere i problemi che potrebbero contenere più soluzioni, questa sembra funzionare, seguita qualche post dopo da un post “oh no, non funziona”. Spesso ci riferiamo ai post di “correzione” effettivi quando qualcun altro ha quel problema in futuro. Se tutto ciò che puoi fare è indirizzare le persone a una pagina che contiene la risposta da qualche parte e che contiene anche soluzioni errate, non aiuterà nessuno.
E, sì, potrebbero esserci modi in Discourse per evidenziare le soluzioni, ad esempio il plugin Solved, ma il mio forum ha 22 anni di post in cui solo gli ultimi 12 mesi sono stati creati in Discourse.
Ehi Seth!
Attualmente sto riscontrando lo stesso problema sul mio progetto.
Ho più URL per una singola pagina a causa della paginazione.
Penso che questo post possa essere utile.
Sono riuscito a utilizzare questo codice per reindirizzare tutte le mie pagine paginate alla loro pagina canonica.
Discourse non utilizza Apache2. Può essere utilizzato davanti a Discourse come proxy inverso, ma è ben lontano dall’ottimale in questo caso.
E non capisco affatto questo argomento. La struttura dell’URL non ha nulla a che fare con la SEO. Ma forse il motivo è che non capisco — ma il mio forum ha ancora un valore SEO piuttosto elevato, ma deriva dal contenuto.
