Meta robots, canonical e robots.txt – Ecco perché non servono

Ultimo aggiornamento 19 Aprile 2024

C’è un problema diffuso tra chi si occupa di SEO su siti web che devono sottostare a logiche aziendali precise o a problemi derivati da linee guida architetturali sbagliate a monte: avere una montagna di pagine in più e pensare di poterle gestire semplicemente con un tag <link>, con un’impostazione dei meta robots o con una riga di codice in htaccess o robots.txt.

Vorrei dire subito una cosa importante: se una pagina non impatta sulle ricerche puoi tenerla lo stesso sul sito. Se però le pagine prive di rilevanza sono in numero maggiore (e magari di molto) rispetto a quelle che punti a rendere visibili su Google, puoi trattarle con un noindex come impostazione del meta robots o con un tag link con attributo canonical, ma tali misure non ridurranno il consumo delle risorse di scansione, serviranno solo a evitare di mostrare quelle pagine agli utenti.

Puoi bloccare la scansione di intere aree del sito mediante il file robots.txt o in alternativa impostando un x-robots tag sul file htaccess, ma ancora una volta non avrai risolto il problema nel migliore dei modi, perché se le risorse da bloccare sono la maggior parte dei percorsi scansionabili e tali percorsi si trovano distribuiti ovunque nel sito, dire a Google che vanno bloccati rappresenta un’anomalia. Per capirci, il file robots.txt non è concepito per far capire al bot che su ogni pagina deve fare diversi distinguo tra cosa seguire e cosa no. Questo problema si risolve evitando a monte di tenere in pagina percorsi inopportuni o in alternativa servendoli come caricamenti dinamici piuttosto che come URL espliciti. Tra un po’ approfondiremo quest’aspetto.

Quindi se hai questo problema dimenticati di risolverlo mettendoci una pezza.

Aree da tagliare su sito aziendale

Un caso di cui ho discusso qualche giorno fa riguarda un’azienda che offre prodotti. I contenuti da rendere visibili saranno un centinaio, ma sullo stesso sito web è presente un’area dedicata alla rassegna stampa con migliaia di articoli (copiati da altrove) risalenti fino al 2009. Tali articoli non hanno alcuna rilevanza rispetto alle ricerche, riguardano risorse recuperate altrove e sono in quantità estremamente più alta rispetto alle pagine da posizionare. In questo caso la cosa da fare sarebbe prendere una scure e tirar via tutto, ma in caso la cosa sia impossibile per decisioni politiche prese, piuttosto che mettere tutto in noindex o bloccare la scansione con robots.txt, una soluzione che mi è sembrata ideale è spostare tutta questa gigantesca mole di pagine su di un sottodominio da tenere dedicato alla rassegna stampa, quanto più possibile indipendente dal dominio principale rispetto ai link interni. In questo modo gli spider di Google potranno seguire solo le pagine rilevanti sul sito principale e allo stesso tempo avremo evitato di rimuovere l’area dell’archivio storico. Puoi applicare questa soluzione alle aree del tuo sito non rilevanti rispetto al modello di business, soprattutto se molto nutrite di pagine.

Siti e-commerce e URI parametrate

Il grande (annoso) problema dei siti e-commerce sono le URI parametrate che troviamo nei classici filtri di ricerca, nei link di paginazione, in quelli che offrono visualizzazioni diverse per le pagine archivio, talvolta nei pulsanti di condivisione social (mannaggialloro). Come pensi di risolvere questo problema? Con il tool parametri url in Search Console? Quello può andar bene, ma Google può non prendere in considerazione le impostazioni che inserisci per i singoli parametri se nel tuo sito si trovano praticamente ovunque. In questo caso la soluzione è stabilire un ordine di scansione a livello del codice stesso che caratterizza i percorsi interni. In particolare puoi tenere in pagina i percorsi espliciti con URI presenti come attributo HREF del tag <A> per muovere in via prioritaria il bot verso le pagine che ti interessa posizionare come prodotti e archivi. Allo stesso tempo puoi servire tutti gli altri percorsi, specie quelli parametrati di cui sopra, come caricamenti dinamici ajax, che Google certamente vedrà e potrà seguire, ma ad un livello di priorità inferiore.

Conclusioni: niente scorciatoie

Se ti muovi così non hai bisogno di mettere le pagine in noindex, non ti serviranno canonical e non dovrai bloccare nulla mediante file robots.txt. Avrai lavorato sul campo, facendo capire direttamente a Google cosa conta e cosa no, indipendentemente da ciò che si vede o non si vede. Avrai risparmiato risorse di scansione che verranno allocate solo (e meglio) verso le pagine rilevanti rispetto al tuo modello di business.

Cosa manca a questo ragionamento? Un bravo sviluppatore. Ciò di cui ho scritto non è alla portata di chiunque, quindi se leggendo questo articolo il tuo webmaster pone obiezioni sostenendo che invece le misure che reputo insufficienti vadano bene, tu non ti scomporre… e comincia a cercare un altro web master.