El archivo robots.txt es una de las piezas más antiguas y peor entendidas del SEO técnico. Es un fichero de texto plano, sin lógica, que vive en la raíz de tu dominio y le dice a los rastreadores qué pueden y qué no pueden visitar. Suena trivial, pero en 2026 ha dejado de ser un detalle de configuración para convertirse en una declaración de política: define quién entrena con tu contenido, quién lo resume sin enviarte tráfico y quién malgasta los recursos de tu servidor.
En este artículo repaso para qué sirve realmente, qué cambia con la irrupción de los bots de inteligencia artificial y cómo plantearlo en un sitio WordPress con WooCommerce. Al final tienes un ejemplo real descargable que uso como base en mi propio fleet de webs.
Qué es y qué no es robots.txt
Conviene desmontar el malentendido más común: robots.txt no es un mecanismo de seguridad ni de bloqueo real. Es una directiva voluntaria. Un crawler educado la lee y la respeta; un crawler malicioso la ignora por completo (e incluso la usa como mapa de las rutas que querías esconder).
Esto tiene una consecuencia práctica importante: si un bot está martirizando tu servidor con scraping agresivo, robots.txt no lo va a detener. Para eso necesitas bloqueo a nivel de servidor, normalmente en el .htaccess o en el firewall. El robots.txt sirve para los que sí cumplen las reglas: Googlebot, Bingbot y los bots de IA que respetan el protocolo.
Dicho de otro modo: robots.txt y .htaccess son capas complementarias. El primero declara tu política de cara a quien la respeta; el segundo ejecuta el bloqueo real contra quien no.
robots.txt y SEO: menos es más
Durante años circuló una plantilla de robots.txt para WordPress que bloqueaba carpetas enteras del CMS: /wp-includes/, /wp-content/plugins/ y similares. Era una práctica razonable hace una década, cuando Google apenas renderizaba JavaScript. Hoy es contraproducente.
El motivo es que Google necesita acceder a los recursos CSS y JavaScript de tu web para renderizarla como la ve un usuario. Si bloqueas la carpeta de plugins, Googlebot no puede cargar los estilos y scripts de Elementor, de tus sliders, de tus formularios o de tu schema dinámico. El resultado es que Google ve una página incompleta o rota, con el riesgo que eso supone para la evaluación mobile-friendly y para los Core Web Vitals percibidos.
La regla moderna es sencilla: no escondas carpetas del sistema; permite los recursos estáticos. Un buen robots.txt de WordPress en 2026 apenas necesita bloquear nada más allá de /wp-admin/ (dejando libre admin-ajax.php), las búsquedas internas y un puñado de URLs duplicadas:
User-agent: * Disallow: /wp-admin/ Allow: /wp-admin/admin-ajax.php Disallow: /?s= Disallow: /search/ Disallow: /*?replytocom=
Las búsquedas internas (/?s=) merecen mención aparte: bloquearlas es de las pocas reglas que aportan valor SEO claro, porque evitan que Google indexe páginas de resultados que generan thin content y contenido duplicado.
El verdadero campo de batalla: los bots de IA
Aquí está el cambio de paradigma. Hasta hace poco, la decisión sobre robots.txt era binaria: dejar entrar a los buscadores o no. Ahora hay una tercera categoría que lo complica todo: los rastreadores de los grandes modelos de lenguaje.
No todos hacen lo mismo, y entender la diferencia es clave para decidir tu política:
- Bots de entrenamiento (GPTBot, ClaudeBot, CCBot, Google-Extended, Applebot-Extended): recogen tu contenido para entrenar o afinar modelos. No te envían tráfico a cambio. Bloquearlos no afecta a tu posicionamiento en Google.
- Bots de búsqueda en vivo (OAI-SearchBot, PerplexityBot, Claude-SearchBot): alimentan respuestas en tiempo real y, en teoría, citan la fuente con un enlace de vuelta. Aquí sí puede haber tráfico potencial.
- Bots agresivos (Bytespider, Amazonbot): conocidos por ignorar las reglas y consumir recursos. A estos solo los frena el servidor.
La decisión estratégica es tuya y depende del tipo de web. Un medio que vive del tráfico quizá quiera aparecer citado en respuestas de ChatGPT o Perplexity, y entonces permitirá los bots de búsqueda en vivo aunque bloquee los de entrenamiento. Una web profesional o de cliente que no quiere que su contenido alimente ningún modelo puede optar por el bloqueo total:
User-agent: GPTBot Disallow: / User-agent: ClaudeBot Disallow: / User-agent: Google-Extended Disallow: / User-agent: CCBot Disallow: / User-agent: PerplexityBot Disallow: /
Una nota importante sobre Google-Extended: bloquearlo impide que tu contenido alimente los modelos de IA de Google (Gemini, los resúmenes generativos), pero no afecta en absoluto a tu inclusión ni a tu ranking en Google Search. Son dos rastreadores distintos con propósitos distintos. Puedes bloquear uno y seguir perfectamente posicionado en el otro.
Existe también un estándar emergente, las Content Signals, que permite declarar de forma más granular tus intenciones (search=yes, ai-input=no, ai-train=no). Es una declaración de intención útil como refuerzo, pero todavía no es un control efectivo: confía en él como complemento, no como barrera.
WooCommerce: rutas que no deberían rastrearse
Si tu WordPress monta una tienda con WooCommerce, el robots.txt tiene una función adicional: evitar que los rastreadores pierdan tiempo (y presupuesto de rastreo) en URLs transaccionales que no tienen ningún valor para indexar.
Páginas como el carrito, el checkout o el área de cliente no deben aparecer en los resultados de búsqueda, y las URLs con parámetros de filtrado u ordenación generan duplicidades infinitas que conviene contener:
Disallow: /carrito/ Disallow: /checkout/ Disallow: /mi-cuenta/ Disallow: /*add-to-cart=* Disallow: /*?orderby= Disallow: /*?filter_*
Dos avisos prácticos. Primero: si tu tienda es multilingüe (con WPML o Polylang), verifica los slugs reales, porque /carrito/ puede ser /cart/ o /cistella/ según el idioma. Segundo: si tienes una estrategia SEO de facetas, con categorías filtradas que sí quieres posicionar, no bloquees esos parámetros con una regla global; afínalos caso por caso.
Un fichero, muchas webs
Si gestionas varias webs, como es mi caso, la tentación es crear un robots.txt distinto para cada una. En la práctica, un único fichero universal bien diseñado cubre la inmensa mayoría de los casos: las reglas de WooCommerce son inocuas en webs sin tienda (simplemente no coinciden con ninguna ruta), y el bloque de bots de IA es idéntico en todas partes.
El único punto que obliga a personalizar es la línea Sitemap:, que apunta a un dominio concreto. Una solución limpia es omitirla del robots.txt y enviar el sitemap directamente por Google Search Console, manteniendo así un fichero idéntico en todo el conjunto de webs.
Conclusión
El robots.txt pasó de ser un trámite técnico a ser una herramienta de gobernanza de tu contenido. En 2026 un buen fichero hace tres cosas: no estorba al SEO (no bloquea recursos de renderizado), define tu relación con la IA (decides qué modelos pueden y cuáles no) y protege el presupuesto de rastreo en tiendas WooCommerce. Lo que no hace —y conviene repetirlo— es detener a los bots agresivos: para eso está el servidor.
Si quieres un punto de partida sólido, puedes ver el ejemplo de robots.txt que utilizo como plantilla base, con bloqueo de IA, reglas SEO-safe para WordPress y soporte para WooCommerce. Adáptalo a tu caso antes de desplegarlo y valida siempre el resultado en Search Console.
