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

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

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

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

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

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

В гуляющих по сети после последней утечки списках факторов ранжирования Яндекса позабавил фактор 1908 "'Случайный' фактор для коммерческих сайтов."
Рандом - наше всё )

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

Рекомендую подписчикам канала вступить в привязанную к нему группу @sealytics_seo_chat
Так интересные обсуждения постов не пройдут мимо вас. Ну и можно будет позадавать различные интересующие вас вопросы.

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

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

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

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

А вот это уже любопытнее. Во вчерашней буржуйской статейке https://searchengineland.com/yandex-leak-learnings-392393 чувак по имени Michael King утверждает, что нашел в коде развесовку 257 из аж 17,000+ факторов. Действительно какие-то коэффициенты, привязанные к факторам на скриншоте https://searchengineland.com/wp-content/seloads/2023/01/yandex-relevance-scoring-554x600.png.webp присутствуют, однако очень сомнительно, что вот так вот прямо в коде забиты веса. Опять же - по какой именно формуле/запросу? Да и сами веса довольно странные, например, фактор FI_TEXT_RELEV_PHRASE (есть все слова запроса подряд в документе) имеет отрицательный коэффициент на скриншоте.

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

А вот нашелся и комментарий Дэна Расковалова (бывший сотрудник отдела качества поиска Яндекса) к тому самому мутному списку факторов с развесовками, выложенному на https://gist.github.com/lord-alfred/97400a79f10f3bb13bb4bcd42268b1f8

"nav_linear.h has nothing to do with ranking web search results in Yandex search."

Хозяйке на заметку, как говорится.

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

Пока все ищут священный грааль в утечке из Яндекса, в Гугле тоже немножко рассказали за факторы. Джон Мюллер заявил, что у них нет понятия оптимальной плотности ключевых слов: https://www.youtube.com/watch?v=TMLE-Hrcgvw&t=359s
В общем-то, ничего нового, но многие сеошники до сих пор отказываются верить в это. Кстати, если отмотаете в самое начало, то услышите подтверждение еще одной прописной истины - метатег keywords не помогает в ранжировании.

Итак, продолжаем копаться в файле 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.

Продолжаю тему факторов из файла factors_gen.txt. Любопытным показался фактор 1085 FI_AVG_TITLE_CAPITAL_LETTERS_RATIO с описанием "Доля заглавных букв в Title". Судя по прикрепленной ссылке на внутреннюю Вики (https://wiki.yandex-team.ru/JandeksPoisk/Antispam/Tech/Mascot), этот фактор имеет отношение к Антиспаму.
Сразу вспомнилась практика, несколько лет назад активно использовавшаяся сеошниками для формирования более заметного сниппета - писать тег title заглавными буквами. Видимо, эта практика и стала причиной появления этого фактора. Странно, что в списке не нашлось фактора, который учитывает наличие спецсимволов Юникода в тегах title и description, которые сеошники используют с той же целью. Хотя, судя по тому, что такие спецсимволы в сниппетах топа Яндекса встречаются гораздо реже, чем у Гугла, в файлик могли попасть не все факторы Антиспама.