Изображения сайта не находятся в Google Картинках: как проверить индексацию

Фотографии товаров видны посетителям, но их не удаётся найти в Google Картинках. Причина может находиться в шаблоне страницы, адресе файла, настройках CDN или способе загрузки галереи. Иногда технических препятствий нет, а отсутствие результата по одному запросу ошибочно принимают за отсутствие индексации. Поэтому начинать нужно с конкретного изображения и проверяемых наблюдений.

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

Уточните, что именно отсутствует в поиске

Запишите, какое наблюдение вызвало вопрос: новая фотография не находится по названию товара, после переезда упали переходы из поиска картинок, пропало изображение у обычного текстового результата или поисковик показывает старую обложку. Это разные симптомы. Отдельно сохраните запрос, дату, устройство и адрес страницы, на которую должен попадать посетитель.

Не смешивайте фотографию товара с favicon и миниатюрой ссылки. Отсутствие значка рядом с названием сайта не показывает, индексируются ли изображения каталога. Выбор обложки для превью также отличается от проверки доступности всех фотографий. В актуальном руководстве Google по изображениям выбор превью описан как автоматический процесс; метаданные могут влиять на предпочтение, но не гарантируют показ выбранного файла.

Зафиксируйте исходную формулировку без преждевременного вывода: «Не найдено по проверенному запросу», «Нет показов в выбранном отчёте» или «Файл возвращает 403». Последнее уже указывает на техническое препятствие в проверенных условиях. Первые два наблюдения ещё требуют выяснить, как файл обнаруживается и какие данные доступны для оценки.

Составьте небольшую карту страниц и файлов

Не начинайте с массовой переделки медиатеки. Выберите пять–десять важных примеров из разных шаблонов: основное фото товара, дополнительный ракурс, иллюстрацию статьи, изображение категории и файл с отдельного CDN. Для каждого нужны два адреса: HTML-страница и сам медиафайл. Их удобно проверять независимо.

Пример	Ожидаемое размещение	Первый вопрос
Главное фото товара	В карточке модели	Есть ли настоящий адрес в img
Второй ракурс	В галерее этой же карточки	Появляется ли адрес без обязательного клика
Иллюстрация статьи	Рядом с соответствующим объяснением	Совпадают ли изображение и контекст
Фотография на CDN	На отдельном медиадомене	Доступен ли файл вне сессии сотрудника
Изображение после переноса	По новому постоянному адресу	Обновлены ли ссылки на него

Добавьте наблюдаемый HTTP-статус, конечный URL, тип содержимого, способ загрузки, alt и дату изменения. При нескольких размерах одной фотографии сохраните выбранный браузером вариант и резервный адрес из разметки. Это позволяет заметить ситуацию, когда большая версия работает, а маленькая отдаёт ошибку.

Реестр должен описывать проверенный файл, а не запись в административной панели. В CMS может храниться оригинал, тогда как посетитель получает преобразованную копию с другого хоста. Исправлять необходимо тот путь доставки, который используется на публичной странице.

Проверьте img, src и адаптивные варианты

Google извлекает изображения из src элемента img, в том числе внутри picture. Картинка, представленная только CSS-фоном, не получает такой способ обнаружения. Для содержательной фотографии используйте обычный элемент изображения. Декоративный фон страницы может остаться фоном: не каждый элемент оформления должен становиться поисковым материалом.

Учебный фрагмент карточки на вымышленном домене:

<img
  src="https://example.com/images/pump-a-front.webp"
  alt="Насос Pump A: вид спереди, корпус и панель управления"
  width="1200"
  height="800">

Размеры в примере относятся к условному файлу. На реальной странице проверьте их соответствие изображению. Если используются srcset и picture, оставьте рабочий резервный src согласно рекомендациям Google. Одного адреса в data-src или внутреннем объекте JavaScript недостаточно для подтверждения правильной итоговой разметки.

Посмотрите HTML ответа сервера и DOM после загрузки. Нужный адрес должен оказаться в правильном элементе, а не только в списке настроек галереи. Сам формат WebP или AVIF не означает ошибку: оба поддерживаются Google. Проверять следует реальный файл и способ его размещения, прежде чем массово конвертировать всю медиатеку.

Убедитесь, что галерея не скрывает URL до клика

Отложенная загрузка может уменьшать первоначальный объём передачи, но её реализация должна позволять получить изображения. В инструкции Google по lazy loading рекомендуется проверять отрисованный HTML и наличие адресов в src. Поисковый процесс не следует считать посетителем, который обязательно прокрутит страницу и нажмёт все миниатюры.

Разберите конкретную галерею. В одном варианте все элементы с адресами уже присутствуют, а браузер откладывает загрузку находящихся вне экрана файлов. В другом адрес второго ракурса приходит только после клика. В третьем показана заглушка, а сценарий замены сломан. Внешне эти варианты могут выглядеть одинаково до взаимодействия.

Откройте карточку в чистой сессии, дождитесь обычной загрузки и сохраните DOM до нажатий. Затем выполните действия посетителя и сравните, какие адреса добавились. Это диагностический опыт; окончательный вывод о доступности для Google делайте также по результату его рендеринга.

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

Откройте сам файл и проверьте ответ CDN

Скопируйте фактический URL изображения и откройте его отдельно без авторизации. Проверьте статус и содержимое ответа. Код 200 не помогает, если вместо фотографии возвращается HTML страницы входа, сообщение защиты или универсальная заглушка. Сравните Content-Type с полученными данными и убедитесь, что файл действительно декодируется как изображение.

Успешная загрузка у сотрудника не исключает проблемы для других клиентов. Браузер мог сохранить старый файл, нужную cookie или временное разрешение. Для CDN отдельно проверьте срок действия подписанной ссылки, ограничения доступа и журнал отказов. Изменяйте конкретное ошибочное правило; доступ к приватным материалам ради публичной фотографии открывать не требуется.

Документация Google по HTTP-ответам различает отсутствие ресурса и серверные ошибки. Поэтому сохраняйте фактический код каждого неудачного запроса. Повторяющийся 404 у миниатюры, 403 от защитного слоя и 503 при перегрузке преобразователя требуют разных исправлений.

Если в журнале запрос подписан как Googlebot, это ещё не доказательство его происхождения. При необходимости применяйте официальные способы проверки Google, включая сопоставление с опубликованными диапазонами IP или обратную и прямую DNS-проверку. Одна подмена User-Agent в ручном запросе не воспроизводит весь процесс загрузки поисковой системой.

Разделите ограничения страницы и медиафайла

У HTML-страницы и изображения могут быть разные хосты и разные правила. Проверка только основного robots.txt не объясняет поведение файла на CDN. Укажите в реестре хост каждого ресурса и проверьте относящиеся к нему запреты, а также заголовки фактического ответа.

Где проверять	Что искать	Почему это существенно
HTML-страница	Непреднамеренный noindex, закрытый доступ, noimageindex	Страница и её изображения могут быть ограничены отдельно
Ответ изображения	X-Robots-Tag: noindex	Правило относится к самому файлу
Хост изображения	Запрет нужного пути в robots.txt	Правила основного сайта не описывают автоматически другой хост
Защитный слой	Отказ или требование авторизации	Бот может не получить содержимое

Согласно руководству Google по исключению изображений, запрет через robots.txt способен убрать изображение из поиска, а X-Robots-Tag: noindex требует возможности получить заголовок файла. Правило noimageindex на одной странице не исключает обнаружение той же картинки через другую страницу.

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

Стабилизируйте адреса и проверьте мобильную версию

Повторно откройте одну карточку и сравните URL её основной фотографии. Если адрес каждый раз получает новый случайный параметр или короткий срок действия, поисковику приходится работать с меняющимися ресурсами. В рекомендациях Google для мобильной индексации отдельно указано, что постоянно меняющиеся адреса изображений мешают их обработке.

Задайте стабильные адреса публикуемых вариантов. Это не означает запрет любых параметров: фиксированное преобразование размера может иметь постоянный URL. Проблема возникает, когда одинаковое содержимое бесконечно получает новые адреса или ранее опубликованная ссылка быстро перестаёт работать. Версионирование действительно изменённого файла и случайное изменение адреса при каждом просмотре решают разные задачи.

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

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

Дайте фотографии точный контекст и осмысленный alt

Посмотрите на посадочную глазами человека, который пришёл по изображению. Совпадает ли фотография с выбранной моделью? Понятно ли, какой ракурс показан? Есть ли рядом сведения, необходимые для решения о покупке? Одинаковая картинка разных товаров без пояснения может создавать неверные ожидания, даже если технически загружается без ошибок.

Для alt полезно применять схему W3C по текстовым альтернативам. Содержательное изображение получает краткое описание своего смысла в контексте. Для чисто декоративного элемента подходит пустой alt="". Если изображение служит единственным понятным содержимым кнопки или ссылки, текстовая альтернатива должна объяснять её назначение.

Для условной карточки насоса подходят разные описания ракурсов: «Насос Pump A, вид спереди» и «Подключение патрубков насоса Pump A, вид сбоку». Перечень «насос купить цена недорого доставка» не объясняет изображение. Не добавляйте в alt характеристики, которых нельзя увидеть или подтвердить по содержимому карточки.

Полезно разделить задачи редактора и разработчика. Редактор проверяет соответствие фотографии, модели и пояснения; разработчик обеспечивает вывод утверждённого текста в нужном атрибуте. Автоматический шаблон из названия товара может быть отправной точкой, но для схемы, чертежа и отдельного ракурса потребуется уточнение.

Если иллюстрация содержит сложную инструкцию, важная информация должна быть доступна и в тексте страницы. Покупателю не следует извлекать условия эксплуатации только из мелкой надписи на изображении. Такая правка одновременно делает страницу понятнее и снижает зависимость от качества просмотра файла.

Добавьте изображения в Sitemap корректно

Sitemap изображений помогает сообщить Google об адресах, которые иначе могли остаться необнаруженными. Можно сделать отдельный файл или добавить расширение в существующую карту. Это способ передачи сведений, а не гарантия индексирования каждого перечисленного изображения.

В учебном фрагменте loc указывает на карточку, а image:loc — на фотографию:

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
        xmlns:image="http://www.google.com/schemas/sitemap-image/1.1">
  <url>
    <loc>https://example.com/catalog/pump-a/</loc>
    <image:image>
      <image:loc>https://example.com/images/pump-a-front.webp</image:loc>
    </image:image>
  </url>
</urlset>

Проверьте, что генератор связывает фотографию с правильной страницей. Файл с кодом 404 или URL административного оригинала не становится публичным благодаря записи в XML. Используйте абсолютные адреса и корректное XML-экранирование, особенно если преобразователь изображений добавляет параметры.

В image:loc допустим другой домен, например CDN. Следуйте требованиям документации о подтверждении соответствующих доменов в Search Console и доступности ресурсов. В действующем формате не стоит рассчитывать на устаревшие поля image:caption, image:title, image:geo_location и image:license: они удалены из актуальной спецификации Google.

После выпуска откройте опубликованную карту и проверьте несколько записей вручную. Затем убедитесь, что обновление фотографии и удаление карточки корректно отражаются в следующей версии файла. Разовая правильная выгрузка не подтверждает работу ежедневной генерации.

Что можно подтвердить в Search Console

Начните с HTML-страницы, содержащей фотографию. В инструменте проверки URL сравните сведения об индексированной версии с проверкой текущей страницы. Изучите отрисованный HTML, наличие нужного img и проблемы загрузки ресурсов. Успешный live-тест страницы не является подтверждением индексации всех её изображений.

Далее откройте отчёт об эффективности и выберите тип поиска «Изображения». Сравнивайте одинаковые периоды и группы посадочных. В справке Google о поисковых метриках объясняется: изображения учитываются как ссылки на содержащую их страницу, а отдельные файлы одной страницы не разделяются в этих показателях. Поэтому рост показов карточки не доказывает, что проиндексирован каждый ракурс.

Нулевые значения также нельзя автоматически переводить в список неиндексируемых файлов. Отчёт описывает показы и взаимодействия в выбранных условиях. Для технического вывода нужны дополнительные свидетельства: фактический ответ файла, разметка, ограничения доступа и результат рендеринга.

Если раньше переходы были, сопоставьте дату падения с переносом CDN, сменой шаблона, заменой адресов и изменениями публичного ассортимента. Совпадение по времени задаёт направление проверки, но само не доказывает причину. Например, одновременно могли измениться спрос и состав товаров. Отдельно проверяйте техническую доставку и поисковые показатели.

Пример: главная фотография работает, второй ракурс пропадает

Рассмотрим вымышленную карточку с тремя фотографиями. Основное изображение присутствует в src и открывается отдельно. Адрес второго ракурса добавляется только после клика по миниатюре. Третий файл указан правильно, но его CDN-ссылка перестаёт работать после истечения короткого срока. Жалоба «изображения сайта не индексируются» здесь объединяет две разные технические причины.

Задачу делят на проверяемые изменения. Для второго ракурса исправляют способ публикации адреса и проверяют итоговый HTML без обязательного взаимодействия. Для третьего организуют стабильную публичную ссылку на разрешённый файл. Основное изображение используют как контрольный пример, чтобы изменение галереи не сломало уже работающий путь.

После выпуска проверяющий повторно открывает все три URL файлов, карточку в чистой сессии и результат рендеринга. В протоколе отмечает каждый ракурс отдельно. Формулировка «три адреса получены и доступны» подтверждает устранение обнаруженных препятствий, но не означает «три изображения появились в индексе».

Для масштабирования выберите ещё несколько карточек того же шаблона и один другой шаблон. Если исправление касается общего генератора ссылок, проверьте новый товар, давно опубликованную карточку и фотографию после замены. Так команда проверяет правило, а не только вручную исправленную запись.

В отчёте исполнителю достаточно указать URL страницы, URL файла, условия воспроизведения, ожидаемый результат и фактическое расхождение. Отдельные задачи для галереи и CDN проще принять, чем общее поручение «сделать SEO изображений», у которого нет ясного признака завершения.

Закрепите проверку в публикации материалов

Для новых карточек и статей подготовьте короткий список приёмки. Его задача — подтвердить готовность изображения к обнаружению и обработке, а последующие показы в поиске оценивать отдельно. Сохраняйте несколько контрольных примеров после каждого изменения шаблона или медиахранилища.

• У содержательного изображения есть рабочий адрес в правильной HTML-разметке.
• Публичный файл открывается без авторизации и не заменяется страницей ошибки.
• URL стабилен, а используемые адаптивные версии доступны.
• Правила страницы, файла и медиахоста соответствуют назначению материала.
• Галерея не требует обязательного действия для обнаружения нужных адресов.
• Фотография, alt и соседний текст правильно описывают товар или материал.
• Карта изображений содержит действующие связи страниц и файлов.
• Результат проверки HTML отделён от наблюдений о поисковых показах.

Назначьте владельца каждого слоя: редактор отвечает за содержание, разработчик — за разметку, администратор доставки — за доступность файлов, SEO-специалист — за поисковые наблюдения. В небольшой команде роли может совмещать один человек, но сами вопросы стоит проверять раздельно.

Для внешнего контроля HTTP-доступности важных страниц подключите SiteGuard. Доступность каждого изображения и его появление в поиске проверяйте отдельно: успешный ответ страницы не подтверждает загрузку всей галереи.