Говорить ли Гуглю про перенос сайта

Как известно, при смене домена (например, example.com.ua на example.ua) обычно рекомендуется не только настроить 301 redirects, но и сообщить Гуглю через Webmasters Tools.

Но есть случай, когда это делать не стоит: если вы одновременно со сменой домена меняете и структуру URL. Допустим, раньше у вас были миллионы страниц с адресами вроде example.com.ua/offers/London/. А теперь каждая из них переносится в example.ua/best-offers-in-London/. В этом случае нам нужна грубая сила - Гугль должен переиндесировать каждую из миллиона страниц. Если же сообщить ему про смену домена, он может схалтурить и решить, что просто меняется домен, а все пути остаются старыми.

По этой же причине в такой ситуации не стоит добавлять в robots.txt директиву Host:example.ua (впрочем, она вроде влияет только на Яндекс).

Включение nofollow-страниц в sitemap

Я был уверен, что идеале для запрета индексирования страницы надо использовать все доступные способы: noindex, nofollow (причем как в tag, так и заголовке страницы), robots.txt и исключение из XML sitemap. Таким образом, ты помогаешь Гуглю не делать лишнюю работу, индексируя заведомо ненужные страницы.

Но жизнь не стоит на месте. Теперь Гугль просит включать в XML sitemap все страницы, кроме тех, которые запрещены в robots.txt. Оказывается, они уже не верят на слово вебмастеру, который говорит "эта страница плохая". Они хотят сначала проиндесировать всё, что есть; определить, что такое хорошо, а что такое плохо; и только потом сравнить свои результаты с тем, что ты поотмечал как nofollow / noindex.

И вот если результаты примерно совпадут, то они скажут: "О, вот это хороший сайт - люди стараются, ответственно подходит к работе".

noindex, follow

Как-то я раньше думал, что такая комбинация в заголовке страницы бессмыслена: как можно просить поисковик не индексировать страницу, но в то же время проиндексировать её ссылки? Тем более, что, подсчитывая ранг страницы, Гугль придает большое значение качеству страниц, которые ссылаются на неё . И если ты прямо сам говоришь Гуглю, что исходная страница плохая, то как можно ожидать, что он хорошо проиндесирует имеющиеся на ней ссылки?

Но нет, я ошибался. Оказывается, комбинация "noindex, follow" имеет право на жизнь: "Да, эта страница - дерьмо, но ссылочки Вы всё же проиндексируйте, пожалуйста".

"Хлебные крошки": а если всего один уровень?

Как известно, Гугль рекомендует использовать специальную разметку для "хлебных крошек" (breadcrumbs). Это не только помогает ему индексировать сайты, но и может менять внешний вид результатов в результатах поисках. Вместо URL Гугль покажет что-то вроде
www.example.com > Автомобили > Жигули > Подержанные

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

Но, похоже, все гораздо проще: если хочешь, чтобы красиво отображалось в Гугле, то breadcrumb должен содержать как минимум два уровня.

У меня же в некоторых случаях уровень был только один. Почему? Во-первых, не делал разметку для ссылки на главную страницу (какой смысл добавлять пункт "Главная", если Гугль и так показывает ссылку на главную страницу сайта?). Во-вторсых, не ставил ссылку на текущую страницу (потому что самоссылка - это вообще-то плохо). Т.е. визуально пункт "Главная" у меня был как бы частью breadcrumb, но как обычная ссылка, без специальной разметки. И пункт с названием текущей страницы тоже был, но просто как текст, а не ссылка.

nofollow vs robots.txt

Как известно, попросить поисковый робот не индексировать ссылку можно одним из трех способов: nofollow на уровне страницы или ссылки, или robots.txt.

А как лучше? Раньше я считал, что нужно всегда стараться использовать robots.txt. Во-первых, вся логика в одном месте; во-вторых, не надо засорять HTML кодом, который нужен исключительно для роботов. Конечно, есть исключения. Для внешних ссылок нужен nofollow, тут без вариантов. Или структура URL может быть такая сложная, что нет смысла заносить сотни правил в robots.txt. Или наоборот: один тип URL (например, ссылка на информацию о товаре), но в зависимости от типа товара ты иногда хочешь ставить nofollow.

Но я был неправ. Оказывается, может быть ещё одна серьезная причина отказаться от robots.txt...

Попросили написать программку, чтобы загрузить все crawl issues (потенциальные проблемы при индексации) из Google Webmasters Tools API. Почему через API? Потому что через сайт они дают загрузить только небольшую часть проблем, а надо всё.

Результаты меня поразили. Во-первых, у всех наших сайтов оказалось примерно по 100 тысяч проблем. Хотя количество страниц и внутренних ссылок у этих сайтов очень разное. Очевидно, Google ограничивает максимальное количество проблем в своей базе. А почему получилось примерно по 100 тысяч, а не ровно? Может им так удобнее было сделать; или ограничение не на количество записей, а на объем в килобайтах. Ну, неважно...

Интересно другое: 99% всех "проблем" - это то, что ссылка была заблокирована в robots.txt. А это на самом деле вовсе не проблема, так и задумано. Всё бы ничего, если бы не было лимита на 100 тысяч проблем. Получается, лжепроблемы засоряют отчёт, а информация о каких-то настоящих проблемах теряется. И ещё интересный момент - большинство заблокированных ссылок повторяются в отчете много раз.

Перенос тИЦ на новый домен

Несколько месяцев назад я перенес сайт на новый домен. Как положено, со всех старых страниц сделал 301 redirect.

В Google Webmaster Tools сообщил о смене адреса. Google переиндекировал довольно быстро. PageRank у нового домена стал такой же, как был у старого, всё старые ссылки учлись. А вот Яндекс никак не хотел переносить тИЦ. Я сделал, как они рекомендовали - в robots.txt добавил директиву Host: newdomain.ua , но это не помогло. Писал в поддержку - они ответили "ждите".

И вдруг меня осенило: может, надо делать 301 redirect не для всех страниц, а для всех, кроме robots.txt? Иными словами, страницы вида olddomain.ua/my-page1.html должны перенаправляться на newdomain.ua/my-page1.html, но не надо перенаправлять с olddomain.ua/robots.txt на newdomain.ua/robots.txt.

Попробовал - и действительно, уже через неделю мой старый тИЦ перенесся на новый домен. Я считаю, это глюк Яндекса; если происходит 301 redirect файла robots.txt, то для поисковика должно быть очевидно, что сайт переехал. Тем более, что я прописал Host, как они просили. В крайнем случае, надо было хотя бы описать эту особенность в документации...

Сайт - это не только SEO

Заметка о том, что надо не только заниматься SEO, но и не забывать о качестве продукта. Очень понравился комментарий редактора (вольный перевод - мой):

Как много SEO-экспертов требуется, чтобы заменить лампочку, лампочки, лампу, лампы, светильник, свечение, свет, освещение, торшер, патрон, выключатель, электричество, энергия...?

Google Webmasters Central: проблема со старым доменом

Гугль слегка поменял алгоритм верификации в Google Webmaster Tools. У меня имеется mydomain.com.ua, со всех страниц которого происходит перманентное перенаправление на mydoman.ua. Для верификации использовался файл. Раньше работало.

Сегодня вдруг Гугль стал говорить в том смысле, что "не удается проверить право собственности на mydomain.com.ua, потому что файл googleXXX.html перенаправляет на неразрешенный адрес mydoman.ua". Почему "неразрешенный", ведь mydoman.ua у меня верифицирован? Не знаю - то ли у них ошибка, то ли специально решили ужесточить правила.

Можно, конечно, воспользоваться другими методами верификации(meta tag или записать в DNS), но мне не хотелось: про запись в DNS легко забыть, когда переезжаешь на новый хостинг, а meta tag - некрасиво (засоряет главную страницу).

Вместо этого поменял правила в IIS URL Rewrite так, чтобы файл googleXXX.html обслуживался и по старому, и по новому адресу. Для всех остальных файлов по-прежнему делаю перенаправление:

<rule name="DomainRedirects" patternSyntax="ECMAScript">
<match url=".*" />
<conditions logicalGrouping="MatchAll">
<add input="{HTTP_HOST}" pattern="^(www.mydomain.ua|((www.)?(mydomain.com.ua|mydomain.co.ua)))$" />
<add input="{URL}" pattern="googleXXX.html" negate="true" />
</conditions>
<action type="Redirect" url="http://mydomain.ua/{R:0}" redirectType="Permanent" />
</rule>

Интересно было бы почитать, как различные правила URL Rewrite влияют на производительность IIS. Не заставляю ли я его делать лишнюю работу при каждом запросе? Думаю, что нет - по идее, он всё должен кэшировать...

P.S. Как видите, я заодно убираю www., но это уже отдельная тема, из-за которой идут жаркие холиворы.