среда, 3 июня 2020 г.

Аффилирование в Яндексе – мимикрия или амнистия?

Задача определения аффилирования двух сайтов в Яндексе всегда была одной из важнейших в SEO-аналитике. До недавнего времени было несколько рабочих способов ее решения, в основе которых лежал один основополагающий принцип: необходимо было определенным образом сформировать поисковую выдачу, чтоб можно было убедится в следующем.
Если в поисковой выдаче находятся документы с обоих проверяемых на аффилированность сайтов, и при этом имеет место группировка выдачи по сайтам, то эти сайты не аффилированны.
Если же при отсутствии группировки по сайтам в выдаче присутствуют документы с обоих сайтов, а при наличии группировки – только с одного, то проверяемые сайты аффилированы.
Этот принцип накладывает существенные ограничения на выбор способа определения аффилированности двух сайтов.
Нам нужно максимально сузить не сгруппированную по сайтам выдачу так, чтоб в ней присутствовали документы с обоих сайтов. А потом суметь ее сгруппировать, чтоб проверить, сохраняется ли в ней присутствие документов с обоих сайтов, либо один из них исчезает. Либо продемонстрировать в сгруппированной по сайтам поисковой выдаче наличие документов с обоих. 
В разное время я опубликовал три способа определения аффилированности сайтов в выдаче Яндекса, основанные на этом принципе.
Первый способ был самый простой и изящный. Выдача сужалась до самого минимума – двух документов (по одному с каждого сайта) с помощью оператора url:. Но у этого оператора, равно как и у большинства документных операторов текущего официального довольно скудного языка запросов Яндекса (а именно, site:, host: и rhost:, исключение составляет только оператор domain:, но об этом чуть позже), есть одно свойство – они разгруппируют выдачу по доменам. Поэтому после сужения построенную выдачу необходимо было сгруппировать по доменам, чтоб проверить наличие аффилированности. И это делалось довольно простым, но интересным способом – добавлением к запросу любого документного оператора (как правило, использовались операторы url: или site:) с произвольным значением (естественно, отличным от значений операторов url:, использовавшихся в базовом запросе) после оператора отрицания ~~. Эта связка оператора отрицания и документного оператора вызывала обратный эффект применению документного оператора – она группировала выдачу.
Но, к сожалению, после периодических кастраций языка запросов Яндекса оператор отрицания ~~ потерял статус документированного, хоть и продолжал корректно работать во многих случаях. Но самое неприятное, что несколько месяцев назад исчез чудесный эффект обратной группировки по сайтам, присущий его связке с документными операторами. Минус один способ, увы.
Второй способ базировался на использовании для сужения выдачи точных цитат со страниц проверяемых на аффилированных сайтов. Но со временем логика языка запросов Яндекса сильно изменилась, и теперь он не желает корректно применять оператор | («логическое ИЛИ») к точным фразам (заключенным в оператор «кавычки»).  Итоге в поисковой выдаче по запросам, сформированным путем применения оператора | к точным фразам получается сущая белиберда, не связанная с логикой запроса. Минус два способа, увы и ах.
В запасе остался третий способ, основанный на единственном документированном документом (прошу прощения за невольный каламбур) операторе domain:, который в отличие от остальных документных операторов не разгруппировывает выдачу по сайтам. Но и он некоторое время назад начал выкидывать фортели. 
Дело в том, что из достаточно большого известных мне пар аффилированных доменов (и не только пар, но и троек, четверок и т.д.) проверка с использованием этого способа вдруг перестала показывать их аффилированность. Для примера возьмем пару сайтов, использовавшихся мной в качестве примера аффилированных в последней статье об этом методе. Сейчас они прекрасно чувствуют себя на одной странице в выдаче, сформированной с использованием оператора domain:
То есть с точки зрения озвученного мною выше принципа определения аффилиатов, не считаются аффилированными. Более того, есть и четвертый метод, о которым я еще не писал. Он основывался на использовании для сужения выдачи некогда ставшим недокументированным операторе inurl:, который подобно оператору domain: не разгруппировывает поисковую выдачу.  Так вот, он тоже сейчас пасует на всех известных мне случаях аффилированных пар сайтов, в том числе и на вышеупомянутой:
Вместо с тем, как мои практические наблюдения, так и мнения других SEO-специалистов, высказываемые в приватных профессиональных беседах, говорят за то, что сам по себе аффилиат-фильтр никуда не делся.  Но очень похоже на то, что он мимикрировал, сменив свою природу с жесткой группировки аффилированных сайтов в поисковой выдаче на нечто иное, например, некий дисконт (пост-штраф) к значению релевантности для страниц одного из аффилиатов, который сочтен алгоритмом ранжирования менее релевантным, чем другой. Если это действительно так, то на возможности адекватной проверки двух сайтов на аффилированность, к моему большому сожалению, можно поставить крест. Но всё-таки хочется и не исключать вероятность какой-то иной причины наблюдаеиого эффекта, например, чем черт не шутит, масштабной амнистии аффилиатов, под которую попали все известные мне пары. Поэтому я буду очень признателен, если читатели пришлют мне на e-mail ludkiewicz@ya.ru свои примеры некогда аффилированных пар сайтов для пополнения моей тестовой выборки.

понедельник, 25 мая 2020 г.

Определяем быстроботовскую примесь в Яндексе

В своей недавней статье «Очистка органической выдачи Яндекса от примесей» я упоминал о таком виде примеси как Свежие результаты, в среде SEO-специалистов носящей название «быстроботовской» примеси.

Идентификация относится ли конкретный документ в выдаче Яндекса к быстроботовской примеси, бывает очень полезна при решении аналитических задач. Дело в том, что документы, индексируемые быстроботом и попадающие в выдачу в течение короткого времени, ранжируются иначе, чем документы из основного индекса, и поэтому выдачу от них необходимо очищать при анализе основного алгоритма.
Тогда я рекомендовал идентифицировать быстроботовскую примесь по наличию специальных меток свежести документа («N минут назад», «N часов назад», «вчера», «позавчера» или просто дата не старше 3-4-х дней). Но похоже, подобная метка не является необходимым признаком документа, проиндексированного быстроботом.
Поясню на примере. Так, например, на момент написания статьи в индексе Яндекса присутствует следующий документ без специальной метки свежести в сниппете:
 
Однако, если мы заглянем в сохраненную копию, то увидим, что документ был проиндексирован через 3 минуты после его появления на сайте (судя по индикации времени, прошедшего с момента публикации пользователем этого материала):
Так быстро после их появления документы могут с большой вероятностью попасть в индекс через быстроботовскую примесь. Однако, как уже было сказано выше, метка свежести, характерная для этой примеси, в сниппете данного документа отсутствует. 
Изучая поведение документов из быстроботовской примеси, я заметил одну интересную особенность. В отличие от документов из основного индекса, быстроботовские документы показываются в выдаче по запросу, состоящему из связки текстового запроса и документного оператора даже в том случае, когда документ нерелевантен текстовому запросу из этой связки.
Например, возьмем текстовый запрос в виде абракадабры, выдача по которому пуста:
 
И добавим к этому текстовому запросу документный оператор url: с адресом рассматриваемого документа в качестве значения. Вопреки логике этот документ показывается в выдаче:
Причем, расширив выдачу на весь сайт с помощью документного оператора site:, мы увидим, что в выдаче в подавляющем большинстве находятся документы с быстроботовской меткой в сниппете. 
А в сохраненных копиях тех, у кого эта метка отсутствует, наблюдаются признаки того, что документ проиндексирован быстроботом.
Таким образом, можно с определенной долей уверенности утверждать, что подобным способом мы можем проверять документ без быстроботовской метки в сниппете на предмет того, проиндексирован ли он быстроботом. Как правило, это срабатывает на документах трех-четырехдневной давности. Настоятельно рекомендую делать перепроверку с использованием нескольких достаточно сильно отличающихся друг от друга вариантов абракадабр. Дело в том, что некоторые абракадабры Яндекс интерпретирует как опечатки и пытается подобрать варианты замены, не предупреждая об этом пользователя, и в этом случае можно получить ложноположительные срабатывания метода. 
Интересно, что добавление к текстовому запросу в рассматриваемой связке операторов группы «Морфология и поисковый контекст» +плюс» – поиск документов, в которых обязательно присутствует выделенное слово) или ""кавычки» – поиск по цитате), чудесный эффект быстроботовской примеси пропадает:


Воспользуемся этим фактом, чтобы убедиться в том, что сохраненная копия для документа, который рассматривался в первом примере, совпадает с той, что находится в индексе (ведь может быть иначе, о чем я писал в своей статье «Сохраненные копии страниц – это не то, что находится в индексе»). Не мешало бы это проверить, ведь именно по сохраненной копии страницы мы делали предположение о быстроботном характере ее индексации. По точной фразе их сохраненной копии о времени публикации сообщения рассматриваемая страница находится:
А, значит, в индексе действительно та копия, которая показывается как сохраненная. Кстати, для документов из быстроботной примеси я еще не встречал примеров рассинхронизации сохраненной и проиндексированной копий.


четверг, 2 апреля 2020 г.

Сужение выдачи в Яндексе – лайфхаки

Одной и важных исследовательских задач SEO-аналитики является сужение выдачи на определенную группу документов или сайтов. 
Попробуем задать запрос поиск, ограничив выдачу только двумя документами – главными страницами сайта Яндекса и русскоязычного сайта Google. 
Для сужения поиска на заданные URL воспользуемся документированным оператором url:, относящемуся к группе «Документные операторы», который прекрасно справляется со своей задачей в случае поиска по одному документу:
Однако его применение «в лоб» в случае с двумя документами задачу не решает:
 
В этом случае решить задачу помогает небольшой трюк – добавление между операторами url: документированного оператора | (поиск документов, в которых присутствует любое слово из запроса). Согласно официальной документации этот оператор относится к группе «Морфология и поисковый контекст» и его следует применять к ключевым словам. Однако, как показывает практика, он прекрасно справляется с задачей, будучи примененным и к документным операторам:
   
Убедимся, что оператор | применяется именно к операторам url: т.е. имеет логику 
поиск (url:yandex.ru | url:www.google.ru),
а не делит запрос на две части, имея логику 
(поиск url:yandex.ru) | (url:www.google.ru).
Для этого возьмем запрос, по которому ищется главная страница Яндекса, но не ищется главная страница Google:
 
Если оператор | работает как нам надо, то мы в результатах поиска увидим только один Яндекс, если нет – то оба документа. Убеждаемся, что имеет место первый вариант:
Также все прекрасно работает и в случае с тремя документами:
Проверка на логику работы в случае трех документов также дает ожидаемый результат:

Таким же образом можно организовывать поиск сужением на несколько сайтов, используя вместо оператора url: оператор site:
Также исследовательские задачи SEO-аналитики могут требовать исключение определенных документов или сайтов из поисковой выдачи по запросу. 
Для наглядности возьмем запрос, по которому в поисковой выдаче находится всего три сайта:


В текущем официальном языке запросов Яндекса есть документированный оператор отрицания: («минус»). Однако он работает только со словами и неприменим для документных операторов. В случае применения его с документным оператором, он попросту игнорируется, и вместо удаления документа или сайта из выдачи мы получаем поиск по этому документу или сайту:
К текущему моменту официальный язык запросов Яндекса сжался буквально до нескольких документированных операторов – 8 документных и 6 морфологии и поискового контекста. Хотя ранее Яндекс мог похвастаться весьма обширным языком запросов, позволяющим решать разнообразнейшие поисковые задачи. 
Однако некоторые операторы, бывшие когда-то документированными, а сейчас исчезнувшие из официального списка, продолжают работать и помогать решать задачи, с которыми только лишь с помощью документированных операторов справиться не получается.
И в данном случае нам приходит на помощь бывший некогда документированным оператор отрицания ~~двойная тильда»)
Он прекрасно справляется в поставленной задачей, очищая выдачу как от заданного сайта в связке c оператором site:
Так и от заданного документа в связке с оператором url:
Причем можно исключать из выдачи несколько сайтов или документов, применяя оператор последовательно к каждому:
Либо можно сгруппировать исключаемые сайты иди документы, используя уже упоминавшийся документированный оператор | в связке с еще одним оператором, бывшим некогда документированным, но потом исчезнувшим из языка запросов – оператором группировки ()скобки»):
Без оператора группировки оператор отрицания будет применяться только к одному сайту или документу, т.е. в данном случае автоматической группировки не происходит:
Любопытно, что в других случаях оператор группировки может не работать. Например, нам не удастся с его помощью изменить логику учета операторов в примере, который рассматривался в первом случае. После применения оператора группировки главная страница сайта Google по-прежнему не находится:
Так что применять недокументированный оператор группировки в общем случае следует с осторожностью.

вторник, 3 марта 2020 г.

Очистка органической выдачи Яндекса от примесей


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

Можно выделить два типа документов, которые не являются органическими результатами поиска. Первый тип (я бы назвал его внешней примесью) – это документы, которые отсутствуют в результатах выдачи сервиса Яндекс.XML. В обычной выдаче их можно визуально отличить от органики по различным признакам. К внешней примеси можно отнести:
  1. Рекламные места в результатах поиска (контекстная реклама).
Сотрудники Яндекса, несомненно, очень бы хотели, чтоб рекламные места на странице поисковой выдачи ничем бы не отличались от органики. Однако, им все-таки приходится помечать контекстную рекламу. В «Правилах показа Яндекс.Директ» указывается, что «Показ Рекламных объявлений (далее по тексту также — «объявления») на Рекламных местах может сопровождаться пометкой: "Яндекс.Директ", "Директ", "Реклама", "₽" или "Р"». Причем, с любопытной оговорочкой: «В связи с техническими ограничениями пометка может быть сокращена либо отсутствовать». 
На страницах поисковой выдачи на данный момент для маркировки рекламных объявлений используется слово «реклама», написанное более мелким шрифтом, чем шрифт, используемый в объявлении. И в некоторых случаях эта пометка действительно может практически исчезать, вырождаясь буквально до одной буквы. Например, в мобильной выдаче:
В остальном же рекламные объявления практически ничем не отличаются от сниппетов органики. Ну, разве что, у рекламных объявлений никогда не бывает ссылки «Читать ещё >». Впрочем, она не всегда присутствует и в органических сниппетах, так что этот признак нельзя считать надежным средством идентификации рекламы в обычной выдаче. Также следует учитывать, что рекламные объявления могут показываться не только до или после органических результатов, но и между ними.

  1. Поисковые колдунщики, фактовые и объектные ответы.
Поисковые колдунщики - это специальным образом оформленные ответы, найденные на собственных сервисах Яндекса. Подробнее о них можно прочесть на сайте Технологии Яндекса
Фактовый и объектный ответы – это специальные карточки с кратким ответом на вопрос, расположенные над результатами поиска и справа от них соответственно. 
Ввиду специфики представления спутать эти элементы с органическими результатами поиска очень сложно.
Впрочем, как уже указывалось ранее, если у Вас есть возможность получать выдачу от сервиса Яндекс.XML, то задача идентификации внешней примеси становится неактуальной – таких документов в XML выдаче просто нет.
Второй тип примеси к органике (назовем его внутренней примесью) находится в результатах поиска, получаемых от сервиса Яндекс.XML. К нему можно отнести:
  1. Витальные ответы. 
Это документы, считающиеся однозначно лучшим ответом на запрос, например, главная страница официального сайта компании по запросу ее бренда. По сути это органические результаты, получающие огромный искусственный буст к рассчитанному основным алгоритмом значению релевантности запросу, который прочно ставит их на первые места выдачи. По внешнему виду витальные ответы не отличимы от органических сниппетов. Их идентификация возможно только по анализу выдачи сервиса Яндекс.XML. У витальных ответов значение поля name параметра <categ> содержит специальный идентификатор, включающий в себя подстроку UngroupVital, например, <categ attr="d" name="UngroupVital59.ru"/>. Причем, витальных ответов может быть несколько:
  1. Свежие результаты
    Свежие результаты показываются в ответ на «событийные запросы», для которых по мнению Яндекса важны свежие ответы. В сеошной среде для таких ответов используется термин «быстроботовская примесь». Это результаты, составленные из документов, индексируемых специальным роботом – быстроботом – и в течение очень короткого времени попадающих в индекс.  Ранжирование их осуществляется специальным алгоритмом, и поэтому очистка органики от подобных результатов актуальна при анализе работы основного алгоритма. Идентифицитовать быстроботовскую примесь можно по наличию специальных меток свежести документа («N минут назад», «N часов назад», «вчера», «позавчера»):
  1. Разгруппированные результаты
По умолчанию результаты поиска с одного сайта группируются в поисковой выдаче, и мы видим только один результат с каждого сайта, самый релевантный запросу. B XML выдаче у сгруппированных по сайту органических результатов значение поля name параметра <categ> представляет собой доменное имя, например, <categ attr="d" name="yandex.ru"/>. Но иногда Яндекс оказывает преференции отдельным страницам с отдельных сайтов и показывает их в выдаче вне группировки по сайту. Так, например, по запросу геморрой можно увидеть два результата c сайта kp.ru:
В XML выдаче один из этих результатов имеет в качестве значения поля name параметра <categ> доменное имя, а вот второй – малопонятную конструкцию MiddleUngroup_kp.ru_68.ru:
Также в качестве значения поля name параметра <categ> может фигурировать не доменное имя сайта, а URL документа. И это тоже может быть признаком того, что такие результаты не являются органическими.
Так, например, в последнее время сайт принадлежащего Яндексу сервиса Едадил замечен в топах по огромному количеству запросов, причем, зачастую контент страниц сайта этим запросам совершенно нерелевантен. Такое впечатление, что документы с этого сайта получили значительный буст к своему регулярному значению релевантности запросам. Типичный пример:
 
В XML выдаче в значение поля name параметра <categ> для этого результата содержит именно URL документа, а не доменное имя сайта:

Я рекомендую все результаты, которые в XML выдаче имеют значение поля name параметра <categ>, отличное от доменного имени сайта, на котором находятся, исключать из анализа органической выдачи, так как есть определенные основания считать, что эти результаты либо обрабатываются не основным алгоритмом ранжирования либо получают некоторый буст к значению релевантности, вычисленному основным алгоритмом.

  1. Собственные проекты Яндекса
Так как есть определенные основания утверждать, что Яндекс может давать буст к органическому значению релевантности запросу, вычисленному основным алгоритмом для документов собственных проектов (как расположенных на домене yandex.ru, например, Яндекс.Район, Яндекс.Дзен или Яндекс.Коллекции, так и на других доменах, например, Едадил, Кинопоиск или Авто.ру), то рекомендую такие ответы исключать из анализа органической выдачи в любом случае, даже если в качестве значения поля name параметра <categ> XML выдачи содержится доменное имя сайта. 

Blog Archive

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