En qué me equivoqué sobre `robots.txt`

• Tras intentar bloquear a todos los rastreadores del sitio web mediante la configuración de robots.txt, experimenté efectos secundarios inesperados
• La vista previa de las publicaciones en LinkedIn desapareció y también confirmé una disminución en el alcance de las publicaciones
• La causa fue que robots.txt bloqueaba el acceso de LinkedInBot a la página, impidiendo la recopilación de metaetiquetas
• Reconocí de nuevo que el Open Graph Protocol cumple un papel clave al generar vistas previas en redes sociales
• Modifiqué robots.txt con un enfoque de permisos parciales y resolví el problema; entendí la necesidad de hacer suficientes pruebas al cambiar funciones

---

Introducción: configuración de robots.txt y una experiencia con problemas no intencionales

• Recientemente, mientras aprendía sobre la configuración de robots.txt en mi blog, empecé a pensar en el tema de los derechos sobre los datos de mi contenido
• Modifiqué robots.txt para bloquear a todos los rastreadores del sitio web
• De forma inesperada, esto produjo resultados no deseados en el sitio

El problema con la vista previa de publicaciones en LinkedIn

• Después de cambiar robots.txt, al publicar el enlace de mi blog en LinkedIn ya no aparecía la vista previa (miniatura y resumen)
• Antes la vista previa se mostraba con normalidad, pero tras el cambio la visibilidad y la interacción disminuyeron drásticamente
• Al principio pensé que era un problema temporal, pero el fenómeno continuó durante más de dos semanas
• Al analizarlo con LinkedIn Post Inspector, se comprobó que robots.txt restringía el acceso de LinkedInBot, por lo que no podía recopilar la metainformación
• En las plataformas de redes sociales, para generar vistas previas de enlaces es indispensable solicitar la página y recopilar metaetiquetas

Introducción al Open Graph Protocol

• El Open Graph Protocol (OGP) es un protocolo estándar creado por Facebook que convierte una página web en un objeto del grafo social
• OGP define un conjunto mínimo de metaetiquetas obligatorias
  • og:title: título de la publicación
  • og:type: tipo de objeto, por ejemplo "video.movie"
  • og:image: URL de la imagen en miniatura
  • og:url: URL representativa de ese objeto
• Gracias a este protocolo, el contenido puede resumirse eficazmente y mostrarse de forma atractiva en distintas plataformas sociales

Solución mediante permisos parciales en robots.txt

• Para resolver el problema, modifiqué robots.txt para permitir únicamente a LinkedInBot
• Si también necesitas vistas previas en otras plataformas sociales, debes permitir cada bot por separado
• Ejemplo de la configuración que tengo aplicada actualmente:

  User-agent: LinkedInBot
  Allow: /
  
  User-agent: *
  Disallow: /
  

Reflexión y aprendizajes

• Si bloqueas indiscriminadamente a todos los rastreadores, pueden surgir problemas de visibilidad y presentación del contenido
• Reconocí que fue un error actuar sin suficientes pruebas sobre los efectos del cambio
• Gracias a esta experiencia, aprendí más sobre herramientas y estándares web útiles como Open Graph Protocol y LinkedIn Post Inspector
• Al agregar o modificar funciones, es necesario entender y verificar suficientemente toda el área de impacto
• Al principio no logré relacionar OGP con el bloqueo de robots.txt, pero la experiencia me hizo reconocer su importancia

[GN⁺]

Opinión de Hacker News

• Antes, el propósito principal de robots.txt era evitar penalizaciones por contenido duplicado en los motores de búsqueda. Cuando operabas un sitio dinámico difícil de gestionar, la misma página podía exponerse bajo varias URL por cosas como parámetros de consulta, y los buscadores te penalizaban. robots.txt servía para decir: "esta es la URL canónica, ignora las demás". Además, ayudaba a que los rastreadores "buenos" no se perdieran siguiendo enlaces infinitos. Claro, los rastreadores "malos" no le hacían caso, y a esos se les bloqueaba por IP y similares. Bloquear por User-Agent no servía de mucho. Creer que un bot malicioso va a respetar tranquilamente las reglas es una idea ingenua. El encabezado DNT (Do Not Track) era parecido: básicamente pedirle a empresas cuyo negocio es rastrearte que "por favor no rastreen". O como la idea del Evil Bit del RFC, esperando que un paquete malicioso marque por sí solo en el encabezado "soy malicioso"

  • Hay que recordar que la propuesta de Evil Bit era un RFC del Día de los Inocentes ver RFC 3514

  • Al final también me hace pensar si robots.txt cumple un rol parecido al del sitemap, pero en realidad es lo opuesto. robots.txt indica a qué lugares no debe acceder el rastreador, y el sitemap indica qué quieres que se indexe. No conocía ese propósito original de gestionar penalizaciones por contenido duplicado, así que me dio un nuevo contexto sobre cómo pensar el control de SEO

  • La clave es que, cuando declaras cierta conducta como "prohibida", solo funciona con algunos actores honestos o con quienes por descuido no ocultaron bien el nombre de su user agent. Más allá de eso no suele servir mucho, así que termina siendo una medida algo simbólica

  • Como pasa con el encabezado DNT, este tipo de intentos que parecen imposibles de hacer cumplir en la práctica a veces reciben críticas, pero en realidad la idea de DNT buscaba aplicarse junto con mecanismos legales. Aunque sea difícil impedirlo completamente por medios técnicos, también hay que considerar que, si una empresa comete actos ilegales a gran escala, eventualmente puede quedar expuesta por denunciantes internos

  • Hay gente que cree que, si se establecen reglas, todos las van a cumplir, y a veces me pregunto si esa creencia vendrá de una diferencia cultural

• En 2003 construí mi propio motor de búsqueda y rastreé la web. Puse mi correo de contacto en el user agent y recibí muchísimos mensajes de queja. Sentí que, aunque mi rastreador era lo más cuidadoso y educado posible, la gente no quería nada que no fuera Google. Esa actitud es precisamente lo que impide que aparezcan competidores frente a Google. No es solo un tema del problema de previsualización de LinkedIn; también hay que pensar que la web debería estar abierta a distintos bots y usuarios. Claro que hay que bloquear a los rastreadores abusivos, pero no es deseable tratar por defecto a todos los bots como si fueran maliciosos

  • Desde el lado de quien intentaba operar un bot de forma responsable, lo más irritante que me pasó fue que alguien lanzó un bot malicioso usando el user agent de mi bot y luego las quejas me llegaron a mí

  • Cualquiera puede querer protegerse de su propio bot, pero en la práctica no es solo un problema de un bot individual, sino de que hay como 9000 bots iguales rondando y consumiendo demasiados recursos del servidor. Esos bots en realidad no te traen tráfico de referencia

  • Yo también al principio tomé el enfoque de bloquear todo, pero luego entendí mejor la interconexión y complejidad de la web. Me parece importante tener control sobre tus propios recursos. Aun así, cuando decides si permitir o bloquear cierto tráfico, debes preguntarte "por qué" y entender qué hace cada bot. Ese proceso requiere tiempo y esfuerzo. Empecé a interesarme en robots.txt por la práctica de las empresas de IA de rastrear indiscriminadamente para entrenar datos. Quiero poder decidir por mí mismo qué permitir y qué bloquear. No todos los bots respetan robots.txt, pero bastantes sí. Una forma de probarlo tú mismo es pedirle a un modelo con capacidades de navegación que scrapee un enlace específico. En el fondo, lo más importante para decidir si un bot es malicioso es cómo esa empresa usa los datos y cómo me hace sentir eso a mí

  • Frente a la idea de que "no todos los bots son maliciosos, así que no hay que bloquearlos por defecto", yo creo que acercarse sin una base para confiar es una estrategia riesgosa

  • Es natural desconfiar de rastreadores desconocidos. La mayoría son maliciosos y no hay forma de saber de antemano cuáles son buenos o malos, así que tiene sentido tratar provisionalmente como maliciosos a los bots desconocidos

• Intento no ser demasiado crítico, pero me sorprende que este artículo se presente como si el autor hubiera tomado conciencia muy seriamente de las consecuencias de sus actos. Las historias de crecimiento personal tienen valor, pero esto se siente menos como una reflexión y más como una confesión de ignorancia. Al final da la impresión de que publicó el texto para llamar la atención

  • Lo que pasó es que el autor no había reconocido que el fetcher de previsualización de páginas no era un crawler, y por eso no pensó en bloquearlo con robots.txt. Aunque no sea una revelación para todos, al menos sí fue algo nuevo que aprendió desde su propia perspectiva. Creo que una entrada de blog escrita por una persona real puede elevar la calidad promedio de la web

  • Como no aparece en Google, lo publicó aquí (Hacker News)

  • Para mí también hubo partes que sí se sintieron realmente nuevas. Me sirvió para aprender un poco más sobre Open Graph Protocol y Robots Exclusion Protocol. Suelo anotar y compartir las cosas que aprendo o que me parecen interesantes. Lo compartió porque pensó que a otras personas también podía interesarles

  • Me pregunto cómo llegó esto a la portada. Parece un texto larguísimo para decir algo tan obvio como "si bloqueas el agua, los buenos se apartan y los malos lo ignoran". Al final robots.txt no deja de ser un cortés "por favor no"; no es un firewall

• El problema de robots.txt es que al final filtra no según el propósito del rastreador, sino según su "identidad". El autor también bloqueó todos los bots para frenar la recolección para IA, pero luego volvió a permitir los rastreadores de previsualización OpenGraph, como los de LinkedIn. Pero entonces, ¿qué pasa si el enlace se comparte en Twitter o Mastodon? Tendrías que permitir manualmente los UA de todas las redes sociales, y eso termina favoreciendo solo a unas pocas plataformas grandes. En esencia, hace falta algún mecanismo para decir "bloquea el entrenamiento de IA, pero permite indexación de búsqueda, previsualizaciones, archivado, etc.". Haría falta un marco legal para hacerlo cumplir de forma efectiva, pero eso tampoco es sencillo

  • Siempre ha existido discusión sobre el uso fundamental de robots.txt. Yo creo que originalmente, y todavía en gran medida, era para crawlers en el sentido estricto: sistemas que descubren contenido nuevo siguiendo enlaces. Los motores de búsqueda son el ejemplo típico. Pero si un usuario solicita directamente una URL específica, como en un navegador o una suscripción iCal, no debería ser necesario respetar robots.txt. De hecho, ha habido casos de servicios como Google Calendar que no podían suscribirse por estar bloqueados por robots.txt, y me parece un comportamiento incorrecto. En el caso de las previsualizaciones de URL, si el usuario solo pide un enlace, eso se parece más a una solicitud puntual que a un rastreo. Pero si el mensaje contiene muchos enlaces, entonces eso también empieza a parecer una forma de crawling. En resumen, todavía me parece ambiguo si las previsualizaciones de URL de redes sociales deberían seguir robots.txt

  • Datos como los de Common Crawl pueden reutilizarse tanto en motores de búsqueda como en entrenamiento de IA y otros usos. No es fácil separar los usos

  • Se podría resolver separando el intercambio de información out-of-band en vez de in-band. Si los metadatos de Open Graph se ofrecieran por una ruta o encabezado aparte, podrías permitir esa ruta —que contiene datos no sensibles— y rechazar con fuerza el contenido principal. No haría falta necesariamente un marco legal

  • Me gusta la idea de crear un estándar que permita o bloquee por función o propósito. Pero la clave sería verificar esa función y evitar el spoofing, y al final también se mezcla con cuestiones legales. En la práctica parece que habría que volver a permitir muchas plataformas distintas, como las previsualizaciones de redes sociales, y estoy aprendiendo bastante en el proceso de elegir cuidadosamente qué permitir o bloquear. Escuchar distintas opiniones como estas me está sirviendo mucho

• Para el OP: 1) pensaste en LinkedIn, pero en realidad tus enlaces también pueden compartirse en otras redes sociales como Facebook o Bluesky. En el ai.robots.txt de Facebook también puedes terminar bloqueando por accidente incluso al rastreador de previsualización de FB (ejemplo de ai.robots.txt).

2. Sobre la relación entre ranking de Google y bloqueo por robots.txt: aunque bloquear con robots.txt puede frenar la exposición en buscadores, y aunque también intervienen variables indirectas como enlaces externos, en general permitir el crawling directo es mucho más favorable para el SEO en Google/Naver. Si bloqueas, la calidad del resultado cae porque no aparecen miniaturas ni descripciones. Si el tráfico desde buscadores es importante para ti, conviene pensar bien antes de bloquear por completo con robots.txt

• ¡Gracias por el comentario! 1) Yo también solo estaba pensando en LinkedIn y HN. No se me había ocurrido que otras personas pudieran compartir enlaces de mi blog en muchas otras plataformas. Quizá tenga que reconsiderar permitir acceso a varias plataformas. 2) Viendo que la tendencia de los buscadores va hacia resúmenes con IA, creo que en adelante el tráfico orgánico hacia los sitios mismos va a disminuir. Así que no me preocupa demasiado perder tráfico desde Google. Puede que cambie de opinión después, pero por ahora siento que para mi blog el boca a boca a través de HN y de las compartidas en redes sociales puede generar tráfico más valioso. Voy a investigar más para asegurarme de que esta decisión no me termine perjudicando. Las distintas opiniones me están ayudando mucho a decidir

• Hay otro efecto secundario que surge por confundir "crawling" con "indexación" en robots.txt.
  Si quieres impedir desde el principio que una página nueva entre al índice de Google, bloquearla por robots.txt sí puede servir.
  Pero si quieres eliminar una página que ya está indexada y solo la agregas a robots.txt, eso es un error. Como Google ya no puede rastrearla, seguirá mostrándola en los resultados sin metadatos, y tampoco podrá ver la etiqueta noindex, por lo que puede permanecer mucho tiempo en búsquedas. Google acaba quitándola después, pero el proceso puede ser muy frustrante

  • Google puede enterarse de URLs bloqueadas por robots.txt a través de enlaces externos y similares, y en ese caso, aunque no pueda rastrearlas, el registro indexado puede seguir apareciendo en resultados (ver advertencia: documentación oficial de Google). Para quitarla por completo de resultados de búsqueda, debes poner necesariamente una etiqueta noindex en el código; si está bloqueada por robots.txt, Google tampoco podrá leer esa etiqueta, así que hay que tener cuidado

  • En mi caso no necesito necesariamente que Google elimine eso del índice. Me da igual la indexación; lo que me preocupa es el crawling/scraping. Reconozco que alguna vez usé mal los términos

• Este texto da la impresión de alargar demasiado una idea que se podía decir en una o dos líneas. Tiene como vibra de tarea escolar inflada para llenar espacio

  • Podría haberse explicado en un solo párrafo. El objetivo de mi texto era dejar constancia del recorrido: mi experiencia, el problema, la investigación y la solución. Lo escribí lo más detalladamente posible para que también pudiera seguirlo alguien no técnico

• La limitación fundamental de robots.txt es que el problema real no son los bots que lo obedecen, sino los que no. robots.txt no controla a la mayoría de los bots que hoy generan problemas de tráfico. Cuanto más abusivo y dañino es un bot para el servidor, menos le importa robots.txt

  • Para atrapar ese tipo de bots, un "honeypot" puede ser útil. Puedes declarar explícitamente un camino /honeypot como bloqueado en robots.txt y agregar en index.html un enlace oculto con display:none: <a href="/honeypot">ban me</a>. Cualquier IP que acceda a esa ruta se puede bloquear de inmediato

  • No entiendo por qué esto recibió votos negativos. No hay base para confiar en qué tan bien respetan robots.txt empresas importantes como OpenAI o Anthropic. Estas compañías dificultan la detección haciendo pasar tráfico por IP residenciales de ISP y distribuyen la responsabilidad evitando el rastreo directo mediante "anuncios de terceros"

• Lo que más me sorprende es que casi no existan bibliotecas de parser bien resueltas para interpretar a la vez robots.txt y la etiqueta meta robots, y decidir qué prioridad dar cuando entran en conflicto. El parser de referencia oficial de Google es un caso raro, basado en C++11, y en bibliotecas populares para Python o JS al final el desarrollador tiene que implementarlo por su cuenta. Para colmo, en el caso de meta robots la información ni siquiera está en el archivo robots.txt sino escondida dentro de index.html. El problema es que, incluso si quien escribe un bot quiere hacer las cosas correctamente desde un punto de vista ético, la dificultad de implementación se lo complica

  • En la biblioteca estándar de Python existe urllib.robotparser (documentación oficial). Por otro lado, rel=nofollow tiene un propósito completamente distinto a robots.txt. Ese atributo le dice al motor de búsqueda que no "confíe" en ese enlace ni le transfiera valor, no significa "no sigas este enlace" (más detalle). La intención original era evitar que en comunidades llenas de spam dejaran enlaces a sitios propios de forma indiscriminada

  • Un desarrollador de bots "bien intencionado" con recursos limitados no suele bombardear servidores sin control, así que en la práctica la falta de bibliotecas no le causa tantos problemas

  • Si realmente quieres crear un bot correcto y de buena fe, también es perfectamente posible portar la biblioteca parser a otro lenguaje y publicarla como open source. No tiene nada de imposible

• Curiosamente, Apple aborda este problema de otra manera. Cuando compartes un enlace en iMessage, es el cliente del lado del remitente el que obtiene la previsualización directamente. Servicios como LinkedIn tienen razones para raspar ellos mismos los datos del enlace desde el servidor —como prevenir spam o phishing—, pero sin duda es un enfoque diferente

  • Yo también pensaba que tenía sentido que, después de recibir un enlace en un mensaje, fuera el cliente quien generara la previsualización. Y también esperaba que alguien ya hubiera señalado ese punto. Aun así, entiendo por qué hay varias razones para que el servidor haga el scraping directamente. 1) Prepararse para un futuro en el que pueda rasparse y reutilizarse cualquier página; 2) aunque la página cambie, dé 404 o se pierda la base de datos del cliente, el servidor todavía puede entregar información de previsualización obtenida antes; 3) el cliente no tiene que generar la previsualización por su cuenta y puede mostrar una vista previa rápida junto al mensaje. Al final, si como en iMessage la previsualización la genera el "remitente", entonces solo quedan el punto 1 y parte del 2, y puede que para robustez sea mejor que el servidor siga reintentando por su cuenta