¿Tu enlace de imagen acaba en Google? Prueba de noindex en 7 servicios (2026)

El derecho al olvido frente a los buscadores no nació de una teoría abstracta, sino de un caso muy concreto: un ciudadano español pidió que Google dejara de mostrar una noticia antigua sobre él, y el Tribunal de Justicia de la Unión Europea le dio la razón en 2014. Ese precedente sigue siendo la base legal que hoy protege, en toda la UE, a cualquiera cuya imagen personal termine indexada sin que lo sepa. Y ese riesgo es más cotidiano de lo que parece: el enlace de imagen que acabas de pegar en un grupo de WhatsApp puede estar, ahora mismo, sentado tranquilamente en el índice de Google, esperando a que alguien lo encuentre con una búsqueda cualquiera.

A finales de julio de 2026 estalló un caso que ilustra exactamente ese mecanismo, sin que nadie cometiera ningún error deliberado: bastaba con buscar site:claude.ai/share en Google para desenterrar una cantidad enorme de conversaciones ajenas con IA —claves de API, frases semilla de carteras de criptomonedas, consultas legales, currículums—. La causa no fue un ataque, sino un conflicto de configuración: esas páginas de compartición estaban marcadas como "no rastreables" en robots.txt, pero además llevaban un X-Robots-Tag: none. El problema es que, en cuanto Googlebot queda bloqueado por robots.txt, ni siquiera puede entrar a la página, así que tampoco puede leer esa etiqueta noindex que en teoría debía funcionar. El resultado: la página se descubrió a través de enlaces externos y se indexó, sin que ningún mecanismo pudiera evitarlo. Era el cuarto incidente de este tipo en un año, después de ChatGPT (se estima entre 70.000 y 100.000 conversaciones) y Grok (varios cientos de miles).

¿Qué tiene que ver esto con el alojamiento de imágenes? Nada directamente —aquello eran enlaces de conversaciones de IA, no fotos—, pero el mecanismo se traslada exactamente igual: cualquier función de compartir que confíe en "nadie adivinará la URL" sin bloquear correctamente a los rastreadores cae en la misma trampa. La página de visualización de un servicio de alojamiento de imágenes funciona con la misma lógica de "quien conoce la URL puede verla", y depende de las mismas tres capas: robots.txt, meta robots, X-Robots-Tag. Si una sola falla, la imagen puede terminar en los resultados de búsqueda. En las auditorías de seguridad que he hecho para empresas, una fuga de imágenes suele pasar más desapercibida que una de texto, sencillamente porque a nadie se le ocurre que una captura de pantalla enviada sin pensar pueda ser rastreable.

Así que decidí probarlo.

Tres capas deciden si una imagen aparece en Google

Antes de la tabla, aclaremos los criterios para que no parezca que hablamos de adivinación. Que una URL termine indexada por Google depende de tres mecanismos independientes.

robots.txt decide si un rastreador puede siquiera entrar en una ruta; la etiqueta <meta name="robots"> en el HTML decide si una página ya rastreada debe indexarse; y la cabecera HTTP X-Robots-Tag es una tercera instrucción, independiente, con el mismo efecto que la etiqueta meta pero sin necesidad de tocar el HTML. Las tres capas son técnicamente independientes, pero en la práctica suelen tratarse como si fueran una sola cosa —y ese fue exactamente el fallo detrás del incidente de Claude: robots.txt bloqueaba el acceso, X-Robots-Tag estaba bien configurado, pero nadie podía llegar a leerlo.

Regla para recordar: para que un noindex funcione, el rastreador tiene que poder entrar primero. Si bloqueas una ruta con robots.txt y al mismo tiempo esperas que una etiqueta noindex en esa misma ruta surta efecto, estás construyendo una contradicción; casi siempre acaban fallando las dos cosas a la vez.

Metodología: qué hice y qué no hice

Sinceramente, el mayor riesgo de este tipo de pruebas es fiarse de la impresión. Así que primero la metodología: en septiembre de 2026 usé curl -I contra la página de visualización de cada servicio para capturar las cabeceras HTTP (buscando X-Robots-Tag), después descargué el HTML completo para buscar <meta name="robots">, y por último leí directamente el robots.txt de cada servicio con curl. Para los servicios cuyo contenido se renderiza con JavaScript y donde curl no consigue enlaces reales —el bloque de recomendaciones de la portada de Imgur es un ejemplo—, usé automatización de navegador para cargar la página de verdad y extraer los enlaces después.

Para comprobar si una imagen realmente aparece en las búsquedas, hice además pruebas reales en Google, con una limitación que prefiero dejar clara: la herramienta de búsqueda que utilicé está bloqueada por el propio dominio imgur.com (no por Google, sino por la protección antibots de Imgur). Por eso, en la columna "ya está indexada" no pude verificar Imgur con el mismo método; solo pude juzgar, a partir de su configuración técnica, que "en teoría es indexable", y así lo indico en la tabla. No es que quiera ocultarlo, es una limitación de la herramienta, y prefiero decirlo con claridad antes que fingir que lo comprobé.

Resultados de la prueba

Cada fila de esta tabla corresponde a una URL que realmente comprobé esta vez, no a algo copiado de documentación.

Servicio	Estado de indexación (prueba 2026-09)	Restricción en robots.txt	meta robots / X-Robots-Tag	URL de ejemplo
ImgBB	Ya indexado — encontré varias páginas de imágenes reales con búsquedas genéricas	robots.txt completamente vacío	ninguna de las dos etiquetas configurada	ibb.co/xxx
Postimages	Ya indexado — igualmente encontré varias páginas con el nombre del archivo en el título	robots.txt completamente vacío	ninguna de las dos etiquetas configurada	postimg.cc/xxx
Flickr	Ya indexado — encontré la página concreta de una fotografía de un usuario específico	rastreadores concretos (incluido Googlebot) autorizados por nombre en /photos/	solo noarchive, sin noindex	flickr.com/photos/user/id
Google Fotos	Ya indexado — encontré enlaces de compartición de otros usuarios, algunos todavía accesibles	ruta /share/ no excluida explícitamente	página renderizada con JS, imposible de juzgar con curl	photos.app.goo.gl/xxx
Imgur	teóricamente indexable; no pude verificarlo directamente por el bloqueo de imgur.com a la herramienta de búsqueda	ruta /gallery/ no bloqueada	ninguna de las dos etiquetas configurada (indexable por defecto)	imgur.com/gallery/xxx
Catbox	estructuralmente no existe una página de visualización indexable	algunas rutas de administración bloqueadas, ClaudeBot/GPTBot bloqueados explícitamente	el archivo es un enlace directo binario, sin HTML donde poner una etiqueta meta	files.catbox.moe/xxx
lpic.cc	noindex explícito — diseñado para que la página de visualización nunca se indexe	Allow: / a nivel de raíz del sitio	el código fuente fija explícitamente index: false, follow: true	lpic.cc/código-corto

Cuando llegué a la fila de Google Fotos, la verdad es que me quedé un momento parado.

Análisis servicio por servicio: dónde está el problema exactamente

ImgBB y Postimages son los dos contraejemplos más claros de esta prueba: robots.txt devuelve una respuesta vacía, así que no hay ninguna restricción de ruta, y en las páginas tampoco aparece ninguna etiqueta meta robots. Sin bloqueo y sin etiqueta es igual a "completamente abierto" —y esto es el valor por defecto, no una opción que puedas desactivar al subir la imagen—. Encontré resultados casi al instante, muchos con el título de página igual al nombre de archivo original de la cámara del móvil (IMG_ seguido de fecha y hora), señal inequívoca de subida directa desde el teléfono.

Flickr es un caso más matizado y más fácil de malinterpretar. Su robots.txt enumera casi cuarenta rastreadores con nombre propio (Googlebot incluido); esa lista de permitidos solo excluye unas pocas cuentas y páginas funcionales concretas, y la ruta habitual /photos/usuario/id-foto no está en la lista de exclusión. La página en sí solo lleva noarchive (sin instantánea en caché), ningún noindex. Dato curioso: la página que encontré indexada era precisamente una publicación oficial que explicaba "cómo compartir fotos de Flickr" —el propio tutorial de cómo compartir acabó siendo un resultado de búsqueda—. Tiene su ironía.

Google Fotos fue, para mí, el resultado más inquietante de toda la prueba. Un enlace de compartición parece, a primera vista, un mecanismo privado —"solo lo ve quien yo se lo mande"—, pero con una búsqueda de Google totalmente normal, sin ningún comando especial, pude encontrar enlaces cortos photos.app.goo.gl de otras personas (por privacidad, no incluyo aquí los enlaces reales). Algunos ya pedían iniciar sesión al abrirlos —lo que indica que el permiso de compartición se cambió o caducó—, y otros seguían abriéndose sin más. Un enlace pensado para "compartir en privado con alguien concreto" puede, durante un tiempo o incluso todavía, encontrarse mediante una búsqueda pública. Es exactamente el mismo tipo de riesgo que la filtración de Claude: el enlace no nació con intención pública, pero los detalles de las reglas para rastreadores deciden si termina siéndolo.

Catbox es un caso aparte. A diferencia de los demás servicios, no tiene una "página de visualización" separada: al subir el archivo obtienes un enlace directo al propio archivo, sin ninguna envoltura HTML donde colocar una etiqueta meta robots. La comprobación clásica de meta robots aquí, literalmente, no tiene sobre qué aplicarse. Eso no significa que sea más seguro, solo que el riesgo se traslada a otro sitio: la búsqueda de imágenes de Google puede indexar potencialmente un enlace directo a un archivo de imagen, con criterios distintos a los de una página HTML normal. No encontré un método fiable para verificar esto concretamente, y prefiero decirlo así de claro antes que inventarme una cifra.

lpic.cc, mi propio producto, también fue sometido a la prueba —no sería justo evaluar solo a la competencia—. El código fuente de su página de visualización fija explícitamente robots: { index: false, follow: true } —aunque tu código corto se comparta y un rastreador llegue a él, la propia página le dice activamente a Google "no me indexes"—. Es una decisión de diseño desde el origen, no un parche añadido para esta prueba. Aun así, con la misma honestidad: noindex solo evita aparecer en los resultados de búsqueda, no resuelve el problema de fondo de que "quien conoce la URL puede abrirla" —para eso existe la función de protección con contraseña, y ambos mecanismos se complementan, no se sustituyen.

RGPD, derecho al olvido y lo que significa para un enlace de imagen

Hay un ángulo que las comparativas puramente técnicas suelen dejar fuera: dentro de la Unión Europea, una imagen indexada que muestre a una persona identificable también entra en el ámbito del RGPD. El derecho de supresión (artículo 17 del RGPD) se aplica cuando se tratan datos personales —y una foto en la que alguien es reconocible cuenta como tal— sin base legal suficiente. Como se mencionaba al principio, el propio principio del "derecho al olvido" frente a los buscadores nació de un caso español que llegó al Tribunal de Justicia de la UE en 2014, y hoy la Agencia Española de Protección de Datos (AEPD) sigue tramitando reclamaciones basadas en ese mismo derecho cuando aparecen contenidos personales indexados sin consentimiento.

Es importante distinguir dos cosas: un derecho de supresión bajo el RGPD y un noindex técnico no son lo mismo. El noindex previene la indexación de antemano y depende de una decisión del proveedor del servicio; el derecho al olvido se ejerce después y hay que reclamarlo activamente —en Google, mediante el formulario propio de eliminación de resultados de búsqueda, independientemente de si el servicio de alojamiento llegó a configurar un noindex—. Para cualquier persona en España o en la UE que quiera retirar una imagen personal ya indexada, existen así dos vías paralelas, no solo una.

Qué riesgo real supone esto para ti

Traducido a lenguaje sencillo: si subes a ImgBB o Postimages —dos servicios completamente abiertos a la indexación por defecto— una imagen con datos personales, una factura, una captura de una conversación o un documento de identidad, en teoría cualquiera podría encontrarla por palabras clave o por un fragmento de texto visible en la propia imagen. Ni siquiera hace falta tener el enlace compartido: basta con que el buscador ya la haya rastreado. La diferencia con publicar ese archivo directamente en abierto en tu propia web es, técnicamente, casi nula.

Un escenario que mucha gente pasa por alto: cuando publicas un enlace de imagen en un foro o en Discord, normalmente no te planteas si esa imagen será rastreable. Pero si contiene tu nombre, tu dirección o parte de un número de documento (algo habitual en capturas de declaraciones de renta, devoluciones o trámites), esa información queda permanentemente accesible una vez indexada, hasta que tú mismo lo descubras y pidas su retirada —y la mayoría ni siquiera sabe dónde buscarlo.

Cómo proteger tu propio enlace compartido

No todas las imágenes necesitan el mismo nivel de protección; lo importante es distinguir entre "un meme compartido sin pensar" y "una captura con datos personales" y usar herramientas distintas para cada caso. Tres pasos concretos:

• Búscate a ti mismo primero. Antes y después de subir la imagen, busca en Google el nombre del archivo o un fragmento de texto visible en ella para comprobar si ya hay señales de que está indexada.
• Para contenido sensible, evita los servicios abiertos a la indexación por defecto y usa uno que indique claramente noindex o que ofrezca protección con contraseña.
• Configura activamente una fecha de caducidad para tus enlaces compartidos en lugar de confiar en que "nadie conoce la URL" —el caso Claude ya demostró que un rastreador ni siquiera necesita conocer la URL directamente, basta con que un solo enlace externo apunte a ella.

Si buscas un servicio de alojamiento que integre de serie "enlace compartido sin indexar por defecto" y protección con contraseña, lpic.cc reúne ambas cosas: la página de visualización está diseñada como noindex desde el principio, sumada a la protección con contraseña. Pero hay que ser claros con sus límites: en el plan gratuito, los archivos caducan por defecto a los 30 días de subirse (el formulario de subida activa por defecto la "prórroga automática al visualizarse") y se eliminan al llegar la fecha, y el servicio se sostiene con publicidad —conviene saberlo antes de subir el archivo, no después.

Preguntas frecuentes

P1: Si configuro noindex, ¿la imagen tiene garantizado que nunca se encontrará? No, no es una garantía absoluta. noindex es una "petición" al rastreador para que no indexe, que Google respeta en la mayoría de los casos, pero solo si el rastreador realmente puede leer esa etiqueta. Si robots.txt bloquea la ruta al mismo tiempo, el rastreador nunca llega a la página y por tanto nunca ve el noindex —esa fue exactamente la causa del incidente de Claude.

P2: Con un alojamiento de enlace directo como Catbox, ¿la imagen se puede encontrar igualmente? No se puede juzgar mediante meta robots porque no hay página HTML. En teoría, la búsqueda de imágenes de Google podría indexar el enlace directo a un archivo, pero el método de verificación es distinto al de una página web normal. Para esta prueba no encontré un método de verificación fiable en este punto y prefiero no hacer una afirmación sin comprobar.

P3: Ya subí una imagen a ImgBB y descubrí que está indexada, ¿puedo eliminarla de la búsqueda? Primero elimina la imagen original para invalidar la URL, y después envía una solicitud de eliminación con la herramienta "Eliminar URLs" de Google Search Console, mucho más rápido que esperar a que el rastreador vuelva a pasar de forma natural.

P4: ¿Puedo invocar el RGPD si mi imagen ya está indexada? Sí, además de cualquier noindex que el servicio pudiera tener configurado. El artículo 17 del RGPD reconoce un derecho de supresión de datos personales, y en Google se puede solicitar la eliminación de un resultado de búsqueda de forma independiente. Es una vía posterior que hay que activar uno mismo, no un sustituto de un noindex definido desde el principio.

P5: Esta prueba es de septiembre de 2026, ¿qué pasa si las plataformas cambian su configuración después? robots.txt y las etiquetas meta pueden cambiar en cualquier momento, este tipo de configuración nunca ofrece una garantía permanente. En lugar de memorizar esta tabla, es más útil comprobarlo tú mismo con curl -I o las herramientas de desarrollador del navegador: el método sigue siendo válido más tiempo que el resultado concreto.

Fuentes

• Reportaje sobre el incidente de conversaciones de Claude indexadas por Google (2026-07-29)
• Archivos robots.txt de Imgur, ImgBB (ibb.co), Postimages (postimg.cc), Flickr, Google Fotos (photos.google.com) y Catbox (catbox.moe), consultados directamente en septiembre de 2026
• Cabeceras HTTP y código fuente HTML de las páginas de visualización de cada servicio, comprobados en septiembre de 2026 con curl y automatización de navegador
• Código fuente de los metadatos de la página de visualización de lpic.cc (app/(public)/[locale]/[code]/page.tsx)