Жил был сайт. Небольшой, на пару-тройку десятков страниц. С нормальным контентом и небольшой посещаемостью. Пока в один день трафик с Яндекса не прекратился почти полностью. При этом сайт индексируется, 3-5 страниц, потому что остальные не представляют ценности для пользователя.

Вот такая она — Яндекс.Панда

Решил перепроверить в принципе уже известные факты о том, как ведут себя Яндекс и Google при запрете страниц в robots.txt. Хотя на самом деле речь в основном пойдет про Google, потому что поведение Яндекса вполне просто и прямолинейно.

Есть два варианта:

1) Страница, страницы или разделы уже существуют и проиндексированы, после чего они закрываются от индексирования в robots.txt

2) Страница или группа страниц изначально закрыта в robots.txt до возможности их индексации.

Казалось бы второй вариант вообще нет смысла рассматривать, потому что сразу запрещено и «мышь не проскочит, робот не пройдет». Ан, нет — возможны варианты!

Запрещение уже проиндексированных страниц сайта

Не так давно появилась необходимость закрыть от индексации сайт с сотней тысяч проиндексированных страниц. Практически полностью, т.е. из 100 тыс. осталось штук 30-40. Яндекс в этом случае при ближайшем апдейте безусловно удаляет все 999 960 «лишних» страниц, никак специально не уведомляя об этом, т.е. если вебмастер запретил — он знает, что делает.

Что же нужно сделать для правильной склейки зеркал сайта в Яндексе? Последовательность действий по склейке зеркал будет зависеть от текущей ситуации с зеркалами, ее надо выяснить прежде всего и здесь нам поможет форма добавления нового сайта — http://webmaster.yandex.ua/addurl.xml. При добавлении сайта в форму делается автоматическая проверка на “зеркальность” и если сайт является не главным зеркалом, то будет указано главное: “Указанный вами сайт является неглавным зеркалом сайта notes.webartsolutions.com” (и правда является, сейчас переклеиваю).
Если зеркала никак пока не склеены, то это самый идеальный случай, нужно сделать следующие шаги:

1. Прописать директиву Host в robots.txt, где указать главное зеркало, после всех прочих директив в секции для Яндекса написать “Host: www.chernyshov.kiev.ua” без http, просто адрес. Лучше всего это сделать именно в отдельной секции Яндекса, потому что кроме Яндекса директиву Host никто не поддерживает.
2. Максимум ссылок ставить именно на главное зеркало, при возможности отредактировать существующие ссылки, чтобы тоже вели на главное зеркало.
3. Можно поставить 301-й редирект на главное зеркало, а можно этого не делать, смотря как индексируются зеркала и сколько посетителей ходит на них. При установке 301-го редиректа тот сайт, откуда стоит редирект, скорее всего выпадет из индекса.
4. Набраться терпения и ждать.

В случае Яндекса 301-м редиректом пользоваться следует осторожно, поскольку в случае неправильной склейки зеркал, когда главным зеркалом уже выбран неправильный адрес, 301-й редирект скорее навредит.
В помощи Яндекса по этому поводу имеется интересная фраза в разделе как склеить зеркала:

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

На практике получается, что склеивать зеркала с помощью 301-го редиректа в Яндексе можно только в том случае, когда главным зеркалом должен стать новый адрес, еще не склеенный ни с чем. Я проверил, действительно работает: адреса site.ru и www.site.ru были зеркалами, а newsite.ru надо было сделать новым главным зеркалом. Host, редирект, полтора месяца ожидания и — вуаля!

Если же зеркала уже склеены, но склеены неправильно и их надо переклеить или свапнуть, то тут надо немного изменений и очень много… терпения:

1. Выключаем редирект, если он был.
2. Прописываем директиву Host в robots.txt, где указываем главное зеркало.
3. По возможности ставим новые ссылки на главное зеркало и меняем на старое.
4. Ждем

Ждать придется несколько месяцев так точно, поэтому склейку зеркал лучше не откладывать.

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

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

А закрыть доступ к разделу или незапароленной админке в robots.txt — это все равно, что дать незнакомому человеку ключи от квартиры и указать пальцем на дверь. Любой даже не хакер, а пользователь с уровнем выше среднего, пройдется по таким «закрытым» разделам пылесосом wget’а и будут потом писать уже не про поисковики, а чт-то вроде:

…в руки хакеров попало н-дцать тысяч пользовательских записей из ряда интернет-магазинов и сервисов…

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