четверг, 8 июня 2023 г.

Консолидация страниц из группы хоста в выдаче Google

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

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

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

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

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

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


среда, 7 июня 2023 г.

О сторонних сервисах оценки ссылок

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

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

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

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


понедельник, 5 июня 2023 г.

Bad neighborhood для доменных зон в Google

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

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

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


суббота, 3 июня 2023 г.

О кроссдоменных директивах canonical в Google

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 - всё? 


среда, 31 мая 2023 г.

Об инструментах проверки URL поисковиками

Обнаружился баг в инструменте "Проверка ответа сервера" сервиса Яндекс Вебмастер. Если для проверки выбирать по умолчанию Основной робот Яндекса 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)



среда, 24 мая 2023 г.

Ограничение функционала оператора url: в Яндексе

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

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

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




понедельник, 22 мая 2023 г.

О заголовке Last-Modified и запросе If-Modified-Since

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

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

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

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

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


четверг, 18 мая 2023 г.

Влияние некорректной микроразметки на ранжирование

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

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

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

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

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


среда, 26 апреля 2023 г.

Отключение персонализации результатов поиска в Google

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

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

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

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

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


четверг, 20 апреля 2023 г.

Текстовые версии сохраненных копий


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

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

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


вторник, 18 апреля 2023 г.

О 404 ошибке

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

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

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

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


вторник, 21 марта 2023 г.

Изменение отношения Яндекса к запрету индексации в файле robots.txt

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

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

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

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

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

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

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

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


пятница, 17 марта 2023 г.

О дифференциации веса внутренних ссылок

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

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

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

“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.”


четверг, 16 марта 2023 г.

Переезд сайта с изменением URL

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

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

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

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

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

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

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


вторник, 7 марта 2023 г.

О внутренней перелинковке

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

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

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

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

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

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

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

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

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

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


пятница, 3 марта 2023 г.

Quod liced Jovi non liced bovi


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

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

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


суббота, 25 февраля 2023 г.

Про индексацию страниц пагинации

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

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

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

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

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

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

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


суббота, 18 февраля 2023 г.

Google учит, как SEO ссылки расставлять

На днях 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.

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


среда, 15 февраля 2023 г.

PageRank - течет или не течет?

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

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

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


вторник, 7 февраля 2023 г.

О геозависимости запросов с топонимом

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

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

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

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


пятница, 3 февраля 2023 г.

"Неиспользуемые" факторы ранжирования Яндекса

Итак, продолжаем копаться в файле factors_gen.txt. Мысли по поводу факторов с пометкой TG_UNUSED.
Многие комментаторы априори записали такие факторы в разряд неиспользуемых. Но я думаю, что не все так просто.
В описании фактора FI_MATRIXNET читаем: "Ко всем факторам применяется MatrixNet - формула (TG_UNUSED - чтобы предотвратить вхождние в какие-либо формулы)", в описании фактора FI_URL_SHOWS_WITH_NEXT_PAGE_CLICKS_P10 еще интереснее: "Фактор используется в SelectionRank. TG_UNUSED: не должен входить в формулы во избежание обратной связи".
Итак, получается факторы с такой пометкой не используются в Матрикснете из-за опасности положительной обратной связи. Но вполне себе могут использоваться в других частях модели ранжирования. В том же SelectionRank - осталось только понять, что это такое ). Или, например, в антиспаме. Или в добавке из полиномов, которая точно была раньше, и, возможно, есть и сейчас - предлагаю присмотреться к описанию факторов FI_FULL_POLYNOM, FI_FAST_POLYNOM, FI_FILTER_POLYNOM, FI_META_POLYNOM.
Так что я бы не сбрасывал такие факторы со счетов. Кстати, интересно, что такую пометку имеет фактор FI_PAGE_RANK.

среда, 1 февраля 2023 г.

Как сеошники Матрикснет вскрывали

Наверное, только совсем далекий от интернета человек еще не слышал о недавней утечке данных из Яндекса. Естественно, такое событие не могло не поднять ажиотаж на рынке SEO. Многие сеошники начали искать, чем бы можно поживиться в 40+ гигабайтах утекших данных. Первым объектом стал файл factors_gen.txt со списком 1922 факторов ранжирования. Добыча была, прямо сказать, не слишком жирная, так как кроме краткого описания факторов в списке ничего не было. И понять, насколько важен тот или иной фактор, не представлялось возможным. Можно было только порефлексировать типа «Гляди-ка, догадались учитывать наличие цифр в URL, наверное в минус» или «Надо же, они считают количество заглавных букв в теге title».

Но потом один въедливый иностранец по имени Michael King опубликовал статью, в которой продемонстрировал некий файлик nav_linear.h. В нём некоторым факторам были сопоставлены некоторые коэффициенты, как положительные, так и отрицательные. Вот тут уже у сеошников образовалось широкое пространство для творчества. И постепенно этот мутный список с непонятной развесовкой факторов начал завладевать их умами. Почему-то они решили, что эти коэффициенты и есть самые что ни на есть настоящие веса факторов ранжирования и начали на их основе разрабатывать рекомендации по покорению топов поисковой выдачи Яндекса. И уже на полном серьезе от разных лиц зазвучали призывы отказываться от доменов в зоне .ru, так как в списке это отрицательный фактор. И менять их на домены в зоне .com, так как этот фактор обозначен, как положительный. Правда совсем уж неудобные нестыковки комментаторы старались обходить стороной, и пока еще никто не призывал отказаться, к примеру, от использования в тексте всех слов запроса подряд, хотя в файле этот фактор имеет отрицательный коэффициент.

Списочек факторов с развесовками упорядочили и выложили на Github, однако вдруг в комментариях там отметился не кто иной, как Ден Расковалов, бывший сотрудник отдела качества поиска Яндекса. Он заявил, что "nav_linear.h has nothing to do with ranking web search results in Yandex search."

Ну, а окончательно паззл складывается, если сопоставить название взбудоражившего сеошные умы файла с коэффициентами – nav_linear.h – с названием одного из факторов – FI_NAV_LINEAR, отвечающим за классификацию неких «полунавигационных» запросов. Вот так вот. Один фактор. Про классификацию запросов. Вскрытие Матрикснета отменяется. Можно менять домены .com обратно на .ru )

понедельник, 30 января 2023 г.

Антиспам Яндекса игнорирует тег noindex

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

пятница, 27 января 2023 г.

О текстовых анализаторах

В одной из сеошных групп зашёл разговор о текстовых анализаторах. Которые считают что-то там среднее по текстам документов из топов и дают советы, как к этому среднему приблизиться. И мало кто задумывается, что главное - не как сравнить, а с кем сравнить. Как сравнить - решения предлагают куча сервисов. Но никто не предлагает - с кем сравнивать будет правильно. Помню, лет сколько-то назад то ли на Ашмановке, то ли на Кибермаркетинге представляли один из первых текстовых анализаторов. А тогда ещё в Яндексе работал оператор intext:, который ранжировал чисто по текстовой релевантности. И на мой вопрос разработчикам, а используют ли они его, я видел в их глазах полнейшее непонимание - а зачем? Ведь массам лучше продается сравнение с обычным топом. Вот и считают за эталон тексты у документов из топа, которые там оказались вполне возможно не благодаря этим текстам, а может даже вопреки.
Например, совернуются в порте многоборцы. Они и бегут на разные дистанции, и прыгают с шестом и без, и копьё с диском мечут. И не факт, что призеры мечут копьё лучше всех. А мы берём их технику метания копья и считаем ее лучшей, раз они призеры. А они на самом деле из-за бега и прыжков в призерах, а копьё мечут так себе. А потом мы ещё это "так себе" ещё и усредняем и возводим в эталон.
К сожалению, сервисы как продукт стремятся заменить мозг оптимизатора. Мозг не нужен, раз есть кнопка. Именно это в первую очередь продается. Кнопка как альтернатива мозгу, а не кнопка, которая без мозга не работает.

четверг, 26 января 2023 г.

Проверка региональной привязки в Яндексе

Мне поступил вопрос о том, можно как то узнать региональную привязку сайта конкурента в Яндекс вебмастере и Яндекс Бизнесе?
Способ именно узнать мне на данный момент неизвестен, но зато известен способ проверить привязку к конкретному региону для любого сайта. Это можно сделать с помощью документированного оператора site: и бывшего некогда документированным оператора cat:, в качестве аргумента для которого используются определенные идентификаторы, называемые смещениями. Для проверки региональной привязки, сделанной через Яндекс Вебмастер надо использовать смещение 21000000, через Яндекс Бизнес - 81000000.
К смещению надо прибавить номер региона (значение get-параметра lr в URL страницы поисковой выдачи), для которого Вы хотите осуществить проверку. Например, для Москвы это 213.
Примеры запросов:
site:yandex.ru cat:21000213
site:yandex.ru cat:81000213
Если выдача непустая, значит, соответствующая региональная привязка есть.

вторник, 24 января 2023 г.

Переезд с HTTP на HTTPS для параноиков

Если Вы все еще опасаетесь переезжать c http на https через 301-й редирект из-за того, что есть вероятность, что http страницы вылетят из индекса раньше, чем они подклеятся к https страницам, то для параноиков у Google есть интересное решение - настроить на http страницах директиву canonical, указывающую на соответствующую https страницу. Тогда переезд обещает быть безболезненным. В Яндексе такой способ не сработает, так как тот не поддерживает кросс-доменные директивы canonical. Но в Яндексе относительно безболезненно можно переехать на https через опцию выбора главного зеркала.

среда, 18 января 2023 г.

Потеря региональной привязки при переезде на HTTPS в Яндексе

Казалось бы, Яндекс сделал всё, чтоб переезд с http на https прошел максимально безболезненно для сайта. Однако, по крайней мере одна очень неприятная вещь всё-таки есть - с http сайта на https не передается региональная привязка, сделанная через Яндекс.Вебмастер, и нужно ее делать заново. Имейте в виду.

Собственно, в Яндекс.Справке о непередаче региональности указано на странице https://yandex.ru/support/webmaster/site-geography/site-region.html: "Примечание. По умолчанию, если вы указываете регион для неглавного зеркала, он не будет присвоен главному зеркалу. Укажите регион для главного зеркала отдельно, чтобы он учитывался в результатах поиска." Но вот понять логику этого решения для случая изменения протокола я не могу.

И еще один хинт в тему региональности. Если Вы в карточке компании в сервисе "Яндекс Бизнес" указали неглавное зеркало сайта (например, не тот префикс или протокол), то региональность оттуда в индексе не учтется. Будьте внимательны.

среда, 11 января 2023 г.

Несколько мыслей о современном состоянии фильтра аффилиатов в Яндексе

Судя по всему, он таки существует. Действует не по всем запросам, видимо, его срабатывание зависит от каких-то характеристик запроса. Аффилированные сайты группируются в одну группу, самый релевантный документ из всех сайтов группы аффилиатов показывается в выдаче согласно его релевантности, самый релевантный документ со второго сайта группы получает к своей релевантности приличный дисконт (эквивалентный нескольким десяткам позиций), но все-таки показывается в выдаче, и так далее по всем сайтам группы. Если самые релевантные документы с двух сайтов группы аффилиатов имеют близкие расчетные значения релевантности, то можно наблюдать своеобразную чехарду - сегодня документ с сайта А, скажем, в топ-10, а документ с сайта В, скажем, в топ-50, а завтра - наоборот - документ с сайта В - в топ-10, документ с сайта А - в топ-50. Послезавтра - опять ротация. Наряду с фильтром аффилиатов есть механизм исключения из выдачи очень похожих документов с разных сайтов, не признанных аффилиатами, что очень сильно затрудняет детекцию именно аффилированности сайтов. Но все-таки при правильном подходе она возможна с достаточно неплохой степенью достоверности.

Blog Archive

Технологии Blogger.