Home » Аналитика
Показаны сообщения с ярлыком Аналитика. Показать все сообщения

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

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

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


Автор: на пятница, 31 июля 2020 г. - 1 комментарий:

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

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

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

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


Автор: на понедельник, 25 мая 2020 г. - Комментариев нет:

вторник, 6 августа 2019 г.

Неканонический canonical

4 июля 2019 года в блоге разработчиков Яндекса появилась заметка «Неканонические страницы в Поиске», в которой разработчики поисковой системы поведали о своем новом отношении к директиве canonical. Теперь они собираются выполнять ее только в том случае, если страница, которая ее содержит, несущественно отличается о той, которая указана в этой директиве как каноническая.
К слову сказать, Google также может проигнорировать директиву canonical, если содержимое канонической и неканонической страницы существенно различается. Причем я встречал курьезные случаи, когда не согласившись с канонической страницей, выбранной пользователем, Google не смог выбрать каноническую страницу сам, при этом все-таки выкинув неканоническую страницу из индекса:
У директивы canonical есть два неоспоримых преимущества. Во-первых, происходит так называемая консолидация URL, при которой объединяются нетекстовые факторы канонической и неканонической страниц. Так, например, Google в своей «Справке» упоминает об объединении ссылок и переходов. Что касается Яндекса, то о том, что факторы неканонической страницы учитываются для канонической, говорил сотрудник компании Александр Смирнов на Шестой Вебмастерской.
Во-вторых, несмотря на то, что неканоническая страница исключается из поискового индекса, поисковики знают о ссылках, которые на ней находятся, и включают ее в ссылочную структуру сайта. Так, например, собирательный сотрудников службы поддержки Яндекса Платон Щукин высказывался следующим образом: «При этом ссылки на товары, которые находятся на неканонических страницах, также будут известны индексирующему роботу».
Поэтому, на мой взгляд, использование директивы canonical – наиболее предпочтительный инструмент объединения страниц сайта, вписанных в ссылочную структуру сайта, хотя и не самый оптимальный с точки зрения оптимизации краулингового бюджета, о чем я писал в своей предыдущей статье.
Однако теперь с его помощью может не получится объединить страницы, содержание которых существенно различается. Порассуждаем, в каких случаях это может произойти.
Первое, что приходит в голову – это дубликаты одной и той же страницы с динамическим контентом, расположенные на разных URL. Поисковые боты сканируют эти URL в разные моменты времени и получают различный контент. В итоге в индексе может накопиться некоторое количество копий по сути одной и той же страницы.
Если URL дубликатов отличаются от канонического URL только наличием get-параметров, то для Яндекса можно воспользоваться директивой Clean-Param в файле robots.txt. Но этот метод не является универсальным, т.к. Google эту директиву не поддерживает. В случае Google можно будет воспользоваться инструментом «Параметры URL» в Google Search Console. Однако поисковые машины не уточняют, будет ли в данном случае происходить консолидация URL без параметров и URL с параметрами, сканирование которых запрещается. Поэтому данный способ я бы предпочел применять только в крайнем случае.
Консолидация URL произойдет, если поисковому роботу при посещении неканонической страницы отдать код статуса 301 Moved Permanently с редиректом на каноническую. Причем, обычным пользователям можно показывать неканоническую страницу с кодом статуса 200 ОК. Нарушением с точки зрения поисковых систем это не будет. Криминал возникает там, где поисковику показывают содержимое, отличное от того, что получает пользователь.  Здесь же поисковик не будет получать никакого содержимого.
Однако в отличие от директивы canonical, в данном случае у поисковика не будет информации о ссылках, ведущих с неканонической страницы. Поэтому данный метод я рекомендую использовать в тех случаях, когда неканонические страницы не вписаны в ссылочную структуру сайта, например, для страниц с get-параметрами в URL, не влияющими на ее содержимое – utm-метки, идентификаторы сессии. 
В случае же, когда неканоническая страница является достаточно важным элементом ссылочной структуры сайта, например, страницы пагинации или страницы с результатами фильтрации, то демонстрация поисковому роботу кода статуса 301, на мой взгляд, не будет оптимальным решением.
Так же как и практикуемый некоторыми SEO-специалистами способ, который заключается в размещении на странице мета-тега robots со значением ”noindex, follow”. В данном случае поисковик получит информацию о содержащихся на страницах ссылках, но исключит эту страницу из индекса без консолидации с каноническим URL. Да и к тому же со временем и информация о ссылках может перестать учитываться. 
Итого результаты анализа можно свести в небольшую таблицу:
Способ
Консолидация
Учет ссылок
canonical
+
+
Clean-Param / Инструмент «Параметры URL»
?
-
301 для ботов
+
-
<meta name="robots" content="noindex, follow">
-
+

Таким образом достойной альтернативы директиве canonical для страниц, вписанных в структуру сайту, не просматривается.  Остается только надеяться, что поисковик, проигнорировав эту директиву из-за существенных различий содержимого неканонической страницы с содержимым страницы, указанной как каноническая, будет считать в этом случае страницу действительно качественной. И что такие страницы не будут впоследствии удаляться из индекса как некачественные без консолидации URL и учёта ссылок с них, да еще и с негативным вкладом в «карму сайта». 

Автор: на вторник, 6 августа 2019 г. - Комментариев нет:

понедельник, 15 апреля 2019 г.

Исследуем новые операторы before: и after: в Google

9 апреля 2019 года Google в официальном твиттере разработчиков поиска порадовал неожиданной новостью – вводом новых операторов поиска before: и after:.
В последнее время, что в Google, что в Яндексе, наблюдается отчетливая тенденция на урезание поискового функционала (вспомнить хотя бы недавнюю отмену Google оператора info:), а тут вдруг случается его расширение. Новые операторы по сути являются некоторыми аналогами яндексовского оператора date: и позволяют фильтровать поисковую выдачу в определенные временные периоды по дате последнего изменения документов (в терминах Google, причем довольно непрозрачных, как мы убедимся далее). Подобные фильтры бывают полезны при решении ряда задач SEO-аналитики, и, в целом, отрадно, что в Google теперь тоже есть подобная возможность.
Однако, к моему сожалению, в данном случае не произошло унификации поисковых функционалов двух крупнейших поисковиков Рунета, и, хотя с помощью операторов before: и after: в Google и date: в Яндексе можно решать аналогичные задачи, однако логика применения операторов все-таки различается. Так, например, для того, чтобы найти релевантные запросу документы за определенную дату в Google, в отличие от Яндекса, придется сооружать конструкцию из двух операторов. И, как мы убедимся далее, все равно не получается найти корректного решения.
В данной статье я постараюсь исследовать некоторые свойства новых операторов Google, взяв в качестве «подопытного кролика» сайт своего SEO-блога. 
На момент написания статьи Google показывает в выдаче 63 страницы с этого сайта, причем, в силу небольшого числа страниц это число нетрудно проверить, просто сосчитав количество результатов на странице, с настроенной выдачей по 100 результатов:
Однако применение к результатам поиска операторов before: или after: с заведомо покрывающими все возможные результаты значениями, оставляет в выдаче только по 40 результатов:
И действительно, можно найти проиндексированные страницы с сайта, применение к которым операторов before: и after: дает пустую выдачу. Например:
Получается, что не все страницы имеют дату с точки зрения операторов before: и after: (а в данном случае это без малого четверть страниц с сайта), даже не смотря на наличии даты в сниппете. Этот факт следует учитывать при анализе выдачи с использованием данных операторов.
Теперь попробуем составить конструкцию для поиска документов в Google за определенную дату.   Для главной страницы исследуемого сайта Google показывает на момент написания статьи в сниппете дату 11 февраля 2019 года (что хорошо видно из первого сниппета статьи). Главная страница находится в выдаче, если в эту дату взять в качестве значения как для оператора before:, так и для оператора after:
Если же для оператора before: дату уменьшить на один день, а для оператора after: дату увеличить на один день, то главная страница исчезает из выдачи, что явно свидетельствует о том, что ее дата с точки зрения этих операторов – именно 11 февраля 2009:
Причем, отметим, что количество страниц выдачи в обоих случаях уменьшается на две (в первом – с 35 до 33, во втором – с 7 до 5). Логично предположить, что с датой 11 февраля 2019 года на сайте по мнению Google должно находиться две страницы.
Попробуем сконструировать запрос, скомбинировав оба оператора с одинаковым значением 2019-02-11. Ожидаемо видим в выдаче главную страницу, однако здесь что-то явно не так. На втором месте страница с другой датой в сниппете, а всего результатов 63 – как если бы операторы к запросу не применялись:
Получается, что подобная конструкция (когда значения операторов совпадают) является некорректной. Ведь такая же картина наблюдается, если выбирать такие значения операторов before: и after:, которые задают пустой временной промежуток:
Каким же тогда должен быть запрос, которым можно найти выдачу в Google за определенную дату? Искомый результат получаем, если увеличить на один день значение оператора before: или же увеличить на один день значение оператора after:, то есть расширив фильтр с одного дня на два. И вот они, те самые два искомых документа от 11 февраля 2019 года:
Однако, в данном случае, нам просто повезло, что на сайте нет документов, датированных днем ранее или днем позже, которые тоже должны были попасть в эту расширенную на два дня выдачу. В чем мы можем убедиться, изменив границы двухдневного окна на период, когда есть документы, датированные идущими подряд днями:
Итого имеем, что на текущий момент задачу поиска документов за определенный день в Google с помощью новых операторов решить корректно, увы, нельзя. В отличие от Яндекса, где на подобную задачу как раз и ориентирован оператор date:.
И в заключение хочется обратить внимание на довольно странную логику определения даты документа в Google. Так, главная страница исследуемого сайта на момент написания статьи имеет дату 11 февраля 2019, что показывается в сниппете и подтверждается выдачей, сформированной с помощью операторов before: и after:. Однако в том же сниппете мы видим фрагмент текста, который относится к новости с гораздо поздней датой:
 
Почему же Google выбрал в качестве даты страницы дату новости двухмесячной давности при том, что страница явно проиндексирована не далее, как несколько дней назад, причем ее контент не один раз за это время изменился, остается только догадываться.
В общем, в сухом остатке имеем, что данное нововведение Google несомненно достойно того, чтоб его приветствовать, однако при его использовании для задач SEO-аналитики необходимо учитывать определенные нюансы.

Автор: на понедельник, 15 апреля 2019 г. - 1 комментарий:
Подписаться на: Сообщения (Atom)

Blog Archive

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