SEO-блог Сергея Людкевича

 Хинт от гуглоида Гэри Ийеша на июньских SEO office hours. 

Если в поисковой выдаче у вашего сайта показывается два результата (Гэри называет это "host group"), то неплохо будет консолидировать эти две страницы, назначив одну из них канонической для другой, если есть такая возможность.

На мой взгляд, хороший совет по крайней мере по двум причинам:

1) Объединение поисковых сигналов обеих страниц, происходящее при консолидации, может увеличить релевантность страницы, назначенной канонической.

2) Не будет происходить каннибализации кликов по поиске.

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

 На форуме по техническому SEO Reddit один юзер пожаловался, что сервис Semrush пометил ссылку с Github как токсичную.

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

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

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

Гуглоид Джон Мюллер в дискуссии на форуме Reddit  не рекомендует выбирать для продвижения домены в дешевых доменных зонах, перегруженных спамом:

"From an SEO POV, I would just not pick a TLD that's super-cheap and over-run with spam."

Выглядит так, что "плохое окружение" ("bad neighborhood") касается и доменных зон.

Google изъял из англоязычной версии документации о директиве canonical рекомендацию использовать его для управления скопированным контентом, размещенном на других доменах (интересно, что в русскоязычной версии эта рекомендация еще остается).

Причина объяснена на другой странице документации (русскоязычной версии у нее нет): 

"The canonical link element is not recommended for those who wish to avoid duplication by syndication partners, because the pages are often very different. The most effective solution is for partners to block indexing of your content."

Получается, кроссдоменные директивы canonical в Google - всё? 

Обнаружился баг в инструменте "Проверка ответа сервера" сервиса Яндекс Вебмастер. Если для проверки выбирать по умолчанию Основной робот Яндекса Mozilla/5.0 (compatible; YandexBot/3.0; +http://yandex.com/bots), то проверять приходит не он, а Робот Яндекс Вебмастера Mozilla/5.0 (compatible; YandexWebmaster/2.0; +http://yandex.com/bots).

Будьте внимательны, если вы дифференцируете отдачу содержимого страниц своего сайта по User agent.

Кстати, в Google следует принимать во внимание, что в случае проверки страницы на сайте инструментом "Проверка URL" в Google Search Console проверять страницу придет не Googlebot Smartphone или Desktop, а робот Google Inspection Tool.

Варианты полных строк его User agent для мобильных устройств и десктопов можно найти на странице англоязычной версии документации по поисковым роботам Google Search Central (в русскоязычной версии этой информации пока нет):

Mobile

Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/W.X.Y.Z Mobile Safari/537.36 (compatible; Google-InspectionTool/1.0)

Desktop

Mozilla/5.0 (compatible; Google-InspectionTool/1.0)

С каждым годом функционал языка запросов Яндекса становится все беднее.

Старый добрый оператор url: тоже стал привирать.

В связке с символом * (Цитата из Яндекс Справки: "Чтобы найти все документы, адреса которых начинаются с заданного значения, поставьте в конце URL символ *") он теперь показывает явно не все, что есть в индексе. Грусть-печаль.

Гуглоид Джон Мюллер развенчивает очередной сеошный миф о том, что некорректно выставленная дата в заголовке Last-Modified отклика сервера (в частности, всегда текущая) может негативно влиять на ранжирование.

Честно говоря, не понимаю, откуда подобные мифы берутся, но Джон вот где-то сумел найти )

Собственно, имеет значение не столько само содержимое заголовка Last-Modified, сколько, какой код ответа сервер отдает на запрос If-Modified-Since. По идее здесь может быть только одно влияние на ранжирование - если контент страницы изменился с даты указанной в запросе, а сервер будет отдавать 304, а не 200, то эти изменения просто не учтутся.

Между тем, интересная ведь штука получается - можно сделать контент для ботов, дать ему быстренько проиндексироваться, а затем разместить контент для людей, и отдавать 304 на все запросы от ботов If-Modified-Since. В итоге в индексе висит версия для ботов, люди получают версию для людей.

С одной стороны, вроде очень похоже на клоакинг, а с другой - всего лишь некорректная обработка запроса If-Modified-Since.

Тем, кто опасается, что некорректная микроразметка может негативно повлиять на ранжирование, гуглоид Gary Illyes во время майских Google SEO office-hours дал однозначный ответ: нет.

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

Так что алерты в Google Search Console об ошибках в микроразметке на странице не являются причиной ее плохого ранжирования.

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

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

Чем мне импонирует Google, так тем, что персонализация результатов поиска в нем, в отличие от Яндекса, очень незначительна, и почти не мешает анализировать выдачу, не прибегая к ухищрениям типа режима "Инкогнито" в браузере. 

К тому же персонализацию можно легко отключить.

Сделать это можно двумя способами:

1) В настройках - как это сделать, описано в Google Справке

2) С помощью get-параметра &pws=0, который нужно добавить к URL страницы выдачи.

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

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

Для Яндекса это &mode=text , для Google это &strip=1.

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

Не знаю, откуда растут ноги у подобных опасений, но явление довольно таки массовое. Возможно, причина в том, что и в Яндекс Вебмастере, и в Google Search Console страницы с откликом 404 имеют "токсичный" статус исключенных из индекса, и это воспринимается, как негативный сигнал.

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

В качестве пруфа можно откопать в недрах блога Центра Search Console древнюю статью, чтоб убедиться, что "ошибки 404 – это нормальное явление".

Обнаружил, что Яндекс изменил своё отношение к запрещенным в файле robots.txt страницам.

На странице Яндекс Справки "Использование файла robots.txt" появилось примечание:

"Ограниченные в robots.txt страницы могут участвовать в поиске Яндекса. Чтобы удалить страницы из поиска, укажите директиву noindex в HTML-коде страницы или настройте HTTP-заголовок."

А на странице "Как удалить страницы из поиска" в описании способа удаления "Запрет в файле robots.txt" вместо фразы 

"Робот прекращает обращаться к странице в течение суток."

появилась фраза

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

Таким образом Яндекс в данном вопросе перенял позицию Google. Надеюсь, что так же, как и Google, сканировать запрещенные в robots.txt страницы Яндекс все-таки не будет.

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

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

Но вот подобные идеи насчет внутренних - считаю, мягко говоря, некомпететными и не имеющими под собой никаких оснований. Ну, и старина Джон Мюллер подтверждает: 

“We don’t really differentiate there.

So if like, things are linked in your footer of the page and they’re linked from across the whole website then from our point of view you have those links from across your whole website.

It’s not the case that we would say, Oh, like links in a footer have less weight or are not as useful we will ignore them or anything like that.

So from that point of view, when it comes to links we essentially just see them as links on a page.”

Рекомендации Google и Яндекса в этом вопросе существенно разнятся.

И если Google позволяет просто напрямую сопоставить старые и новые URL и настроить 301-й редирект (другие виды редиректов не рекомендуются), то Яндекс требует двойной редирект:

"Установите на сервере редирект с HTTP-кодами 301 или 302. Перенаправление должно вести со страниц старого сайта на аналогичные страницы нового — который должен участвовать в поиске.

Если у сайта изменились доменное имя и названия каталогов, то нужно установить двойной редирект. Например, адрес страницы http://сайт.рф/стр/ изменился на http://example.ru/page/. Тогда перенаправление должно работать следующим образом:

http://сайт.рф/стр/ -> http://example.ru/стр/ -> http://example.ru/page/ "

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

Google хоть и не рекомендует использовать цепочки редиректов, но допускает их, если количество переходов сведено к минимуму.

 Важная вещь, о которой часто забывают.

Значимость внутренней страницы сайта для поисковой системы во многом определяется двумя факторами: 

1) Количеством входящих ссылок.

2) Длиной самой короткой цепочкой ссылок от главной страницы (чем короче, тем лучше).

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

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

Совершенствуйте рубрикаторы, делайте более плотную перекрестную перелинковку. 

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

Страница, на которую ссылается только одна 100500-ая страница пагинации - не нужна никому, ни поисковикам, ни пользователям. Большое количество таких страниц на сайте говорит о том, что и сам сайт никому не нужен )

Даже если адепты модного "силосования" пытаются вас убедить в обратном.

Всякий раз, когда натыкаюсь на подобное, хочется сказать "И эти люди запрещают нам ковыряться в носу?" 

А как же незабвенное "Мы стараемся не индексировать или не ранжировать высоко: ... Страницы с результатами поиска по сайту или результатами отбора товаров, услуг, других объектов по условиям, если они мало информативны и мало полезны для пользователей."? 

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

Мысли про пагинацию. Индексировать или не индексировать?

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

Сделать это можно двумя способами:

1) Директива canonical со всех страниц пагинации на первую страницу.

2) Мета robots со значением noindex, follow для страниц пагинации кроме первой.

Первый способ, на мой взгляд, предпочтительней. Про рекомендацию Google не использовать первую страницу пагинации в качестве канонической знаю, однако опыт подсказывает обратное. Но могут быть нюансы, когда поисковик игнорирует canonical, но массово выкидывает страницы пагинации из индекса как малоценные или дубли. Тогда использовать второй способ.

Закрывать пагинацию от индексации в robots.txt с помощью директив Disallow или Clean-param (в Яндексе, если пагинация задается get-параметром в URL) категорически не рекомендую.

На днях Google обновил контент на англоязычной версии страницы документации по ссылкам.  

Интересно изменение заголовка страницы с "Make your links crawlable" на "SEO Link Best Practices for Google".

Среди прочего показался любопытным следующий момент:

As a fallback, Google can use the title attribute as anchor text if the <a> element is for some reason empty.

<a href="https://example.com/ghost-pepper-recipe" title="how to pickle ghost peppers"></a>

Честно говоря, не совсем понимаю, по каким причинам содержимое тега <a> можно оставлять пустым. Ведь в этом случае ссылка будет не видна пользователю. И еще более странным видится то, что в этом случае вполне легально содержимое атрибута title будет считаться анкором такой невидимой ссылки.

Еще один любопытный момент - плохими  обозначены так называемые "безанкорные" ссылки, которыми сеошники так любят "разбавлять" анкор-файлы:

Bad (too generic):

<a href="https://example.com">Click here</a> to learn more.

<a href="https://example.com">Read more</a>.

Learn more about our cheese on our <a href="https://example.com">website</a>.

We have an <a href="https://example.com">article</a> that provides more background on how the cheese is made.

А хорошими ссылками обозначены как-раз таки акорные, главное, чтоб были не слишком длинные.

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

Меж тем давным-давно уже ходит байка про бывшего сотрудника Гугла, заявившего, что аж с 2006-го года классический алгоритм PageRank заменен на некий более экономный в расчетах. Что в общем-то вполне логично. Но так как новой формулы никто не знает, то многие предпочитают верить в старую )

В общем, рекомендую в работе сосредоточиться на том, кто и как ссылается на вас, а не на том, сколько ссылаетесь вы. Ну, конечно, при условии, что ссылаться надо все-таки на хороших ребят )

Увидел тут в одном чате дискуссию про то, какими следует считать запросы, содержащие в себе топоним - геозависимыми или геонезависимыми.

Здесь все зависит от того, что считать геонезависимостью. Независимость выдачи по запросу от региона пользователя или вообще от какого-либо региона. 

На мой взгляд, второе определение будет более корректным. Запросы с топонимами зависят от региона, который в них указан, и поэтому их следует считать геозависимыми.

Да и сам Яндекс в своей статье "Поиск с учётом  региона" особо оговаривает случай, когда город указан в запросе, в подразделе о результатах регионального поиска, т.е. геозависимых.