После миграции, смены домена, очистки медиатеки или переноса сайта на CDN часто остаются ссылки на изображения, которые уже не существуют. Визуально страница может выглядеть нормально, но в HTML, атрибутах src, srcset, в произвольных полях и даже в старых редакциях записей продолжают жить старые URL. В результате появляются 404 на медиафайлы, ломается верстка карточек, а поисковик видит мусорные ссылки.
Ниже — рабочий сценарий: как понять, где именно сидят такие ссылки, чем их безопасно заменить и как проверить, что проблема действительно закрыта.
Как выглядит проблема на практике
Обычно жалобы приходят в одном из трех вариантов:
- в браузере не открываются отдельные картинки, хотя запись опубликована;
- в отчете сервера или в логах много
404на файлы из/wp-content/uploads/; - после переезда на новый домен часть изображений все еще грузится со старого адреса или с другого поддомена.
Важно не путать битую ссылку с отсутствующим файлом в медиатеке. Иногда файл на сервере есть, но в контенте остался старый путь. Иногда наоборот: запись ссылается на корректный URL, а сам файл удален из uploads.
Диагностика: где искать старые URL
Начинать лучше не с массовой замены, а с поиска источника. У WordPress изображения могут храниться не только в тексте записи. Проверьте несколько мест:
- контент записей и страниц;
- поле
post_contentв базе; - произвольные поля, если тема или плагин сохраняет туда URL;
- виджеты и шаблонные блоки;
- настройки темы, если там есть баннеры, слайдеры, шапка или фон;
- старые редакции записей.
Быстрая проверка через SQL
Если у вас есть доступ к базе, можно быстро найти записи, где встречается старый домен или путь к медиафайлам:
SELECT ID, post_title, post_type
FROM wp_posts
WHERE post_content LIKE '%old-domain.ru/wp-content/uploads/%'
OR post_content LIKE '%/wp-content/uploads/2023/%';Запрос не исправляет данные, а только показывает, где искать. Если префикс таблиц у вас не wp_, подставьте свой.
Проверка через WP-CLI
Если на сервере доступен WP-CLI, искать старые строки удобнее через wp search-replace в режиме проверки:
wp search-replace 'https://old-domain.ru' 'https://new-domain.ru' --dry-run --all-tablesКоманда покажет, в каких таблицах и сколько замен было бы выполнено. Это полезно, когда непонятно, сидит ли старый адрес только в контенте или еще и в метаданных.
Пошаговое решение без лишнего риска
Если задача именно убрать старые ссылки на изображения, а не просто заменить домен целиком, лучше идти по шагам.
1. Сделайте резервную копию базы
Это не формальность. Массовая замена в базе затрагивает не только записи, но и сериализованные данные плагинов. Перед правками нужен дамп базы или хотя бы рабочий бэкап через панель хостинга.
2. Определите точный шаблон ссылки
Не заменяйте слишком широкую строку вроде https://old-domain.ru, если проблема касается только изображений. Лучше искать конкретный путь:
https://old-domain.ru/wp-content/uploads/Так вы не заденете ссылки на внешние сервисы, документы или API.
3. Выполните замену в базе
Для массовой замены безопаснее использовать штатный механизм WordPress или WP-CLI. Если вы работаете через консоль, пример выглядит так:
wp search-replace 'https://old-domain.ru/wp-content/uploads/' 'https://new-domain.ru/wp-content/uploads/' --all-tables --preciseПараметр --precise полезен, когда в базе есть сериализованные данные. Он медленнее, но снижает риск повредить структуру данных.
Если нужно заменить не домен, а только путь к конкретной папке, например после переноса медиа на CDN, меняйте именно этот фрагмент. Не трогайте лишнее.
4. Проверьте вложения и миниатюры
После замены откройте несколько записей, где были проблемы. Убедитесь, что:
- картинка открывается по новому адресу;
- в HTML у изображения правильный
src; - атрибут
srcsetне содержит старых URL; - миниатюры в списках записей и на архивных страницах тоже обновились.
Если тема выводит изображения через собственные шаблоны, проверьте не только контент, но и код темы.
Когда нужен код, а не только замена в базе
Иногда старые ссылки появляются не в контенте, а на этапе вывода. Например, тема берет URL из произвольного поля и подставляет его в шаблон. Тогда массовая замена в базе не решит проблему полностью.
В таком случае можно добавить фильтр, который будет нормализовать URL перед выводом. Пример для случая, когда в метаполе хранится старый домен:
add_filter('post_thumbnail_html', function ($html) {
$old = 'https://old-domain.ru';
$new = 'https://new-domain.ru';
return str_replace($old, $new, $html);
});Это не универсальное решение, а точечная страховка. Используйте его только если точно знаете, откуда приходит старый адрес. Для постоянной поддержки лучше исправить источник данных, а не маскировать проблему на выводе.
Таблица: чем лучше решать задачу
| Подход | Когда подходит | Минусы |
|---|---|---|
| WP-CLI search-replace | Нужно массово заменить URL в базе | Требует доступа к консоли |
| SQL-поиск | Нужно понять, где сидит проблема | Не исправляет данные |
| Ручная правка записей | Проблемных страниц мало | Долго и легко пропустить часть ссылок |
| Фильтр в теме/плагине | Старый URL формируется на выводе | Не лечит источник, только скрывает симптом |
Проверка результата после внедрения
После замены не ограничивайтесь визуальным просмотром одной страницы. Проверьте несколько уровней:
- откройте страницу в браузере и посмотрите, нет ли 404 в DevTools;
- прогоните сайт через краулер или хотя бы через поиск по исходному коду страницы;
- проверьте логи сервера на обращения к старым URL;
- если используется CDN, убедитесь, что кэш обновился и не отдает старую версию;
- посмотрите, не осталось ли старых ссылок в RSS, если изображения попадают туда через контент.
Полезная ручная проверка — поиск по исходнику страницы. Откройте HTML и найдите старый домен или старый путь к /uploads/. Если совпадений нет, а картинка грузится, значит замена сработала не только в визуальном слое.
Частые ошибки и как их исправить
Заменили весь домен и сломали внешние ссылки
Такое случается, когда в базе меняют слишком общий шаблон. Если на сайте были ссылки на внешние CDN, сервисы аналитики или документы, они тоже могли попасть под замену. Исправление простое: откатить бэкап и повторить замену уже по точному пути к медиафайлам.
Не учли сериализованные данные
Если править базу вручную через SQL REPLACE(), можно повредить сериализованные массивы. В итоге часть настроек темы или плагина перестанет читаться. Для таких случаев лучше использовать WP-CLI с --precise или штатный инструмент миграции.
Проверили только главную страницу
На главной может не быть старых ссылок, а в архиве, в блоке похожих материалов или в шаблоне записи они останутся. Проверяйте несколько типов страниц: запись, страницу, архив, поиск, страницу автора.
Забыли про миниатюры и srcset
Если меняли только src, но не проверили srcset, браузер может продолжить брать старый URL из набора размеров. Поэтому после замены обязательно смотрите полный HTML тега img.
Что делать, если изображения физически удалены
Если ссылка ведет на файл, которого уже нет на сервере, одной заменой URL проблему не решить. Тогда есть два варианта: восстановить файл из бэкапа или заменить изображение в записи на новое. Для массовых случаев удобнее сначала найти все записи, где используется конкретный attachment ID, а потом уже решать, что с ним делать.
Если медиа удаляли вручную, проверьте, не остались ли записи в базе, которые ссылаются на этот attachment. Иногда WordPress продолжает показывать «пустую» миниатюру, хотя файл уже исчез.
Практические советы по безопасности и производительности
- не запускайте массовую замену на живом сайте без бэкапа;
- если сайт большой, сначала протестируйте замену на копии;
- не используйте плагины, которые делают «поиск и замену» без понимания сериализации данных;
- после правок очистите кэш страницы, объектный кэш и CDN, если они есть;
- если проблема повторяется после каждого обновления темы, ищите источник в шаблоне или настройках темы, а не в контенте.
Если вам часто приходится чистить дубли, старые ссылки и мусор в базе, такие задачи удобно закрывать через набор точечных инструментов вроде Clearfy Pro: он не заменяет разработку, но помогает убрать часть технического шума на типовых сайтах. Ссылку лучше проверять по конкретной задаче, а не ставить плагин «на всякий случай».
Когда старые ссылки на изображения найдены и заменены, сайт обычно перестает отдавать лишние 404, а контент становится предсказуемее для браузера и поисковых роботов. Самое важное здесь — не лечить симптом точечно, а понять, где именно формируется устаревший URL: в записи, в метаполе, в шаблоне или в кэше.