asp.net mvc 4 - sirve - Archivo robots.txt para diferentes dominios del mismo sitio
un archivo robots txt bloquear el robot de google (1)
Tengo una aplicación web ASP.NET MVC 4 a la que se puede acceder desde múltiples dominios diferentes. El sitio está completamente localizado en función del dominio de la solicitud (similar en concepto a esta pregunta ).
Deseo incluir un archivo robots.txt y quiero localizar el archivo robots.txt en función del dominio, pero soy consciente de que solo puedo tener un archivo de texto físico "robots.txt" en el directorio del sistema de archivos de un sitio.
¿Cuál es la forma más fácil / mejor (e incluso es posible) de usar el marco MVC de ASP.NET para lograr un archivo robots.txt por dominio para que la misma instalación del sitio sirva contenido a cada dominio, pero el contenido del archivo de robots está localizado dependiendo del dominio solicitado?
El proceso es razonablemente simple:
El enfoque del controlador / acción
- Utilizando su tabla de rutas, asigne su ruta de robots.txt a una acción en un controlador (uso el controlador y la acción como un simple ejemplo para comenzar), tal como lo haría con cualquier otro controlador y vista para una ruta determinada.
- Dentro de la Acción, verifique el dominio en la solicitud y elija su contenido robots.txt para ese dominio.
- Devuelve el archivo apropiado del disco usando algo como:
-
ContentResulty configurarContentTypeen"text/plain" -
FilePathResultsi sus archivos robots son solo archivos en el disco, a través de uno de los métodos auxiliares en la claseControllercomoFile(name, "text/plain")
-
El siguiente ejemplo asume un solo archivo robots.txt de nivel superior:
// In 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" }
);
// The controller:
public class SeoController : Controller {
public ActionResult Robots() {
var robotsFile = "~/robots-default.txt";
switch (Request.Url.Host.ToLower()) {
case ".com":
robotsFile = "~/robots-so.txt";
break;
case "meta..com":
robotsFile = "~/robots-meta.txt";
break;
}
return File(robotsFile, "text/plain");
}
}
Una de las formas más fáciles de hacer que esto funcione es garantizar que se llame al módulo de enrutamiento para todas las solicitudes que utilizan runAllManagedModulesForAllRequests en web.config (no lo use, consulte el párrafo siguiente):
<system.webServer>
<handlers>
...
</handlers>
<modules runAllManagedModulesForAllRequests="true" />
</system.webServer>
Esto no es bueno en general ya que ahora todos los archivos estáticos (css, js, txt) pasan por manejadores administrados antes de ser desviados al manejador de archivos estáticos. IIS es realmente bueno para servir rápidamente archivos estáticos (un sitio web de archivos estáticos maximizará su forma de E / S de disco antes de la CPU), por lo que para evitar este rendimiento, el enfoque recomendado es la sección de muestra de web.config a continuación. Tenga en cuenta la similitud con el controlador ExtensionlessUrlHandler-Integrated-4.0 en las aplicaciones de plantilla de Visual Studio MVC 4:
<system.webServer>
<handlers>
<add name="Robots-Integrated-4.0"
path="/robots.txt" verb="GET"
type="System.Web.Handlers.TransferRequestHandler"
preCondition="integratedMode,runtimeVersionv4.0" />
... the original handlers ...
</handlers>
<modules runAllManagedModulesForAllRequests="false" />
</system.webServer>
Beneficios / inconvenientes
Las ventajas de este tipo de enfoque se ponen de manifiesto una vez que empiezas a usarlo:
- Puede generar dinámicamente archivos robots.txt utilizando los ayudantes para generar URL de acción que luego puede agregar todo / parte del archivo robots.txt de la plantilla.
- Puede verificar que el agente de usuario del robot devuelva diferentes archivos de robots por agente de usuario de robot.
- Puede usar el mismo controlador para generar archivos sitemap.xml para rastreador web
- Puede administrar el contenido de los robots desde una tabla de base de datos que los usuarios del sitio pueden administrar fácilmente.
A la baja,
- su archivo de robots ahora está complicando su tabla de rutas, y realmente no necesita
- Deberá optimizar el almacenamiento en caché para evitar lecturas constantes de discos. Sin embargo, esto es lo mismo para cualquier enfoque que tome.
Recuerde también que se pueden usar diferentes archivos robots.txt para diferentes subdirectorios. Esto se complica con el enfoque de ruta y controlador, por lo que el enfoque IHttpHandler (abajo) es más fácil para esta situación.
El enfoque IHttpHandler
También puede hacer esto con un IHttpHandler personalizado registrado en su web.config . runAllManagedModulesForAllRequests="true" costumbre ya que esto evita la necesidad de hacer que TODOS los controladores vean TODAS las solicitudes (con runAllManagedModulesForAllRequests="true" , a diferencia de agregar un manejador de ruta personalizado en su tabla de rutas.
Este también es potencialmente un enfoque más ligero que el controlador, pero tendría que tener un tráfico de sitio enorme para notar la diferencia. Otro beneficio es un fragmento de código reutilizable que puede usar para todos sus sitios. También podría agregar una sección de configuración personalizada para configurar las correlaciones de robot user agent / domain name / path con los archivos de robots.
<system.webServer>
<handlers>
<add name="Robots" verb="*" path="/robots.txt"
type="MyProject.RobotsHandler, MyAssembly"
preCondition="managedHandler"/>
</handlers>
<modules runAllManagedModulesForAllRequests="false" />
</system.webServer>
public class RobotsHandler: IHttpHandler
{
public bool IsReusable { get { return false; } }
public void ProcessRequest(HttpContext context) {
string domain = context.Request.Url.Host;
// set the response code, content type and appropriate robots file here
// also think about handling caching, sending error codes etc.
context.Response.StatusCode = 200;
context.Response.ContentType = "text/plain";
// return the robots content
context.Response.Write("my robots content");
}
}
robots.txt en subdirectorios
Para servir a los robots para los subdirectorios, así como a la raíz del sitio, no puede usar el enfoque del controlador fácilmente; el enfoque del controlador es más simple en este escenario. Esto se puede configurar para recoger solicitudes de archivos robots.txt a cualquier subdirectorio y manejarlas en consecuencia. A continuación, puede optar por devolver 404 para algunos directorios o una subsección del archivo robots para otros.
Menciono esto específicamente aquí ya que este enfoque también se puede usar para los archivos sitemap.xml, para servir diferentes mapas de sitio para diferentes secciones del sitio, múltiples sitemaps que se refieran entre sí, etc.
Otras referencias: