На WordPress часто путают две разные задачи: закрыть от индексации attachment-страницы и запретить поисковикам обходить сами файлы в /wp-content/uploads/. Если у вас в индексе появляются пустые страницы вложений, а в выдаче — прямые ссылки на PDF, изображения или архивы, одного noindex обычно недостаточно. Нужно разделить сценарии и проверить, что именно вы хотите скрыть.
Ниже разберём рабочую схему: где ставить запрет, как не сломать доступ к медиа на сайте и чем отличается управление индексацией страниц вложений от блокировки файлов в uploads.
Что именно попадает в индекс и почему это проблема
В WordPress у каждого загруженного файла может быть отдельная страница вложения. Она часто почти пустая: заголовок, картинка и ссылка на сам файл. Поисковик видит такой URL как отдельную страницу и может добавить её в индекс. Это создаёт дубли, размывает релевантность и иногда приводит к тому, что в поиске показывается не статья, а бесполезная attachment-страница.
Отдельная история — прямые URL к файлам в /wp-content/uploads/. Если документ или изображение не должны быть доступны из поиска, их нужно ограничивать на уровне robots.txt и мета-тегов, а в некоторых случаях — ещё и на уровне сервера или прав доступа. Но важно понимать: robots.txt не скрывает файл от пользователя, он только ограничивает обход роботом.
Диагностика: что сейчас индексируется
Перед правками проверьте, что именно уже попало в поиск. Это можно сделать вручную и через инструменты для вебмастеров.
Быстрая проверка в поиске
- Введите в Google или Яндекс запрос вида
site:example.com inurl:attachment. - Проверьте прямые файлы:
site:example.com/wp-content/uploads/ filetype:pdfилиsite:example.com/wp-content/uploads/. - Откройте несколько URL и посмотрите, есть ли у них содержимое, отличное от самого файла.
Что смотреть в коде страницы
Если у вас уже есть SEO-плагин, проверьте, не ставит ли он noindex на attachment-страницы автоматически. Если нет — в исходном коде страницы вложения должен быть мета-тег вида <meta name="robots" content="noindex,follow">. Для файлов это не сработает, потому что у файла нет HTML-страницы.
Рабочая схема: закрываем attachment-страницы и ограничиваем обход файлов
Лучше всего разделить решение на два слоя. Первый — убрать из индекса страницы вложений. Второй — ограничить обход папки с медиа, если это действительно нужно.
| Подход | Что решает | Ограничения |
|---|---|---|
| SEO-плагин | Ставит noindex на attachment-страницы | Не управляет прямыми файлами в uploads |
| Код в теме или мини-плагине | Гибко отключает индексацию и редиректит вложения | Нужно аккуратно тестировать после обновлений |
robots.txt | Ограничивает обход каталогов и файлов | Не скрывает уже известные URL из индекса мгновенно |
Вариант 1: убрать attachment-страницы из индекса через код
Если вы не хотите зависеть от настроек плагина, можно добавить фильтр, который переводит attachment-страницы в noindex. Это не ломает сами файлы и не мешает их вставке в записи.
<?php
add_filter( 'wp_robots', function( array $robots ) {
if ( is_attachment() ) {
$robots['noindex'] = true;
$robots['follow'] = true;
}
return $robots;
} );
Этот вариант хорош тем, что работает на уровне стандартного API WordPress. Но если у вас уже подключён SEO-плагин, проверьте, не конфликтует ли он с этим фильтром и не переопределяет ли мета-теги позже.
Вариант 2: редиректить attachment-страницы на сам файл или родительскую запись
Если attachment-страницы вам вообще не нужны, их можно отправлять либо на сам файл, либо на родительскую запись. Для медиа-библиотеки это часто практичнее, чем просто noindex, потому что пользователь не попадает на пустую страницу.
<?php
add_action( 'template_redirect', function() {
if ( ! is_attachment() ) {
return;
}
$attachment_id = get_queried_object_id();
$parent_id = wp_get_post_parent_id( $attachment_id );
$file_url = wp_get_attachment_url( $attachment_id );
if ( $parent_id ) {
wp_safe_redirect( get_permalink( $parent_id ), 301 );
exit;
}
if ( $file_url ) {
wp_safe_redirect( $file_url, 301 );
exit;
}
} );
Здесь важно не делать редирект наугад. Если файл нужен как отдельная ссылка для скачивания, редирект на родительскую запись может быть неудобен. Для документов и архивов лучше заранее определить, какой URL должен быть каноническим.
Вариант 3: ограничить обход папки uploads в robots.txt
Если цель — уменьшить количество обхода медиафайлов, можно добавить правила в robots.txt. Это не универсальная защита, но для некоторых сайтов помогает сократить мусорный crawl budget.
User-agent: *
Disallow: /wp-content/uploads/private/
Disallow: /wp-content/uploads/tmp/
Не закрывайте весь /wp-content/uploads/ без необходимости. Если у вас в медиа есть изображения, которые должны участвовать в поиске картинок или открываться из материалов, полная блокировка может навредить.
Пошаговая настройка без лишнего риска
- Определите, что именно нужно скрыть: attachment-страницы, отдельные файлы или только часть каталога uploads.
- Проверьте, есть ли в SEO-плагине настройка для attachment-страниц. Если есть — используйте её, а не дублируйте логику кодом.
- Если attachment-страницы не нужны, добавьте
noindexили редирект через код. - Для приватных файлов настройте отдельный каталог и закройте его в
robots.txt, а при необходимости — на уровне сервера. - После правок обновите sitemap и отправьте страницы на переобход в инструментах для вебмастеров.
Проверка результата после внедрения
Проверять нужно не только наличие мета-тега, но и фактическое поведение URL.
- Откройте attachment-страницу в браузере и проверьте исходный код: должен быть
noindex, если вы выбрали этот вариант. - Убедитесь, что редирект ведёт туда, куда вы задумали: на родительскую запись или на файл.
- Проверьте, что изображения и документы всё ещё открываются в контенте сайта.
- Через 1–2 обхода поисковика посмотрите, уменьшается ли число attachment-URL в индексе.
Если используете Google Search Console или Яндекс Вебмастер, отправьте на проверку несколько проблемных URL. Для страниц с noindex важно дождаться повторного обхода, иначе в отчётах они ещё какое-то время будут отображаться как найденные ранее.
Частые ошибки и как их исправить
Закрыли весь uploads в robots.txt
Это частая ошибка после попытки «убрать всё лишнее». В результате поисковик перестаёт обходить и полезные изображения. Исправление простое: закрывайте только приватные подкаталоги или отдельные маски, а не весь каталог целиком.
Поставили noindex, но URL всё равно в индексе
noindex не удаляет страницу мгновенно. Робот должен снова зайти на URL и увидеть мета-тег. Если страница заблокирована в robots.txt раньше, чем робот увидит noindex, удаление может затянуться.
Редирект сломал скачивание файла
Так бывает, если attachment-страница использовалась как промежуточный URL для загрузки документа. В этом случае лучше не редиректить все вложения одинаково, а разделить типы файлов: изображения — на запись, документы — на файл или на отдельную страницу с описанием.
SEO-плагин и код делают одно и то же
Если плагин уже ставит noindex, а вы добавили второй фильтр, результат может быть непредсказуемым. Оставьте один источник правды: либо настройка плагина, либо код в мини-плагине.
Когда лучше использовать плагин, а когда код
Если задача типовая и сайт уже использует SEO-плагин, проще включить штатную настройку. Если же вам нужно точечно управлять вложениями, документами и приватными каталогами, код в мини-плагине даёт больше контроля и меньше зависимостей от интерфейса админки.
Для сайтов, где одновременно нужно чистить дубли, управлять индексированием и не перегружать админку, удобно смотреть в сторону комплексных SEO-инструментов. Например, у Clearfy Pro есть функции для удаления дублей и технической чистки сайта: https://wpshop.ru/plugins/clearfy. Но даже с плагином полезно понимать, что именно он меняет в коде и как это проверить вручную.
Практический чек-лист перед публикацией
- Проверили, какие attachment-URL уже есть в индексе.
- Выбрали один способ управления: плагин или код.
- Убедились, что
noindexстоит только там, где нужно. - Не закрыли полезные медиафайлы в
robots.txtцеликом. - Протестировали редиректы на нескольких типах вложений.
- Отправили важные URL на повторный обход в вебмастерах.
Если после правок в индексе всё ещё остаются старые attachment-страницы, это обычно не ошибка настройки, а вопрос времени и повторного обхода. В такой ситуации помогает не добавлять новые запреты, а проверить, доступен ли URL роботу и видит ли он актуальный noindex или редирект.