Собственно, в Яндекс.Справке о непередаче региональности указано на странице 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, которые сеошники используют с той же целью. Хотя, судя по тому, что такие спецсимволы в сниппетах топа Яндекса встречаются гораздо реже, чем у Гугла, в файлик могли попасть не все факторы Антиспама.

Увидел тут в одном чате дискуссию про то, какими следует считать запросы, содержащие в себе топоним - геозависимыми или геонезависимыми.
Здесь все зависит от того, что считать геонезависимостью. Независимость выдачи по запросу от региона пользователя или вообще от какого-либо региона.
На мой взгляд, второе определение будет более корректным. Запросы с топонимами зависят от региона, который в них указан, и поэтому их следует считать геозависимыми.
Да и сам Яндекс в своей статье https://yandex.ru/company/technologies/regions особо оговаривает случай, когда город указан в запросе, в подразделе о результатах регионального поиска, т.е. геозависимых.

Прочтя свежеопубликованную позицию Гугла по поводу сгенерированого с помощью искусственного интеллекта контента (https://developers.google.com/search/blog/2023/02/google-search-and-ai-content), подумалось, что не за горами появление для него маркера по типу nofollow для неестественных ссылок.
Несмотря на то, что позиция Гугла по этому поводу на данный момент, ну, очень обтекаема.

Оказывается, в своем посте https://t.me/sealytics/13 я немножко предвосхитил события. Яндекс только сегодня объявил о прекращении поддержки директивы canonical при смене протокола: https://webmaster.yandex.ru/blog/otklyuchenie-podderzhki-rel-canonical-pri-pereezde-s-https-na-http
Получается таки, это был единственный известный мне случай поддержки Яндексом кросс-доменной директивы canonical.
Любопытна оговорка в названии новости: "при переезде с https на http". Обычно переезжают в другом направлении )

Поступила информация о том, что слова о переезде именно с https на http в заголовке новости https://webmaster.yandex.ru/blog/otklyuchenie-podderzhki-rel-canonical-pri-pereezde-s-https-na-http - не опечатка.
Насколько я понимаю, проблема с директивой canonical возникает именно при необходимости переезда с https на http в случае неработающего сертфиката ssl - робот не имеет доступа к https и не видит canonical.
В случае же "классического" переезда с http на https проблем с директивой canonical быть не должно.