Продолжаю тему факторов из файла 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 быть не должно.

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

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

Немножко о том, чем я могу быть полезен.
Вы занимаетесь поисковым продвижением сайта, но понимаете, что уперлись в потолок или близки к нему. Вы прогнали свой сайт по всевозможным сеошным сервисам и программам, но в голове каша из их отчетов. Нужен свежий незамыленный взгляд со стороны. Тогда это ко мне. Проведу глубокий авторский SEO-аудит сайта, внимательно посмотрю его глазами, пощупаю руками, и обязательно найду препятствующие хорошему ранжированию ошибки, дам рекомендации по их исправлению.
Не нужен полноценный аудит, а есть только отдельные вопросы? На этот случай есть разные варианты, начиная от часовой беседы без предварительной подготовки. Всегда рад помочь: @ludkiewicz

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

На днях 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 будет считаться анкором такой невидимой ссылки.

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

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.

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

Меж тем в заголовке поста об отключении поддержки canonical при смене протокола произошло изменение. Фраза "при переезде с https на http" изменилась на "при переезде с http на https". Значит, таки была опечатка ) Кстати, URL страницы менять не стали.

В дополнение к посту https://t.me/sealytics/36
По итогам обращений принял решение сделать для подписчиков канала спецтариф на аудит для интернет-магазинов.
Конечно, бывают исключения, но, как правило, интернет-магазины имеют схожие проблемы, и поэтому есть возможность унифицировать подход, что позволяет сократить временной бюджет.
Обращайтесь: @ludkiewicz

Между тем детектив с отключением поддержки директивы canonical при смене протокола продолжается (предыдущая серия здесь: https://t.me/sealytics/40 ). В заголовок поста опять вернулась фраза "с https на http". Похоже, в Яндексе столкнулись какие-то противоборствующие по этому поводу группировки )
Кстати, могу поделиться реальным эпизодом из практики, когда поддержка этой директивы была бы полезна именно с таком направлении. Дело в том, что по техническим причинам было необходимо существование обоих версий (т.е. редирект исключался), но главным зеркалом надо было назначить именно HTTP. В разделе "Переезд сайта" в Яндекс Вебмастере деактивировалась опция "Добавить HTTPS", но хватало этого буквально на несколько дней. Затем Яндекс сам активировал эту опцию и назначал главным зеркалом HTTPS. И так по кругу, только успевай замечать.

Неприятные новости от Роскомнадзора. По одному из сайтов от них пришло "письмо счастья", в котором указывается на нарушения 152-ФЗ "О персональных данных" - зарубежный айпишник (используется Cloudfare) и наличие кода Google Analytics без формы согласия посетителей сайта на обработку их персональных данных с использованием именно этого сервиса.
Ну, положим, запрос на согласие использования GA можно включить в форму, но вот использование зарубежных CDN, получается, под запретом.

Мысли про пагинацию. Индексировать или не индексировать.
Считаю, что в случае списков (например, товаров в категории или статей по теме) для нормальной перелинковки конечных страниц просто необходимо позволять роботу проходить по ссылкам пагинации. При этом наличие страниц пагинации в индексе совершенно необязательно.
Сделать это можно двумя способами:
1) Директива canonical со всех страниц пагинации на первую страницу.
2) Мета robots со значением noindex, follow для страниц пагинации кроме первой.
Первый способ, на мой взгляд, предпочтительней. Про рекомендацию Google не использовать первую страницу пагинации в качестве канонической знаю, однако опыт подсказывает обратное. Но могут быть нюансы, когда поисковик игнорирует canonical, но массово выкидывает страницы пагинации из индекса как малоценные или дубли. Тогда использовать второй способ.
Закрывать пагинацию от индексации в robots.txt с помощью директив Disallow или Clean-param (в Яндексе, если пагинация задается get-параметром в URL) категорически не рекомендую.

По итогам обсуждения в комментариях к предыдущему посту канала хотелось бы поговорить о различиях упоминаемых в нем способов:
1) Canonical - происходит склейка страниц с консолидацией нетекстовых (внешних) факторов плюс учёт ссылок с неканонической страницы в ссылочной структуре.
2) Мета robots со значением noindex, follow - никакой склейки, только учёт ссылок.
3) Clean-param - склейка с консолидацей есть, учёта ссылок нет, по сути аналог 301-го редиректа.
4) Disallow - ни склейки, ни учёта ссылок.

Небольшое уточнение по мете robots. Формально значение follow (равно как и index) - необязательно. По умолчанию робот делает все, что не запрещено (сканирует ссылки и индексирует контент). А вот для запрещения сканирования ссылок используется nofollow, для запрещения индексации контента - noindex.

Перекину в канал из чата интересное наблюдение Игоря Бакалова. Вообще-то для главных страниц запрещенных к индексации сайтов Яндекс практикует подобные сниппеты с сообщением "Владелец сайта предпочёл скрыть описание страницы" довольно давно. Но вот для внутренних я что-то действительно такого не припомню.

Похоже что Яндекс последовал примеру Google и начал показывать в поиске страницы, которые закрыты от индексации. Наблюдаю на 2 сайтах. Что характерно, страницы со скриншота ниже закрыты при помощи тега <meta name="robots" content="noindex"/> и до кучи при помощи Disallow: /files/

В продолжение темы про директивы для поисковиков.
Наткнулся тут на комментарий Джона Мюллера пятилетней давности, котором он говорит о том, что директива canonical имеет для Google больший приоритет, чем мета robots со значением noindex, если вдруг они окажутся в коде одной страницы.
Честно говоря, полагал, что должно быть наоборот.