На WordPress часто путают две задачи: закрыть от индексации служебные URL и при этом не сломать показ изображений на сайте. Ошибка обычно появляется после установки SEO-плагина, миграции или ручного редактирования robots.txt: в индексе остаются мусорные URL из /wp-content/uploads/, а иногда поисковик перестаёт нормально обходить картинки и вложения.
Если у вас сайт с большим количеством изображений, PDF, превью и автогенерируемых размеров, robots.txt нужно настраивать аккуратно. Он не удаляет URL из индекса сам по себе, но помогает ограничить обход тех разделов, которые не должны тратить краулинговый бюджет и светиться в выдаче.
Когда проблема действительно в robots.txt
Сначала стоит убедиться, что вы боретесь именно с обходом, а не с индексацией. Если в поиске видны URL медиафайлов, это не всегда означает, что их нужно закрывать через robots.txt. Иногда правильнее поставить noindex на страницы вложений, убрать ссылки на них из шаблонов или настроить каноникал.
Типичные симптомы
- в индексе есть URL вида
/wp-content/uploads/2024/05/image-150x150.jpg; - в отчётах сканирования много запросов к служебным изображениям, PDF и миниатюрам;
- в
robots.txtуже есть правила, но они конфликтуют между собой; - после правки файла пропали изображения из тестов в Search Console или стали хуже обходиться медиа-страницы.
Если проблема только в страницах вложений, а не в самих файлах, robots.txt не всегда лучший инструмент. Но если нужно сократить обход папки загрузок и закрыть служебные каталоги, настройка файла даёт быстрый и понятный эффект.
Что именно закрывать, а что оставить открытым
В WordPress обычно не стоит блокировать весь /wp-content/uploads/ без разбора. Поисковику нужны сами файлы изображений, если они участвуют в поиске картинок или встроены в контент. Чаще закрывают только служебные и неинформативные участки.
| Что делать | Когда подходит | Риск |
|---|---|---|
| Закрыть отдельные служебные папки | Если в uploads есть приватные выгрузки, временные файлы, документы для внутреннего использования | Низкий, если путь выбран точно |
| Закрыть вложения через noindex | Если в индексе много страниц attachment, но сами файлы нужны в поиске | Нужно отдельно проверить шаблоны и SEO-плагин |
| Закрыть весь uploads | Редко, только если медиа не должны участвовать в поиске вообще | Можно потерять трафик из поиска по картинкам |
Пошаговая настройка robots.txt для медиа
Самый безопасный путь — начать с минимального набора правил и проверить, что они не конфликтуют с уже существующими директивами. В WordPress файл может быть виртуальным, если вы используете SEO-плагин, или физическим, если он лежит в корне сайта.
Шаг 1. Проверьте текущий robots.txt
Откройте https://ваш-домен.ru/robots.txt и посмотрите, кто его формирует. Если там уже есть строки от SEO-плагина, не дублируйте правила в другом месте. Двойные директивы часто приводят к путанице: один блок разрешает обход, другой запрещает, а итог зависит от конкретного робота и порядка чтения.
Шаг 2. Добавьте только нужные запреты
Если задача — убрать служебные файлы и временные каталоги, можно использовать такой шаблон:
User-agent: *
Disallow: /wp-content/cache/
Disallow: /wp-content/uploads/tmp/
Disallow: /wp-content/uploads/private/
Allow: /wp-content/uploads/
Sitemap: https://example.com/sitemap_index.xmlЗдесь важно, что общий каталог /wp-content/uploads/ остаётся доступным, а закрываются только конкретные подкаталоги. Это безопаснее, чем блокировать всё подряд.
Шаг 3. Если нужно закрыть только служебные расширения
Иногда в uploads лежат архивы, отчёты, CSV или PDF, которые не должны обходиться. Тогда можно ограничить не папку, а типы файлов:
User-agent: *
Disallow: /*.csv$
Disallow: /*.zip$
Disallow: /*.xlsx$
Disallow: /*.pdf$
Sitemap: https://example.com/sitemap_index.xmlТакой подход полезен, если документы загружаются редакторами, но не должны попадать в поиск. Однако он не заменяет контроль доступа: если файл действительно приватный, его лучше хранить вне публичной директории или закрывать сервером.
Если robots.txt генерирует SEO-плагин
На практике файл часто управляется плагином, а не вручную. В этом случае править его через FTP бессмысленно: после сохранения настроек плагин может перезаписать содержимое. Нужно искать раздел с настройками robots.txt или шаблоном файла в самом плагине.
Если вы используете плагин, который умеет чистить технические URL и управлять индексированием, проверьте, не создаёт ли он лишние правила автоматически. Например, в Clearfy Pro есть инструменты для технической чистки сайта и удаления дублей; это не отменяет ручную проверку robots.txt, но помогает убрать часть мусорных URL из индекса и из обхода. Подробности смотрите на Clearfy Pro.
Диагностика после правки
Проверять нужно не только сам файл, но и то, как его читает робот. Иначе можно получить ситуацию, когда правило выглядит правильно, а фактически не работает из-за кеша, CDN или конфликта с другим источником.
Что проверить вручную
- открывается ли
/robots.txtбез редиректов и ошибок; - нет ли в нём второго блока
User-agent: *с противоположными директивами; - сохранился ли sitemap;
- не закрыли ли вы случайно весь
/wp-content/или/uploads/; - не отдаются ли медиафайлы с кодом ошибки 403 из-за правил сервера.
Проверка через curl
Если есть доступ к консоли, быстро проверьте ответ сервера и содержимое файла:
curl -I https://example.com/robots.txt
curl https://example.com/robots.txtЕсли сайт отдаёт старую версию файла, ищите кеш на уровне плагина, хостинга или CDN. Для robots.txt это частая причина ложных срабатываний: вы уже исправили правила, а поисковик ещё видит прежний вариант.
Как не сломать индексацию картинок и вложений
Главная ошибка — закрыть всё медиа целиком и потом удивляться падению видимости в поиске картинок. Если изображения приносят трафик, не блокируйте их без необходимости. Лучше закрыть только:
- служебные подкаталоги;
- временные выгрузки;
- архивы и документы, не предназначенные для поиска;
- страницы вложений, если они не несут ценности.
Для страниц вложений чаще помогает не robots.txt, а настройка SEO-плагина: редирект attachment-страниц на сам файл или на родительскую запись, либо установка noindex для таких страниц. Это уже решает именно проблему индексации, а не обхода.
Частые ошибки и как их исправить
Закрыли весь uploads
После этого поисковик может хуже обходить изображения, а часть страниц потеряет медиа-подсказки. Исправление простое: уберите общий Disallow: /wp-content/uploads/ и оставьте только точечные подкаталоги или расширения.
Смешали ручной файл и настройки плагина
Если SEO-плагин генерирует robots.txt, ручные правки могут исчезать. Решение: редактировать только один источник. Либо физический файл, либо настройки плагина.
Оставили sitemap внутри закрытого блока
Иногда sitemap случайно попадает после слишком широкого Disallow. В итоге робот видит файл, но не может нормально его использовать. Sitemap должен быть доступен и указан отдельно.
Проверяли только в браузере
Браузер показывает файл, но не говорит, как его интерпретирует робот. Для проверки используйте Search Console, логи сервера и хотя бы curl.
Практические советы по безопасности и производительности
Безопасность. Если в uploads лежат приватные документы, не рассчитывайте только на robots.txt. Он не защищает файл от прямого доступа по URL. Для действительно закрытых данных используйте отдельное хранилище, авторизацию или ограничения на уровне сервера.
Производительность. Не плодите лишние правила. Длинный и хаотичный robots.txt хуже читается и сложнее поддерживается. Лучше 5 точных строк, чем 30 спорных.
Поддержка. После любого изменения в медиа-структуре сайта проверьте, не появились ли новые служебные папки от плагинов галерей, оптимизации изображений или резервного копирования. Именно они чаще всего начинают мусорить в обходе.
Короткий чек-лист перед публикацией изменений
- robots.txt открывается по прямому URL;
- нет конфликтующих блоков
User-agent: *; - sitemap указан отдельно и доступен;
- не закрыт весь каталог uploads без причины;
- страницы вложений проверены отдельно;
- после правки очищен кеш на сайте и на CDN;
- в Search Console отправлена повторная проверка файла.
Если после настройки медиа всё ещё попадает в индекс, не пытайтесь лечить это только robots.txt. Обычно нужно смотреть связку: шаблон вложений, canonical, noindex и внутренние ссылки. Именно в этой связке WordPress чаще всего и даёт лишние URL.