Медиабиблиотека разрослась: как найти картинки, которых нет ни на одной странице

Медиабиблиотека на сайте, которому пять-семь лет, почти всегда крупнее, чем нужно: в ней лежат черновики баннеров, картинки удалённых статей, три версии одного логотипа и десятки снимков, загруженных «на посмотреть». Занимают они гигабайты, но главная проблема не в месте на диске, а в том, что удалять их наугад опасно — половина «неиспользуемых» файлов на самом деле используется там, где вы не догадались посмотреть.

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

Чем реально мешает раздутая медиабиблиотека

Обычно называют место на хостинге, но это самая мелкая из причин. Настоящие издержки другие.

• Бэкапы и переносы. Архив папки uploads на десятки гигабайт делается долго, разворачивается ещё дольше, а у части хостингов упирается в ограничение по времени выполнения скрипта. В итоге резервная копия либо не создаётся, либо создаётся без картинок — и об этом узнают в момент аварии.
• Обход роботом. Картинки робот тоже скачивает, и на них расходуется внимание, которое могло уйти на страницы. Когда файлов в разы больше, чем нужно, часть этого внимания тратится на мусор. Про сам механизм распределения обхода я писал отдельно, здесь достаточно понимать, что бесконечного бюджета нет.
• Мусор в поиске по картинкам. В индекс попадают случайные файлы: скриншоты для внутренней переписки, старые прайсы картинкой, фото с чужим водяным знаком. Человек приходит по такой картинке и ничего не находит. Это плохая точка входа, и она портит впечатление.
• Страницы вложений. WordPress умеет создавать отдельный адрес под каждую картинку — почти пустую страницу с одним изображением. Если они открыты, сайт получает сотни тонких страниц, которые не нужны никому.
• Путаница в работе. Когда в библиотеке десять файлов с именами вида IMG_4471-1-scaled.jpg, найти нужный невозможно, и вместо поиска человек загружает новую копию. Так библиотека растёт сама.

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

Как WordPress на самом деле хранит одну картинку

Понимание этого механизма отсекает 90 % ошибок при чистке. Когда вы загружаете один файл, происходит вот что.

В таблице записей появляется запись с типом attachment — у неё есть свой идентификатор, заголовок, описание и родитель (запись, из редактора которой файл загрузили). В метаданных к ней пишутся два ключевых поля: _wp_attached_file с относительным путём к файлу и _wp_attachment_metadata — массив со списком созданных размерных копий. Атрибут alt хранится отдельным полем _wp_attachment_image_alt.

Дальше WordPress нарезает копии. По умолчанию это миниатюра, средний, средний крупный и большой размеры, а для крупных исходников добавляются копии шириной 1536 и 2048 пикселей. Если исходник шире примерно 2560 пикселей, создаётся уменьшенная основная версия с суффиксом -scaled, и именно она подставляется на страницы. Тема и плагины регистрируют свои размеры сверх этого: обложка записи, миниатюра для списка, картинка для слайдера.

Что вы видите	Что лежит на диске	Следствие
Одна картинка в библиотеке	от 5 до 12 файлов, в зависимости от темы и плагинов	«тысяча картинок» — это несколько тысяч файлов и в разы больше места, чем кажется
Картинка вставлена в статью	в HTML статьи — конкретный размер плюс список альтернатив в srcset	поиск по имени файла в тексте статьи может не найти вхождение, если в коде стоит копия с суффиксом размера
Обложка записи	в тексте статьи файла нет вообще	ищется только через метаполе _thumbnail_id
Картинка в поле темы или конструктора	в метаданных записи или в настройках темы, часто по идентификатору, а не по имени	обычным поиском по имени файла не находится
Удалили файл по FTP	запись в базе осталась	битая картинка на странице и «фантом» в библиотеке
Удалили запись из библиотеки	WordPress убирает и все размерные копии	правильный способ удаления — только через библиотеку

Последние две строки — главное практическое правило: чистим через медиабиблиотеку или через код, который делает то же самое, но никогда не удаляем файлы по FTP. Иначе получите записи-фантомы, которые дальше не удалить обычным способом.

Почему «неиспользуемая» не значит «можно удалить»

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

Где может прятаться картинка	Почему поиск её не видит	Как проверить
Обложка записи	в тексте нет ни имени, ни адреса файла	метаполе _thumbnail_id у всех записей и страниц
Галерея по идентификаторам	в коде стоят номера вложений, а не имена файлов	вхождения идентификатора вложения в текст и метаданные
Поля темы и плагинов	хранят номер вложения в настройках	таблица настроек: логотип, иконка, фон, картинка-заглушка
Конструктор страниц	вся вёрстка лежит одним куском данных в метаполе	поиск имени файла и идентификатора внутри этих метаполей
Стили темы	фон блока задан прямо в CSS	поиск по файлам темы и дочерней темы
Карточки товаров	основное изображение и галерея хранятся в метаданных товара	метаполя товаров, а не тексты
Письма и рассылки	шаблон письма ссылается на файл напрямую	настройки плагина рассылок
Внешние ссылки	на файл ссылаются с других сайтов или из соцсетей	отчёт по внешним ссылкам в панели вебмастера
Индекс поиска по картинкам	файл сам приводит людей	отчёт по показам в поиске по картинкам

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

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

Смысл в том, чтобы собрать не один список, а два: полный перечень вложений и перечень всех использований, — и вычесть второй из первого. Логика такая.

• Шаг первый: инвентаризация. Все записи с типом attachment и их поля _wp_attached_file. Это полный список того, что зарегистрировано в базе. Отдельно — список файлов, физически лежащих в uploads. Уже на этом этапе находятся расхождения: файлы без записей (мусор от старых плагинов) и записи без файлов (следы удаления по FTP).
• Шаг второй: использования. Вхождения имени файла — без суффикса размера — в тексты всех записей, страниц и товаров. Плюс все значения _thumbnail_id. Плюс вхождения идентификатора вложения в метаданные. Плюс значения в настройках темы и в данных конструктора. Важная деталь: искать надо по имени без размерного хвоста, то есть по logo, а не по logo-300x200.jpg, иначе половина вхождений потеряется.
• Шаг третий: вычитание и сортировка. Разница между списками — кандидаты. Их нужно отсортировать по дате загрузки и по размеру: сначала смотреть самые тяжёлые, а из одинаково тяжёлых — самые старые.
• Шаг четвёртый: ручная проверка выборки. Возьмите двадцать-тридцать кандидатов и откройте их адреса в браузере, а также поищите каждый по сайту. Если хотя бы один найдётся используемым — метод сбора неполный, и надо искать, какое место вы пропустили. Это самая важная проверка, и её всегда пропускают.

Этот способ похож на поиск страниц, на которые не ведёт ни одна ссылка: там та же арифметика двух списков, и я описывал её в материале про страницы-сироты. Разница в том, что с картинками слишком много мест хранения, поэтому шаг с ручной проверкой обязателен.

Плагины-чистильщики: что умеют и где ошибаются

Подход	Что находит	Чего не видит	Когда уместен
Плагин по вхождениям в тексты	картинки, вставленные в статьи	обложки, поля темы, конструкторы, товары	простой блог без конструктора
Плагин со сканом метаданных	тексты, обложки, часть метаполей	CSS темы, внешние ссылки, индекс картинок	как источник списка кандидатов, не для автоудаления
Сравнение файлов на диске с базой	файлы без записей и записи без файлов	используется ли зарегистрированный файл	первый шаг любой чистки
Собственный список запросов к базе	всё, что вы догадались проверить	то, о чём не подумали	сайты с конструктором, магазином, кастомными полями
Кнопка «удалить всё неиспользуемое»	то же, что и скан	то же, что и скан	никогда без бэкапа и карантина

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

Карантин вместо удаления

Порядок, который снимает почти весь риск. Идея простая: сначала сделать файлы недоступными, подождать и посмотреть, кто по ним постучится.

1. Полный бэкап базы и папки uploads, с проверенной возможностью развернуть. Не «у хостера что-то есть».
2. Возрастной фильтр. Из списка кандидатов исключить всё, загруженное за последние три-четыре месяца: свежие файлы часто относятся к материалам в работе.
3. Карантин. Перенести кандидатов в отдельную папку вне uploads либо закрыть к ним доступ на уровне сервера, оставив записи в базе на месте.
4. Наблюдение 30–60 дней. Смотреть журнал ошибок сервера и отчёт по ошибкам в панели вебмастера: всё, что запрашивают люди и роботы, всплывёт как ошибка 404. Каждый такой файл — вернуть и пометить как используемый. Проверять журнал стоит раз в неделю, а не один раз в конце срока.
5. Удаление. Пережившее карантин удалять только через медиабиблиотеку или кодом, который делает то же самое: тогда уйдут и размерные копии, и запись в базе.
6. Проверка после. Пройти глазами главную, шаблон статьи, карточку услуги или товара, страницу категории. Автоматическая проверка тут помогает мало — битая картинка в фоне блока видна только глазом.

Да, это дольше, чем нажать кнопку в плагине. Зато после такой чистки не приходится через месяц объяснять, почему на десяти страницах пропали фотографии, а восстановить их не из чего.

Что делать с картинками, которые уже в индексе

Если файл приводил людей из поиска по картинкам, простое удаление — потеря трафика. Варианты по убыванию предпочтительности:

• Оставить и использовать. Раз по картинке приходят, ей нужна нормальная страница: вставить в подходящий материал, заполнить alt, дать осмысленное окружение в тексте. Это превращает мусорный файл в рабочую точку входа.
• Перенаправить на близкую картинку. Если содержимое дублируется, настроить постоянный редирект со старого адреса файла на актуальный. Вес и переходы сохраняются. Только не выстраивайте цепочки из нескольких редиректов — это отдельная болезнь, про которую я писал в разборе цепочек и петель редиректов.
• Отдавать код 410. Если картинка удалена намеренно и навсегда, код «удалено окончательно» честнее, чем 404: поиск выкидывает такой адрес из индекса быстрее.
• Просто удалить. Нормально для файлов без показов и без внешних ссылок — то есть для большинства кандидатов.

Страницы вложений — отдельная беда

По умолчанию WordPress долгие годы создавал отдельный адрес под каждое вложение: страница с одной картинкой, заголовком вида IMG_2048 и без текста. Сотни таких адресов — это сотни тонких страниц, из-за которых сайт в целом выглядит хуже, чем есть.

В WordPress 6.4 появилась настройка, отключающая страницы вложений: на новых сайтах она выключена, а на сайтах, созданных раньше, по умолчанию осталась включённой — то есть если ваш сайт старый, страницы вложений у вас, скорее всего, работают. Проверяется за минуту: откройте любую картинку в библиотеке и посмотрите, есть ли у неё ссылка вида «просмотреть страницу вложения» и открывается ли она.

Что делать: отключить их средствами SEO-плагина или настройкой, а существующие адреса перенаправить на родительскую запись. Закрывать их от индексации через robots.txt — половинчатое решение: адреса уже известны поиску, и правильнее их именно перенаправить. Тема тонких и пустых страниц шире одной этой проблемы, я разбирал её отдельно: пустые и тонкие страницы, которые тянут сайт вниз.

Дубли файлов и повторные загрузки

Второй по объёму источник раздувания. Механика простая: если загрузить файл с уже занятым именем, WordPress не заменит старый, а добавит к имени числовой суффикс. Так появляются banner.jpg, banner-1.jpg, banner-2.jpg — три разных файла с одинаковой картинкой, каждый со своим набором размерных копий.

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

Что помогает:

• Осмысленные имена файлов латиницей до загрузки: zamena-radiatora-otopleniya.jpg вместо IMG_4471.jpg. Это одновременно и сигнал для поиска по картинкам, и способность найти файл через месяц.
• Поиск в библиотеке перед загрузкой — работает только если предыдущий пункт соблюдается.
• Заполнение поля alt сразу при загрузке, а не «потом»: потом не наступает.
• Осознанный набор размеров. Если тема регистрирует восемь размеров, а используются три, лишние можно не создавать — библиотека перестанет расти в три раза быстрее необходимого.

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

Профилактика и порядок на будущее

Чистка — разовая операция, и через два года всё повторится, если не поменять привычки загрузки. Короткий регламент, который я ставлю на проектах.

Правило	Что даёт	Как проверить, что соблюдается
Имя файла латиницей по смыслу	файл находится в библиотеке, работает поиск по картинкам	отсортировать библиотеку по дате и посмотреть последние 20 загрузок
Сжатие до загрузки	меньше вес страницы и вес бэкапа	средний вес файлов за последний месяц
Ширина не больше, чем нужно шаблону	не создаются лишние копии и версия -scaled	посмотреть, какая ширина реально выводится в статье
Заполненный alt при загрузке	доступность, показы в поиске по картинкам	выборочная проверка десяти последних вложений
Отключены неиспользуемые размеры	библиотека растёт медленнее	сравнить список зарегистрированных размеров с тем, что выводит шаблон
Страницы вложений выключены	нет тонких страниц	открыть адрес вложения и убедиться в перенаправлении
Ревизия раз в год	долг не накапливается	задача в календаре, иначе не произойдёт

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

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

Коротко

• Одна загруженная картинка — это от пяти до двенадцати файлов на диске. Поэтому библиотека растёт быстрее, чем кажется по счётчику в админке.
• Главные издержки — не место, а неподъёмные бэкапы, мусор в поиске по картинкам и тонкие страницы вложений.
• Картинка может использоваться в обложке, галерее по идентификаторам, полях темы, данных конструктора, метаданных товара, стилях и в письмах. Поиск по имени файла в текстах находит только часть.
• Метод — два списка: все вложения минус все использования. Искать по имени без размерного суффикса и обязательно проверить руками выборку из двадцати-тридцати кандидатов.
• Список от плагина-чистильщика — черновик. Кнопку «удалить всё неиспользуемое» без бэкапа не нажимать.
• Вместо удаления — карантин на 30–60 дней с наблюдением за ошибками 404. Всё, что запросили, вернуть.
• Файлы по FTP не удалять: останутся записи-фантомы. Только через медиабиблиотеку или кодом.
• Картинки с показами в поиске лучше не удалять, а использовать или перенаправить. Для намеренно удалённых честнее код 410, чем 404.
• Страницы вложений на старых сайтах обычно открыты. Их отключают и перенаправляют на родительскую запись.
• Без правил загрузки — осмысленное имя, сжатие, alt, ограниченный набор размеров — библиотека зарастёт заново за пару лет.