¿Qué es el X-Robots-Tag?

El X-Robots-Tag es una cabecera de la respuesta HTTP con la que un servidor le dice a los buscadores qué pueden hacer con el archivo que acaban de pedir: indexarlo o no, seguir sus enlaces o no, guardar una copia o no. Es la misma conversación que ocurre con la etiqueta meta robots, solo que en otro sitio.

Ese «otro sitio» es toda la diferencia. La etiqueta meta vive dentro del HTML, así que solo existe si hay HTML. La cabecera viaja por delante del archivo, sea del tipo que sea, y por eso es el único camino para un PDF, una imagen o un fichero descargable.

Conviene separarlo desde el principio de la otra instrucción con la que se confunde. El robots.txt regula si el rastreador puede pedir el archivo; el X-Robots-Tag regula qué hace con él después de recibirlo. Son dos momentos distintos, y esa distinción explica casi todos los fallos que aparecen más abajo.

El prefijo X- del nombre recuerda que nació como una cabecera propuesta fuera del estándar, igual que tantas otras de los primeros años de la web. Hoy la respetan los buscadores grandes, pero sigue siendo una petición, no una orden: un cliente cualquiera puede ignorarla sin incumplir nada.

De ahí una consecuencia que conviene tener clara antes de seguir. Todo lo que hace esta cabecera ocurre del lado de quien lee, no del lado del archivo. No lo cifra, no lo mueve, no lo borra: solo cambia lo que un buscador decide hacer con una copia que ya tiene delante.

La pregunta práctica no es cuál de las dos instrucciones es mejor, sino cuál llega al archivo que se quiere controlar. En una página normal las dos funcionan y la elección es de comodidad. En cuanto el archivo deja de ser HTML, solo queda una.

El caso que más aparece en auditorías de SEO técnico son los PDF: catálogos antiguos, tarifas de hace tres años, manuales que nadie mantiene. Están indexados, salen en resultados con su propio título y compiten con las páginas que sí se cuidan. No hay ninguna etiqueta que ponerles dentro, así que el control pasa forzosamente por la cabecera.

Con imágenes ocurre algo parecido, aunque el efecto es distinto: sacar una imagen del índice no saca la página que la contiene, solo deja de mostrarla en la búsqueda de imágenes. Y una precisión que evita sustos: aplicar la cabecera a un archivo no lo protege ni lo esconde, sigue siendo accesible para cualquiera que tenga la URL.

Hay un cuarto grupo de archivos que casi nadie recuerda hasta que aparece en el informe: las hojas de cálculo, los documentos de texto y los archivos comprimidos que se cuelgan «temporalmente» para compartirlos con un cliente. Se quedan, los encuentra el rastreador por un enlace olvidado, y acaban indexados con su nombre de archivo como título.

Merece la pena mirarlo desde el ángulo del presupuesto de rastreo: cada uno de esos archivos se pide y se procesa como cualquier otra URL. En un sitio pequeño no se nota; en uno con miles de documentos, el rastreo que se va en ellos es rastreo que no llega a las páginas que sí importan, algo que se comprueba en los informes de Search Console.

Las instrucciones son las mismas que acepta la etiqueta meta, y conviene conocerlas porque la diferencia entre dos de ellas decide resultados muy distintos. noindex saca la URL de los resultados; nofollow le dice al buscador que no siga los enlaces que contiene, lo cual afecta al enlazado interno y no debe ponerse por costumbre.

Después vienen las que controlan cómo se ve el resultado en la SERP: nosnippet suprime el texto de muestra, max-snippet lo limita, noarchive impide la copia en caché y noimageindex deja fuera las imágenes de esa página. Se combinan separadas por comas en una sola línea.

Hay además dos que se usan poco y resuelven casos concretos: unavailable_after con una fecha, pensado para contenidos con caducidad como una página de campaña o un evento, y none, que equivale a noindex, nofollow a la vez. También se puede dirigir la instrucción a un buscador concreto poniendo su nombre delante, algo útil cuando se quiere tratar distinto a uno de ellos.

Dos de estas instrucciones merecen un aviso porque se ponen con más ligereza de la que deberían. nosnippet quita el texto de muestra del resultado, y un resultado sin descripción recibe menos clics: baja el CTR aunque la posición no se mueva. Tiene sentido en contenido de pago o sensible, no como norma general.

La otra es noarchive, que impide la copia guardada. Suena inocuo, pero esa copia es lo que consultan algunos usuarios cuando el sitio no responde, y también parte de la materia con la que trabajan los sistemas que resumen contenido. Antes de ponerla conviene saber a qué se renuncia, igual que ocurre con las decisiones de indexación en general.

Se configura en el servidor web o en la aplicación que responde, no en el contenido. En Apache y en Nginx se añade una regla que aplica la cabecera a un patrón de archivos; en un CMS suele haber un ajuste por tipo de contenido, y en una aplicación propia se añade a la respuesta como cualquier otra cabecera.

La comprobación es la parte que más se salta y la única que demuestra algo. Pide la URL y mira las cabeceras de la respuesta, no la página renderizada: la instrucción no se ve en pantalla ni en el código fuente. Cualquier cliente que muestre la respuesta HTTP sirve, y la inspección de URLs de Search Console enseña además cómo la interpretó Google.

Y hay que comprobarla en el archivo real, no en una página de ejemplo. Las reglas por patrón fallan justo en los bordes: una extensión en mayúsculas, una carpeta que quedó fuera, un archivo servido por un subdominio distinto con su propio certificado con otra configuración.

Una advertencia sobre dónde se pone la regla: si delante hay una red de distribución de contenidos o una capa de caché, la cabecera tiene que sobrevivir a ese paso. Hay configuraciones que solo reenvían un conjunto de cabeceras conocidas y descartan el resto, de modo que la regla existe en el servidor de origen y no llega nunca al rastreador. Se comprueba pidiendo la URL pública, no la interna.

Y otra sobre el orden de las comprobaciones. Antes de revisar la cabecera hay que asegurarse de que la URL responde 200 y no un 301: una redirección se lleva por delante toda la conversación, porque las cabeceras que cuentan son las del destino final, no las del salto. Es el mismo despiste que hace creer que una regla no funciona cuando en realidad se está mirando la respuesta equivocada.

El primero es el clásico y merece decirse sin rodeos: bloquear la URL en el robots.txt y a la vez poner noindex en la cabecera. El bloqueo impide la petición, así que la cabecera nunca se lee y la página puede seguir apareciendo. Para sacar algo del índice hay que dejar que lo rastreen.

El segundo es olvidar quitarla. Una regla puesta durante una migración o un entorno de pruebas que se copia a producción deja secciones enteras fuera del índice sin que nadie lo note durante semanas; el descenso de tráfico se atribuye entonces a cualquier otra cosa.

Y el tercero, más sutil: usarla donde el problema es otro. Una página que no debería existir y que acaba como soft 404 o como contenido pobre no se arregla con noindex, se arregla dejando de generarla. La cabecera es una instrucción a los buscadores, no una limpieza de la arquitectura del sitio.

Queda un cuarto error que no está en la configuración sino en la expectativa: esperar el efecto de un día para otro. La instrucción solo actúa cuando el buscador vuelve a pedir el archivo, y en una URL poco visitada eso puede tardar semanas. Un índice que no se vacía a las cuarenta y ocho horas no significa que la regla falle, significa que todavía no se ha vuelto a mirar.

Y una recomendación que ahorra discusiones: dejar por escrito qué regla se puso, dónde y por qué. Estas cabeceras se configuran una vez y se leen dos años después, cuando quien las puso ya no está y nadie se atreve a quitarlas por si acaso. Una línea de comentario junto a la regla evita que una decisión razonada acabe tratada como una superstición.