Por qué el robots.txt es un problema gordo en WordPress multisitio … pero afortunadamente tiene solución

Si gestionas una red de WordPress con varios sitios esto te va a sonar…

Quieres que un sitio tenga unas reglas en el robots.txt y otro las suyas, normal ¿no?, porque no todos necesitan lo mismo, y resulta que WordPress te sirve el mismo robots.txt para todos. Y encima, si abres el de cualquiera de los dominios, ves uno que no has puesto tú.

Me lo trajo hace poco un cliente del servicio de mantenimiento, con un multisitio de varios dominios, que me pidió tocarle los robots.txt de cada web.

Cuando me puse a mirarlo resulta que el problema no era suyo ni de su configuración, era de cómo funciona WordPress por dentro con los ficheros en una red multisitio.

Así que aprovecho para contártelo con calma, porque tiene más miga de la que parece. Y sí, ya te lo adelanto, se puede tener un robots.txt distinto por sitio en una red multisitio de WordPress, pero antes hay que darle una pensada, porque todo tiene sus matices.

¿Por qué en cada dominio de WordPress multisitio hay dos archivos para robots?

Primero, un apunte rápido para quien llegue nuevo. WordPress no crea un fichero robots.txt de verdad en el disco, lo genera dinámicamente cada vez que alguien lo pide, lo que se llama un robots.txt virtual. Puedes verlo y modificarlo, pero eso ya te lo conté al detalle en el post sobre el robots.txt virtual de WordPress, con el truco de verlo tecleando ?robots=1 y el filtro para cambiarlo.

El caso de mi cliente era que en su multisitio hay un robots.txt físico, un fichero de verdad, en la raíz del dominio principal, el que aloja la red y desde el que se instalan los plugins y el tema.

Y como toda la red comparte esa misma carpeta raíz, ese fichero se sirve igual para todos los dominios, así que tecleas otro-dominio.com/robots.txt y sale el del principal, no el del subsitio, porque no tiene un robots.txt físico, no es posible.

¿Y el virtual de cada sitio, el que tú crees que estás editando con tu plugin de SEO? Ahí sigue, pero solo aparece si lo fuerzas a mano con otro-dominio.com/?robots=1.

Los rastreadores piden siempre /robots.txt, así que se meriendan el físico compartido y nunca ven las reglas propias de cada web. De ahí la sensación de tener dos, el que sirven los bots y el que gestiona el plugin, cada uno con sus reglas y sin enterarse el uno del otro.

¿Y por qué gana el físico? Pues porque cuando existe uno en la raíz, lo entrega el servidor web antes de que WordPress ni siquiera arranque, así que el virtual y el filtro se quedan sin pintar nada para esa dirección.

Subdominios, dominios mapeados y subcarpetas

El estándar del robots.txt, recogido en el RFC 9309 que es la norma oficial, dice que el archivo vive en la raíz de cada host, o sea de cada dominio o subdominio, y de ahí salen tres escenarios muy distintos según cómo tengas montada la red.

• Red por subdominios (es.tudominio.com, en.tudominio.com): cada sitio es un host distinto, así que cada uno puede y debe tener su propio robots.txt. Aquí lo de «uno por sitio» tiene todo el sentido.
• Red por dominios mapeados (dominio.com, domain.com): igual que el anterior, cada dominio es un host, así que cada uno lleva el suyo.
• Red por subcarpetas (dominio.com/es, dominio.com/en): todos comparten el mismo host, así que solo hay un robots.txt que cuente, el de la raíz del dominio, y manda el sitio principal. Un subsitio en subcarpeta no puede servir el suyo a los rastreadores por mucho plugin que le pongas.

Y ojo, que lo de las subcarpetas no es una carencia de WordPress, es el propio estándar.

El robots.txt va en la raíz del host y punto, así que si tu red es por subcarpetas, lo máximo que puedes hacer es meter todas las reglas que necesites, conjuntas, en el robots.txt del dominio principal, teniendo cuidado de no meter reglas que solo sirvan para el dominio o una carpeta concreta, todas generales.

¿Qué hago con el robots.txt del sitio principal?

Da igual la vía que elijas luego, con código o con plugin, si hay un robots.txt físico en la raíz y quieres reglas por subsitio quítalo, porque carga antes que WordPress y ningún plugin o PHP se lo puede saltar.

Mientras ese fichero siga ahí los bots seguirán leyéndolo a él y las reglas por sitio no llegarán a ninguna parte.

Pero, si es el caso, con quitarlo no basta, además tienes que asegurarte de que ningún plugin te lo vuelve a crear. El editor de ficheros de Yoast, por ejemplo, escribe un robots.txt físico si le das al botón, y en una red ese fichero se te cuela para todos. Así que bórralo, comprueba por FTP que no reaparece, desactiva la edición de archivos dentro de WordPress, y solo entonces pasamos al siguiente paso.

Una vez fuera  el archivo físico WordPress ya sirve el virtual de cada sitio por su cuenta, y ahí sí puedes empezar a configurar en cada web el suyo. En subdominios y dominios mapeados esto funciona tal cual, cada host sirve el suyo. En subcarpetas no hay manera, se siente, solo cuenta el del dominio principal.

Cómo darle reglas propias de robots a cada subsitio de una red multisitio (con código)

Si no quieres depender de ningún plugin de SEO para esto, WordPress trae un filtro, robots_txt, que te deja modificar el robots.txt virtual, y combinándolo con get_current_blog_id() (la función que te dice en qué sitio de la red estás) puedes dar reglas distintas según la web. La idea, que he ido ampliando y actualizando, me la dio Florian Brinkmann, en un post de hace ya unos pocos años.

Lo que hay que hacer es meter el siguiente código en un mu-plugin que se activa en toda la red. Lo subes por FTP a la carpeta wp-content/mu-plugins y listo:

/**
 * Plugin Name: Archivo robots.txt por sitio en WordPress Multisitio
 * Plugin URI: https://ayudawp.com/
 * Description: Permite definir reglas de robots.txt diferentes para cada sitio en una red multisitio de WordPress.
 * Version: 1.0
 * Author: Fernando Tellado
 * Author URI: https://tellado.es
 */

// Añade reglas por sitio al archivo robots.txt virtual de cada sitio a través de la red
add_filter( 'robots_txt', 'ayudawp_multisite_robots_txt', 20, 2 );

function ayudawp_multisite_robots_txt( $output, $public ) {

// Solo funciona si es multisitio
if ( ! is_multisite() ) {
return $output;
}

// Reglas por sitio asignadas por ID de blog (tienes el ID en Administrador de la red > Sitios)
switch ( get_current_blog_id() ) {

// Sitio con ID 2: tienda online
case 2:
$output .= "Disallow: /carrito/\n";
$output .= "Disallow: /finalizar-compra/\n";
$output .= "Disallow: /mi-cuenta/\n";
break;

// Sitio con ID 3: blog
case 3:
$output .= "Disallow: /?s=\n";
$output .= "Disallow: /descargas/\n";
$output .= "Disallow: /gracias/\n";
break;
}

return $output;
}

Cambias los ID (case x)  y las reglas por las tuyas, y cada web servirá las suyas.

El código tiene sus límites, como que es obvio que lo mantienes tú a mano cada vez que cambien las necesidades, y luego claro está, no se puede aplicar a otros archivos, como el llms.txt, que arrastra el mismo problema. Y por supuesto, te recuerdo de nuevo que en una red en subcarpetas no hay milagro que valga.

¿Afecta esto también al llms.txt?

Ya que estás con el robots.txt, los archivos llms.txt sufren del mismo problema.

Es un fichero que sirve de índice en Markdown de tu web para los agentes de IA, y en una red cada sitio querría el suyo. Mismo patrón que el robots.txt, por sitio si lo sirves dinámico, y compartido y roto si escribes un físico en la raíz. La diferencia con el robots.txt es que aquí ni el filtro tienes.

WordPress no genera archivos llms.txt ni trae ninguna función para tocarlo, así que el mu-plugin de arriba no sirve y por código te quedas sin un atajo como el del robots.txt. Para tenerlo por sitio en una red la vía práctica es un plugin que lo genere dinámico por sitio, y de eso va lo que viene ahora.

Cómo darle reglas propias de robots a cada sitio (con plugins)

Si lo de mantener un mu-plugin no te apetece, o también quieres que el llms.txt sea configurable en cada sitio, esto lo resuelven algunos plugins.

De pago te lo ofrece AIOSEO, que tiene un editor de robots.txt de red que te deja tocar el de cada subsitio, pero solo en redes por subdominios, no por subcarpetas (lo dicen ellos en su documentación), y en su versión Pro. SEOPress anuncia edición de robots.txt para multisitio y multidominio, y luego hay plugins dedicados solo a esto, como Multisite Robots.txt Manager. De las subcarpetas nos seguimos olvidando, porque ya sabes que ahí manda el estándar.

Y luego está Visibility, plugin gratuito de SEO que sirve el robots.txt y también el llms.txt de cada sitio de la red por su cuenta, sin que tengas que tocar nada.

Entrega por una única URL, la de siempre, /robots.txt, y de paso arregla ese lío del ?robots=1 y los 404 en instalaciones en subcarpeta. Además, está pensado para no repetir el problema, porque en una red no escribe un físico compartido, solo lo escribe donde de verdad es del sitio, en una instalación normal o en el sitio principal de una red por subcarpetas.

Visibility sustituye a tu plugin de SEO, no convive con él, así que si vienes de Yoast u otro plugin, esto supone cambiar el que tuvieses por Visibility, no añadir uno más, que siempre es mala idea. Pero no es algo preocupante, no pierdes nada importante, tiene lo que los demás, y algunas cosas (casi todas) las hace mejor.

Ah, y da igual la elección, aunque uses Visibility el robots.txt físico de la raíz hay que quitarlo igual, porque un fichero que sirve el servidor no lo salta nadie. Eso sí, si Visibility detecta un físico compartido tapando el virtual, te avisa en su pestaña de descubrimiento para que sepas que está ahí y lo quites.

Y, por si no lo sabías Visibility, además de hacer lo que todos los demás plugins de SEO, redirecciones incluidas, también emite las señales por sitio (robots.txt, llms.txt y el schema), y si además quieres medir, tienes VigIA, que ofrece analítica de qué rastreadores de IA entran de verdad en cada web y puede bloquearlos, y puedes complementar el pack IA con AI Content Signals, que añade las directivas de IA de Cloudflare.

Resumiendo: Qué hacer con los ficheros robots.txt en multisitio según el tipo de red

En un par de líneas, por si ya estás con algo de lío:

• Si tu red es por subdominios o por dominios mapeados: quita el físico de la raíz y luego das las reglas por sitio con el mu-plugin del filtro robots_txt, o dejas que lo haga tu plugin de SEO (o Visibility) por ti. Cada dominio servirá el suyo.
• Si tu red es por subcarpetas: solo hay un robots.txt, el del dominio principal, así que mete ahí todas las reglas que necesites para los distintos subsitios. Es el único sitio donde los bots las van a leer.

¡Te toca decidir!

Antes de tocar nada, échale un vistazo a tu red y mira si tienes el problema. Pide el robots.txt de cada dominio y compáralos, y si todos te devuelven exactamente el mismo, tienes un físico compartido mandando sobre todos.

Desde el terminal es tan fácil como teclear la URL tipo https://dominio.com/robots.txt cambiando el dominio o subdominio, y comparar lo que sale. Y si quieres ver el virtual la URL es añadir ?robots=1 al dominio o subdominio.

Con eso claro decides si quitar el físico y tirar de código, o quitar el físico y dejar que un plugin te sirva el de cada sitio. Lo que no funciona es dejar el robots.txt físico compartido ahí, porque se antepone en toda la red y, salvo que uses las mismas reglas para todos los subsitios, puedes estar creándote un problema de rastreo.

Si tienes una red montada de una forma rara, o te topas con algún caso que no encaja con esto, me tienes en los comentarios aquí abajo, que estos temas de multisitio siempre traen su cosilla, y no lo usa muchísima gente.

¿Te gustó este artículo? ¡Ni te imaginas lo que te estás perdiendo en YouTube!