Les fichiers robots.txt et sitemap.xml peuvent-ils être dynamiques via une redirection .htaccess?


12

J'ai un site multilingue et multidomaine. Il fonctionne à travers une installation CMS unique (Drupal), j'ai donc un seul répertoire racine. Donc, si j'ai un fichier robots.txt statique, je ne peux y afficher que les fichiers d'un seul domaine, pour autant que je sache.

Puis-je mettre une ligne dans .htaccess

Redirect 301 /robots.txt /robots.php

(ou instruction équivalente, et veuillez indiquer laquelle si elle est autorisée)

donc il redirige vers un fichier php dynamique, où je peux servir différents contiennent selon le $_SERVER['HTTP_HOST']?

Et la même question pour sitemap.xml , donc je peux servir un sitemap.php dynamique qui indique différents liens pour chaque domaine différent.

Le problème avec l'absence d'utilisation de .txt et .xml est, comme mentionné, que tous les domaines partagent un seul répertoire physique sur l'ordinateur serveur.


Réponses:


11

Vous pouvez rendre n'importe quel fichier dynamique. La meilleure façon de le faire n'est pas via des redirections, mais via des règles de réécriture.

RewriteRule ^robots\.txt$  /robots.php [L]

De cette façon, vous l'alimentez avec un script dynamique, mais l'URL ne change pas. La plupart des robots (y compris Googlebot) suivront les redirections pour robots.txt , mais certains robots seront confus si vous introduisez des redirections.

Notez que même si vous l'alimentez avec PHP, votre robots.txt devrait apparaître comme statique pour chaque robot pour chaque domaine. Il est bien de servir un contenu différent pour différents domaines, ou même pour différents agents utilisateurs. Cependant, servir un contenu différent de manière aléatoire ou en fonction de l'heure de la journée peut vraiment confondre les robots des moteurs de recherche et gâcher votre référencement.


Les plans de site sont bien nommés comme vous le souhaitez. Vous pouvez les rediriger ou utiliser une règle de réécriture pour les dynamiser à la même URL. Vous pouvez également les nommer comme

  • site-a-sitemap.xml
  • site-b-sitemap.xml
  • site-c-sitemap.xml

Reportez-vous ensuite à eux dans robots.txt :

Sitemap: http://www.example.com/example-sitemap.xml

ou soumettez-les aux moteurs de recherche manuellement via leurs outils pour les webmasters ou la console de recherche.


Merci à tous les deux pour votre réponse. Veuillez corriger ce qui pourrait être une faute de frappe, c'est l' instruction w3d qui a fonctionné, donc le code doit être RewriteRule ^robots\.txt$ robots.php [L]sans le symbole \.
Cesar

Oui, la version avec la barre oblique serait appropriée pour votre fichier apache.conf. Pour .htaccess, vous devez le laisser hors tension. J'ai modifié la réponse pour inclure la version appropriée pour .htaccess.
Stephen Ostermiller

@Cesar Le préfixe de barre oblique sur le modèle (c'est-à-dire. ^/robots\.txt$) Serait requis si cette directive était dans la configuration du serveur, mais oui, elle ne correspondra pas dans les fichiers .htaccess par répertoire. Le préfixe de barre oblique sur la substitution (ie. /robots.php) Est facultatif dans ce cas.
MrWhite

5

Oui, de la même manière, toute demande peut être "dynamique".

Cependant, vous ne redirigeriez pas (comme dans votre exemple de code), vous devriez réécrire en interne en utilisant mod_rewrite. (Identique à ce que Drupal fait probablement déjà.)

Par exemple, dans votre fichier racine .htaccess:

RewriteEngine On
RewriteRule ^robots\.txt$ robots.php [L]

RewriteEngine ne devrait se produire qu'une seule fois (même si cela n'a pas vraiment d'importance s'il se produit plusieurs fois).

Vous devez juste vous assurer que cela n'entre pas en conflit avec les autres directives de votre fichier .htaccess. Donc, cela devrait probablement être près du début du fichier, certainement avant votre contrôleur frontal .


4

Rendre le fichier sitemap dynamique est très bien - c'est un bon moyen de mettre à jour automatiquement vos sitemaps.

Rendre le fichier robots.txt dynamique (pour le même hôte! Faire cela pour des hôtes séparés est essentiellement juste un fichier robots.txt normal pour chacun d'eux.) Causerait probablement des problèmes: il n'est pas analysé chaque fois qu'une URL est explorée depuis le site , il peut donc arriver que la "mauvaise" version soit mise en cache. Par exemple, si vous faites analyser votre bloc de fichiers robots.txt pendant les heures ouvrables, il est possible qu'il soit mis en cache puis suivi pendant une journée - ce qui signifie que rien n'est analysé (ou alternativement, mis en cache lorsque l'exploration est autorisée). Par exemple, Google analyse le fichier robots.txt environ une fois par jour pour la plupart des sites.


Je ne vois aucune différence ici entre statique ou dynamique. J'utiliserais également la partie dynamique pour proposer différentes versions en fonction de différents hôtes, mais parce que les hôtes partagent tous le même répertoire physique dans le serveur informatique, c'est une façon d'avoir robots1.txt, robots2.txt, robots3.txt (nombres ce qui signifie dans quel domaine nous sommes).
Cesar

Je ne pense pas que la dynamique ici signifie qu'ils veulent servir un contenu différent à chaque fois. Ils veulent juste l'alimenter via PHP afin qu'ils puissent prendre des décisions basées sur le nom d'hôte dans le code PHP. Je rend souvent robots.txt dynamique pour servir différentes règles à différents agents utilisateurs.
Stephen Ostermiller

2
Oui, comme je l'ai mentionné, le faire pour plusieurs hôtes revient essentiellement à avoir des fichiers robots.txt séparés par hôte, ce qui est bien. Cependant, nous voyons parfois des sites essayer de contrôler l'exploration par heure du jour en utilisant un fichier robots.txt dynamique - ce qui cause beaucoup de problèmes.
John Mueller

Bon point. J'ai modifié ma réponse acceptée avec un avertissement de ne pas rendre le fichier robots.txt très dynamique.
Stephen Ostermiller

0

Il n'est pas nécessaire de créer sitemap.php car: 1. Pour chaque langue, vous pouvez exécuter un fichier sitemap.xml distinct et le spécifier dans les consoles des moteurs de recherche. 2. Les fichiers de plan de site standard peuvent être réécrits régulièrement pour inclure du contenu récent et cela les rend d'une manière dynamique - pour cela .php n'est pas requis. C'est au mécanisme de mise à jour interne et au cron de recréer le même fichier avec l'extension standard .xml

Les fichiers Sitemap.xml sont statiques et seules les mises à jour les rendent dynamiques - ils ne sont pas mis à jour en temps réel. Il est possible de les faire réécrire toutes les minutes, mais cela n'est pas nécessaire car: 1. Google ne le vérifiera pas dans moins d'une heure depuis la dernière soumission 2. Lorsque les fichiers de sitemap sont volumineux, réécrivez-les rendra souvent les performances du serveur kaput.

Lorsqu'il y a un grand volume de données et que le fichier du plan du site est supérieur à 50 Mo, un système avec plusieurs plans du site est requis. Cela signifie que sitemap2,3 ... .xml s'ajoutera à la liste du fichier principal, mais le contenu de ces fichiers reste également fixe jusqu'à ce que ces fichiers soient recréés (par cron par exemple).

De plus, une fois qu'un moteur de recherche a accédé au fichier, il n'y reviendra pas très rapidement (à moins qu'il ne soit fait manuellement). Cela confirme qu'il n'est en aucun cas nécessaire de créer une mise à jour en temps réel de sitemap.php, car un sitemap.xml normal est en lui-même peut être dynamique, mettant à jour avec un nouveau contenu tout au long de la journée ou de la semaine.

Je ne peux penser à aucun professionnel utilisant un sitemap.php. Cela ne servira à rien, car il existe d'autres façons meilleures / appropriées d'utiliser ces fichiers.


La dynamique peut être privilégiée pour plusieurs raisons: les plans Sitemap occupent beaucoup d'espace disque, tandis que la génération dynamique n'en occupe aucun. Les plans de site doivent être tenus à jour et les plans de site dynamiques peuvent être un moyen facile 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.