В Google Webmaster Tools анонсировали новое расширенное описание описание ошибок на сайте — проблем с DNS и доступом к robots.txt. Полез к себе в аккаунт посмотреть и с удовольствием обнаружил отсутствие каких-либо проблем с DNS и robots за последние 90 дней, несмотря на переезд на новый сервер в конце июля. Так что будем довольствоваться оригинальным скрином от Google под катом.
Читать далее «Описание ошибок сайта в GWT»
Метка: robots.txt
Статус индексирования в Google и зеркала
Новый инструмент «Статус индексирования» в Google Webmaster Tools появился буквально на прошлой неделе. В отчете можно увидеть динамику индексации сайта за последний год с шагом в одну неделю. Лучше всего сразу переключаться в расширенный вариант, где, кроме проиндексированных документов, можно видеть графики не попавших в поиск (а-ля supplemental) и запрещенных в robots.txt страниц.
Как раз по графику не попавших в поиск документов можно отслеживать процесс переключения зеркал сайта, когда нет возможности поставить подокументный 301-й редирект. Случаи такие возникают для переклейки зеркал в Яндексе — пока не сработает директива Host в robots.txt, меняющая местами главное и второстепенное зеркало, о чем я раньше уже писал. Читать далее «Статус индексирования в Google и зеркала»
robots.txt и кеш Google
Решил перепроверить в принципе уже известные факты о том, как ведут себя Яндекс и Google при запрете страниц в robots.txt. Хотя на самом деле речь в основном пойдет про Google, потому что поведение Яндекса вполне просто и прямолинейно.
Есть два варианта:
1) Страница, страницы или разделы уже существуют и проиндексированы, после чего они закрываются от индексирования в robots.txt
2) Страница или группа страниц изначально закрыта в robots.txt до возможности их индексации.
Казалось бы второй вариант вообще нет смысла рассматривать, потому что сразу запрещено и «мышь не проскочит, робот не пройдет». Ан, нет — возможны варианты!
Запрещение уже проиндексированных страниц сайта
Не так давно появилась необходимость закрыть от индексации сайт с сотней тысяч проиндексированных страниц. Практически полностью, т.е. из 100 тыс. осталось штук 30-40. Яндекс в этом случае при ближайшем апдейте безусловно удаляет все 999 960 «лишних» страниц, никак специально не уведомляя об этом, т.е. если вебмастер запретил — он знает, что делает. Читать далее «robots.txt и кеш Google»
Как склеить зеркала сайта в Яндексе
Что же нужно сделать для правильной склейки зеркал сайта в Яндексе? Последовательность действий по склейке зеркал будет зависеть от текущей ситуации с зеркалами, ее надо выяснить прежде всего и здесь нам поможет форма добавления нового сайта — http://webmaster.yandex.ua/addurl.xml. При добавлении сайта в форму делается автоматическая проверка на “зеркальность” и если сайт является не главным зеркалом, то будет указано главное: “Указанный вами сайт является неглавным зеркалом сайта notes.webartsolutions.com” (и правда является, сейчас переклеиваю).
Если зеркала никак пока не склеены, то это самый идеальный случай, нужно сделать следующие шаги:
- Прописать директиву Host в robots.txt, где указать главное зеркало, после всех прочих директив в секции для Яндекса написать “Host: www.chernyshov.kiev.ua” без http, просто адрес. Лучше всего это сделать именно в отдельной секции Яндекса, потому что кроме Яндекса директиву Host никто не поддерживает.
- Максимум ссылок ставить именно на главное зеркало, при возможности отредактировать существующие ссылки, чтобы тоже вели на главное зеркало.
- Можно поставить 301-й редирект на главное зеркало, а можно этого не делать, смотря как индексируются зеркала и сколько посетителей ходит на них. При установке 301-го редиректа тот сайт, откуда стоит редирект, скорее всего выпадет из индекса.
- Набраться терпения и ждать.
В случае Яндекса 301-м редиректом пользоваться следует осторожно, поскольку в случае неправильной склейки зеркал, когда главным зеркалом уже выбран неправильный адрес, 301-й редирект скорее навредит.
В помощи Яндекса по этому поводу имеется интересная фраза в разделе как склеить зеркала:
С помощью серверного редиректа со страниц старого домена на соответствующие им страницы нового. Этот способ рекомендуется использовать в том случае, если новый домен не является неглавным зеркалом.
На практике получается, что склеивать зеркала с помощью 301-го редиректа в Яндексе можно только в том случае, когда главным зеркалом должен стать новый адрес, еще не склеенный ни с чем. Я проверил, действительно работает: адреса site.ru и www.site.ru были зеркалами, а newsite.ru надо было сделать новым главным зеркалом. Host, редирект, полтора месяца ожидания и — вуаля!
Если же зеркала уже склеены, но склеены неправильно и их надо переклеить или свапнуть, то тут надо немного изменений и очень много… терпения:
- Выключаем редирект, если он был.
- Прописываем директиву Host в robots.txt, где указываем главное зеркало.
- По возможности ставим новые ссылки на главное зеркало и меняем на старое.
- Ждем
Ждать придется несколько месяцев так точно, поэтому склейку зеркал лучше не откладывать.
Персональные данные в поисковиках
Дважды за последние пару недель возникали информповоды по поводу индексации поисковыми системами, а вернее речь шла практически только о Яндексе, совсем не публичной информации. Многие при этом склонны обвинять именно поисковики в таком нехорошем поведении, хотя поисковики вполне корректно делают свою работу: можно проиндексировать контент — индексируют.
На самом деле разгоняй надо делать админам, архитекторам и ПМам, которые вообще допустили доступность такого контента в интернете. По хорошему доступ к бек-енду должен открываться буквально по IP-адресам только непосредственно работающим с админкой людям, запароленный доступ и https обязательны. Никто не отменял VPN, кстати.
А закрыть доступ к разделу или незапароленной админке в robots.txt — это все равно, что дать незнакомому человеку ключи от квартиры и указать пальцем на дверь. Любой даже не хакер, а пользователь с уровнем выше среднего, пройдется по таким «закрытым» разделам пылесосом wget’а и будут потом писать уже не про поисковики, а чт-то вроде:
…в руки хакеров попало н-дцать тысяч пользовательских записей из ряда интернет-магазинов и сервисов…
В общем, кажущаяся простота развертывания готовых сервисов и модулей различных CMS и прочих готовых решений, а также изменяющий реальность подход к публичности личной информации все равно не снижает требований к ответственным специалистам.