пятница, 31 июля 2020 г.

Реквием универсальному способу проверки аффилированности двух сайтов в Яндексе

В своей предыдущей статье «Аффилирование в Яндексе – мимикрия или амнистия?», посвященной анализу ранее работавших универсальных методов определения аффилированности двух сайтов в Яндексе, я сделал два предположения – либо изменился принцип ранжирования аффилированных сайтов («мимикрия»), либо все известные мне пары некогда аффилированных сайтов перестали быть аффилированными («амнистия»). Я попросил читателей поделиться известными им парами некогда аффилированных сайтов, а также сам стал исследовать поисковую выдачу на предмет поиска таковых. 
Хочу сказать огромное спасибо всем откликнувшимся на мою просьбу, ваши примеры реально помогли мне сделать вывод о том, какое из двух предположений верно.
Оказалось, что верно предположение о «мимикрии», т.е. изменился принцип ранжирования аффилированных сайтов. Если раньше аффилированные сайты группировались в одну группу, из которой в выдаче показывался только один наиболее релевантный документ, то теперь такой группировки аффилированных сайтов нет. Однако в выдаче, сгруппированной по сайтам, документы с тех из них, которые являются менее релевантными запросу, чем их аффилиат, получают некий дисконт (пост-штраф) к рассчитанному значению релевантности. 
Продемонстрирую это на примере. Во время анализа поисковой выдачи на предмет поиска аффилиатов в поле моего зрения попали сайт Столичного Института Экономики и Финансов https://www.rhll.ru/ и сайт учебного центра при этом же институте https://www.moscow-kursy.ru/. На обоих сайтах предлагаются различные курсы, например, бухгалтерские. 
Я сформировал следующий запрос, по которому первый сайт показывается на третьем месте, а второго нет в топ-50:
Эта выдача по умолчанию сгруппирована по сайтам. Я решил ее разгруппировать. Для этого я воспользовался недокументированным get-параметром &pag=u, который я упоминал с одной из своих статей «Параметры URL страницы выдачи Яндекса». Несмотря на то, что этот параметр уже давно по сути является артефактом, он, тем не менее, прекрасно работает. В принципе, разгруппировывать выдачу по сайтам можно и другими способами, добавляя в запрос документные операторы таким образом, чтоб они не искажали выдачу, но данный способ мне нравится больше всего, т.к. при его использовании исходный запрос остается неизменным. Так вот, в разгруппированной выдаче второй сайт появляется где-то в районе топ-20:
И это ведь выдача не по сайтам, а по документам, то есть в сгруппированной выдаче он должен был быть еще ближе к топу, т.к. в разгруппированной выше него попадается по нескольку документов с одного сайта. Напрашивается вывод, что в сгруппированной выдаче что-то ему мешает занять это место в топе. Я попробовал исключить из выдачи первый исследуемый сайт (не прибегая к документным операторам, ниже объясню почему). И, вуаля, второй сайт занял седьмое место на первой странице выдачи:
Таким образом мы определили, что мешал ему занять это место именно теперь исчезнувший из выдачи первый сайт.
Теперь поясню, почему я для исключения из выдачи второго сайта не пользовался документными операторами. Во-первых, исключать сайты из выдачи, используя документные операторы можно только с помощью уже недокументированного оператора отрицания ~~. А во-вторых, теперь связка оператора отрицания с документным оператором разгруппирует выдачу (чего не было ранее), что не позволит нам корректно определить аффилиат:
Так что для исключения из выдачи первого аффилиата следует использовать оператор отрицания без документного оператора, исключая, например, ключевое слово из его доменного имени или какое-нибудь слово, содержащееся на всех его страницах, но не содержащееся на страницах второго аффилиата (если таковое имеется).
Итак, получается, что в данном примере величина дисконта оказалась достаточной, чтоб отправить второй аффилиат за пределы топ-50 выдачи, но далеко не всегда это так.  Например, по другому запросу оба сайта находятся на первой странице выдачи – первый на первом месте, второй – на пятом:
 
Но исключение первого сайта ожидаемо подбрасывает второй на первое место:
То есть в данном случае величины дисконта не хватило, чтоб выдавить второй аффилиат даже из топ-5.
В общем, приходится констатировать факт, что аффилированность никуда не делась, просто все прежние универсальные способы определения аффилированности двух сайтов, основанные на принципе исчезновения одного из них при сужении выдачи на малое количество сайтов (в идеале – на два исследуемых сайта), оказываются теперь абсолютно неработоспособными. Но, как показывают мои примеры, аффилированность двух сайтов все-таки возможно определить, только придется делать это вручную, каждый раз подбирая запросы, подходящие для того, чтоб зафиксировать перемещение второго аффилиата в выдаче при исключении из нее первого. Универсальность же, являющаяся залогом возможности автоматизации, увы, пока недоступна.
И в заключении хочется заметить, что теперь аффилированность можно в прямом смысле этого слова называть фильтром, в то время как раньше это была все-таки группировка.


среда, 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 по-прежнему не находится:
Так что применять недокументированный оператор группировки в общем случае следует с осторожностью.

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