La importancia del archivo llms.txt
El objetivo principal de llms.txt es definir de forma explícita qué partes de un sitio web pueden o no ser utilizadas por modelos de lenguaje para entrenamiento, indexación o generación de respuestas. A diferencia de robots.txt, que regula el comportamiento de crawlers tradicionales orientados a motores de búsqueda, llms.txt introduce una capa adicional de control específica para la IA.
Su importancia radica en varios puntos clave:
Control del uso de contenido: permite al propietario del sitio decidir si su contenido puede ser usado por LLMs y en qué condiciones.
Protección de recursos: los crawlers de LLM suelen realizar exploraciones profundas y repetitivas, generando muchas más peticiones que un bot SEO convencional.
Cumplimiento y gobernanza: ayuda a dejar constancia técnica de la política de uso del contenido, algo cada vez más relevante en términos legales y de licencias.
Transparencia: establece reglas claras y legibles por máquinas sobre cómo debe interactuar la IA con el sitio.
En un contexto donde el número de crawlers de IA crece constantemente, no disponer de un archivo llms.txt implica perder control tanto sobre el contenido como sobre el consumo de recursos del servidor.
Un archivo llms.txt estándar para WordPress genérico sería:
# llms.txt
# Policy for Large Language Models
User-agent: *
Training: disallowed
# Block sensitive WordPress paths
Disallow: /wp-admin/
Disallow: /wp-login.php
Disallow: /wp-cron.php
Disallow: /wp-json/
Disallow: /wp-uploads/
# Allow public frontend
Allow: /
El problema de wp-cron y los crawlers de LLM
Por defecto, WordPress utiliza wp-cron.php, un sistema de pseudo-cron que se ejecuta en cada visita al sitio. Esto significa que cada request HTTP puede disparar comprobaciones y tareas programadas, incluso aunque no haya nada que ejecutar.
Aquí surge el problema:
Cuando crawlers de LLM acceden al sitio (a menudo con alta frecuencia, ejecutando JavaScript y sin cache) cada visita puede activar wp-cron, provocando:
Uso excesivo de CPU
Aumento de procesos PHP simultáneos
Saturación de memoria
Retrasos en la respuesta del sitio
Errores 503 intermitentes
Con crawlers tradicionales esto ya era un riesgo, pero con LLM crawlers el impacto se multiplica, ya que suelen recorrer grandes volúmenes de URLs en poco tiempo.
¿Cómo detectar si tenemos un problema de consumo de recursos derivado por incidencia de bots sobre wp-cron?
Si tenemos todo correctamente configurado en nuestro cPanel, solo usamos un gestor PHP, no tenemos archivos configuracion .ini u handlers en el .htaccess no correspondientes, la memoria asignada es correcta, no hay errores fatales en el error_log
Pero aun así la velocidad de carga en el wp-admin es terrible, de 5 a 6 segundos con 503 si abres varias pestañas.
No cuesta nada revisar el ancho de banda consumido.
En Sered a diferencia de otras empresas no limitamos el ancho de banda de los usuarios por lo que no se suspende el servicio pasado un limite.
Por lo que podemos encontrarnos casos asi:
Donde se puede observar un ancho de banda mensual totalmente desproporcionado.
En cualquier caso siempre que un ancho de banda mensual sea superior a 10GB aunque seamos una tienda es recomendable revisar las estadisticas de entrada.
Ya que si fueran visitas de clientes web, su propia cache debería evitar un consumo constante.
Para comprobarlo basta con revisar los datos en Webalizer, ahí lo normal al seleccionar el mes y el top por kb veamos que la mayoria son bots y ejecuciones del host del usuario
Básicamente estos nuevos robots (IA), ejecutan JS, cambian cosas (colores, combinaciones, etc) y empiezan a realizarse peticiones que hacen que el wp-cron inicialice pero sin contenido/instrucciones se va apilando con cada nueva instrucciones terminando en un desbordamiento.
¿Por qué es mejor desactivar wp-cron y usar Cronjobs?
La solución recomendada en entornos profesionales es desactivar wp-cron desde wp-config.php y delegar su ejecución a un cron real del sistema (cronjob).
Basta con añadir esta instrucción dentro de su archivo wp-config.php para evitar que wp-cron se ejecute en cada visita: define('DISABLE_WP_CRON', true);
Y posteriormente se programa una tarea en el crontab del servidor (por ejemplo, cada 30 minutos) que ejecute wp-cron.php de forma controlada.
https://guias.sered.net/es/articles/517519-como-llevar-a-cabo-la-creacion-y-gestion-de-cron-jobs-en-cpanel
La forma más sencilla de modificar el archivo wp-config.php y crear el CronJob en cPanel de manera automática, es haciendo click en "Take over wp-cron.php" desde el WP Toolkit
Las ventajas de este enfoque son claras:
Ejecución predecible: las tareas se lanzan solo cuando toca, no en cada visita.
Ahorro de recursos: se elimina el impacto directo del tráfico (humano o bot) sobre el cron.
Mejor rendimiento global: menos procesos PHP innecesarios.
Mayor estabilidad: especialmente importante frente a crawlers agresivos, incluidos los de LLM.
Escalabilidad: el sistema aguanta mejor picos de tráfico y exploración automatizada.
Conclusión
En el contexto actual, donde los LLMs y sus crawlers son una realidad permanente, la combinación de llms.txt bien definido y una gestión correcta del cron en WordPress deja de ser una optimización opcional para convertirse en una medida esencial de rendimiento y protección del servidor.
Controlar quién accede al contenido y evitar que cada visita dispare procesos internos innecesarios es clave para mantener un WordPress eficiente, estable y preparado para el ecosistema de la inteligencia artificial moderna.
Si encuentras cualquier dificultad o tienes alguna pregunta, no dudes en contactar con nuestro equipo de soporte técnico a través de la dirección de correo electrónico [email protected] o mediante el chat en vivo desde tu área de clientes para obtener asistencia adicional.