Robots.txt en WordPress bloquea tu web sin que lo sepas

El robots.txt en WordPress es el primer archivo que lee Googlebot al llegar a un sitio, y casi nadie lo mira hasta que el tráfico cae sin motivo aparente. Sirve para decirle a los rastreadores qué carpetas pueden visitar, no para decidir qué páginas aparecen en el buscador: esa confusión es la que deja blogs enteros fuera de Google durante meses.

Esta pieza es para quien administra un WordPress con el blog recién reactivado o con un desarrollador distinto en cada fase del proyecto, y quiere comprobar en cinco minutos si su configuración está bloqueando algo que no debería.

El robots.txt en WordPress no evita que una página se indexe: solo le dice a Google qué carpetas no debe visitar. Si bloquea una URL que otros sitios enlazan, Google puede seguir mostrándola en los resultados sin su contenido real. Para sacar una página de Google hace falta la etiqueta noindex, no un Disallow.

Robots.txt en WordPress controla el rastreo, no el índice

Un robots.txt es un fichero de texto plano con instrucciones para los rastreadores: qué carpetas pueden recorrer y cuáles no. En WordPress vive, por defecto, solo en la memoria del servidor: la función do_robots() del núcleo lo genera al vuelo cada vez que alguien visita tudominio.com/robots.txt, sin que exista ningún fichero físico que tocar. Esa es la raíz de la confusión más común: creer que bloquear una carpeta en ese archivo basta para que Google deje de mostrarla en sus resultados.

Según la documentación de robots.txt de Google, el archivo no es un mecanismo para mantener una página fuera de Google: sirve para no sobrecargar el servidor con peticiones, y nada más. Si una página bloqueada tiene enlaces desde otros sitios, puede seguir apareciendo en el buscador con su URL visible pero sin descripción, porque Google nunca llegó a leer el contenido.

Para una pyme que acaba de retomar su blog, confundir los dos conceptos tiene un coste real: se revisa el contenido, se corrige el SEO on-page y la pieza sigue sin aparecer, porque el problema nunca estuvo en el artículo sino en el archivo que decide si Google puede llegar a él.

El archivo virtual que genera WordPress por defecto

Mientras no exista un fichero físico en la raíz del sitio, el robots.txt que ve Google es el que genera do_robots(): un bloque mínimo con User-agent: *, Disallow: /wp-admin/ y Allow: /wp-admin/admin-ajax.php. Según la referencia de funciones del núcleo de WordPress.org, ese es el contenido por defecto en cualquier instalación sin plugin de SEO ni archivo propio.

Un robots.txt físico anula siempre al de WordPress

En cuanto aparece un archivo robots.txt real en la carpeta raíz —subido por un desarrollador, dejado por una migración o creado por un plugin de seguridad— el servidor lo entrega directamente y la función del núcleo deja de ejecutarse. No hay término medio: gana siempre el físico, aunque el plugin de SEO tenga configurada otra cosa en su pantalla de ajustes. Es el motivo por el que a veces se cambia la configuración del robots.txt desde Yoast o RankMath y el archivo público no se mueve ni una línea: alguien dejó un robots.txt estático de una migración anterior, con un Disallow: / completo pensado para el entorno de pruebas, y nadie volvió a tocarlo tras publicar el sitio en producción.

WordPress abandonó el bloqueo total en la versión 5.3

Hasta la versión 5.3, de noviembre de 2019, marcar la casilla «Disuade a los motores de búsqueda de indexar este sitio» en Ajustes > Lectura añadía un Disallow: / al robots.txt virtual: bloqueaba el rastreo del sitio entero, no solo su indexación. El propio equipo de WordPress cambió ese comportamiento porque generaba el problema contrario al que pretendía resolver.

Desde esa versión, la casilla ya no toca el robots.txt: activa en su lugar una etiqueta noindex en cada página, a través del filtro wp_robots_no_robots(). El cambio sigue al pie de la letra lo que explica Google sobre cómo eliminar contenido del índice: para que la etiqueta noindex funcione, la página tiene que seguir siendo rastreable. Un Disallow: / previo nunca deja que Google llegue a leer esa etiqueta, así que el bloqueo por robots.txt termina siendo menos eficaz que la propia etiqueta que sustituyó.

La etiqueta noindex solo funciona si el rastreador puede abrir la página: si el robots.txt la bloquea antes, Google nunca llega a leerla y el bloqueo pierde su efecto.

Search Console avisa cuando el bloqueo no sirve

El informe de cobertura de Search Console distingue dos situaciones que se confunden constantemente. «Bloqueada por robots.txt» significa que Google ni siquiera intentó abrir la página. «Indexada, aunque bloqueada por robots.txt» es la combinación peligrosa: la URL está en el índice, normalmente porque algún otro sitio enlaza a ella, pero Google no puede leer su contenido real y la muestra con un resultado pobre, sin descripción ni datos estructurados.

Cómo comprobarlo sin esperar a que avise Search Console

No hace falta esperar a que aparezca el informe: basta con abrir tudominio.com/robots.txt en el navegador y leer qué carpetas aparecen con Disallow. Si el archivo es el virtual de WordPress, solo debería bloquear /wp-admin/. Si aparece un Disallow: / a secas, o reglas que nadie recuerda haber escrito, hay un archivo físico heredado de otra fase del proyecto. La herramienta de inspección de URLs del propio Search Console confirma el resto: muestra si esa página concreta está permitida para el rastreo y si WordPress la ha marcado además con una etiqueta noindex, que es la pieza que de verdad decide si sale en el buscador.

Bloquear carpetas técnicas también penaliza el rastreo

Hay una costumbre antigua, de cuando Google no ejecutaba JavaScript ni CSS, que consistía en bloquear por robots.txt las carpetas técnicas de WordPress para «ahorrar» rastreo. Desde que Google renderiza las páginas como un navegador para entender su diseño, bloquear esas rutas no ahorra nada: le impide ver la maquetación real de la página, y el límite de velocidad que fija Google para considerarla rápida se mide precisamente sobre esa versión renderizada. Las carpetas que con más frecuencia aparecen bloqueadas por error son estas:

• /wp-content/themes/: ahí viven el CSS y las fuentes del tema activo.
• /wp-content/plugins/: scripts y estilos que muchos plugins cargan en el frontend.
• /wp-includes/: librerías de WordPress que algunas plantillas usan para pintar el diseño.
• /feed/: bloquearlo no afecta al SEO, pero rompe los lectores RSS de quien sigue el blog.

Ninguna de ellas debería bloquearse hoy, ni siquiera para pensar que así se protege al servidor de un rastreo excesivo. La única carpeta con un Disallow legítimo en un WordPress estándar sigue siendo /wp-admin/, y eso es así porque no aporta nada indexable, no porque haya riesgo de que Google la visite de más. Revisarlo no exige conocimientos técnicos: basta con abrir el archivo y pedir que lo corrija quien mantenga la web, antes de dar por perdida una pieza que nunca tuvo el problema en el texto.

Preguntas frecuentes sobre el robots.txt en WordPress

¿Puedo borrar el robots.txt para que todo se indexe sin problema?

No hace falta: sin archivo físico, WordPress sirve su versión virtual con un único Disallow a /wp-admin/, que no afecta al resto del sitio. Borrar un archivo físico heredado de una migración sí puede ayudar, siempre que antes se compruebe qué reglas tenía y por qué las puso quien lo subió.

¿El plugin de SEO puede sobrescribir un robots.txt físico?

Sí, casi todos —Yoast, RankMath, All in One SEO— ofrecen un editor que crea o modifica el archivo directamente desde el panel de WordPress. Si ya existe uno físico subido por FTP, hay que corregirlo desde ese mismo editor: tocar el servidor sin pasar por el plugin vuelve a desincronizar los dos.

¿Un Disallow en robots.txt borra una página ya indexada?

No. Si Google ya indexó la página antes de bloquearla, el Disallow impide que vuelva a rastrearla pero no retira la URL del índice por sí solo; puede seguir apareciendo con una descripción vacía. Para retirarla de verdad hace falta la etiqueta noindex, con la página todavía rastreable para que Google llegue a leerla.

¿Cómo sé si mi robots.txt actual es el virtual o uno físico?

Si en el hosting, por FTP o gestor de archivos, no hay ningún robots.txt en la raíz del sitio, lo que ves al visitarlo es el virtual de WordPress. En cuanto encuentras el archivo físicamente en esa carpeta, es el que manda, sea quien sea quien lo haya dejado ahí.

Fuente: Google Search Central: Introducción a robots.txt