Le processus est assez simple :
L'approche contrôleur/action
- En utilisant votre table de routes, mappez le chemin de votre robots.txt vers une action dans un contrôleur (j'utilise contrôleur et action comme exemple simple pour vous aider à démarrer), tout comme vous le feriez pour n'importe quel autre contrôleur et vue pour un chemin donné.
- Dans l'action, vérifiez le domaine de la requête et choisissez le contenu de votre robots.txt pour ce domaine.
- Retournez le fichier approprié depuis le disque en utilisant quelque chose comme :
L'exemple suivant suppose un seul fichier robots.txt de premier niveau:
// Dans App_Start/RouteConfig:
public static void RegisterRoutes(RouteCollection routes)
{
routes.IgnoreRoute("{resource}.axd/{*pathInfo}");
routes.MapRoute(
name: "robots",
url: "robots.txt",
defaults: new { controller = "Seo", action = "Robots" }
);
// Le contrôleur :
public class SeoController : Controller {
public ActionResult Robots() {
var robotsFile = "~/robots-default.txt";
switch (Request.Url.Host.ToLower()) {
case "stackoverflow.com":
robotsFile = "~/robots-so.txt";
break;
case "meta.stackoverflow.com":
robotsFile = "~/robots-meta.txt";
break;
}
return File(robotsFile, "text/plain");
}
}
Une des façons les plus simples de faire fonctionner cela est donc de s'assurer que le module de routage est appelé pour toutes les demandes en utilisant runAllManagedModulesForAllRequests dans le web.config (ne l'utilisez pas, voir le paragraphe suivant) :
...
Ce n'est pas une bonne chose en général car maintenant tous les fichiers statiques (css, js, txt) passent par des gestionnaires gérés avant d'être redirigés vers le gestionnaire de fichiers statiques. IIS est vraiment bon pour servir rapidement les fichiers statiques (un site largement statique saturera votre E/S disque bien avant le CPU), donc pour éviter cette baisse de performance, l'approche recommandée est comme l'exemple de la section web.config ci-dessous. Notez la similitude avec le gestionnaire ExtensionlessUrlHandler-Integrated-4.0 dans les applications modèles Visual Studio MVC 4 :
... les gestionnaires originaux ...
Avantages/inconvénients
Les avantages de ce type d'approche deviennent apparents une fois que vous commencez à l'utiliser :
- Vous pouvez générer dynamiquement des fichiers robots.txt en utilisant les helpers pour générer des URL d'actions que vous pouvez ensuite ajouter en tout ou en partie au fichier robots.txt modèle.
- Vous pouvez vérifier l'agent utilisateur du robot pour retourner différents fichiers robots par agent utilisateur de robot
- Vous pouvez utiliser le même contrôleur pour produire des fichiers sitemap.xml pour les robots d'exploration du Web
- Vous pourriez gérer le contenu des robots à partir d'une table de base de données qui peut facilement être administrée par les utilisateurs du site.
Cependant,
- Votre fichier robots complique maintenant votre table de routes, et ce n'est pas vraiment nécessaire
- Vous devrez optimiser la mise en cache pour éviter les lectures constantes du disque. Cependant, c'est la même chose pour n'importe quelle approche que vous adoptez.
Rappelez-vous également que différents fichiers robots.txt peuvent être utilisés pour différents sous-répertoires. Cela devient compliqué avec l'approche route et contrôleur, donc l'approche IHttpHandler (ci-dessous) est plus facile pour cette situation.
L'approche IHttpHandler
Vous pouvez également le faire avec un IHttpHandler personnalisé enregistré dans votre web.config. J'insiste sur le terme personnalisé pour éviter que tous les contrôleurs voient TOUTES les demandes (avec runAllManagedModulesForAllRequests="true"), contrairement à l'ajout d'un gestionnaire de route personnalisé dans votre table de route.
C'est aussi potentiellement une approche plus légère que le contrôleur, mais vous devriez avoir un énorme trafic sur le site pour remarquer la différence. Son autre avantage est un morceau de code réutilisable que vous pouvez utiliser pour tous vos sites. Vous pourriez également ajouter une section de configuration personnalisée pour configurer l'agent utilisateur du robot/nom de domaine/ mappings de chemin vers les fichiers robots.
public class RobotsHandler: IHttpHandler
{
public bool IsReusable { get { return false; } }
public void ProcessRequest(HttpContext context) {
string domain = context.Request.Url.Host;
// définir le code de réponse, le type de contenu et le fichier robots approprié ici
// penser également à la gestion de la mise en cache, l'envoi de codes d'erreur, etc.
context.Response.StatusCode = 200;
context.Response.ContentType = "text/plain";
// retourner le contenu des robots
context.Response.Write("mon contenu de robots");
}
}
robots.txt dans les sous-répertoires
Pour servir les robots pour les sous-répertoires ainsi que pour la racine du site, vous ne pouvez pas facilement utiliser l'approche contrôleur; l'approche gestionnaire est plus simple dans ce scénario. Cela peut être configuré pour intercepter les demandes de fichiers robots.txt à n'importe quel sous-répertoire et les gérer en conséquence. Vous pourriez alors choisir de renvoyer une erreur 404 pour certains répertoires, ou une sous-section du fichier robots pour d'autres.
Je mentionne spécifiquement cela ici car cette approche peut également être utilisée pour les fichiers sitemap.xml, pour servir différents sitemaps pour différentes sections du site, plusieurs sitemaps qui se réfèrent mutuellement, etc.
Autres références :
6 votes
Je ne crois pas que ces questions auraient dû être fermées : il s'agit d'une question de programmation pertinente pour asp.net MVC, et exactement le type de problème auquel le pipeline ASP.NET est adapté pour résoudre : comment prendre des décisions contextuelles sur le contenu à servir. Ce n'est certainement pas hors sujet.