El robots.txt ideal para WordPress en 2026 (qué poner de verdad)

Un buen robots.txt de WordPress ocupa unas cinco líneas. Bloquea /wp-admin/, permite admin-ajax.php, señala tu sitemap a los rastreadores y para ahí: esas listas de bloqueo de 40 líneas que encuentras en los foros o rompen el renderizado o no hacen nada. El archivo entero:

User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php

Sitemap: https://example.com/wp-sitemap.xml

Cambia el dominio y, si usas un plugin de SEO que se encarga de los sitemaps, apunta la línea Sitemap al índice de ese plugin. Ya está. Si tu archivo es más largo que esto, lo más probable es que las líneas de más te estén costando algo.

WordPress ya genera uno, hasta que creas un archivo real

WordPress trae un robots.txt virtual. Cuando llega una petición a /robots.txt y no existe ningún archivo real en tu raíz web, WordPress intercepta la petición e imprime una respuesta en memoria. No se escribe nada en disco. La salida por defecto es el bloqueo de wp-admin de arriba, más una línea Sitemap: para wp-sitemap.xml que el núcleo emite desde WordPress 5.5.

Dos cosas cambian esa salida. Si está marcada la casilla Ajustes → Lectura → Disuade a los motores de búsqueda de indexar este sitio, WordPress sustituye todo por Disallow: /, que bloquea absolutamente todo. Esa casilla es, con diferencia, la causa más frecuente de que un sitio desaparezca de la búsqueda tras un lanzamiento. Y segundo, los plugins y temas pueden modificar la salida virtual mediante el filtro robots_txt, que es como los plugins de SEO inyectan sus propias líneas de sitemap y sus reglas.

Ahora la parte que arruina tardes enteras. Un archivo robots.txt físico en tu raíz web anula todo lo anterior sin decir nada. Tu servidor encuentra un archivo real en disco, lo sirve, y WordPress no llega a cargarse. El generador virtual no se ejecuta. El filtro robots_txt no se dispara. Puede que el editor de robots.txt de tu plugin de SEO te siga enseñando una interfaz preciosa con las reglas correctas dentro, y que nada de eso llegue a un rastreador.

Dónde viven las reglas	Editable desde el escritorio de WordPress	Gana en una petición real
Virtual (sin archivo en disco)	Sí, con el filtro robots_txt o un plugin	Solo si no existe ningún archivo físico
Archivo físico en la raíz web	Solo si el plugin escribe en disco	Siempre

Así que antes de depurar nada: abre https://tusitio.com/robots.txt en el navegador, después conéctate por SFTP o con el gestor de archivos de tu hosting y comprueba si hay un robots.txt real junto a wp-config.php y .htaccess. Si lo hay, ese archivo es tu robots.txt. Edítalo ahí o bórralo y deja que WordPress tome el mando, pero elige una de las dos. Mantener los dos es como los sitios acaban con una URL de sitemap obsoleta que nadie encuentra.

Por qué se bloquea /wp-admin/ pero se permite admin-ajax.php

/wp-admin/ es el escritorio. Esas URL no pintan nada en los resultados de búsqueda y rastrearlas gasta presupuesto de rastreo en páginas que redirigen a una pantalla de acceso. Bloquear el directorio no lo discute nadie.

admin-ajax.php está dentro de ese directorio, pero no es una página de administración. Es el punto de entrada que plugins y temas usan para gestionar peticiones AJAX del front-end: botones de “cargar más”, rejillas de productos filtradas, calculadoras, formularios. Si un rastreador no puede descargarlo, no ve el contenido que cargan esas funciones, y Google renderiza tu página como la vería un visitante con la función rota.

Que Google necesite descargar admin-ajax.php en tu sitio concreto depende de si tu front-end lo usa. Respuesta honesta: en muchos sitios modernos da exactamente igual, porque el tema usa la API REST en /wp-json/ en su lugar. La línea Allow es un seguro barato contra un fallo real, no un factor de posicionamiento. Mantenla porque no cuesta nada.

No bloquees /wp-content/ ni /wp-includes/

Este es el peor consejo sobre robots.txt que sigue circulando, y viene de una época en la que Google no renderizaba las páginas.

/wp-content/ contiene tus temas, plugins y subidas: las hojas de estilo, los scripts y las imágenes que hacen que tus páginas parezcan páginas. /wp-includes/ contiene JavaScript del núcleo del que dependen los plugins. Google renderiza tus páginas con un navegador sin interfaz antes de valorarlas. Bloquea esos directorios y el renderizador se encuentra una página sin CSS y sin imágenes. Lo que Google evalúa es un muro de texto sin estilos y con el diseño roto, lo que afecta a cómo entiende tu contenido y a la puntuación de usabilidad móvil.

Si has heredado un archivo con estas líneas, bórralas:

Disallow: /wp-content/
Disallow: /wp-includes/
Disallow: /wp-content/plugins/
Disallow: /wp-content/themes/

Puedes confirmar tú mismo el daño con la herramienta de inspección de URL de Google Search Console. Lanza una prueba en vivo sobre cualquier página, mira la captura renderizada y revisa la lista de recursos de la página en busca de elementos bloqueados. Si tu CSS aparece como bloqueado, ahí tienes la causa.

La directiva Sitemap

Una línea, URL absoluta, y puede ir en cualquier parte del archivo: no está ligada a ningún grupo de User-agent.

Sitemap: https://example.com/wp-sitemap.xml

Usa la URL que realmente funcione. El núcleo de WordPress sirve wp-sitemap.xml. La mayoría de plugins de SEO desactivan los sitemaps del núcleo y sirven su propio índice en otra ruta, normalmente sitemap_index.xml. Carga tu URL en un navegador antes de darla por buena: una línea Sitemap que apunta a un 404 es peor que no tener línea, porque en una auditoría parece correcta.

Listar varios sitemaps está bien, uno por línea. Enviar los sitemaps por Search Console sigue mereciendo la pena aparte; la directiva de robots.txt es la forma en que los encuentran los rastreadores que nunca verán tu cuenta de Search Console.

robots.txt no es noindex, y no es seguridad

Estos dos malentendidos causan casi todos los destrozos con robots.txt.

Bloquear una URL no la saca de Google. Robots.txt gobierna el rastreo. Si otro sitio enlaza una URL bloqueada, Google puede indexar la URL en sí y obtienes un resultado con la dirección pelada y una nota de que no hay información disponible. Y hay una trampa peor: si una página ya tiene una metaetiqueta noindex y después la bloqueas en robots.txt, Google no puede rastrearla, no puede ver el noindex y la página puede quedarse indexada indefinidamente. Para quitar una página, permite el rastreo y sirve una metaetiqueta robots con noindex en la cabecera de la página o una cabecera HTTP X-Robots-Tag. Google dejó de admitir directivas noindex dentro de robots.txt en 2019.

Bloquear una ruta no la protege. Tu robots.txt es público por definición. Poner /archivos-privados-clientes/ le dice a cada visitante y a cada escáner exactamente dónde mirar, y el cumplimiento es voluntario: Google lo respeta, los bots hostiles no. Todo lo que necesite protección necesita autenticación, una restricción por IP o reglas a nivel de servidor en .htaccess, no una línea en un archivo de texto que señala el objetivo.

Reglas que vale la pena añadir y reglas que vale la pena saltarse

Hay dos añadidos realmente útiles en muchos sitios. Bloquear la ruta de resultados de búsqueda evita que los rastreadores generen URL sin valor a partir de tu buscador interno. Bloquear la ruta del carrito o del pago en WooCommerce mantiene las URL con parámetros de sesión fuera del rastreo.

Disallow: /?s=
Disallow: /search/

Sáltate esto:

• Crawl-delay: Google lo ignora por completo. Usa los controles de frecuencia de rastreo de Search Console si tienes un problema real de carga en el servidor.
• Bloquear /feed/ o /trackback/: son URL inofensivas, y los feeds son útiles.
• Listas largas de nombres de bots concretos: la mayoría de los bots que la gente intenta bloquear no se identifican con honestidad de todos modos.
• Bloquear /wp-json/: puede ser justo lo que usa tu tema para renderizar el contenido.

Monta el archivo con el generador de robots.txt para WordPress, que produce la versión mínima correcta y te deja añadir las reglas de búsqueda y de tienda sin pelearte con la sintaxis a mano.

Después de cambiarlo

Carga https://tusitio.com/robots.txt directamente y confirma que los bytes servidos son los que esperas, no lo que te enseña el editor de tu plugin. Después lanza una inspección de URL en vivo desde Search Console sobre una página normal y comprueba que ningún recurso CSS o JavaScript vuelve como bloqueado. Google cachea el robots.txt aproximadamente un día, así que ni un arreglo surte efecto al instante ni un error tampoco. Ese retardo es justo el motivo para verificar con calma en vez de probar en producción y esperar a ver qué pasa.