Ottimizzare il file robots.txt per Wordpress, Joomla, Drupal & Co.

juanin

Ottimizzare il file robots.txt per Wordpress, Joomla, Drupal & Co.

Cercando su Google informazioni su robots.txt e Wordpress quello che troviamo è qualcosa di imbarazzante. Lo avevo** già espresso qui**, ma ora voglio ampliare la cosa e riprendere un mio commento al post che attualmente viene definito da Google come la risposta a questa richiesta di aiuto.

Ovviamente Google sta dando una risposta errata.

Di seguito gli articoli che secondo Google sono validi.

Articoli ricchi di parole, link addirittura a Wikipedia con esempi pratici di implementazioni da copia/incolla che li rendono appetibili, ma non per questo validi.
Sarebbe molto più utile, corretto e reale un bel post che includa solamente


User-agent: *
Disallow:

Ma ovviamente nessuno (utente o motore) lo considererebbe valido, utile o migliore di altri.

[Primo articolo errato] Ottimizzare il file robots.txt per WordPress

a cui ho risposto nei commenti come segue. Estraggo solo la parte utile che smonta la tesi:

Il robots.txt a parte un caso non documentato che trovi descritto qui con un esperimento http://bit.ly/1edhz6i non è rivolto in nessun modo al processo di indicizzazione, ma semplicemente gestisce l'accesso dello spider alle nostre risorse.

Proprio perché come hai detto nel commento ogni sito è diverso dare una soluzione preconfezionata è errato e di conseguenza lo è anche quell per Wordpress perché spesso la maggior parte delle risorse vengono disperse a causa di una errata ottimizzazione del frontend.

Utilizzare il robots per bloccare feed, trackback, pingback, commenti è una delle cose più scorrette in assoluto perché queste cose andrebbero gestite a livello di template (evitando di generare certe situazioni) oppure a livello server side evitando di generarle.

Altro errore grave è inibire l'accesso alle cartelle wp-content che quasi sempre contengono CSS, JS e altre cose funzionali al tema utilizzato. Spesso alcuni plugin o temi utilizzano JS presenti in wp-includes e da qui un altro errore che si andrebbe a commettere utilizzando un robots.txt tipo quello consigliato.

Consigliar poi di bloccare categorie o tag è un discorso che eviterei totalmente in quanto il consiglio dovrebbe essere:

"gestite 'sti benedetti tag e 'ste benedette categorie con cognizione di causa" il robots.txt non serve a risolvere problemi causati dal caos che le persone hanno nella testa.

Stesso vale per il meta noindex che ovviamente non va usato in combinazione con il disallow del robots, pena vanificarne l'efficacia. Se lo vuoi noindex allora non ci deve essere traccia delle sezioni nella normale navigazione anche per gli utenti.

Detto questo vorrei capire su che base nasce questo robots.txt consigliato se poi non si mostrano i reali benefici che questo porta a livello di crawling e comportamento sulla base dei log del server.
https://plus.google.com/u/0/wm/1/+AnnaritaFaggioni/posts/Phyn9q8TWQL

[Secondo articolo errato] Creare un file Robots.txt ottimizzato per WordPress (nessuno ha commentato spiegando che sta sbagliando)
[Terzo articolo errato] Creare un robots.txt per WordPress ottimizzato per i Motori di Ricerca

Giacomo Pelagatti ha risposto spiegando anche lui che alcuni consigli sono errati. Vi incollo la sua risposta più corposa e potete leggere il resto dei commenti nel post:

Il file robots.txt è uno strumento che -come tutti- andrebbe utilizzato quando non esistono alternative migliori dal punto di vista SEO, o quando le alternative non sono praticabili a causa di limitazioni tecniche. In realtà esistono una serie di strumenti che in alcuni casi è consigliabile usare in sostituzione del “Disallow” nel file robots.txt.Personalmente non sono d’accordo con chi indica di escludere via file robots.txt le pagine archivio di un blog (es., categorie e tag) al fine di prevenire problemi di duplicazione. Impedendo ai crawler di scaricare tali pagine si blocca infatti anche la distribuzione del “link juice” (=PageRank+anchor text) alle pagine dei post attraverso i link (interni o esterni al sito) che puntano alle pagine dei tag o delle categorie: l’uso dei Disallow nel robots.txt, che si può benissimo utilizzare per altri fini, o come workaround o in casi d’emergenza, risulta perciò in questo caso una soluzione sub-ottimale.Se lo scopo è quello di prevenire l’indicizzazione di pagine con contenuti sostanzialmente duplicati rispetto alle pagine dei post, esistono almeno due alternative preferibili al Disallow: una prima soluzione, estremamente semplice da adottare ed efficace nella maggior parte dei casi, è quella di visualizzare sulle pagine archivio soltanto un estratto dei post, e non il loro contenuto integrale; una seconda soluzione (che avevo già suggerito in questo commento) è quella di usare un meta tag robots “NOINDEX,FOLLOW” (“FOLLOW” in realtà è implicito, e perciò può essere omesso): ugualmente efficace ai fini preventivi, ma più efficiente dal punto di vista SEO. Usando il NOINDEX si raggiunge infatti lo scopo (impedire l’indicizzazione delle pagine archivio) e contemporaneamente si lascia fluire liberamente il link juice attraverso il sito e arrivare a destinazione, ottenendo una miglior distribuzione di PageRank e tematizzazione sulle pagine dei post e nel sito nel suo complesso.Se la differenza tra usare l’uno o l’altro metodo può essere trascurabile per blog di piccole dimensioni, su siti con un alto numero di post, categorie o tag (e quindi un alto numero di link verso le pagine archivio), l’introduzione del Disallow potrebbe produrre più danni che altro, specialmente se il rischio duplicazione è più immaginario che reale. Per questo motivo, chi suggerisce di utilizzare il file robots.txt come fosse il migliore (o l’unico) strumento per prevenire problemi di duplicazione, senza nemmeno menzionare l’esistenza di alternative preferibili, dà un’indicazione errata dal punto di vista SEO (se per “SEO” intendiamo “ottimizzazione”, e non solo prevenzione o risoluzione di criticità).

Che dire. In fin dei conti la risposta corretta in quelle pagine c'è, ma in quanti leggeranno i commenti?
Spesso l'utente cerca una soluzione immediata da copia/incolla e per la SEO questo è un male.

Di seguito invece alcune discussioni qui sul forum:

Ovviamente ho preso come esempio Wordpress, ma il concetto di base dietro a questo ragionamento è lo stesso per ogni CMS e ogni sito, che sia esso Drupal, Joomla, Wordpress.

Così come c'è un gran caos nella community SEO nel comprendere la differenza tra follow e nofollow, indicizzazione e posizionamento, come funzioni il motore nei confronti di un robots.txt c'è anche gran confusione nel comprendere le basi, l'ABC. Credo sia utile ogni tanto riproporre le basi di questo mestiere spesso dimenticate a vantaggio di cose che in casi complessi diventano completamente inutili, fuorvianti e pericolose.

Spero che questo contributo possa essere utile a qualcuno e che almeno metta sulla retta via le persone traviate da post completamente errati.

emanuelebolondi

Altro errore grave è inibire l'accesso alle cartelle wp-content che quasi sempre contengono CSS, JS e altre cose funzionali al tema utilizzato. Spesso alcuni plugin o temi utilizzano JS presenti in wp-includes e da qui un altro errore che si andrebbe a commettere utilizzando un robots.txt tipo quello consigliato.

Giustissimo, a tal proposito sono curioso di vedere come si evolve questo caso:
https://yoast.com/google-panda-robots-css-js/

In ogni caso non mi convince molto soprattutto osservando il grafico di Search Metrics, sia per il crollo registrato in data differente da panda, sia per il primo picco subito dopo il crollo.

juanin

Infatti come ho già detto su Google+ (e anche qui) mi sembra un po' avventato e fuori luogo dire che si tratti di Panda.
Non è cosa nuova che non vadano bloccati JS e CSS e le risorse che si trovano su questo forum lo dimostrano così come è già da tempo che sappiamo che Googlebot tenti il rendering aldilà dell'annuncio ufficiale.

La cosa che mi stupisce di più è che lo abbia detto Yoast. Anche lui si è fatto prendere dal folklore.

ram.wm

@Juanin said:

[Terzo articolo errato] Creare un robots.txt per WordPress ottimizzato per i Motori di Ricerca

Giacomo Pelagatti ha risposto spiegando anche lui che alcuni consigli sono errati. Vi incollo la sua risposta più corposa e potete leggere il resto dei commenti nel post:

...

Che dire. In fin dei conti la risposta corretta in quelle pagine c'è, ma in quanti leggeranno i commenti?
Spesso l'utente cerca una soluzione immediata da copia/incolla e per la SEO questo è un male.

Per precisione, la risposta di Giacomo Pelagatti è riportata e linkata anche all'interno del post (che ho scritto quasi 5 anni fa).

Se l'utente poi si limita a scorrere l'articolo per copia/incollare l'ultima porzione di codice, senza leggere tutte le considerazioni... il rischio è suo

juanin

Ecco la conferma che Yoast ha sparato una fesseria. Parlare di Panda era avventato e fuori luogo. Un altro caso per cui bisognerebbe stare in guardia rispetto alle ipotesi di correlazioni tra avvenimenti e realtà.

John Mue dice:

Allowing crawling of JavaScript and CSS makes it a lot easier for us to recognize your site's content and to give your site the credit that it deserves for that content. For example, if you're pulling in content via AJAX/JSON feeds, that would be invisible to us if you disallowed crawling of your JavaScript. Similarly, if you're using CSS to handle a responsive design that works fantastically on smartphones, we wouldn't be able to recognize that if the CSS were disallowed from crawling. This is why we make the recommendation to allow crawling of URLs that significantly affect the layout or content of a page. I'm not sure which JavaScript snippet you're referring to, but it sounds like it's not the kind that would be visible at all. If you're seeing issues, they would be unrelated to that piece of JavaScript being blocked from crawling.

Looking at your site, those disallowed scripts are definitely not causing a problem -- it's primarily an issue of problematic links here. That's what I'd focus on first. Since there's a manual action involved, that's something which you can work on to resolve.

Regarding your more general question of whether disallowed scripts, CSS files, etc play a role in our Panda quality algorithm: our quality algorithms primarily try to understand the overall quality of a page (or website), and disallowing crawling of individual aspects is generally seen as more of a technical issue so that wouldn't be a primary factor in our quality algorithms. There's definitely no simple "CSS or JavaScript is disallowed from crawling, therefore the quality algorithms view the site negatively" relationship.

Oltre a questo bisogna anche notare che il caso di Yoast è precedente di due settimane rispetto al refresh di Panda.

jamesweb

Si concordo meglio lasciare il robots txt con solo Disallow:

mi chiedevo per proteggere wp-admin tramite htaccess è un buona risorsa questa che vi indico:

cyberspazio.eu/wordpress-proteggere-il-pannello-di-amministrazione-con-htaccess/

juanin

Si basta che generi una pass .htpasswd e .htaccess

jamesweb

Si ho seguito le istruzioni insernedo il file .htaccess e .htpasswd in wp-admin ed ho modificato .htaccess nella root, solo quando inserisco user e password me le richiede ogni volta e non mi fa entrare.

juanin

Allora forse hai messo la pass errata.

Genera la password direttamente da shell perché a volte i tool online non funzionano.

jamesweb

Scusami, perdona la mia ignoranza, ma intendi da riga di comando? perchè gironzolando sul web ho trovato indicazioni sul pacchetto apache dove insieme vi è un programma htpasswd per generare la password. Puo essere una soluzione? nel caso dove trovo queso pacchetto apache?

juanin

Sì esatto.
Che distribuzione di linux usi?

jamesweb

Sinceramente non uso linux come sistema operativo ma il Mac, se puoi consigliarmi quale usare potrei installarlo in virtuale, funziona ugualmente?

juanin

In teoria su Max essendo basato su Unix dovrebbe esserci lo stesso.
Apri un terminale e vedi se ti restituisce il comando.

jamesweb

Si il comando mi restituisce le varie istruzioni, proverò ad eseguire la riga di codice per generare la password. Grazie mille per la disponibilità. Se desideri ti aggiorno su come va.

juanin

Un piacere.

Ottimizzare il file robots.txt per Wordpress, Joomla, Drupal &amp; Co.

Ottimizzare il file robots.txt per Wordpress, Joomla, Drupal & Co.