Как правильно менять пути изображений: редиректы и SEO

Короткий ответ: сначала составьте точное соответствие «старый URL изображения → новый URL того же изображения», скопируйте и проверьте файлы, затем поставьте прямой постоянный редирект 301 или 308 с каждого старого адреса на конечный новый. Одновременно замените URL в img src, всех кандидатах srcset, <picture>, Open Graph, ImageObject.contentUrl и Image Sitemap. Новый адрес должен анонимно возвращать 200 OK и корректный тип изображения. Старые редиректы стоит сохранять минимум год, а для востребованных файлов — бессрочно.

Главное правило: у HTML-страницы и файла изображения разные идентичности. Страница описывает изображение и имеет свой canonical. URL картинки указывает на графический файл. Нельзя перенаправлять старый JPG на статью и нельзя объявлять HTML-страницу canonical-адресом бинарного ответа.

Что именно переезжает

В одной миграции часто смешиваются два разных объекта:

Объект	Что находится по URL	Как закрепить новый адрес
HTML landing page	статья, карточка товара, галерея, подпись и контекст	page-to-page 301/308, self-referencing canonical на новой странице, новые внутренние ссылки и Sitemap
Image asset	байты JPEG, PNG, WebP, AVIF, SVG или другого поддерживаемого формата	image-to-image 301/308, единый URL во всех ссылках и разметке, корректный бинарный ответ
Responsive derivative	уменьшенная, увеличенная или перекодированная версия того же изображения	отдельный URL-кандидат в srcset; при миграции — отдельная строка соответствия
Social crop	версия для Open Graph с другим кадрированием	отдельный asset и отдельное соответствие, если его URL тоже меняется

Если переехала только картинка, canonical HTML-страницы не меняется. Если изменилась только страница, URL картинки можно оставить прежним. Если переехали обе сущности, для них нужны две независимые цепочки: страница ведёт на страницу, файл — на файл.

Почему нельзя перенаправлять картинку на HTML

Браузер ожидает получить по img src изображение. После редиректа на статью он получает text/html, поэтому картинка ломается. Поисковому роботу тоже не передаётся эквивалентная графическая сущность: конечный URL описывает документ другого типа.

По той же причине не нужно отдавать от JPG заголовок Link: <...article...>; rel="canonical". Canonical применяют для дубликатов документов и страниц. При смене адреса asset понятный сигнал — постоянный HTTP-редирект на новый URL фактического изображения. Связь изображения со страницей задают в HTML, ImageObject и Image Sitemap.

Какой код редиректа выбрать

Для окончательной смены пути подходят 301 и 308. Google и Яндекс классифицируют оба кода как постоянные. Для обычной загрузки изображения запросами GET и HEAD практическая разница мала: 308 строго сохраняет HTTP-метод, а исторические реализации 301 могли менять метод при перенаправлении небезопасных запросов. К <img> это почти не относится.

Код	Значение	Когда использовать	SEO-сигнал
301	адрес изменён навсегда	основной совместимый вариант для постоянной миграции	цель — новый постоянный адрес
308	адрес изменён навсегда, метод сохраняется	когда инфраструктура полностью поддерживает 308 и нужна строгая HTTP-семантика	цель — новый постоянный адрес
302	временно найдено в другом месте	короткий обратимый routing-test или временная аварийная выдача	старый URL остаётся основной отправной точкой
307	временно, метод сохраняется	временный маршрут с обязательным сохранением метода	не объявляет окончательный переезд

301 — разумный default для большой разнородной инфраструктуры. 308 также корректен, но перед массовым запуском проверьте CDN, origin, middleware, мониторинг и старые клиенты. Не выбирайте 302 только потому, что его проще откатить: временный код не сообщает о постоянной смене идентичности.

Сколько переходов допустимо

Цель — один hop:

https://www.example.ru/old/photo.jpg
  → 301
https://img.example.ru/photos/photo.webp
  → 200 image/webp

Нежелательный вариант:

old.jpg → legacy.jpg → cdn.jpg → cdn.webp → signed-url → 200

Googlebot технически может пройти до десяти переходов, но сам Google советует вести сразу на конечную цель, в сложных случаях держаться не более трёх и в любом случае меньше пяти. Яндекс умеет обрабатывать цепочки и индексирует конечную цель, однако числовой лимит в его актуальной справке не указан. Для Bing отдельный публичный лимит тоже не стоит угадывать. Один переход быстрее для браузера, экономнее для робота и проще для диагностики.

При второй миграции перепишите старые правила. Адрес 2019 года должен вести сразу на текущий URL, а не через адреса 2022 и 2025 годов.

Как долго хранить редиректы

Google рекомендует сохранять permanent redirects максимально долго и обычно не менее года. За это время робот повторно обходит старые и новые URL, а системы обрабатывают перенос сигналов. Пользовательские закладки, старые письма, RSS, кеши и внешние вставки могут жить дольше, поэтому востребованные image redirects лучше оставлять бессрочно.

У Яндекса и Bing в проверенной документации нет универсального числового срока для image redirect. Это не повод удалять его раньше. Решение принимают по логам: старые URL больше не получают значимого трафика людей и роботов, а важные внешние источники обновлены.

Как выбрать стратегию для разных изменений

Новый каталог на том же хосте

Это самый простой случай. Скопируйте файл, убедитесь, что новый URL отвечает 200, добавьте точное правило и обновите ссылки в коде и контенте. Не оставляйте внутренние страницы на старом URL в надежде, что редирект всё исправит: каждый лишний переход увеличивает задержку и расходует ресурсы.

Если структура полностью изоморфна, допустимо правило по префиксу: /uploads/2024/* переезжает в /media/2024/* с сохранением хвоста. Если имена изменились неодинаково, нужен явный mapping. Wildcard, который отправляет все JPG на одну обложку или главную страницу, уничтожает соответствие.

Переезд на CDN или поддомен

Поддомен img.example.ru — другой host. До переключения проверьте:

• DNS и TLS работают из внешней сети;
• новый host отдаёт /robots.txt с 200 OK и не запрещает нужные каталоги;
• анонимный запрос получает файл без cookie, токена и входа;
• WAF и hotlink protection не блокируют Googlebot-Image, YandexImages и bingbot;
• оба host подтверждены в Google Search Console и Яндекс Вебмастере;
• CDN не меняет MIME на application/octet-stream и не заставляет скачивать файл;
• cache key учитывает только действительно значимые параметры и заголовки.

Google разрешает указывать изображения другого домена в Image Sitemap, если права на оба домена подтверждены. Яндекс требует такое же подтверждение для cross-domain image:loc. Сами рекомендации Google по изображениям также требуют доступного стандартного img и fallback src.

Не разрешайте crawler по одному только User-Agent: эту строку легко подделать. Для расследования или allowlist сверяйте reverse DNS и затем forward DNS; Google также публикует IP ranges. Для обычного публичного изображения надёжнее открыть анонимный GET, а злоупотребления ограничивать rate limit и WAF без запрета легитимного обхода.

Смена имени или формата файла

Если визуальная сущность та же, cat-on-sofa.jpg → kot-na-divane.webp может быть прямым постоянным переносом. Новый URL должен возвращать настоящий WebP с Content-Type: image/webp, а не JPEG под расширением .webp.

Google поддерживает JPEG, PNG, WebP и AVIF. Для совместимости и управления форматами удобен <picture>:

<picture>
  <source
    type="image/avif"
    srcset="/media/kot-640.avif 640w, /media/kot-1280.avif 1280w">
  <source
    type="image/webp"
    srcset="/media/kot-640.webp 640w, /media/kot-1280.webp 1280w">
  <img
    src="/media/kot-1280.jpg"
    srcset="/media/kot-640.jpg 640w, /media/kot-1280.jpg 1280w"
    sizes="(max-width: 720px) 100vw, 720px"
    width="1280"
    height="853"
    alt="Рыжий кот лежит на сером диване">
</picture>

<img src> остаётся crawlable fallback. Каждый URL в трёх srcset — отдельный адрес. При миграции недостаточно заменить только src: браузер часто выберет другой candidate, и часть посетителей продолжит обращаться к старому CDN.

Не удаляйте исходники до проверки качества. AVIF или WebP могут потерять прозрачность, цветовой профиль, анимацию либо важные IPTC/XMP-поля при неудачной обработке. Сравните размеры, визуальный результат и права metadata.

Изменение размеров и responsive variants

Разные размеры одной фотографии — производные, но не взаимозаменяемые по трафику и производительности. Старый thumbnail 320 px должен вести на новый thumbnail сопоставимого размера, а не на оригинал 8000 px. Иначе изображение формально откроется, но мобильная страница станет тяжелее.

Выберите один preferred asset для ImageObject.contentUrl, image:loc, основного og:image и fallback img src. Ограниченный набор производных перечислите в srcset. Если Open Graph использует отдельное кадрирование, оформите его как отдельный asset: не называйте wide crop тем же изображением в mapping без проверки смысла.

CDN-трансформации и query parameters

URL вида /image.jpg?width=640&format=webp содержит часть идентичности representation в query string. Автоматическое удаление всех параметров может заменить thumbnail оригиналом или WebP на JPEG. Сначала классифицируйте параметры:

Параметр	Пример	Действие
размер/кадрирование	width=640, fit=crop	сохранить смысл и направить на эквивалентный derivative
формат/качество	format=webp, quality=75	сопоставить с реальным новым representation
версия	v=20260906	если bytes те же — можно нормализовать; если версия указывает новое содержимое — считать отдельным asset
подпись/expiry	Signature=..., Expires=...	не использовать как публичный preferred URL
аналитический мусор	случайный неиспользуемый параметр	удалить или перенаправить на чистый URL после проверки cache key

Нормализуйте порядок и допустимый набор параметров. Иначе /img?w=640&q=80, /img?q=80&w=640 и тысячи произвольных комбинаций раздуют кеш и URL-инвентарь. Не пытайтесь решить этот взрыв заголовком canonical от бинарника: ограничьте генератор URL, ссылки и CDN rules.

Signed URLs

Signed URL предназначен для ограниченного доступа. Он содержит подпись и срок действия, после которого CDN может вернуть 403. Такой адрес непригоден для стабильной индексации: crawler придёт позже, подпись истечёт, а новый токен создаст новый URL.

Для публичного SEO-изображения создайте стабильный HTTPS URL без истекающей подписи. Приватный оригинал можно держать в закрытом bucket, а публичную производную выдавать через CDN. Если изображение обязано оставаться приватным, его нужно исключить из image SEO, а не маскировать краткоживущим contentUrl.

Переезд HTML landing page

Если статья переезжает с /blog/old/ на /stati/new/, настройте отдельный 301/308 page-to-page. На новой странице поставьте self-referencing canonical, замените внутренние ссылки и URL в обычной Sitemap. Изображение может остаться на прежнем стабильном адресе.

Если одновременно меняется image host, настройте второй mapping. Получаются две независимые пары:

/blog/old/          → /stati/new/                 (HTML → HTML)
/uploads/chart.png  → https://img.example.ru/chart.png  (image → image)

Сначала создайте инвентарь и таблицу соответствий

Не начинайте с регулярного выражения в конфигурации. Начните с выгрузки URL из базы, HTML, CSS, XML Sitemap, JSON-LD, Open Graph, CDN logs и хранилища. Добавьте адреса, по которым были запросы хотя бы один раз за разумный период с учётом сезонности.

Минимальная рабочая таблица:

old_url	new_final_url	связь	статус	MIME	где используется	решение
/uploads/a.jpg	/media/a.webp	same-visual	301	image/webp	src, JSON-LD, sitemap	migrate
/uploads/a-320.jpg	/media/a-320.webp	derivative 320w	301	image/webp	srcset	migrate
/uploads/social-a.jpg	/media/social-a.jpg	social crop	301	image/jpeg	og:image	migrate separately
/uploads/obsolete.jpg	—	removed, no equivalent	410	—	old external requests	remove

Для каждой строки зафиксируйте ожидаемые width/height, владельца прав, лицензию, источники ссылок, последние обращения и rollback location. Автоматические проверки должны отвергать:

• два разных old URL, случайно сведённые к нерелевантной общей картинке;
• target с HTML или application/octet-stream вместо image MIME;
• target, который сам отвечает 3xx;
• target с 403/404/5xx для анонимного клиента;
• потерю значимых query parameters;
• несовпадение responsive size или crop;
• перенос чужой подписи, copyright либо license на другой asset.

Каким должен быть новый бинарный ответ

Первичная проверка нового URL должна дать примерно такой результат:

HTTP/2 200
Content-Type: image/webp
Content-Disposition: inline
Cache-Control: public, max-age=31536000, immutable
ETag: "sha256-example"
Last-Modified: Sun, 06 Sep 2026 08:00:00 GMT

Здесь важны детали:

• 200 OK подтверждает, что по URL действительно доступно представление; последующий conditional request может законно получить 304 Not Modified;
• Content-Type должен соответствовать фактическому формату;
• Content-Disposition: inline не заставляет браузер скачивать файл как attachment;
• стабильный ETag или Last-Modified позволяет условные запросы и 304;
• max-age=31536000, immutable подходит только для versioned или content-addressed URL, байты по которому никогда не заменяют на месте;
• для изменяемого /logo.png задайте более короткий TTL и validators, либо версионируйте имя;
• не должно быть X-Robots-Tag: noindex;
• страница-контейнер не должна запрещать изображение директивой noimageindex, если нужен Google Images.

Не блокируйте старый URL в robots.txt сразу после установки redirect. Робот должен запросить старый адрес и увидеть 301/308. Запрет обхода скрывает сам сигнал. Новый asset и его HTML landing page тоже должны быть доступны crawler.

Минимальные адресные группы в robots.txt можно оставить явно разрешёнными:

User-agent: Googlebot-Image
Allow: /media/

User-agent: YandexImages
Allow: /media/

User-agent: bingbot
Allow: /media/

Allow не исправит более специфический конфликт автоматически во всех реализациях. Проверьте полный файл, правила User-agent: *, WAF, auth и origin permissions. Robots.txt управляет обходом, но не защищает файл от скачивания: для безопасности нужны права доступа и инфраструктурные ограничения.

Где заменить URL изображения

После включения redirect старые ссылки продолжают работать, но это страховочная сетка. Собственные источники должны сразу указывать на финальный URL.

Поверхность	Что обновить	Частая ошибка
HTML	img src	заменили только видимый URL в CMS preview
Responsive HTML	все srcset, <source srcset>, sizes при изменении геометрии	часть устройств ходит на old host
Preload	link rel="preload", imagesrcset, imagesizes	preload качает старый файл, <img> — новый
Open Graph	og:image, secure URL, type, width, height, alt	URL новый, MIME и размеры старые
JSON-LD	ImageObject.contentUrl, Article/Product image	contentUrl ведёт на редирект или signed URL
Image Sitemap	image:loc и page loc, если переехала страница	в sitemap остались redirecting URLs
CSS/JS	background images, manifests и hardcoded loaders	изображение не видно обычным HTML crawler
Email/RSS/feeds	абсолютные image URL	старый host нельзя отключить из-за вечных рассылок
External embed docs	код для вставки и партнёрские инструкции	новые публикации продолжают создавать hotlinks на old URL

Для Google Image Sitemap оставьте image:image и image:loc: caption, title, geo location и license там deprecated. Яндекс по-прежнему поддерживает эти четыре необязательных поля; размеры ограничены в байтах. Подробная справка Яндекса по Image Sitemap содержит актуальные лимиты.

Preferred URL одного ценного изображения полезно повторить без противоречий в fallback img src, ImageObject.contentUrl, основном og:image и image:loc. Responsive derivatives остаются в srcset, но не должны случайно конкурировать как десятки «главных» идентичностей.

Права, лицензия и атрибуция

До переноса определите статус изображения: собственное, лицензированное, public domain, third-party или rights unclear. Поля creator, creditText, copyrightNotice, license и acquireLicensePage заполняйте только при подтверждённых основаниях.

Оптимизаторы часто удаляют EXIF/IPTC/XMP ради нескольких килобайт. Нельзя бездумно стирать критические поля автора, credit, copyright, Web Statement of Rights, licensor и provenance. Если формат или pipeline не поддерживает metadata, сохраните права видимым текстом на landing page и корректным ImageObject. Для изображения, созданного или существенно изменённого ИИ, сохраняйте правдивую provenance-информацию, когда она доступна.

Hotlink на файл не является backlink на статью. Если нужна атрибуция и переходы, предложите embed-код, где изображение обёрнуто в обычную ссылку на landing page, и явно укажите условия использования. Не навязывайте чужим сайтам ложную лицензию задним числом.

Безопасный поэтапный запуск

Базовая фиксация

Сохраните inventory, mapping, checksum файлов, текущие headers, robots, sitemap, логи 3xx/4xx/5xx, обращения crawler, image-search clicks и переходы на landing pages. Без baseline невозможно отличить последствие миграции от обычной сезонности.

Подготовка цели

Скопируйте файлы, но пока не удаляйте старые. Проверьте TLS, 200, MIME, размеры, визуальную эквивалентность, validators, caching, rights metadata и доступность с внешней сети. Подтвердите новый host в webmaster tools.

Пилот

Выберите небольшой, не самый сезонный раздел, но включите разные типы: JPEG→WebP, thumbnail, srcset, social crop и одно cross-domain изображение. Обновите ссылки, включите direct redirects и наблюдайте логи. Пилот должен проверять механику, а не только одну идеальную картинку.

Масштабирование

После успешного пилота применяйте mapping партиями. На каждой партии проверяйте долю one-hop redirect, финальный 200, MIME, количество 404/403/5xx, cache hit ratio и старые внутренние references. Не совмещайте перенос CDN, полную смену CMS, дизайн и массовое перекодирование без необходимости: при сбое будет трудно найти причину.

Долгое сохранение

Оставьте old host, сертификат, правила и достаточную серверную ёмкость. После migration crawler временно обращается и к старым, и к новым адресам. Не выключайте origin по первому снижению графика.

Примеры конфигурации

Примеры используют вымышленные домены. Перед применением сгенерируйте правила из проверенной таблицы и протестируйте конфигурацию.

Nginx: точное соответствие

location = /uploads/old-chart.jpg {
    return 301 https://img.example.ru/charts/redirects-seo.webp;
}

location = /uploads/old-chart-640.jpg {
    return 301 https://img.example.ru/charts/redirects-seo-640.webp;
}

Если метод должен строго сохраняться и вся цепочка поддерживает код:

location = /uploads/old-chart.jpg {
    return 308 https://img.example.ru/charts/redirects-seo.webp;
}

Для действительно одинаковой структуры допустимо сохранить URI:

location ^~ /wp-content/uploads/ {
    return 301 https://img.example.ru$request_uri;
}

$request_uri сохраняет путь вместе с query string. Если параметры старого CDN нельзя переносить, используйте нормализованный $uri и отдельные правила для значимых transforms. Не копируйте wildcard, пока выборочная сверка не докажет, что каждый target существует.

После правки:

nginx -t
nginx -s reload

Caddy: точный matcher

example.ru {
    @oldChart path /uploads/old-chart.jpg
    redir @oldChart https://img.example.ru/charts/redirects-seo.webp 301

    @oldChart640 path /uploads/old-chart-640.jpg
    redir @oldChart640 https://img.example.ru/charts/redirects-seo-640.webp 308

    reverse_proxy localhost:3000
}

permanent в Caddy означает 301; числовой 308 можно задать явно. Сначала выполните форматирование и валидацию конфигурации, затем graceful reload.

CDN: wildcard только для изоморфного пути

В Cloudflare Single Redirect логика может выглядеть так:

Request URL:  https://www.example.ru/uploads/*
Target URL:   https://img.example.ru/uploads/${1}
Status code:  301
Preserve query string: false

Флаг query string выбирайте по mapping, а не по удобству. Если ?width=640 меняет representation, false потеряет смысл. Для неодинаковых имён используйте Bulk Redirects или key-value mapping, а не один широкий шаблон. У target всегда должен быть конечный 200; CDN rule не должен запускать новый redirect на origin.

Как проверить миграцию командами

Проверяйте headers без автоматического перехода:

curl -sS -I --max-redirs 0 https://www.example.ru/uploads/old-chart.jpg

Ожидаются 301/308 и один Location на окончательный image URL. Затем проверьте всю трассу:

curl -sS -L --max-redirs 5 -o /dev/null \
  -w 'status=%{http_code} redirects=%{num_redirects} final=%{url_effective}\n' \
  https://www.example.ru/uploads/old-chart.jpg

Ожидаются status=200, redirects=1 и нужный final URL. На Windows замените /dev/null на NUL.

Проверьте target и crawler-like запросы:

curl -sS -I https://img.example.ru/charts/redirects-seo.webp
curl -sS -I -A 'Googlebot-Image/1.0' https://img.example.ru/charts/redirects-seo.webp
curl -sS -I -A 'Mozilla/5.0 (compatible; YandexImages/3.0)' https://img.example.ru/charts/redirects-seo.webp
curl -sS -I -A 'bingbot' https://img.example.ru/charts/redirects-seo.webp
curl -sS https://img.example.ru/robots.txt

Эти User-Agent запросы проверяют только поведение сервера, а не настоящую принадлежность crawler. В production logs проверяйте IP через reverse + forward DNS.

Проверьте conditional cache:

curl -sS -I \
  -H 'If-None-Match: "sha256-example"' \
  https://img.example.ru/charts/redirects-seo.webp

Если representation не изменился, допустим 304. Проверьте и фактические bytes: MIME-sniffing утилитой, декодером изображения, dimensions и checksum. Одного заголовка сервера недостаточно.

Проверка HTML и разметки

Скачайте rendered HTML и найдите старые host/path:

curl -sS https://www.example.ru/stati/redirects/ > page.html
grep -Eo 'https?://[^" ]+' page.html | sort -u

Отдельно проверьте src, srcset, <source>, preload, og:image, JSON-LD и XML Sitemap. В DevTools откройте страницу с мобильным viewport и DPR 1/2: вкладка Network покажет, какой candidate реально выбрал браузер.

Для lazy loading прокрутите страницу до каждого изображения. В исходном или отрендеренном DOM должен появляться стандартный img src; data-атрибут без доступного fallback может быть невидим роботу. LCP-изображение первого экрана не откладывайте через loading="lazy". Для остальных native lazy loading допустим, если загрузка не зависит от жеста или закрытого API.

Что отслеживать после запуска

Соберите отдельные графики по old и new host:

Метрика	Зачем
old URL requests и unique URLs	понять, какие источники ещё не обновились
доля 301/308 и среднее число hops	найти цепочки, циклы и временные коды
final 200/304, 403/404, 429/5xx	обнаружить недоступные targets и перегрузку
запросы Googlebot-Image, YandexImages, bingbot	увидеть повторный обход без доверия к UA alone
response time и CDN cache hit ratio	проверить, дал ли CDN технический выигрыш
bytes transferred и LCP/CLS	не ухудшили ли формат, размер или layout
старые URL в HTML/JSON-LD/sitemap	убрать внутреннюю зависимость от redirect
image-search impressions/clicks	измерить поисковый результат по отдельным системам
переходы на landing pages и конверсии	отличить показы картинки от полезного трафика

Сравнивайте окна 7, 28 и 90 дней с baseline и учитывайте сезонность. Не делайте вывод по одному дню: переобход происходит по URL и зависит от размера сайта, частоты обращения и скорости серверов.

В Google Search Console следите за Image search performance, crawl errors, URL Inspection страниц и image sitemap. В Яндекс Вебмастере — обходом, Sitemap, ответом сервера и внешними ссылками на страницы. В Bing Webmaster Tools — crawl/index reports для обоих host. Ни одна панель не заменяет access logs: только они покажут старые image requests, статус и фактическую цель. Читать полный обзор сервиса Google Search Console.

Как откатить без нового хаоса

До переключения сохраните старые файлы, конфигурацию, mapping и checksums. Rollback должен восстанавливать один стабильный маршрут, а не создавать обратную цепочку.

Если новый CDN недоступен:

1. остановите следующую партию;
2. отключите правило old→new и временно верните старому URL прямой 200 из сохранённого origin;
3. восстановите внутренние ссылки из versioned deployment либо переключите origin за тем же новым URL;
4. не ставьте new→old поверх оставшегося old→new — получится цикл;
5. после исправления повторите полный пилот.

Лучший rollback сохраняет публичный новый URL и меняет его origin за кулисами. Тогда не приходится разворачивать поисковую миграцию обратно. Длинный immutable кеш усложняет исправление байтов под тем же URL, поэтому immutable assets версионируют: ошибка получает новый путь, а не тихую замену содержимого.

Различия Google, Яндекса и Bing

Вопрос	Google	Яндекс	Bing
Постоянные коды	301 и 308	301 и 308	стандартная HTTP-семантика 301/308
Временные коды	302, 303, 307	302, 303, 307; инструмент доменного переезда отдельно допускает 301/302	302/307 не стоит использовать как сигнал постоянной смены
Chains	до 10 hops, рекомендуется прямой target	конечная цель обрабатывается; числовой лимит не опубликован	подтверждённого публичного числового лимита нет
Срок redirect	минимум год, лучше дольше	фиксированный срок не указан	фиксированный срок не указан
Image Sitemap	image:image и image:loc; caption/title/geo/license deprecated	caption/title/geo/license остаются необязательными	придерживайтесь общего sitemap и доступности crawler
Image crawler	Googlebot-Image	YandexImages	bingbot выполняет основную работу обхода
Cross-domain host	подтвердить в Search Console	подтвердить в Вебмастере	добавить и контролировать host в Bing Webmaster Tools

Практический общий знаменатель одинаков: один permanent redirect, конечный 200 image response, обновлённые собственные ссылки, crawlable old и new URL, отдельная проверка каждого host и длительное хранение правила.

Вывод

Правильная смена пути изображения — управляемая миграция идентичности, а не массовая замена строк. Составьте точный mapping, отделите HTML pages от binary assets, подготовьте конечные файлы и только затем включайте прямые 301/308. Обновите все поверхности, включая responsive candidates и метаданные, проверьте headers, robots, rights и cross-domain ownership, запустите пилот и наблюдайте логи.

Редирект остаётся страховкой для старых ссылок и hotlinks, но собственный сайт должен обращаться сразу к новым URL. Сохраните правила минимум год и дольше для востребованных изображений. Так миграция не превращается в цепочки, битые картинки, истёкшие signed URLs и потерянную атрибуцию.