Попадает ли ссылка на фото в Google? Проверка noindex у 7 бесплатных хостингов

Ссылка на картинку, которую вы недавно скинули в чат Telegram или в беседу ВКонтакте, вполне может уже лежать в индексе Google — и её можно найти одним точным запросом с оператором site:.

В конце июля 2026 года разразился скандал: достаточно было ввести в Google site:claude.ai/share, чтобы выкопать огромное количество чужих переписок с ИИ — с API-ключами, приватными ключами криптокошельков, юридическими консультациями, резюме. Причина была не во взломе, а в конфликте настроек: страницы шеринга были помечены как «не сканировать» в robots.txt, и одновременно на них стоял X-Robots-Tag: none. Проблема в том, что если Googlebot вообще не пускают внутрь через robots.txt, он физически не может прочитать тег noindex, который в теории должен был сработать. В итоге страницы находили через внешние ссылки, индексировали — и ни один из механизмов защиты не срабатывал. Это уже четвёртый подобный инцидент за год, до этого были ChatGPT (по оценкам, 70–100 тысяч диалогов) и Grok (сотни тысяч).

Какое это имеет отношение к фотохостингам? Формально никакого — там речь шла о переписках с ИИ, а не о картинках. Но механизм полностью переносится: любая функция, построенная на принципе «приватно, потому что ссылку никто не знает, но без правильной блокировки краулеров», подвержена той же уязвимости. Страница просмотра на фотохостинге устроена ровно так же — знаешь URL, значит, можешь открыть. И её так же защищают три независимых слоя — robots.txt, meta robots, X-Robots-Tag. Ошибка в любом из них — и фото утекает в поисковую выдачу.

Поэтому я решил проверить это на практике.

Три слоя решают, попадёт ли фото в индекс

Прежде чем смотреть на таблицу, стоит договориться о критериях — иначе результаты будут выглядеть как случайность. Индексируется URL или нет — зависит от трёх независимых слоёв: robots.txt определяет, может ли краулер вообще зайти по этому пути; тег <meta name="robots"> в HTML страницы решает, нужно ли её индексировать после того, как краулер туда попал; HTTP-заголовок X-Robots-Tag — отдельная, независимая инструкция по индексации с тем же эффектом, что и meta-тег, только без правки HTML. Три слоя работают независимо друг от друга, но их часто путают, считая одним и тем же механизмом — именно в этом и была суть инцидента с Claude: robots.txt блокировал доступ, X-Robots-Tag был настроен правильно, но его никто не мог прочитать.

Стоит запомнить главное: чтобы noindex сработал, краулер сначала должен «попасть внутрь». Если вы закрываете путь в robots.txt и одновременно рассчитываете, что тег noindex на этом же пути будет работать, — это противоречие в архитектуре, и в итоге, скорее всего, не сработает ни то, ни другое.

Как я тестировал: что сделал, а что — нет

Честно говоря, главная опасность подобных тестов — писать «по памяти». Поэтому сначала методология. В сентябре 2026 года я запускал curl -I с браузерным User-Agent на страницу просмотра каждого сервиса, чтобы прочитать HTTP-заголовки (искал X-Robots-Tag), затем скачивал полный HTML в поисках <meta name="robots">, и отдельно читал robots.txt каждого сервиса напрямую. Для сервисов, где контент рендерится через JavaScript и curl не видит реальные ссылки (так устроен блок рекомендаций на главной Imgur), я использовал инструмент браузерной автоматизации, чтобы реально загрузить страницу перед извлечением ссылок.

Чтобы проверить, находятся ли фото реально в поиске, я дополнительно прогонял запросы в Google — но здесь нужно честно указать ограничение: инструмент поиска, которым я пользовался, сам оказался заблокирован доменом imgur.com (не Google, а именно защитой самого Imgur от ботов), поэтому для Imgur столбец «уже проиндексировано» я не смог проверить тем же методом, что и остальные — могу судить только по техническим настройкам, что оно «теоретически индексируемо», и честно помечаю это в таблице. Это не то, что я хочу скрыть, — это ограничение инструмента, и лучше сказать прямо, чем делать вид, что проверил всё одинаково.

Результаты проверки

Каждая строка этой таблицы — реально проверенный мной URL и реально полученный ответ, а не пересказ документации.

Сервис	Пример страницы	Ограничения robots.txt	meta robots / X-Robots-Tag	Статус индексации (проверка 09/2026)
Imgur	imgur.com/gallery/xxx	Путь /gallery/ не заблокирован	Ничего не задано (индексируется по умолчанию)	Технически индексируемо; напрямую не проверено, так как поисковый инструмент заблокирован доменом imgur.com
ImgBB	ibb.co/xxx	robots.txt полностью пустой	Ничего не задано	Уже в индексе — по обычным ключевым словам сразу находятся реальные страницы с фото
Postimages	postimg.cc/xxx	robots.txt полностью пустой	Ничего не задано	Уже в индексе — так же находятся страницы, включая исходные имена файлов
Flickr	flickr.com/photos/user/id	Часть именованных краулеров (включая Googlebot) допущены к /photos/	Только noarchive, noindex отсутствует	Уже в индексе — найдена страница конкретного фото конкретного пользователя
Catbox	files.catbox.moe/xxx	Часть админ-путей закрыта, ClaudeBot и GPTBot заблокированы явно	Файл — это прямая бинарная ссылка, HTML-страницы для meta-тега просто не существует	Структурно не существует «индексируемой страницы просмотра» — нет страницы, значит, нет и понятия meta robots
Ссылка шеринга Google Фото	photos.app.goo.gl/xxx	Путь /share/ явно не исключён в robots.txt	Страница рендерится через JS, curl не может прочитать содержимое	Уже в индексе — через поиск находятся чужие ссылки на шеринг, часть из них до сих пор открывается
lpic.cc	lpic.cc/короткий-код	Allow: / (открыто на уровне главной страницы)	В исходном коде страницы явно задано index: false, follow: true	Явный noindex — страница просмотра изначально спроектирована не попадать в индекс

Увидев строку про Google Фото, признаюсь честно — на секунду я даже растерялся.

Разбор по каждому сервису: где именно проблема

ImgBB и Postimages — самые однозначные примеры в этом тесте: robots.txt возвращает буквально пустое содержимое, то есть никаких ограничений по путям; на странице также нет ни одного тега meta robots. Отсутствие ограничений плюс отсутствие тегов равно «полностью открыто» — и это значение по умолчанию, а не опция, которую пользователь может отключить при загрузке. Результаты в поиске находились почти мгновенно, причём заголовками многих страниц были исходные имена файлов с камеры телефона (что-то вроде IMG_ плюс дата и время) — сразу видно, что это фото, загруженное прямо со смартфона.

Flickr — случай тоньше, и его легко неверно истолковать. В его robots.txt перечислено около сорока именованных краулеров (включая Googlebot), и этот список исключает только отдельные аккаунты и функциональные страницы; обычный путь /photos/пользователь/id-фото в список исключений не попадает; на самой странице стоит только noarchive (запрет на снимок в кэше), никакого noindex там нет. Вот реальный пример: страница фото, найденная мной через поиск, оказалась обучающим постом официального аккаунта Flickr — про то, «как делиться фотографиями Flickr». То есть в индекс попала даже страница, объясняющая, как делиться ссылками, — забавная ирония.

Ссылка шеринга Google Фото — самая тревожная строка в этом тесте. Обратите внимание: ссылка на шеринг выглядит как приватный механизм «увидит только тот, кому дали доступ», но, используя лишь обычные ключевые слова, без каких-либо специальных операторов поиска, я находил в результатах поиска чужие короткие ссылки photos.app.goo.gl (по соображениям приватности реальные ссылки здесь не привожу). Часть из них при открытии требовала логин — значит, права доступа позже изменили или срок истёк; часть по-прежнему открывалась напрямую — то есть ссылка, «приватно расшаренная конкретному человеку», когда-то была или до сих пор остаётся доступной через публичный поиск. Это тот же тип риска, что и утечка Claude: сама ссылка не задумывалась как публичная, но детали правил для краулеров решают, подберёт ли её поисковик.

Catbox — особый случай. У него нет отдельной «страницы просмотра», как у остальных сервисов: после загрузки вы сразу получаете прямую ссылку на файл, при открытии которой видна сама картинка, без какой-либо HTML-обёртки, куда можно было бы вставить meta robots. Это значит, что традиционную проверку meta robots здесь провести попросту невозможно. Но это не значит, что сервис безопаснее — риск просто смещается в другое место: поиск по картинкам Google теоретически может проиндексировать сам прямой URL файла, только критерий проверки для этого другой, не такой, как для HTML-страниц, — и в этой части я не нашёл надёжного способа проверки, честно говоря, просто не смог это подтвердить, и не буду придумывать цифру из воздуха.

lpic.cc — мой собственный продукт — я тоже протестировал, нельзя проверять только чужие сервисы. В исходном коде видно, что метаданные страницы просмотра явно задают robots: { index: false, follow: true } — то есть даже если ваш короткий код кто-то расшарит и до него доберётся краулер, сама страница активно сообщает Google: «не индексируй меня». Это поведение, заложенное на этапе проектирования, а не патч, добавленный специально для этого теста. Но честно говоря, noindex предотвращает только попадание в результаты поиска, а не возможность открыть страницу, зная URL, — именно поэтому существует функция защиты паролем, и полноценная защита достигается только при использовании обеих вместе.

Что это значит для вас на практике

Переведя техническую суть на простой язык: если вы загружаете фото с персональными данными, чеками, скриншотами переписок, документами, удостоверяющими личность, на ImgBB или Postimages — сервисы с полностью открытой индексацией по умолчанию, — теоретически найти это фото может кто угодно по ключевому слову или фрагменту текста на изображении, причём ваша ссылка для этого даже не нужна: достаточно, что поисковик уже успел его просканировать.

Есть ещё более коварный сценарий, который часто упускают из виду: когда вы публикуете ссылку на фотохостинг на форуме или в соцсети, вы редко думаете «а не попадёт ли эта картинка в индекс», но если на фото есть ваше имя, адрес, часть номера паспорта (частая ситуация со сканами документов для налоговой, возвратов, заявлений), после индексации эта информация остаётся публично доступной в сети до тех пор, пока вы сами это не заметите и не потребуете удаления, — а большинство людей вообще не знает, куда для этого обращаться. В России такие утечки персональных данных подпадают под действие 152-ФЗ «О персональных данных», но правовая защита срабатывает всегда постфактум, а не до утечки.

Как защитить свои ссылки

Не каждой фотографии нужен одинаковый уровень защиты — важно различать «мем, которым поделился на бегу» и «скриншот с персональными данными», и использовать для них разные инструменты. Три конкретных шага:

• Проверяйте сами. До и после загрузки поищите в Google по имени файла или тексту с картинки — есть ли признаки индексации.
• Для чувствительного контента избегайте сервисов с открытой по умолчанию индексацией, выбирайте те, что явно указывают noindex или поддерживают защиту паролем.
• Устанавливайте срок действия ссылки самостоятельно, не полагаясь на «всё равно никто не знает URL» — история с Claude уже доказала, что краулеру не нужно знать URL заранее, достаточно, чтобы на него указывала хотя бы одна внешняя ссылка.

Если вы ищете сервис, где «ссылка на шеринг по умолчанию не индексируется» и «защита паролем» встроены сразу, то страница просмотра lpic.cc изначально спроектирована с noindex, плюс есть функция защиты паролем — оба уровня защиты сразу. Но стоит честно обозначить и ограничения: на бесплатном тарифе медиафайлы по умолчанию истекают через 30 дней после загрузки (в форме загрузки опция «автопродление при просмотре» включена по умолчанию), после истечения срока удаляются, а сам сервис существует за счёт рекламы — эти компромиссы лучше знать заранее, а не узнавать постфактум.

Часто задаваемые вопросы

В1: Если стоит noindex, фото точно никогда не попадёт в поиск? Не абсолютная гарантия. noindex — это «просьба» к краулеру не индексировать, и в большинстве случаев Google её соблюдает, но только если краулер вообще может прочитать этот тег. Если robots.txt одновременно блокирует тот же путь, краулер вообще не заходит внутрь и не видит noindex — именно это стало причиной инцидента с Claude.

В2: На сервисе с прямыми ссылками на файлы, вроде Catbox, может ли фото попасть в индекс? Через meta robots это оценить нельзя, потому что HTML-страницы попросту нет. Теоретически поиск по картинкам Google может проиндексировать прямой URL файла, но способ проверки для этого отличается от обычной веб-страницы — в этом тесте я не нашёл надёжного метода проверки, поэтому не делаю непроверенных утверждений.

В3: Я загрузил фото на ImgBB, обнаружил его в поиске — можно удалить из индекса? Сначала удалите исходное фото, чтобы URL перестал работать, затем отправьте запрос на удаление через инструмент «Удаление URL» в Google Search Console — это заметно быстрее, чем ждать, пока краулер сам переобойдёт страницу.

В4: Этот тест сделан в сентябре 2026-го — а если платформы позже изменят настройки? robots.txt и meta-теги могут измениться в любой момент, здесь никогда нет постоянной гарантии. Правильный подход — не заучивать эту таблицу, а самостоятельно проверить через curl -I или инструменты разработчика в браузере: метод живёт дольше, чем конкретный вывод.

В5: Почему Flickr пускает Googlebot, но блокирует большинство остальных краулеров? Это сознательное решение — разрешить индексацию основным поисковым системам ради трафика и видимости, одновременно блокируя неизвестных сторонних краулеров, чтобы снизить риск кражи или неправомерного использования контента. Это два разных компромисса, а не одно и то же решение.

В6: Куда в России жаловаться, если персональные данные утекли через индексацию фото? Помимо запроса на удаление URL через Google Search Console, можно обратиться в Роскомнадзор — он рассматривает жалобы на нарушения, связанные с обработкой персональных данных в рамках 152-ФЗ.

Источники

• Публикация об инциденте с индексацией ссылок на переписки Claude (29.07.2026)
• robots.txt сервисов Imgur, ImgBB (ibb.co), Postimages (postimg.cc), Flickr, Google Фото (photos.google.com), Catbox (catbox.moe) — получены прямым доступом в сентябре 2026 года
• HTTP-заголовки и HTML-код страниц просмотра указанных сервисов — протестированы в сентябре 2026 года через curl и инструменты браузерной автоматизации
• Исходный код метаданных страницы просмотра lpic.cc (app/(public)/[locale]/[code]/page.tsx)