Discourse risponderà ora con un’intestazione X-Robots-Tag: noindex quando la pagina richiesta non è la pagina canonica per una risorsa.
Mentre Discourse utilizza un design a scorrimento automatico sia per gli elenchi di argomenti che per gli argomenti, questo non è ciò che mostriamo ai crawler dei motori di ricerca, come GoogleBot. I motori di ricerca vedono argomenti paginati, con 20 post in ogni pagina. Tuttavia, poiché gli utenti possono collegarsi a post specifici nei loro post e lo faranno utilizzando il formato URL /t/title/topic_id/post_id, questi verranno rilevati dai crawler e aggiungeranno contenuti duplicati nei risultati di ricerca del tuo sito e sprecheranno il prezioso e limitato budget di scansione che il tuo dominio ha.
Per alleviare questo problema, la nostra community di utenti ha suggerito di aggiungere X-Robots-Tag: noindex agli URL come gli URL specifici dei post, che siamo riusciti ad espandere a tutti gli URL non canonici in Discourse. Questo è stato rilasciato come un’impostazione del sito nascosta e disabilitato per impostazione predefinita 3 mesi fa, durante i quali abbiamo sperimentato l’abilitazione di questa intestazione sui siti della community e su meta.discourse.org.
Poiché i risultati di questo periodo sembrano finora buoni, abbiamo appena impostato questa impostazione per essere effettiva per impostazione predefinita.
Se per qualche motivo non desideri questo comportamento sulla tua istanza, puoi ancora abilitare l’indicizzazione delle pagine non canoniche eseguendo docker exec -i app rails runner \"SiteSetting.allow_indexing_non_canonical_urls = true\" sul tuo server.
Non aspettarti cambiamenti drastici nei crawl e nei risultati di ricerca dall’oggi al domani, ma nei prossimi mesi dovresti vedere una diminuzione dei crawl e dei risultati di ricerca sulle pagine specifiche dei post, il che si tradurrà in più tempo di scansione dedicato ai nuovi argomenti del tuo sito e ai contenuti che non sono stati ancora indicizzati a causa di vincoli di budget di scansione sul tuo dominio.
TL;DR: Non bloccare le pagine non canoniche: puntale semplicemente a un URL corretto tramite \u003clink rel=\"canonical\" … \u003e: è stato creato per questo.
Questa funzionalità potrebbe danneggiare il link building SEO a lungo termine:
Tutti i deep-link alle risposte all’interno degli argomenti si trovano ora su pagine noindex! A Google piacerà?
In realtà, un tag canonical che punta sempre all’URL dell’argomento, anche per le pagine con deep-link a una risposta, dovrebbe fare perfettamente il suo lavoro, senza aggiungere X-Robots-Tag: noindex:
Alla prima scansione di una pagina con deep-link a una risposta, Google riconosce che l’URL della pagina (risposta all’interno dell’argomento) non corrisponde all’URL canonico e decide quindi di scansionare solo l’URL canonico (argomento).
Possiamo aggiungere \u003ca rel=\"nofollow\" …\u003e a tutti i link che effettuano questo deep-linking argomento-risposta? Modifica: no, vedi Search engines now blocked from indexing non-canonical pages - #9 by j127
In questo modo, potremmo risparmiare ancora di più questo prezioso e limitato budget di scansione dei motori di ricerca:
il motore di ricerca non estrarrebbe il link in primo luogo né effettuerebbe una chiamata all’URL. Poiché la chiamata all’URL comporta una risposta con un’intestazione http X-Robots-Tag: noindex che causa la “scartata” della risposta aggiungendo l’URL all’elenco interno “noindex” dei motori di ricerca.
Ulteriori risparmi sul budget di scansione con nofollow aggiunto agli URL dei feed RSS:
Penso che la funzionalità non dovrebbe essere attiva per impostazione predefinita. È pericolosa dal punto di vista del traffico, anche se è attiva solo per breve tempo, quindi chiunque aggiorni ora potrebbe avere una spiacevole sorpresa.
Il tag canonical è il modo che Google raccomanda per affrontare quel problema, e sembra già funzionare. Fare cose strane con i tag canonical può portare a strani problemi con Google, e un errore di noindex potrebbe essere difficile da recuperare.
Sono d’accordo con la prima parte del tuo post, ma non penso che nofollow interno sia l’ideale. I link interni aiutano a dire ai motori di ricerca quali pagine del sito sono importanti. Google non seguirà ogni link che vede, perché sa di averli già visti. Se vedono un URL come example.com/t/1234/5 ma lo hanno già indicizzato e sanno che il suo URL canonical è example.com/t/1234, probabilmente non sprecheranno le loro risorse informatiche visitando più volte la versione non canonica.
Rimuovere ‘noindex’ per gli URL collegati da siti web esterni
Mi scuso, per “risposte” intendo “post” in un argomento:
Tutti i deep-link da domini esterni ai post (ad es. forum.example.com/t/example-topic/5/11) hanno ora un http-header X-Robots-Tag: noindex! Suggerisco di rimuovere nuovamente questo http-header.
Suggerisco che <link rel="canonical" … > non utilizzi mai un URL con un’ancora di post (l’ultimo numero in …/t/example-topic/1234/5 ) ovunque. Gli URL canonici dovrebbero sempre puntare all’URL dell’argomento stesso (…/t/example-topic/1234 ). Penso che sia già implementato in questo modo.
Riscrivere i link per i motori di ricerca se l’URL di destinazione è “reindirizzato” da <link rel="canonical" … >
Ottimo punto, è meglio non aggiungere rel="nofollow" qui.
Discourse ha una vista speciale per i crawler. Nuovo suggerimento solo per la vista crawler:
Convertire tutti i link interni che puntano a un URL di post (example.com/t/1234/5) per puntare invece all’URL dell’argomento corrispondente (example.com/t/1234).
Intenzione: non annunciare URL aggiuntivi ai motori di ricerca quando questi URL aggiuntivi sono comunque “reindirizzati” da <link rel="canonical" … >.
Posizioni in cui si trovano tali link ai post:
link aggiunti manualmente nel contenuto utente
link generati automaticamente in
citazioni
primo post dell’argomento: “link tracciati in entrata” da altri argomenti
primo post dell’argomento: “risposta selezionata”
primo post dell’argomento - mappa dell’argomento aperta: “link argomento”/“link apprezzati”
Excursus: Dove trova Google tutti questi URL?
“link tracciati in entrata” per i motori di ricerca
Proprio per questo motivo, anche i “link tracciati in entrata da altri argomenti” generati automaticamente nel primo post di un argomento dovrebbero essere visibili dai motori di ricerca. Al momento questi “link tracciati in entrata” mancano nella vista crawler. Modifica: Sono già nella vista crawler.
Ma puntano all'URL del post invece che all'URL dell'argomento (vedi sorgente html)
<div class="crawler-linkback-list" itemscope="" itemtype="http://schema.org/ItemList">
<div itemprop="itemListElement" itemscope="" itemtype="http://schema.org/ListItem">
<a href="https://meta.discourse.org/t/removing-the-2-3-4-etc-links-for-each-reply-within-a-topic-url/209648/26" itemscope="" itemtype="http://schema.org/DiscussionForumPosting" itemprop="item">
<meta itemprop="url" content="https://meta.discourse.org/t/removing-the-2-3-4-etc-links-for-each-reply-within-a-topic-url/209648/26">
<span itemprop="name">Removing the /2, /3, /4, etc links for each reply within a topic URL</span>
</a>
<meta itemprop="position" content="2">
</div>
</div>
Questo è un punto cruciale. Un conto è indicizzare tutte le tue pagine e un altro è ottenere un ranking pertinente per esse. Nella mia esperienza (con siti di grandi editori), collegamenti interni intelligenti sono la chiave per raggiungere questo obiettivo.
Per chiunque aggiorni il proprio sito dopo la data di pubblicazione dell’OP.
Abbiamo dati che dimostrano che la nuova intestazione riduce il tempo di scansione su quelle pagine e hanno sempre impostato il canonical.
Ma quelle pagine non sono comunque destinate alla scansione. I metadati con l’URL sono impostati a livello di argomento, non vogliamo che Google scansioni il livello del post poiché si tratta di contenuti duplicati.
Fantastico, quindi non c’è niente da cambiare qui.
Far ciò al runtime potrebbe essere troppo costoso in termini di CPU e salvare due versioni di ogni post sarebbe costoso in termini di disco.
I nostri valori predefiniti sono sempre ciò che raccomandiamo. Tuttavia, manteniamo e annunciamo le impostazioni del sito in modo che le persone possano scegliere diversamente se ritengono che un’impostazione predefinita non sia ideale per il loro sito.
Quindi potrebbero esserci problemi con sitemap_recent.xml che contiene link come questo? https://meta.discourse.org/t/category-moderator-improvements/158628?page=2
Vedo una grande differenza quando c’è un link esterno a un URL di un post.
# A:
Dominio Esterno
|
|--(link juice)---> URL del post
|
|__/ indicizzazione: \---> URL del post non indicizzato e
\ header noindex / link-juice per lo più perso
# B:
Dominio Esterno
|
|--(link juice)---> URL del post
|
|__/ indicizzazione: \__|---> URL del post non indicizzato
\ canonical di risposta / |---> URL del topic indicizzato (comunque)
con trasferimento di link-juice
Per i neofiti come me riguardo alla SEO, ciò implica che si tratta di un miglioramento SEO che potrebbe potenzialmente portare a un leggero aumento/beneficio nei risultati di ricerca di Google?
Abbiamo testato la modifica in una community di notizie tecnologiche per alcuni mesi e abbiamo osservato un ampio aumento picco-picco delle visualizzazioni di pagina anonime. Il nostro obiettivo finale è sempre quello di rendere tutte le community di Discourse più sane su tutti i fronti.
… Suggerisco la seguente implementazione per ottenere il miglior compromesso:
Non aggiungere l’header http X-Robots-Tag: noindex.
– tenendo conto di [E] –
Mantenere sempre i tag canonical puntati all’url dell’argomento.
– diminuzione dei crawl [A] e considerando [C] –
Solo per la visualizzazione del crawler: Convertire i collegamenti generati automaticamente in modo che puntino sempre all’url dell’argomento anziché all’url del post - per tutti i collegamenti nel primo post dell’argomento “collegamenti tracciati in entrata da altri argomenti” e “mappa dell’argomento aperta: collegamenti argomento/collegamenti apprezzati”.
– diminuzione dei crawl [A] e considerando [D], ma ignorando deliberatamente [B] –
Su [B]: le spese di CPU sono solo per le visite dei crawler e consistono nell’eseguire una sostituzione regex per tagliare l’ultimo numero dagli url interni che terminano con due numeri, ad esempio …/t/example-topic/1234/5 → …/t/example-topic/1234 nei confini del primo post dell’argomento “collegamenti tracciati in entrata da altri argomenti” e “mappa dell’argomento aperta” soltanto.
Per tutte le visualizzazioni: aggiungere nofollow interno alle citazioni e ai collegamenti aggiunti manualmente nel contenuto dell’utente.
– diminuzione dei crawl [A] e considerando [B], ma ignorando leggermente [D] –
Su [D]: i collegamenti importanti sono già duplicati automaticamente nel primo argomento nella sezione “mappa dell’argomento aperta: collegamenti argomento/collegamenti apprezzati” [vedi 3.] e la maggior parte delle citazioni rimane comunque all’interno dell’argomento stesso.
Per Google il link va direttamente all’url canonico dell’argomento …/1234 - e Google non viene a conoscenza dell’url del post …/1234/5 da questa sintassi di link.
Per la navigazione dell’utente, un JavaScript aggiuntivo nell’app Ember farà il trucco:
ad esempio, sostituisci href con routerLink.
Importante
