Я обычно настраиваю noindex и nofollow не “по шаблону”, а от задачи: что именно нужно скрыть от поиска, что оставить для перехода веса, а что вообще убрать из индекса через canonical, robots.txt или редирект. В 2026 году это особенно чувствуется: поисковики стали умнее, но и ошибки стали дороже — одна лишняя директива может выкинуть из индекса половину полезных страниц.
Что такое noindex и nofollow в 2026 году
Если совсем по-простому, noindex говорит поисковому роботу: “эту страницу не показывай в выдаче”. А nofollow сообщает, что ссылки на странице не стоит учитывать как рекомендацию для передачи веса. Но на деле всё чуть сложнее. Google, Яндекс и другие системы уже давно не воспринимают эти сигналы как прямой приказ в лоб. Это скорее рекомендация, и иногда её интерпретация зависит от общей картины сайта.
Я на практике видел, как владельцы сайтов ставили noindex на странице фильтра, а потом удивлялись, что она всё равно появляется в поиске в виде URL без сниппета. Такое бывает. Особенно если страница уже попала в индекс раньше, на неё ведут внутренние ссылки, а в sitemap она продолжает жить своей жизнью. Поэтому в 2026 году настройка noindex и nofollow — это не одна галочка в CMS, а часть общей SEO-архитектуры.
Если вам нужно сначала привести сайт в порядок, я бы рекомендовал смотреть в сторону SEO-аудита сайта и аудита robots.txt и XML Sitemap. Очень часто проблема не в самом noindex, а в том, что страницы уже доступны из карты сайта, из хлебных крошек или из старых внутренних ссылок.
Когда вообще нужны noindex и nofollow
Честно говоря, я редко ставлю noindex “на всё подряд”. Это плохая идея. У любого сайта есть страницы, которые нужны пользователю, но не нужны в поиске. И наоборот — есть разделы, которые должны индексироваться, но на них лучше ограничить передачу веса или вообще закрыть ссылочную зону от мусора.
На моей практике noindex чаще всего нужен для:
- страниц внутреннего поиска;
- корзины и оформления заказа;
- личного кабинета;
- страниц благодарности после отправки формы;
- пагинации, если она плодит дубликаты;
- технических страниц сортировок и фильтров;
- служебных разделов: тестов, черновиков, staging.
Nofollow я обычно использую для ссылок, которые ведут на бесполезные или рискованные для индексации места: комментарии, пользовательский контент, партнерские ссылки, временные страницы, иногда — в шаблонах навигации, где не хочу раздувать граф связности. Но и тут надо быть аккуратным. Если вы просто поставите rel="nofollow" на все ссылки в меню, можно сделать сайту только хуже.
У одного клиента на WordPress 6.6 и PHP 8.2 был интернет-магазин с кучей фильтров. Они сами руками закрыли половину URL через noindex в плагине SEO, а другую половину оставили открытой. В итоге в индексе Яндекса оказалось 18 000 страниц, из которых полезных было примерно 2 100. Пришлось делать нормальную схему: каноникал, правила в robots.txt, noindex для служебных URL и пересборку sitemap. После этого мусор в индексе начал уходить, а средняя глубина обхода выросла заметно.
Четыре основных способа закрыть страницу от индексации
Если задача техническая, я почти всегда смотрю на комбинацию инструментов. Один только meta robots — это далеко не всегда достаточно. В 2026 году у нас по-прежнему есть четыре базовых способа:
- meta name="robots" в HTML;
- X-Robots-Tag в HTTP-заголовках;
- robots.txt для запрета обхода;
- canonical для указания основной версии страницы.
Meta robots — самый популярный путь. Он удобен, когда надо закрыть одну конкретную страницу или тип шаблона. X-Robots-Tag я люблю за универсальность: можно закрывать не только HTML, но и PDF, изображения, выгрузки, API-ответы. Robots.txt — это про обход, а не про индексацию. Это ключевой момент. Если вы закрыли URL в robots.txt, робот может не увидеть noindex на самой странице, потому что просто не зайдёт внутрь.
Canonical — это вообще отдельная история. Иногда я вообще не ставлю noindex, а просто указываю канонический URL на основную страницу. Например, для сортировок и UTM-меток это часто лучше, чем грубый запрет. Но если URL несет мусорный трафик или технически бесполезен, однозначно стоит закрывать его сильнее.
Если вы только настраиваете базовую SEO-логику сайта, загляните ещё в статью как настроить canonical URL для SEO и в материал настройка robots.txt. Они хорошо дополняют тему noindex/nofollow.
Как поставить noindex и nofollow через HTML
Самый простой вариант — добавить метатег в <head>. Для WordPress это часто делают через плагины типа Yoast SEO, Rank Math или The SEO Framework. В Bitrix обычно правят шаблон или подключаемую область. В Laravel — уже в Blade-шаблонах, и там всё зависит от логики роутинга.
Пример для страницы, которую нужно полностью исключить из индекса и не передавать вес по ссылкам:
<meta name="robots" content="noindex, nofollow">
Если нужно оставить ссылки без передачи веса, но при этом не закрывать саму страницу от индексации, используется такая связка:
<meta name="robots" content="index, nofollow">
А если вам, наоборот, нужно индексировать страницу, но не хотите, чтобы поисковик учитывал внешние ссылки в тексте, можно писать:
<meta name="robots" content="noindex, follow">
Но тут есть нюанс. В 2026 году я бы не советовал надеяться на “follow” как на способ магически сохранить вес. Поисковые системы давно умеют перераспределять вес по своим алгоритмам. И если страница всё равно мусорная, лучше её убрать совсем или перевести на canonical.
У меня был проект на WordPress 6.5 с WooCommerce, где корзина и checkout закрывались именно через метатеги. Для страниц типа /cart/ и /checkout/ это нормально. Но для фильтров на каталоге такой способ оказался слабым: страницы продолжали появляться через внутренние ссылки и динамические параметры. Пришлось дорабатывать шаблоны, а заодно делать доработку сайта под SEO-логику, потому что стандартные настройки плагина уже не спасали.
X-Robots-Tag в заголовках: nginx, Apache и PHP
Вот этот способ я люблю особенно. На деле он выручает, когда HTML-шаблон трогать не хочется или нельзя. Например, если у вас PDF-каталоги, экспорт прайсов, файлы документов или отдельные служебные ответы API. Тогда проще выдать заголовок X-Robots-Tag.
Пример для nginx:
location ~* \.(pdf|doc|docx)$ {
add_header X-Robots-Tag "noindex, nofollow" always;
}
Если нужно поставить заголовок для конкретного пути:
location = /search/ {
add_header X-Robots-Tag "noindex, nofollow" always;
}
Для Apache через .htaccess это выглядит так:
<FilesMatch "\.(pdf|doc|docx)$">
Header set X-Robots-Tag "noindex, nofollow"
</FilesMatch>
И ещё вариант через PHP, когда у вас Laravel или какой-то кастомный фронт:
<?php
header('X-Robots-Tag: noindex, nofollow');
?>
У меня на практике был кейс с Laravel 10 на PHP 8.3, где PDF-отчёты для клиентов генерировались автоматически и попадали в поисковую выдачу. Это было неприятно: в отчётах были персональные данные и финансовые цифры. Закрыть через robots.txt? Нет, этого мало. Я поставил X-Robots-Tag на уровне роутов и веб-сервера, плюс убрал ссылки на эти файлы из публичных списков. После этого проблема исчезла.
Nofollow для ссылок: когда его применять, а когда нет
Nofollow в ссылках — это не декоративный атрибут. Его ставят не потому, что “так SEO-специалист сказал”, а когда нужно ограничить доверие к конкретной ссылке. Самый типичный пример — пользовательские комментарии, форумы, гостевые книги, партнерские ссылки и временные блоки. Но, если честно, многие ставят nofollow слишком широко и потом сами же мешают поисковику понимать структуру сайта.
В 2026 году я бы смотрел на nofollow так:
- внешние рекламные и партнерские ссылки — да, часто стоит;
- ссылки в пользовательском контенте — да, особенно без модерации;
- основное меню сайта — обычно нет;
- хлебные крошки — нет, если это нормальная навигация;
- внутренние ссылки на важные разделы — нет, это плохая идея;
- ссылки в служебных виджетах — зависит от задачи.
На одном корпоративном сайте на Bitrix 24.0 мне попался шаблон, где разработчики зачем-то поставили rel="nofollow" почти на все внутренние ссылки в подвале и сайдбаре. В итоге страницы глубоко лежащих услуг индексировались хуже, чем должны были. После чистки разметки и исправления внутренней перелинковки позиции начали выравниваться. Тут без шуток: nofollow на внутренних ссылках — это часто вредная самодеятельность.
Если у вас похожая ситуация, посмотрите ещё статью как настроить хлебные крошки и материал как настроить H1, H2 и H3. Структура страницы и ссылки тесно связаны. Нельзя лечить одно и ломать другое.
Noindex в robots.txt: почему это плохо работает
Очень частая ошибка — попытка написать noindex в robots.txt и надеяться, что это сработает везде. Грубо говоря, забудьте про это как про основной метод. Robots.txt управляет обходом, а не прямой индексацией. Да, у Яндекса исторически были свои нюансы, но строить стратегию на старых догадках в 2026 году — это сомнительный путь.
Например, можно закрыть в robots.txt такие URL:
User-agent: *
Disallow: /search/
Disallow: /cart/
Disallow: /checkout/
Disallow: /personal/
Но это не означает, что URL исчезнет из индекса автоматически. Если на него есть внешние ссылки или он уже известен поисковикам, он может продолжать всплывать без содержимого, но с самим адресом. Поэтому закрытие через robots.txt нужно сочетать с другими методами: meta robots, canonical, удаление из sitemap, правильные редиректы или отдача 404/410, если страница больше не нужна.
Я отдельно советую прочитать аудит robots.txt и XML Sitemap. Там хорошо видно, как одна неправильная директива может поломать индексацию всего каталога. На одном интернет-магазине с MySQL 8.0 и старым шаблоном фильтров я видел, как Disallow случайно перекрыл ещё и изображения товара. Итог — падение органики по картинкам и просадка CTR. Исправление заняло два дня, но нервы потратили знатно.
Как настраивать noindex и nofollow в WordPress, Bitrix и Laravel
Если сайт на WordPress, я чаще всего иду через SEO-плагин. Yoast SEO и Rank Math умеют задавать noindex для записей, рубрик, меток, архивов автора и т.д. Но я не всегда доверяю только плагину. Если структура сложная, а шаблоны кастомные, лучше продублировать логику в теме или через хуки. Особенно если на сайте десятки тысяч страниц и каждая роль шаблона важна.
В Bitrix подход другой. Там noindex часто ставят на уровне шаблона компонента или через условия в init.php. Иногда хватает правки метатегов в head.php, иногда — отдельной настройки для конкретного инфоблока. На сайте клиента с Bitrix и PHP 8.2 я делал закрытие параметрических страниц каталога, которые формировались фильтром Smart Filter. Простое решение через SEO-плагин там не подошло, пришлось аккуратно вмешиваться в шаблоны и проверять, чтобы не сломать страницы, которые должны индексироваться.
В Laravel всё зависит от архитектуры. Если это Blade, можно делать так:
@if($page->is_technical)
<meta name="robots" content="noindex, nofollow">
@endif
Но я бы советовал не разбрасывать такую логику по шаблонам. Лучше завести понятный флаг в модели или конфиге. Тогда вы не забудете, почему через полгода часть страниц закрыта, а часть — нет. Если проект уже вырос и требует системной переработки, иногда проще заказать проверку сайта и потом уже делать точечную настройку, чем ковырять всё вручную наугад.
Кстати, если вам нужно оценить объём работ, очень выручает калькулятор стоимости сайта. Я сам обычно сначала смотрю на архитектуру, CMS, количество шаблонов и только потом говорю, сколько времени уйдёт на нормальную настройку noindex/nofollow без сюрпризов.
Типичные ошибки при настройке noindex и nofollow
Ошибок тут хватает, и большинство из них я видел не один раз. Самая распространённая — закрыли страницу от индексации, но оставили её в sitemap. Поисковик видит противоречие и не всегда реагирует так, как ожидает владелец сайта. Вторая ошибка — noindex на важной посадочной странице. Это уже совсем грустно. Потом люди удивляются, почему трафик просел после “маленькой правки”.
Третья ошибка — nofollow на всех внутренних ссылках подряд. Это не защита от SEO-проблем, а выстрел себе в ногу. Четвёртая — закрыть страницу в robots.txt и ждать, что она исчезнет из поиска моментально. Не исчезнет. Пятая — забыть про старые внешние ссылки, когда URL уже переехал или удалён. Тут лучше делать 301 или 410, а не пытаться всё лечить noindex-ом.
Если нужны технические правки после подобных ошибок, я обычно сразу смотрю в сторону правильных редиректов 301 и 302 и статьи страницы 403, 404, 410 и 500 для SEO. Иногда правильный ответ — не noindex, а удаление страницы с корректным кодом ответа.
Как проверить, что noindex и nofollow работают правильно
Проверка — это отдельный этап, и я никогда его не пропускаю. В 2026 году удобно смотреть сразу в несколько источников: исходный код страницы, HTTP-заголовки, robots.txt, sitemap, вебмастер-панели и логи сервера. Иногда всё выглядит нормально в браузере, а поисковый робот видит совсем другую картину.
Что я обычно проверяю:
- есть ли meta robots в head;
- не конфликтует ли он с canonical;
- не заблокирована ли страница в robots.txt раньше, чем робот увидит noindex;
- не попала ли страница в XML sitemap;
- нет ли внутренних ссылок с главной или из хлебных крошек;
- какой HTTP-код отдаёт страница;
- есть ли X-Robots-Tag в ответе сервера.
Для быстрой проверки заголовков удобно использовать curl:
curl -I https://example.com/search/
Если всё настроено правильно, вы увидите нужный X-Robots-Tag или хотя бы поймёте, что сервер вообще отдаёт. На проектах с nginx и PHP 8.1 я часто дополнительно смотрю логи доступа и ошибки через настройку логов сайта. Там видно, как роботы обходят страницы после изменений. Это очень полезно, когда нужно понять, почему какой-то раздел всё ещё держится в индексе.
Если сайт крупный, а структура сложная, я бы ещё включил мониторинг и отслеживание изменений индексации. Порой noindex срабатывает не за один день. Особенно если у сайта тысячи URL, старый ссылочный профиль и много дублей.
Практические сценарии: как я делаю это на проектах
На деле у меня почти никогда не бывает ситуации “закрыть одну страницу и всё”. Обычно это набор решений. Например, у интернет-магазина есть каталог, фильтры, корзина, сравнение, личный кабинет, страницы благодарности, поиск, отдельные PDF-инструкции и служебные URL для интеграции с CRM. И вот здесь noindex/nofollow — только часть общей схемы.
Я обычно действую так:
- Сначала определяю, какие страницы должны индексироваться.
- Потом убираю мусор из sitemap.
- Далее настраиваю noindex для служебных страниц.
- Проверяю robots.txt и canonical.
- Смотрю, нет ли внутренних ссылок, которые снова тащат мусор в обход.
- После этого перепроверяю всё в Search Console и панели Яндекса.
Был случай с корпоративным сайтом услуг на WordPress: клиент сам поставил noindex на страницы тегов, а потом маркетолог добавил туда полезные посадочные через автоматическую генерацию контента. В итоге половина тегов реально была мусором, а половина — нормальными SEO-страницами. Пришлось пересобирать структуру. Часть тегов оставили noindex, часть перевели в полноценные категории, а шаблон внутренней перелинковки переписали. Это как раз тот случай, когда нужна не точечная правка, а полноценная доработка сайта под задачу.
Если сайт на WordPress и вы уже устали от конфликтов плагинов, дублей и странной генерации мета-тегов, я бы ещё посмотрел на статью как ускорить WordPress. Иногда проблемы индексации связаны не только с SEO, но и с тем, как сайт вообще отдает страницы, кеширует их и строит шаблоны.
И ещё один момент. В 2026 году noindex и nofollow не надо воспринимать как “хитрость для SEO”. Это обычный технический инструмент. Как HTTP-редирект, как canonical, как HSTS или CSP. Если использовать его аккуратно, сайт становится чище. Если использовать бездумно, можно убить видимость даже у сильного проекта.
Что делать, если страница уже в индексе
Вот тут начинается самая интересная часть. Если страница уже сидит в индексе, одного noindex может быть мало. Нужны дополнительные действия: убрать её из sitemap, закрыть внутренние ссылки, дать роботу увидеть страницу хотя бы один раз с новым meta robots или X-Robots-Tag, а потом дождаться переобхода. Иногда помогает принудительная переиндексация через панели вебмастеров, но это не магия и не кнопка “исправить всё за минуту”.
Если страница больше не нужна вообще, я обычно делаю 410 Gone или 301 на релевантный аналог. Это зависит от ситуации. Для старых карточек товара, которые заменены новыми моделями, лучше 301. Для технических страниц, которые никогда не должны были существовать, часто правильнее 410. И это уже не про noindex, а про нормальную архитектуру сайта.
Кстати, если у вас после таких правок всплывают ошибки и цепочки редиректов, загляните в материал как исправить ошибки на сайте. А если сайт на хостинге ведёт себя нестабильно, очень часто проблема вообще не в SEO, а в серверной части, кешировании или кривом деплое. Тут уже может понадобиться не только настройка силами специалиста, но и полноценная проверка окружения.
Я бы сформулировал так: noindex и nofollow — это не финальная точка, а часть цепочки. Сначала вы определяете, что должно жить в поиске. Потом технически это подтверждаете. И только после этого ждёте, пока поисковые системы обновят картину. Если сделать всё по уму, результат обычно приходит без драм и лишних сюрпризов.
Нужна помощь с настройкой noindex и nofollow?
Мы поможем правильно закрыть страницы от индексации и сохранить SEO-эффект для важных разделов сайта.
