Invia un’intestazione di link canonical invece di un’intestazione noindex.
L’invio di un’intestazione canonical ha probabilmente lo stesso vantaggio sul budget di scansione dell’invio di un’intestazione noindex, senza le implicazioni SEO dell’esclusione di URL che potrebbero avere backlink tramite noindex.
Se puoi configurare il tuo server, puoi utilizzare un’intestazione HTTPrel="canonical" (invece di un tag HTML) per indicare l’URL canonico per un documento supportato dalla Ricerca, inclusi documenti non HTML come i file PDF.
Possiamo configurare il nostro server.
utilizzare un'intestazione HTTP rel="canonical" invece di un tag HTML enfatizza una preferenza per la soluzione dell’intestazione HTTP?
Googlebot gestisce le intestazioni no-index in modo molto elegante. Consiglia di lasciare aperte quante più route possibile e utilizza le intestazioni per regole ad alta fedeltà riguardanti gli indici.
Forse Google gestisce le intestazioni di link canonical con la stessa eleganza delle intestazioni no-index.
Sto lottando con questo, leggendo la raccomandazione di Google sembra che non gli importi particolarmente.
Le raccomandazioni per l’intestazione HTTP rel="canonical" sono le stesse del tag linkrel="canonical".
Suppongo che non ci sia molto da perdere ed è possibile che un mix di no index più rel canonical sia la giusta ricetta di Google. Ma non ne sono sicuro.
Questa operazione sta annullando l’impostazione del sito introdotta di recente in quella che è essenzialmente una noop (spostando ciò che inviamo come tag di intestazione in un’intestazione, nessuna modifica semantica).
[quote=“sam, post:2, topic:220213”]
Suppongo che non ci sia molto da perdere ed è possibile che un mix di no index più rel canonical sia la giusta ricetta di Google. Ma non ne sono sicuro.
[/quote]Per il nuovo valore predefinito SiteSetting.allow_indexing_non_canonical_urls = false, questo è il modo in cui è implementato al momento e rimane così:
header noindex
html link-tag canonical (potrebbe essere ignorato)
Senza patch e SiteSetting.allow_indexing_non_canonical_urls = true
– nessun header –
html link-tag canonical
Con patch e SiteSetting.allow_indexing_non_canonical_urls = true
html link-tag canonical (potrebbe essere ignorato - ma comunque uguale all’header)
L’intera idea dietro questo:
Imposta canonical come http-header per ottenere lo stesso beneficio dell’ http-headernoindex - ovvero un crawling più veloce.
Ciò potrebbe rendere noindex obsoleto con le sue implicazioni incerte.
Un altro punto su noindex vs canonical:
noindex è più di un segnale molto forte a non inserire la pagina nell’indice di ricerca.
Ma con noindex il contenuto della pagina viene comunque elaborato da Google Bot per estrarre i link (c’è l’opzione aggiuntiva nofollow per disabilitare questo).
canonical è un segnale forte che il contenuto da indicizzare si trova su un altro URL canonico.
Nel caso in cui Google Bot decida di accettare questo segnale per una pagina, c’è una grande possibilità che non elabori affatto il contenuto della pagina – ed elabori solo l’URL canonico.
Questo è un ‘esperimento mentale’. Non è implementato da nessuna parte – e non consiglio mai di implementarlo:
header noindex
html meta-tag noindex (invece di: html link-tag canonical)
– OPPURE –
– nessun header –
html meta-tag noindex
Perché implementarlo o non implementarlo in questo modo?
Questa modifica non è una ‘noop’:
Google potrebbe gestire gli header e i contenuti HTML in diverse fasi delle sue code di elaborazione. Inviando gli header potremmo saltare ulteriori code di elaborazione (ad es. la coda di rendering) e quindi liberare budget di scansione per pagine più importanti.
Non sono fortemente contrario, ma sembra così insignificante. Google scarica sempre contenuti di questi tempi, dubito che il salvataggio di un’analisi HTML farà davvero una differenza materiale.
Ci sono molte altre aree che necessitano di attenzione prima, i microdati sono probabilmente il primo posto che ha bisogno di cure.
Possiamo configurare il nostro server.