Faut-il modifier notre Joomla robots.txt après l'annonce de Google sur l'exploration de CSS et JavaScript?


8

J'ai rencontré une annonce de Google: http://googlewebmastercentral.blogspot.in/2014/10/updating-our-technical-webmaster.html

Il est dit:

Pour un rendu et une indexation optimaux, notre nouvelle directive spécifie que vous devez autoriser Googlebot à accéder aux fichiers JavaScript, CSS et image que vos pages utilisent. Cela vous offre un rendu et une indexation optimaux pour votre site. Interdire l'exploration de fichiers Javascript ou CSS dans le fichier robots.txt de votre site nuit directement à la qualité de rendu et d'indexation de nos contenus et peut entraîner des classements sous-optimaux.

Par défaut, le fichier robots.txt de Joomla est livré avec interdiction:

Disallow: /administrator/
Disallow: /cache/
Disallow: /cli/
Disallow: /components/
Disallow: /includes/
Disallow: /installation/
Disallow: /language/
Disallow: /libraries/
Disallow: /logs/
Disallow: /media/
Disallow: /modules/
Disallow: /plugins/
Disallow: /templates/
Disallow: /tmp/

Veuillez informer, devons-nous supprimer les éléments ci-dessous du fichier robots.txt en fonction de l'annonce de Google?

Disallow: /components/
Disallow: /libraries/
Disallow: /media/
Disallow: /modules/
Disallow: /plugins/
Disallow: /templates/

Est-ce ce qui est recommandé selon l'annonce pour les sites basés sur Joomla?


Pourquoi ne pas simplement s'en débarrasser robots.txtpuisque personne (pas même les moteurs de recherche maintenant que Google fait des demandes sur ce que vous ne devriez pas interdire) ne le suivra pas de toute façon?
Débordement de questions du

Associés (pas un doublon): robots.txt - CSS autorisez ou interdisez
unor

Réponses:


3

Honnêtement, vous feriez mieux de tout supprimer de votre robots.txt. Pour autant que je puisse voir, tous les fichiers PHP dans Joomla contiennent la ligne

defined('_JEXEC') or die;

Ce qui signifie que si vous chargez un fichier PHP directement dans le navigateur, tout ce que vous obtenez est un fichier vierge, que les moteurs de recherche ignoreront. (Ils ne devraient jamais les rencontrer de toute façon, sauf si vous les avez liés directement.)

Le problème de laisser certains de ces répertoires bloqués est que certains composants et modules conservent leurs fichiers CSS / JS dans ces répertoires respectifs et non dans les dossiers de supports ou d'images préférés.

Il n'y a donc aucune raison de bloquer les fichiers Joomla de Google.


Merci. Cependant - je vois - quand une page est récupérée via le Webmaster - c'est très bien - malgré le refus de tous ces dossiers. La suppression de l'interdiction fera-t-elle du bien aux pages?
Gag

1
@Gagan Je ne suis pas sûr, mais l'outil de récupération dans les outils pour les webmasters ignore probablement le fichier robots.txt.
DisgruntledGoat

1
GWMT fait les deux. Lorsque vous récupérez en tant que google, il vous montrera comment Google voit votre site et comment un utilisateur voit votre site. @DisgruntledGoat a raison, il n'est pas nécessaire de bloquer quoi que ce soit.
Brent Friar

2

En dehors de leur utilisation / absence globale, robots.txtdans un site Joomla bien géré, avec de "bonnes" extensions tierces - les seuls endroits qui devraient contenir du CSS, du JS ou des images sont:

/images
/media
/templates

et bien sûr leurs sous-répertoires .

Donc, vous pouvez simplement les supprimer robots.txt.



1

Si vous voyez vos pages sans erreurs lors de la récupération en tant que Google dans WMT, alors vous allez probablement bien. Mais, à l'avenir, vous pourriez mettre à niveau du contenu sur votre site Web, ce qui nécessitera des scripts / css de certains des dossiers bloqués. Par conséquent, je pense que vous pourriez être mieux en autorisant les moteurs de recherche à explorer tous ces dossiers contenant CSS / JavaScript.


1

Les versions les plus récentes de Joomla ne bloquent plus les dossiers /media/et /templates/:

User-agent: *
Disallow: /administrator/
Disallow: /bin/
Disallow: /cache/
Disallow: /cli/
Disallow: /components/
Disallow: /includes/
Disallow: /installation/
Disallow: /language/
Disallow: /layouts/
Disallow: /libraries/
Disallow: /logs/
Disallow: /modules/
Disallow: /plugins/
Disallow: /tmp/

Toutes les extensions ne respectent pas les directives de l'emplacement des fichiers CSS et JS, etc.

Vous pouvez y parvenir en insérant quelques lignes au début de votre robots.txtfichier comme ceci:

#Googlebot
User-agent: Googlebot
Allow: *.css
Allow: *.js

User-agent: *
Disallow: /administrator/
Disallow: /bin/
Disallow: /cache/
Disallow: /cli/
Disallow: /components/
Disallow: /includes/
Disallow: /installation/
Disallow: /language/
Disallow: /layouts/
Disallow: /libraries/
Disallow: /logs/
Disallow: /modules/
Disallow: /plugins/
Disallow: /tmp/

ÉDITER:

Merci @ w3dk et @Stephen Ostermiller pour les commentaires! Vous avez parfaitement raison. Il vaut mieux faire quelque chose comme ça:

User-agent: *
Allow: *.css
Allow: *.js
Disallow: /administrator/
Disallow: /bin/
Disallow: /cache/
Disallow: /cli/
Disallow: /components/
Disallow: /includes/
Disallow: /installation/
Disallow: /language/
Disallow: /layouts/
Disallow: /libraries/
Disallow: /logs/
Disallow: /modules/
Disallow: /plugins/
Disallow: /tmp/

Malheureusement, cela ne semble pas fonctionner comme prévu car les règles plus longues (plus spécifiques) remplacent les règles plus courtes et les lignes d'autorisation sont ignorées. Cela ne semble pas faire de différence si les lignes autorisées suivent les lignes interdites ou vice versa.

La seule façon dont je peux sembler contourner cela est de faire quelque chose comme ça qui semble fonctionner lorsque je le teste dans les outils pour les webmasters:

User-agent: *
Allow: /************************************************************.css
Allow: /************************************************************.js
Disallow: /administrator/
Disallow: /bin/
Disallow: /cache/
Disallow: /cli/
Disallow: /components/
Disallow: /includes/
Disallow: /installation/
Disallow: /language/
Disallow: /layouts/
Disallow: /libraries/
Disallow: /logs/
Disallow: /modules/
Disallow: /plugins/
Disallow: /tmp/

EDIT 2 - MEILLEURE SOLUTION:

OK, j'ai donc fait un peu plus de recherche et trouvé la réponse sur https://stackoverflow.com/a/30362942/1983389

Il semble quelque chose comme ce qui suit (permettant l' accès à la solution la plus correcte et la plus soutenue dans tous les robots d' exploration Web *.csset des *.jsfichiers dans les /bin, /cache, /installation, /language, /logs, et des /tmpdossiers et peut - être quelques - uns des autres dossiers peu de sens):

User-agent: *
Allow: /administrator/*.css
Allow: /administrator/*.js
Disallow: /administrator/
Disallow: /bin/
Disallow: /cache/
Allow: /cli/*.css
Allow: /cli/*.js
Disallow: /cli/
Allow: /components/*.css
Allow: /components/*.js
Disallow: /components/
Allow: /includes/*.css
Allow: /includes/*.js
Disallow: /includes/
Disallow: /installation/
Disallow: /language/
Allow: /layouts/*.css
Allow: /layouts/*.js
Disallow: /layouts/
Allow: /libraries/*.css
Allow: /libraries/*.js
Disallow: /libraries/
Disallow: /logs/
Allow: /modules/*.css
Allow: /modules/*.js
Disallow: /modules/
Allow: /plugins/*.css
Allow: /plugins/*.js
Disallow: /plugins/
Disallow: /tmp/

2
Cela permettra à Googlebot de tout explorer, ce qui est assez différent du fichier robots.txt d'origine - est-ce l'intention? (Cependant, c'est la même chose que simplement inclure Disallow:dans le User-agent: Googlebotgroupe, ce qui serait plus lisible.)
MrWhite

Oui, l'intention est de permettre à Google d'accéder à tous les fichiers CSS et JS du site Web.
Neil Robertson

2
Pas seulement les fichiers CSS et JS, mais tous les fichiers du site Web. (?)
MrWhite

1
w3dk est correct. Si vous ajoutez une section spéciale pour Googlebot, vous devez dupliquer toutes les règles existantes dans cette section. Votre fichier robots.txt proposé permettrait à Googlebot d'explorer /logs/tout en empêchant d'autres robots de le faire.
Stephen Ostermiller
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.