Какие страницы закрывать от индексации и как. Запрет индексации страницы в мета-теге robots

Недавно поделился со мной наблюдением, что у многих сайтов, которые приходят к нам на аудит, часто встречаются одни и те же ошибки. Причем эти ошибки не всегда можно назвать тривиальными – их допускают даже продвинутые веб-мастера. Так возникла идея написать серию статей с инструкциями по отслеживанию и исправлению подобных ошибок. Первый в очереди – гайд по настройке индексации сайта. Передаю слово автору.

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

1. При продвижении сайта их владельцы не задумываются о том, что видит и добавляет в индекс поисковый бот. В этом случае может возникнуть ситуация, когда в индексе больше мусорных страниц, чем продвигаемых, а сами страницы перегружены.

2. Наоборот, владельцы чересчур рьяно взялись за чистку сайта. Вместе с ненужной информацией могут прятаться и важные для продвижения и оценки страниц данные.

Сегодня мы хотим рассмотреть, что же действительно стоит прятать от поисковых роботов и как это лучше делать. Начнём с контента страниц.

Контент

Проблемы, связанные с закрытием контента на сайте:

Страница оценивается поисковыми роботами комплексно, а не только по текстовым показателям. Увлекаясь закрытием различных блоков, часто удаляется и важная для оценки полезности и ранжирования информация.

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

– скрываются от индексации фильтры, форма поиска, сортировка. Наличие таких возможностей у интернет-магазина – важный коммерческий показатель, который лучше показать, а не прятать.
– прячется информация об оплате и доставке. Это делают, чтобы повысить уникальность на товарных карточках. А ведь это тоже информация, которая должна быть на качественной товарной карточке.
– со страниц «вырезается» меню, ухудшая оценку удобства навигации по сайту.

Зачем на сайте закрывают часть контента?
Обычно есть несколько целей:
– сделать на странице акцент на основной контент, убрав из индекса вспомогательную информацию, служебные блоки, меню;
– сделать страницу более уникальной, полезной, убрав дублирующиеся на сайте блоки;
– убрать «лишний» текст, повысить текстовую релевантность страницы.

Всего этого можно достичь без того, чтобы прятать часть контента!
У вас очень большое меню?
Выводите на страницах только те пункты, которые непосредственно относятся к разделу.

Много возможностей выбора в фильтрах?
Выводите в основном коде только популярные. Подгружайте остальные варианты, только если пользователь нажмёт кнопку «показать всё». Да, здесь используются скрипты, но никакого обмана нет – скрипт срабатывает по требованию пользователя. Найти все пункты поисковик сможет, но при оценке они не получат такое же значение, как основной контент страницы.

На странице большой блок с новостями?
Сократите их количество, выводите только заголовки или просто уберите блок новостей, если пользователи редко переходят по ссылкам в нём или на странице мало основного контента.

Поисковые роботы хоть и далеки от идеала, но постоянно совершенствуются. Уже сейчас Google показывает скрытие скриптов от индексирования как ошибку в панели Google Search Console (вкладка «Заблокированные ресурсы»). Не показывать часть контента роботам действительно может быть полезным, но это не метод оптимизации, а, скорее, временные «костыли», которые стоит использовать только при крайней необходимости.

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

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

Тег noindex

У этого метода есть несколько недостатков. Прежде всего этот тег учитывает только Яндекс, поэтому для скрытия текста от Google он бесполезен. Помимо этого, важно понимать, что тег запрещает индексировать и показывать в поисковой выдаче только текст. На остальной контент, например, ссылки, он не распространяется.

Поддержка Яндекса не особо распространяется о том, как работает noindex. Чуть больше информации есть в одном из обсуждений в официальном блоге.

Вопрос пользователя:

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

№1 Noindex не влияет на ранжирование / релевантность страницы вообще

При этом предположении: единственное, что он делает - закрывает часть контента от появления в поисковой выдаче. При этом вся страница рассматривается целиком, включая закрытые блоки, релевантность и сопряженные параметры (уникальность; соответствие и т. п.) для нее вычисляется согласно всему имеющему в коде контенту, даже закрытому.

№2 Noindex влияет на ранжирование и релевантность, так как закрытый в тег контент не оценивается вообще. Соответственно, все наоборот. Страница будет ранжироваться в соответствии с открытым для роботов контентом.»

В каких случаях может быть полезен тег:
– если есть подозрения, что страница понижена в выдаче Яндекса из-за переоптимизации, но при этом занимает ТОПовые позиции по важным фразам в Google. Нужно понимать, что это быстрое и временное решение. Если весь сайт попал под «Баден-Баден», noindex, как неоднократно подтверждали представители Яндекса, не поможет;
– чтобы скрыть общую служебную информацию, которую вы из-за корпоративных ли юридических нормативов должны указывать на странице;
– для корректировки сниппетов в Яндексе, если в них попадает нежелательный контент.

Скрытие контента с помощью AJAX

Это универсальный метод. Он позволяет спрятать контент и от Яндекса, и от Google. Если хотите почистить страницу от размывающего релевантность контента, лучше использовать именно его. Представители ПС такой метод, конечно, не приветствую и рекомендуют, чтобы поисковые роботы видели тот же контент, что и пользователи.
Технология использования AJAX широко распространена и если не заниматься явным клоакингом, санкции за её использование не грозят. Недостаток метода – вам всё-таки придётся закрывать доступ к скриптам, хотя и Яндекс и Google этого не рекомендуют делать.

Страницы сайта

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

Сразу перечислим страницы, которые целесообразно прятать:

– страницы оформления заявок, корзины пользователей;
– результаты поиска по сайту;
– личная информация пользователей;
– страницы результатов сравнения товаров и подобных вспомогательных модулей;
– страницы, генерируемые фильтрами поиска и сортировкой;
– страницы административной части сайта;
– версии для печати.

Рассмотрим способы, которыми можно закрыть страницы от индексации.

Закрыть в robots.txt

Это не самый лучший метод.

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

Во-вторых, запрет в файле robots не является гарантией того, что страница не попадёт в индекс.

Вот что Google пишет об этом в своей справке:

Метатег noindex

Чтобы гарантированно исключить страницы из индекса, лучше использовать этот метатег.

Ниже приведём вариант метатега, который понимают оба поисковика:

Важный момент!

Чтобы Googlebot увидел метатег noindex, нужно открыть доступ к страницам, закрытым в файле robots.txt. Если этого не сделать, робот может просто не зайти на эти страницы.

Заголовки X-Robots-Tag

Существенное преимущество такого метода в том, что запрет можно размещать не только в коде страницы, но и через корневой файл.htaccess.

Этот метод не очень распространён в Рунете. Полагаем, основная причина такой ситуации в том, что Яндекс этот метод долгое время не поддерживал.
В этом году сотрудники Яндекса написали, что метод теперь поддерживается.

Ответ поддержки подробным не назовёшь))). Прежде чем переходить на запрет индексации, используя X-Robots-Tag, лучше убедиться в работе этого способа под Яндекс. Свои эксперименты на эту тему мы пока не ставили, но, возможно, сделаем в ближайшее время.

Защита с помощью пароля

Если нужно скрыть весь сайт, например, тестовую версию, также рекомендуем использовать именно этот метод. Пожалуй, единственный недостаток – могут возникнуть сложности в случае необходимости просканировать домен, скрытый под паролем.

Исключить появление мусорных страниц c помощью AJAX

Речь о том, чтобы не просто запретить индексацию страниц, генерируемых фильтрами, сортировкой и т. д., а вообще не создавать подобные страницы на сайте.

Например, если пользователь выбрал в фильтре поиска набор параметров, под которые вы не создавали отдельную страницу, изменения в товарах, отображаемых на странице, происходит без изменения самого URL.

Сложность этого метода в том, что обычно его нельзя применить сразу для всех случаев. Часть формируемых страниц используется для продвижения.

Например, страницы фильтров. Для «холодильник + Samsung + белый» нам нужна страница, а для «холодильник + Samsung + белый + двухкамерный + no frost» – уже нет.

Поэтому нужно делать инструмент, предполагающий создание исключений. Это усложняет задачу программистов.

Использовать методы запрета индексации от поисковых алгоритмов

«Параметры URL» в Google Search Console

Этот инструмент позволяет указать, как идентифицировать появление в URL страниц новых параметров.

Директива Clean-param в robots.txt

В Яндексе аналогичный запрет для параметров URL можно прописать, используя директиву Clean-param.
Почитать об этом можно .

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

Инструменты точечного удаления страниц из индекса Яндекса и Google

Если возникла ситуация, когда нужно срочно удалить информацию из индекса, не дожидаясь, пока ваш запрет увидят поисковые работы, можно использовать инструменты из панели Яндекс.Вебмастера и Google Search Console.

В Яндексе это «Удалить URL»:

В Google Search Console «Удалить URL-адрес»:

Внутренние ссылки

Внутренние ссылки закрываются от индексации для перераспределения внутренних весов на основные продвигаемые страницы. Но дело в том, что:
– такое перераспределение может плохо отразиться на общих связях между страницами;
– ссылки из шаблонных сквозных блоков обычно имеют меньший вес или могут вообще не учитываться.

Рассмотрим варианты, которые используются для скрытия ссылок:

Тег noindex

Для скрытия ссылок этот тег бесполезен. Он распространяется только на текст.

Атрибут rel=”nofollow”

Сейчас атрибут не позволяет сохранять вес на странице. При использовании rel=”nofollow” вес просто теряется. Само по себе использование тега для внутренних ссылок выглядит не особо логично.

Скрытие ссылок с помощью скриптов

Это фактически единственный рабочий метод, с помощью которого можно спрятать ссылки от поисковых систем. Можно использовать Аjax и подгружать блоки ссылок уже после загрузки страницы или добавлять ссылки, подменяя скриптом тег на . При этом важно учитывать, что поисковые алгоритмы умеют распознавать скрипты.

Как и в случае с контентом – это «костыль», который иногда может решить проблему. Если вы не уверены, что получите положительный эффект от спрятанного блока ссылок, лучше такие методы не использовать.

Заключение

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

Убирая со страницы часть контента, не забывайте, что для ранжирования важны не только текстовые критерии, но и полнота информации, коммерческие факторы.

Примерно аналогичная ситуация и с внутренними ссылками. Да, иногда это может быть полезно, но искусственное перераспределение ссылочной массы на сайте – метод спорный. Гораздо безопаснее и надёжнее будет просто отказаться от ссылок, в которых вы не уверены.

Со страницами сайта всё более однозначно. Важно следить за тем, чтобы мусорные, малополезные страницы не попадали в индекс. Для этого есть много методов, которые мы собрали и описали в этой статье.

Вы всегда можете взять у нас консультацию по техническим аспектам оптимизации, или заказать продвижение под ключ, куда входит .

Большинство роботов хорошо спроектированы и не создают каких-либо проблем для владельцев сайтов. Но если бот написан дилетантом или «что-то пошло не так», то он может создавать существенную нагрузку на сайт, который он обходит. Кстати, пауки вовсе на заходят на сервер подобно вирусам — они просто запрашивают нужные им страницы удаленно (по сути это аналоги браузеров, но без функции просмотра страниц).

Robots.txt — директива user-agent и боты поисковых систем

Роботс.тхт имеет совсем не сложный синтаксис, который очень подробно описан, например, в хелпе яндекса и хелпе Гугла . Обычно в нем указывается, для какого поискового бота предназначены описанные ниже директивы: имя бота ("User-agent "), разрешающие ("Allow ") и запрещающие ("Disallow "), а также еще активно используется "Sitemap" для указания поисковикам, где именно находится файл карты.

Стандарт создавался довольно давно и что-то было добавлено уже позже. Есть директивы и правила оформления, которые будут понятны только роботами определенных поисковых систем. В рунете интерес представляют в основном только Яндекс и Гугл, а значит именно с их хелпами по составлению robots.txt следует ознакомиться особо детально (ссылки я привел в предыдущем абзаце).

Например, раньше для поисковой системы Яндекс было полезным указать, вашего вебпроекта является главным в специальной директиве "Host", которую понимает только этот поисковик (ну, еще и Майл.ру, ибо у них поиск от Яндекса). Правда, в начале 2018 Яндекс все же отменил Host и теперь ее функции как и у других поисковиков выполняет 301-редирект.

Если даже у вашего ресурса нет зеркал, то полезно будет указать, какой из вариантов написания является главным - .

Теперь поговорим немного о синтаксисе этого файла. Директивы в robots.txt имеют следующий вид:

<поле>:<пробел><значение><пробел> <поле>:<пробел><значение><пробел>

Правильный код должен содержать хотя бы одну директиву «Disallow» после каждой записи «User-agent». Пустой файл предполагает разрешение на индексирование всего сайта.

User-agent

Директива «User-agent» должна содержать название поискового бота. При помощи нее можно настроить правила поведения для каждого конкретного поисковика (например, создать запрет индексации отдельной папки только для Яндекса). Пример написания «User-agent», адресованной всем ботам зашедшим на ваш ресурс, выглядит так:

User-agent: *

Если вы хотите в «User-agent» задать определенные условия только для какого-то одного бота, например, Яндекса, то нужно написать так:

User-agent: Yandex

Название роботов поисковых систем и их роль в файле robots.txt

Бот каждой поисковой системы имеет своё название (например, для рамблера это StackRambler). Здесь я приведу список самых известных из них:

Google http://www.google.com Googlebot Яндекс http://www.ya.ru Yandex Бинг http://www.bing.com/ bingbot

У крупных поисковых систем иногда, кроме основных ботов , имеются также отдельные экземпляры для индексации блогов, новостей, изображений и т.д. Много информации по разновидностям ботов вы можете почерпнуть (для Яндекса) и (для Google).

Как быть в этом случае? Если нужно написать правило запрета индексации, которое должны выполнить все типы роботов Гугла, то используйте название Googlebot и все остальные пауки этого поисковика тоже послушаются. Однако, можно запрет давать только, например, на индексацию картинок, указав в качестве User-agent бота Googlebot-Image. Сейчас это не очень понятно, но на примерах, я думаю, будет проще.

Примеры использования директив Disallow и Allow в роботс.тхт

Приведу несколько простых примеров использования директив с объяснением его действий.

Приведенный ниже код разрешает всем ботам (на это указывает звездочка в User-agent) проводить индексацию всего содержимого без каких-либо исключений. Это задается пустой директивой Disallow . User-agent: * Disallow:
Следующий код, напротив, полностью запрещает всем поисковикам добавлять в индекс страницы этого ресурса. Устанавливает это Disallow с «/» в поле значения. User-agent: * Disallow: /
В этом случае будет запрещаться всем ботам просматривать содержимое каталога /image/ (http://mysite.ru/image/ — абсолютный путь к этому каталогу) User-agent: * Disallow: /image/
Чтобы заблокировать один файл, достаточно будет прописать его абсолютный путь до него (читайте ): User-agent: * Disallow: /katalog1//katalog2/private_file.html
Забегая чуть вперед скажу, что проще использовать символ звездочки (*), чтобы не писать полный путь:
Disallow: /*private_file.html
В приведенном ниже примере будут запрещены директория «image», а также все файлы и директории, начинающиеся с символов «image», т. е. файлы: «image.htm», «images.htm», каталоги: «image», «images1», «image34» и т. д.): User-agent: * Disallow: /image Дело в том, что по умолчанию в конце записи подразумевается звездочка, которая заменяет любые символы, в том числе и их отсутствие. Читайте об этом ниже.
С помощью директивы Allow мы разрешаем доступ. Хорошо дополняет Disallow. Например, таким вот условием поисковому роботу Яндекса мы запрещаем выкачивать (индексировать) все, кроме вебстраниц, адрес которых начинается с /cgi-bin: User-agent: Yandex Allow: /cgi-bin Disallow: /
Ну, или такой вот очевидный пример использования связки Allow и Disallow:
User-agent: * Disallow: /catalog Allow: /catalog/auto
При описании путей для директив Allow-Disallow можно использовать символы "*" и "$" , задавая, таким образом, определенные логические выражения.
1. Символ "*"(звездочка) означает любую (в том числе пустую) последовательность символов. Следующий пример запрещает всем поисковикам индексацию файлов с расширение «.php»: User-agent: * Disallow: *.php$
2. Зачем нужен на конце знак $ (доллара) ? Дело в том, что по логике составления файла robots.txt, в конце каждой директивы как бы дописывается умолчательная звездочка (ее нет, но она как бы есть). Например мы пишем: Disallow: /images
  Подразумевая, что это то же самое, что:
  Disallow: /images*
  Т.е. это правило запрещает индексацию всех файлов (вебстраниц, картинок и других типов файлов) адрес которых начинается с /images, а дальше следует все что угодно (см. пример выше). Так вот, символ $ просто отменяет эту умолчательную (непроставляемую) звездочку на конце. Например:
  Disallow: /images$
  Запрещает только индексацию файла /images, но не /images.html или /images/primer.html. Ну, а в первом примере мы запретили индексацию только файлов оканчивающихся на.php (имеющих такое расширение), чтобы ничего лишнего не зацепить:
  Disallow: *.php$

Во многих движках пользователи (человеко-понятные Урлы), в то время как Урлы, генерируемые системой, имеют знак вопроса "?" в адресе. Этим можно воспользоваться и написать такое правило в robots.txt: User-agent: * Disallow: /*?

Звездочка после вопросительного знака напрашивается, но она, как мы с вами выяснили чуть выше, уже подразумевается на конце. Таким образом мы запретим индексацию страниц поиска и прочих служебных страниц создаваемых движком, до которых может дотянуться поисковый робот. Лишним не будет, ибо знак вопроса чаще всего CMS используют как идентификатор сеанса, что может приводить к попаданию в индекс дублей страниц.

Директивы Sitemap и Host (для Яндекса) в Robots.txt

Во избежании возникновения неприятных проблем с зеркалами сайта, раньше рекомендовалось добавлять в robots.txt директиву Host, которая указывал боту Yandex на главное зеркало.

Директива Host — указывает главное зеркало сайта для Яндекса

Например, раньше, если вы еще не перешли на защищенный протокол , указывать в Host нужно было не полный Урл, а доменное имя (без http://, т.е..ru). Если же уже перешли на https, то указывать нужно будет полный Урл (типа https://myhost.ru).

Замечательный инструмент для борьбы с дублями контента — поисковик просто не будет индексировать страницу, если в Canonical прописан другой урл. Например, для такой страницы моего блога (страницы с пагинацией) Canonical указывает на https://сайт и никаких проблем с дублированием тайтлов возникнуть не должно.

Но это я отвлекся...
Если ваш проект создан на основе какого-либо движка, то дублирование контента будет иметь место с высокой вероятностью, а значит нужно с ним бороться, в том числе и с помощью запрета в robots.txt, а особенно в мета-теге, ибо в первом случае Google запрет может и проигнорировать, а вот на метатег наплевать он уже не сможет (так воспитан).
Например, в WordPress страницы с очень похожим содержимым могут попасть в индекс поисковиков, если разрешена индексация и содержимого рубрик, и содержимого архива тегов, и содержимого временных архивов. Но если с помощью описанного выше мета-тега Robots создать запрет для архива тегов и временного архива (можно теги оставить, а запретить индексацию содержимого рубрик), то дублирования контента не возникнет. Как это сделать описано по ссылке приведенной чуть выше (на плагин ОлИнСеоПак)
Подводя итог скажу, что файл Роботс предназначен для задания глобальных правил запрета доступа в целые директории сайта, либо в файлы и папки, в названии которых присутствуют заданные символы (по маске). Примеры задания таких запретов вы можете посмотреть чуть выше.
Теперь давайте рассмотрим конкретные примеры роботса, предназначенного для разных движков — Joomla, WordPress и SMF. Естественно, что все три варианта, созданные для разных CMS, будут существенно (если не сказать кардинально) отличаться друг от друга. Правда, у всех у них будет один общий момент, и момент этот связан с поисковой системой Яндекс.
Т.к. в рунете Яндекс имеет достаточно большой вес, то нужно учитывать все нюансы его работы, и тут нам поможет директива Host . Она в явной форме укажет этому поисковику главное зеркало вашего сайта.
Для нее советуют использовать отдельный блог User-agent, предназначенный только для Яндекса (User-agent: Yandex). Это связано с тем, что остальные поисковые системы могут не понимать Host и, соответственно, ее включение в запись User-agent, предназначенную для всех поисковиков (User-agent: *), может привести к негативным последствиям и неправильной индексации.
Как обстоит дело на самом деле — сказать трудно, ибо алгоритмы работы поиска — это вещь в себе, поэтому лучше сделать так, как советуют. Но в этом случае придется продублировать в директиве User-agent: Yandex все те правила, что мы задали User-agent: * . Если вы оставите User-agent: Yandex с пустым Disallow: , то таким образом вы разрешите Яндексу заходить куда угодно и тащить все подряд в индекс.
Robots для WordPress
Не буду приводить пример файла, который рекомендуют разработчики. Вы и сами можете его посмотреть. Многие блогеры вообще не ограничивают ботов Яндекса и Гугла в их прогулках по содержимому движка WordPress. Чаще всего в блогах можно встретить роботс, автоматически заполненный плагином .
Но, по-моему, все-таки следует помочь поиску в нелегком деле отсеивания зерен от плевел. Во-первых, на индексацию этого мусора уйдет много времени у ботов Яндекса и Гугла, и может совсем не остаться времени для добавления в индекс вебстраниц с вашими новыми статьями. Во-вторых, боты, лазящие по мусорным файлам движка, будут создавать дополнительную нагрузку на сервер вашего хоста, что не есть хорошо.
Мой вариант этого файла вы можете сами посмотреть. Он старый, давно не менялся, но я стараюсь следовать принципу «не чини то, что не ломалось», а вам уже решать: использовать его, сделать свой или еще у кого-то подсмотреть. У меня там еще запрет индексации страниц с пагинацией был прописан до недавнего времени (Disallow: */page/), но недавно я его убрал, понадеясь на Canonical, о котором писал выше.
А вообще, единственно правильного файла для WordPress, наверное, не существует. Можно, кончено же, реализовать в нем любые предпосылки, но кто сказал, что они будут правильными. Вариантов идеальных robots.txt в сети много.
Приведу две крайности :
можно найти мегафайлище с подробными пояснениями (символом # отделяются комментарии, которые в реальном файле лучше будет удалить): User-agent: * # общие правила для роботов, кроме Яндекса и Google, # т.к. для них правила ниже Disallow: /cgi-bin # папка на хостинге Disallow: /? # все параметры запроса на главной Disallow: /wp- # все файлы WP: /wp-json/, /wp-includes, /wp-content/plugins Disallow: /wp/ # если есть подкаталог /wp/, где установлена CMS (если нет, # правило можно удалить) Disallow: *?s= # поиск Disallow: *&s= # поиск Disallow: /search/ # поиск Disallow: /author/ # архив автора Disallow: /users/ # архив авторов Disallow: */trackback # трекбеки, уведомления в комментариях о появлении открытой # ссылки на статью Disallow: */feed # все фиды Disallow: */rss # rss фид Disallow: */embed # все встраивания Disallow: */wlwmanifest.xml # xml-файл манифеста Windows Live Writer (если не используете, # правило можно удалить) Disallow: /xmlrpc.php # файл WordPress API Disallow: *utm= # ссылки с utm-метками Disallow: *openstat= # ссылки с метками openstat Allow: */uploads # открываем папку с файлами uploads User-agent: GoogleBot # правила для Google (комментарии не дублирую) Disallow: /cgi-bin Disallow: /? Disallow: /wp- Disallow: /wp/ Disallow: *?s= Disallow: *&s= Disallow: /search/ Disallow: /author/ Disallow: /users/ Disallow: */trackback Disallow: */feed Disallow: */rss Disallow: */embed Disallow: */wlwmanifest.xml Disallow: /xmlrpc.php Disallow: *utm= Disallow: *openstat= Allow: */uploads Allow: /*/*.js # открываем js-скрипты внутри /wp- (/*/ - для приоритета) Allow: /*/*.css # открываем css-файлы внутри /wp- (/*/ - для приоритета) Allow: /wp-*.png # картинки в плагинах, cache папке и т.д. Allow: /wp-*.jpg # картинки в плагинах, cache папке и т.д. Allow: /wp-*.jpeg # картинки в плагинах, cache папке и т.д. Allow: /wp-*.gif # картинки в плагинах, cache папке и т.д. Allow: /wp-admin/admin-ajax.php # используется плагинами, чтобы не блокировать JS и CSS User-agent: Yandex # правила для Яндекса (комментарии не дублирую) Disallow: /cgi-bin Disallow: /? Disallow: /wp- Disallow: /wp/ Disallow: *?s= Disallow: *&s= Disallow: /search/ Disallow: /author/ Disallow: /users/ Disallow: */trackback Disallow: */feed Disallow: */rss Disallow: */embed Disallow: */wlwmanifest.xml Disallow: /xmlrpc.php Allow: */uploads Allow: /*/*.js Allow: /*/*.css Allow: /wp-*.png Allow: /wp-*.jpg Allow: /wp-*.jpeg Allow: /wp-*.gif Allow: /wp-admin/admin-ajax.php Clean-Param: utm_source&utm_medium&utm_campaign # Яндекс рекомендует не закрывать # от индексирования, а удалять параметры меток, # Google такие правила не поддерживает Clean-Param: openstat # аналогично # Укажите один или несколько файлов Sitemap (дублировать для каждого User-agent # не нужно). Google XML Sitemap создает 2 карты сайта, как в примере ниже. Sitemap: http://site.ru/sitemap.xml Sitemap: http://site.ru/sitemap.xml.gz # Укажите главное зеркало сайта, как в примере ниже (с WWW / без WWW, если HTTPS # то пишем протокол, если нужно указать порт, указываем). Команду Host понимает # Яндекс и Mail.RU, Google не учитывает. Host: www.site.ru
А вот можно взять на вооружение пример минимализма: User-agent: * Disallow: /wp-admin/ Allow: /wp-admin/admin-ajax.php Host: https://site.ru Sitemap: https://site.ru/sitemap.xml

Истина, наверное, лежит где-то посредине. Еще не забудьте прописать мета-тег Robots для «лишних» страниц, например, с помощью чудесного плагина — . Он же поможет и Canonical настроить.
Правильный robots.txt для Joomla
User-agent: * Disallow: /administrator/ Disallow: /bin/ Disallow: /cache/ Disallow: /cli/ Disallow: /components/ Disallow: /includes/ Disallow: /installation/ Disallow: /language/ Disallow: /layouts/ Disallow: /libraries/ Disallow: /logs/ Disallow: /modules/ Disallow: /plugins/ Disallow: /tmp/
В принципе, здесь практически все учтено и работает он хорошо. Единственное, в него следует добавить отдельное правило User-agent: Yandex для вставки директивы Host, определяющей главное зеркало для Яндекса, а так же указать путь к файлу Sitemap.
Поэтому в окончательном виде правильный robots для Joomla, по-моему мнению, должен выглядеть так:
User-agent: Yandex Disallow: /administrator/ Disallow: /cache/ Disallow: /includes/ Disallow: /installation/ Disallow: /language/ Disallow: /libraries/ Disallow: /modules/ Disallow: /plugins/ Disallow: /tmp/ Disallow: /layouts/ Disallow: /cli/ Disallow: /bin/ Disallow: /logs/ Disallow: /components/ Disallow: /component/ Disallow: /component/tags* Disallow: /*mailto/ Disallow: /*.pdf Disallow: /*% Disallow: /index.php Host: vash_sait.ru (или www.vash_sait.ru) User-agent: * Allow: /*.css?*$ Allow: /*.js?*$ Allow: /*.jpg?*$ Allow: /*.png?*$ Disallow: /administrator/ Disallow: /cache/ Disallow: /includes/ Disallow: /installation/ Disallow: /language/ Disallow: /libraries/ Disallow: /modules/ Disallow: /plugins/ Disallow: /tmp/ Disallow: /layouts/ Disallow: /cli/ Disallow: /bin/ Disallow: /logs/ Disallow: /components/ Disallow: /component/ Disallow: /*mailto/ Disallow: /*.pdf Disallow: /*% Disallow: /index.php Sitemap: http://путь к вашей карте XML формата
Да, еще обратите внимание, что во втором варианте есть директивы Allow, разрешающие индексацию стилей, скриптов и картинок . Написано это специально для Гугла, ибо его Googlebot иногда ругается, что в роботсе запрещена индексация этих файлов, например, из папки с используемой темой оформления. Даже грозится за это понижать в ранжировании.
Поэтому заранее все это дело разрешаем индексировать с помощью Allow. То же самое, кстати, и в примере файла для Вордпресс было.

Удачи вам! До скорых встреч на страницах блога сайт
посмотреть еще ролики можно перейдя на
");">
Вам может быть интересно
Домены с www и без него - история появления, использование 301 редиректа для их склеивания
Зеркала, дубли страниц и Url адреса - аудит вашего сайта или что может быть причиной краха при его SEO продвижении

У CMS Joomla есть один недостаток, это дубли адресов страниц. Дубли — это когда одна статья доступна по двум адресам.

Например:

Подробнее и как убрать из индексации дубли страниц в Joomla читаем под катом.

У CMS Joomla есть один недостаток, это дубли адресов страниц. Дубли — это когда одна статья доступна по двум адресам. Например:

http://сайт/dizayn/ikonki-sotsial-noy-seti-vkonrtakte.html
index.php?option=com_content&view=article&id=99:vkontakteicons&catid=5:design&Itemid=5

Как появляются дубли страниц? Очень просто, на примере выше мы видим две ссылки на один материал. Первая ссылка - красивая и человекопонятная (ЧПУ ссылка), создана компонентом JoomSEF который преобразует все ссылки на сайте в такой красивый, удобочитаемый вид. Вторая ссылка - внутренная системная ссылка Джумлы, и если бы компонент Artio JoomSef не был установлен, то все ссылки на сайте были бы как вторая — непонятные и некрасивые. Теперь от том насколько это страшно и как бороться с дублями.

Насколько дубли вредны для сайта. Я бы не называл его очень большим недостатком, так как по моему мнению, поисковые машины не должны сильно банить и пессимизировать сайт за такие дубли, так как дубли эти делаются не специально, а являются частью CMS системы. Причем, замечу, очень популярной системы, на которой сделаны миллионы сайтов, а значит поисковики научились понимать такую «особенность». Но все таки, если есть возможность и желание, то лучше такие дубли позакрывать от глаз большого брата.

Как бороться с дублями в Joomla и других cms

1) Два дубля одной страницы, запрет в robots.txt

К примеру, в индекс поисковика попадают следующие два адреса одной страницы:

http://site.ru/страница.html?replytocom=371
http://site.ru/страница.html?iframe=true&width=900&height=450

Для закрытия таких дублей в robots.txt нужно добавить:

Disallow: /*?*
Disallow: /*?

Этим действием мы закрыли от индексации все ссылки сайта со знаком «?». Такой вариант подходит для сайтов где включена работа ЧПУ, и нормальные ссылки не имеют в себе знаков вопроса — «?».

2. Использовать тег rel=”canonical”

Допустим на одну страницу идет две ссылки с разными адресами. Поисковикам Google и Yahoo моджно указать на то какой адрес на страницу является главным. Для этого в теге надо прописать тег rel=”canonical”. Яндекс эту опцию не поддерживает.

Для Joomla для постановки тега rel=”canonical” я нашел два расширения, под названием 1)plg_canonical_v1.2; и 2) 098_mod_canonical_1.1.0. Можете их потестировать. Но я бы поступил другим образом и просто запретил к индексации все ссылки имеющие в себе знак вопроса, как показал в примере выше.

3. Запретить индексирование в robots.txt Joomla дублей (страницы с окончанием index.php) и других не нужных страниц.

Так как все дубли страниц в Joomla начинаются с index.php, то можно запретить их все к индексации одной строкой в robots.txt - Disallow: /index.php. Также этим самым мы запретим дубль главной страницы, когда она доступна по адресу «http://site.ru/» и «http://site.ru/index.php».

4. Cклейка домена с www и без при помощи 301 редиректа (переадресаци).

Для склейки домена с www и без нужно сделать переадресацию – 301 редирект. Для этого в файле.htaccess прописываем:

RewriteEngine on

Если вам нужно наоборот сделать редирект с http://site.ru на www.site.ru, то запись будет выглядеть так:

RewriteEngine On
RewriteCond %{HTTP_HOST} ^site.ru
RewriteRule (.*) http://www.site.ru/$1

5. Директива Host дает определение основного домена с www или без для Яндекса.

Для тех вебмастеров, которые только что создали свой сайт, не спешите выполнять те действия, которые я описал в этом пункте, сначала нужно составить правильный robots.txt прописать директиву Host, этим вы определите основной домен в глазах яндекса.

Это будет выглядеть следующим образом:

User-Agent: Yandex
Host: site.ru

Директиву Host понимает только Яндекс. Google ее не понимает.

6. Joomla дубли страниц склеиваем в файле.htaccess.

Очень часто главная страница сайта на joomla бывает доступна по адресу http://site.ru/index.html или http://site.ru/index.рhp, http://site.ru.html , то есть это дубли главной страницы (http://site.ru), конечно от них можно избавиться путем закрытия их в robots.txt, но лучше это сделать при помощи.htaccess. Для этого в этот файл добавить следующее:

Используйте этот код если вам нужно избавиться от дубля с index.рhp, не забудьте в коде вместо http://ваш сайт.ru/, поставить свой домен.

Чтобы проверить получилась у вас или нет, просто введите в браузер адрес дубля (http://site.ru/index.рhp), если получилось, то вас перебросит на страницу http://site.ru, также будет происходить и с поисковыми ботами и они не будут видеть эти дубли.

И по аналогии склеиваем Joomla дубли с другими приставками к URI вашей главной страницы, просто отредактируйте код который я привел выше.

7. Указать sitemap в robots.txt

Хоть это и не относится к дублям, но раз уж пошла такая движуха, то заодно я рекомендую в файле robots.txt указать путь к карте сайта в xml формате для поисковиков:

Sitemap: http://домен.ru/sitemap.xml.gz
Sitemap: http://домен.ru/sitemap.xml

Итог

Подвоя итог вышесказанному, для Joomla я бы прописал вот такие строки в robots.txt:

Disallow: /index.php
Указать основной хост для Яндекса
User-Agent: Yandex
Host: site.ru

И вот такие строки в.htaccess

# Склейка домена с www и без
RewriteEngine on
RewriteCond %{HTTP_HOST} ^www.site.ru
RewriteRule ^(.*)$ http://site.ru/$1
# Склейка дублей страниц
RewriteCond %{THE_REQUEST} ^{3,9} /index.php HTTP/
RewriteRule ^index.php$ http://ваш сайт.ru/

Если вы используете другие способы устранения дублей, знаете как усовершенствовать описанное выше или просто Вам есть что сказать по этой теме - пишите, жду в комментариях.

Как запретить индексацию определенных страниц?

Разрешения и запрещения на индексацию берутся всеми поисковыми системами из файла robots.txt , находящегося в корневом каталоге сервера. Запрет на индексацию ряда страниц может появиться, например, из соображений секретности или из желания не индексировать одинаковые документы в разных кодировках. Чем меньше ваш сервер, тем быстрее робот его обойдет. Поэтому запретите в файле robots.txt все документы, которые не имеет смысла индексировать (например, файлы статистики или списки файлов в директориях). Обратите особое внимание на CGI или ISAPI скрипты - наш робот индексирует их наравне с другими документами.

В простейшем виде (разрешено все, кроме директории скриптов) файл robots.txt выглядит следующим образом:

User-Agent: *
Disallow: /cgi-bin/

Детальное описание спецификации файла можно прочитать на странице: « ».

При написании robots.txt обратите внимание на следующие часто встречающиеся ошибки:

1. Строка с полем User-Agent является обязательной и должна предшествовать строкам с полем Disallow . Так, приведенный ниже файл robots.txt не запрещает ничего:

Disallow: /cgi-bin
Disallow: /forum

2. Пустые строки в файле robots.txt являются значимыми, они разделяют записи, относящиеся к разным роботам. Например, в следующем фрагменте файла robots.txt строка Disallow: /forum игнорируется, поскольку перед ней нет строки с полем User-Agent.

User-Agent: *
Disallow: /cgi-bin
Disallow: /forum

3. Строка с полем Disallow может запретить индексирование документов только с одним префиксом. Для запрета нескольких префиксов нужно написать несколько строк. Например, нижеприведенный файл запрещает индексирование документов, начинающихся с “/cgi-bin /forum ”, которых, скорее всего, не существует (а не документов с префиксами /cgi-bin и /forum ).

User-Agent: *
Disallow: /cgi-bin /forum

4. В строках с полем Disallow записываются не абсолютные, а относительные префиксы. То есть файл

User-Agent: *
Disallow: www.myhost.ru/cgi-bin

запрещает, например, индексирование документа http://www.myhost.ru/www.myhost.ru/cgi-bin/counter.cgi , но НЕ запрещает индексирование документа http://www.myhost.ru/cgi-bin/counter.cgi .

5. В строках с полем Disallow указываются именно префиксы, а не что-нибудь еще. Так, файл:

User-Agent: *
Disallow: *

запрещает индексирование документов, начинающихся с символа «* » (которых в природе не существует), и сильно отличается от файла:

User-Agent: *
Disallow: /

который запрещает индексирование всего сайта.

Если вы не можете создать/изменить файл robots.txt , то еще не все потеряно — достаточно добавить дополнительный тег в HTML-код вашей страницы (внутри тега ):

Тогда данный документ также не будет проиндексирован.

Вы также можете использовать тэг

Он означает, что робот поисковой машины не должен идти по ссылкам с данной страницы.

Для одновременного запрета индексирования страницы и обхода ссылок с нее используется тэг

Как запретить индексацию определенных частей текста?

Чтобы запретить индексирование определенных фрагментов текста в документе, пометьте их тегами

Внимание! Тег NOINDEX не должен нарушать вложенность других тегов. Если указать следующую ошибочную конструкцию:

…код1…

…код2…

…код3…

запрет на индексирование будет включать не только «код1» и «код2», но и «код3».

Как выбрать главный виртуальный хост из нескольких зеркал?

Если ваш сайт находится на одном сервере (одном IP), но виден во внешнем мире под разными именами (зеркала, разные виртуальные хосты), Яндекс рекомендует вам выбрать то имя, под которым вы хотите быть проиндексированы. В противном случае Яндекс выберет главное зеркало самостоятельно, а остальные имена будут запрещены к индексации.

Для того, чтобы индексировалось выбранное вами зеркало, достаточно запретить индексацию всех остальных зеркал при помощи . Это можно сделать, используя нестандартное расширение robots.txt — директиву Host , в качестве ее параметра указав имя основного зеркала. Если www.glavnoye-zerkalo.ru — основное зеркало, то robots.txt должен выглядеть примерно так:

User-Agent: *
Disallow: /forum
Disallow: /cgi-bin
Host: www.glavnoye-zerkalo.ru

В целях совместимости с роботами, которые не полностью следуют стандарту при обработке robots.txt, директиву Host необходимо добавлять в группе, начинающейся с записи User-Agent, непосредственно после записей Disallow.

Аргументом директивы Host является доменное имя с номером порта (80 по умолчанию), отделенным двоеточием. Если какой-либо сайт не указан в качестве аргумента для Host , для него подразумевается наличие директивы Disallow: / , т.е. полный запрет индексации (при наличии в группе хотя бы одной корректной директивы Host ). Таким образом, файлы robots.txt вида

User-Agent: *
Host: www.myhost.ru

User-Agent: *
Host: www.myhost.ru:80

эквивалентны и запрещают индексирование как www.otherhost.ru , так и www.myhost.ru:8080 .

Параметр директивы Host обязан состоять из одного корректного имени хоста (т.е. соответствующего RFC 952 и не являющегося IP-адресом) и допустимого номера порта. Некорректно составленные строчки Host игнорируются .

# Примеры игнорируемых директив Host
Host: www.myhost- .ru
Host: www.- myhost.ru
Host: www.myhost.ru:0
Host: www.my_ host.ru
Host: . my-host.ru:8000
Host: my-host.ru.
Host: my.. host.ru
Host: www.myhost.ru/
Host: www.myhost.ru:8080/
Host: http:// www.myhost.ru
Host: www.mysi.te
Host: 213.180.194.129
Host: www.firsthost.ru, www.secondhost.ru
Host: www.firsthost.ru www.secondhost.ru

Если у вас сервер Apache, то можно вместо использования директивы Host задать robots.txt с использованием директив SSI:

User-Agent: *
Disallow: /

В этом файле роботу запрещен обход всех хостов, кроме www.главное_имя.ru

Как включать SSI, можно прочесть в документации по вашему серверу или обратиться к вашему системному администратору. Проверить результат можно, просто запросив страницы:

Http://www.главное_имя.ru/robots.txt
http://www.другое_имя.ru/robots.txt и т.д. Результаты должны быть разные.

Рекомендации для веб-сервера Русский Apache

В robots.txt на сайтах с русским апачем должны быть запрещены для роботов все кодировки, кроме основной.

Если кодировки разложены по портам (или серверам), то надо выдавать на разных портах (серверах) РАЗНЫЙ robots.txt. А именно, во всех файлах robots.txt для всех портов/серверов, кроме «основного», должно быть написано:

User-Agent: *
Disallow: /

Для этого можно использовать механизм SSI, .

Если кодировки в вашем Apache выделяются по именам «виртуальных» директорий, то надо написать один robots.txt, в котором должны быть примерно такие строчки (в зависимости от названий директорий):

User-Agent: *
Disallow: /dos
Disallow: /mac
Disallow: /koi