среда, 16 мая 2018 г.

Рекламная мимикрия под фильтром

Во второй половине апреля сего года многие вебмастера, занимающиеся поддержкой так называемых «контентных» проектов, монетизирующихся за счет размещения на своих страницах контекстной рекламы, начали массово получать в сервисе Яндекс.Вебмастер малоприятные сообщения о фатальной ошибке «Малополезный контент, спам, избыток рекламы»:
Судя по активности в теме форума Searchengines.guru, в которой развернулась дискуссия по данной проблеме, количество практически одновременно попавших под данный фильтр сайтов, достаточно велико. Что наводит на мысль об очередном обновлении алгоритма антиспама.
И действительно 24 апреля в блоге Яндекса для вебмастеров появилась запись «О рекламе, которая вводит в заблуждение», которая подтвердила эту версию, внеся некоторую конкретику: «Мы обновили алгоритм, определяющий влияние рекламы на удобство использования сайта, улучшив определение страниц с рекламой, вводящей пользователей в заблуждение и мешающей навигации по сайту (например, маскирующуюся под элементы интерфейса сайта)».
Проанализировав высказывания представителей Яндекса в различных дискуссиях по данной проблеме на различных площадках (в том числе и в блоге Яндекс.Вебмастера), можно с определенностью утверждать, что данное обновление направлено на распознавание рекламных ссылок, которые обладают следующими свойствами:
  1. явно не обозначены, как рекламные, при этом имитируя элементы навигации по сайту, на котором демонстрируются;
  2. описание ссылок не соответствует контенту страниц, на которые они ведут.
При этом сотрудники Яндекса утверждают, что нововведения направлены не против конкретной рекламной платформы. Однако массовость санкций говорит за то, что под них наверняка попадает какой-то достаточно популярный среди вебмастеров формат. И действительно, оказывается, что в указанный паттерн идеально укладывается один из наиболее кликабельных форматов рекламных объявлений системы контекстной рекламы Google Adsense – «Адаптивные блоки ссылок». Во-первых, эти блоки действительно адаптируются под интерфейс сайта, на котором размещаются, во-вторых, нередки ситуации, когда тексты ссылок не соответствуют содержимому страниц, на которые они ведут.
Так, например, вот такой типичный адаптивный блок ссылок Google Adsense, расположенный на странице со статьей про укладку ламината на информационном сайте, неискушенный пользователь может действительно принять за элемент внутренней навигации по сайту:
Малозаметная надпись «Объявления, связанные с запросом» особой ясности для пользователя о том, что этот блок является рекламным, не вносит, да, и появляться она стала не так давно, судя по обсуждению на форуме Searchengines.guru. Тем более такой яcности не вносит микроскопический треугольный логотип ассоциации Digital Advertising Alliance (в которую входит компания Google) в верхнем правом углу рекламного блока. Итак, первое условие для срабатывания нового фильтра – мимикрия под элементы навигационного интерфейса сайта – соблюдено.
К тому же при клике на ссылку данного блока пользователь попадает на страницу рекламного сервиса Google, где ему в большинстве случаев предлагается рекламная ссылка совсем по другой теме:
То есть соблюдается и второе условие для срабатывания фильтра – несоответствие контента целевой страницы содержимому рекламного объявления. Бинго! Можно резать.
Очень похоже на то, что новый алгоритм пытается каким-то образом сопоставить текст рекламного объявления с контентом страницы, на которую он ведет. И в случае наличия несоответствия накладывает санкции на рекламную площадку.  Таким образом страдают не все рекламные площадки, использующие определенный рекламный формат, а только те, которым не посчастливилось разместить у себя рекламные объявления, ведущие на нерелевантный им контент. Этим вполне могут объясняться и сообщения вебмастеров о том, что в ряде случаев пометка о нарушении исчезает без каких-либо действий по изменению формата рекламных объявлений – видимо, в определенный момент вследствие естественной ротации рекламы боты Яндекса просто перестают обнаруживать на сайте «неправильные» объявления.
В общем, как-то так удачно совпало, что один из наиболее популярных рекламных форматов основного конкурента Яндекса идеально подходит под условия срабатывания его нового фильтра. Хочется думать, что это не более чем совпадение.
Справедливости ради стоит упомянуть, что Яндекс и сам отнюдь не лишен в склонности к мимикрии своих рекламных форматов под элементы страниц, на которых они размещаются. Так, например, формат объявлений Директа на странице поисковой выдачи сейчас практически неотличим от сниппетов органических результатов поиска, а пометка «Реклама» рядом с ними становится все менее и менее заметной. Не удивлюсь, что скоро ее можно будет разглядеть только на высокочётких и высококонтрастных мониторах дизайнеров Яндекса. И то, если знать точно, где ее искать. Ну, а собственные сервисы Яндекса, подмешиваемые в выдачу, и вовсе не нуждаются в каких-либо отличающих их от органики пометках:
Точно так же довольно ловко мимикрируют объявления Директа под формат ленты навигации Яндекс.Дзен, отличаясь по сути лишь скромным малозаметным сереньким шильдиком с надписью «Яндекс.Директ»:

А теперь вопрос – многие ли неискушенные пользователи понимают, что «Яндекс.Директ» – это реклама?
В общем, похоже, что своя мимикрия всяко ближе к телу.

пятница, 20 апреля 2018 г.

Яндексовский оператор "минус" - всё?.. Уфф, нет, ещё дышит...

Оставшийся единственным документированным из всех операторов отрицания Яндекса оператор ("минус") внезапно полностью прекратил свою работу.
Причем, в официальной документации по языку запросов он продолжает фигурировать:
Но вот выдача по приведенному в документации примеру демонстрирует его полнейшую неработоспособность. Такое впечатление, что этот оператор просто игнорируется:
Напомню, что в прошлом году прекратили своё существование и исчезли из документации операторы отрицания ~ и ~~.
Интересно, что мы наблюдаем на этот раз – планомерное продолжение политики на урезание функционала языка запросов или же просто очередной пример ставших уже обыденностью глюков и багов?


UPD. Оказывается, что слухи о смерти оператора ("минус"), похоже, слегка преувеличены, и с ним не везёт только залогинившимся в свой аккаунт пользователям Яндекса (спасибо Евгению Кулакову за указание на этот факт). В случае разлогинивания обнаруживается пропащая работоспособность оператора. Правда, только в органике, виджет справа от органики продолжает явно игнорировать оператор отрицания:
Так, что, жив, курилка! Но, похоже, при этом таки серьезно болен…


вторник, 10 апреля 2018 г.

Безвременная кончина директивы Host в Яндексе

Изменения в поисковом функционале Яндекса продолжают демонстрировать стабильную тенденцию на урезание – ничего нового уже давно не добавляется, а вот многое из старого планомерно перестает поддерживаться. В марте текущего года очередной жертвой этого процесса стала директива Host для файла robots.txt.
12 марта 2018 года Яндекс в своем блоге для вебмастеров анонсировал скорое прекращение поддержки директивы Host, а уже 20 марта констатировал сей факт, сопроводив его новыми подробными инструкциями по переезду с помощью 301-го редиректа.
Директива Host как рекомендация для робота-зеркальщика о выборе главного зеркала была введена еще в начале прошлого десятилетия, если не ошибаюсь, в Рамблере, и со временем стала поддерживаться другими российскими поисковиками. На данный момент она содержится в документации поисковой системы Mail.Ru. Google эту директиву никогда не поддерживал.
Яндекс долгое время использовал эту директиву как рекомендацию для указания главного зеркала наряду с серверным редиректом. В 2011-м году для случаев выбора предпочтительного домена для индексирования из вариантов с www или без www, в сервисе Яндекс.Вебмастер появился инструмент «Главное зеркало», для которого был заявлено, что «такой способ выбора главного зеркала имеет больший приоритет, чем директива Host, но меньший, чем редирект (301, 302)».
Удивительно, но не смотря на заявленное главенство приоритета серверного редиректа перед остальными способами указания главного зеркала, сотрудники Яндекса никогда не рекомендовали его применять. Дело в том, что при использовании редиректа в Яндексе типичной ситуацией было выпадение редиректящего сайта из индекса до того момента, пока проиндексируется сайт, на который указывает редирект. И даже если сайт, являющийся целью редиректа, уже был проиндексирован, то все равно процесс выпадения редиректящего сайта происходил быстрее, чем его подклейка в качестве второстепенного зеркала к цели редиректа. В итоге характеристики, влияющие на позиции, а, следовательно, и поисковый трафик, переходили от второстепенного к главному зеркалу далеко не сразу, процесс мог затянуться на месяцы. Поэтому намного более надежным способом переклейки главного зеркала была директива Host, т.к. сайт, указанный как второстепенное зеркало, находился в индексе непосредственно до момента переклейки.
Одну из проблемных ситуаций, в которой необходимо было поменять главное и второстепенное зеркало местами, так описывал в своей инструкции по деликатному переезду с http на https собирательный образ сотрудников службы поддержки Яндекса Платон Щукин: «Процесс в целом ничем не отличается от склейки, только в этом случае я особенно не рекомендую использовать редирект для переезда: получится, что главное зеркало недоступно из-за редиректа, а цель редиректа - это неглавное зеркало и в поиск попасть не сможет. В результате в поиск страницы не смогут попасть совсем. В такой ситуации устанавливайте директиву "Host: https://site.ru", используйте "Переезд сайта", адрес в поиске будет изменён в течение нескольких недель».
Сейчас этот совет Платона Щукина перечеркнут с пометкой о том, что он устарел, и сотрудники Яндекса, отменив поддержку директивы Host, утверждают, что переклейка сайта с помощью постранично настроенного 301-го редиректа будет занимать всего несколько дней. Однако это будет возможно только в том случае, если в связке с 301-м редиректом будет использоваться инструмент «Переезд сайта», подразумевающий наличие подтвержденных прав на оба сайта.
Инструмент «Переезд сайта» можно использовать для склейки зеркал и без настройки редиректа, однако в таком случае оперативность не гарантируется и срок склейки может затянуться на несколько недель. Стоит заметить, в этом случае, как и раньше в случае директивы Host, второстепенное зеркало будет гарантированно находится в индексе, и поэтому этот способ могут выбрать наиболее осторожные владельцы сайтов, готовые пожертвовать временем ради минимизации рисков потери трафика, пусть и кратковременной. Тем более, что в комментариях к новости Яндекса об отмене поддержки директивы Host уже встречаются совсем свежие печальные истории потери трафика при переезде с помощью 301-го редиректа:
В случае же, когда нет возможности подтвердить права на оба сайта, придется пользоваться только 301-м редиректом без поддержки инструментом «Переезд сайта». Сотрудник Яндекса Елена Першина утверждает, что склейка должна произойти, но отсутствия проблем не гарантирует:
Склейка сайтов без использования инструмента «Переезд сайта» также весьма актуальна для тех случаев, когда переезд сайта осуществляется с целью ухода из-под наложенных на него санкций поисковика. Так как инструмент «Переезд сайта» требует наличия подтверждения прав владельца на оба сайта, то не надо быть семи пядей во лбу, чтобы понимать, что в случае наличия такой информации у Яндекса, санкции очень быстро переедут со старого на новый сайт. Если же у поисковика достоверной информации о связи между владельцами склеиваемых сайтов нет, то ему следует исключить возможность попытки нанесения целенаправленного вреда конкуренту путем подклейки к его сайту своего скомпрометированного сайта в качестве второстепенного зеркала с целью переноса санкций. Здесь поисковику придется оценивать вероятность наличия реальной связи между владельцами сайтов на основе косвенных признаков, каковыми, например, могут являться идентичность структуры и контента сайтов до переезда.
Кстати, в свете изменений в процедуре переезда сайтов в Яндексе интересен также и вопрос возможных изменений степени полноты переноса характеристик сайта на новый домен. Ведь до сих пор при склейке зеркал с второстепенного зеркала на главное переносились явно не все характеристики. Например, нельзя было предать возраст сайта, что было сделано для предотвращения манипуляций с «состариванием» сайтов с помощью подклейки к ним возрастных «дропов».
В любом случае, отказ от директивы Host в пользу 301-го редиректа является еще одним шагом Яндекса в процессе унификации своего функционала с функционалом Google, для которого 301-й редирект изначально являлся основной процедурой для указания главного зеркала при склейке сайтов. Напомню, что в прошлом году Яндекс расстался с частью операторов языка запросов, не имевших аналогов в Google, что я отмечал в своей статье «Кастрация языка запросов Яндекса». Вполне возможно, что в скором времени следует ожидать от Яндекса очередных шагов по прекращению поддержки других элементов своего функционала, не имеющих аналогов в Google. К наиболее известным из них можно отнести тег noindex, а также директивы файла robots.txt Clean-param и Crawl-Delay.


вторник, 27 марта 2018 г.

Субъективная классификация современного отечественного SEO

Как-то вдруг в одном закрытом сообществе зашел разговор за перспективы современного отечественного SEO. Много игроков, много вопросов, всяк кулик своё болото хвалит, всяк хват тянет одеяло на себя, но мне было интересно классифицировать игроков по типам. Итого моя классификация, сугубо субъективная.
Я вижу по меньшей мере четыре типа:
1) Поточные компании. "Регулярная армия". Есть один-два-три толковых специалиста, которые по сути ничего не решают, либо работают с VIP-клиентами, либо делают "аналитику", которую надо натянуть на поток, а это противоречивые вещи. В итоге аналитика аналитикой, а поток потоком, в лучшем случае аналитик пишет достаточно простые к исполнению потоком чек-листы.  По факту поток заказов делают так называемые джуниоры-мидлы-синьоры, которые работают по стандартным схемам "собрал семантику - нагеренил лендинги - проспамил меты и сео-тексты" ("накупил ссылок" уже почти отвалилось).
2) Бутики. "Частные военные компании". Это те, кто не доросли до поточных, но очень хотят. Толковых специалистов – ноль или одна вторая, пытаются облизывать клиентов, брать харизмой фронтмена, но компетенций не хватает. Предел мечтаний - запилить свой сервис, и подсадить на него как можно большее количество подписчиков.
3) Фрилансеры. "Партизаны". Тут полный разброд, Попадаются толковые, но большинство некомпетентны. Портят рынок первым двум категориям.
4) Инхаус. "Личная охрана". Позволить могут немногие, но по факту самый предпочтительный вариант. Ибо есть личная ответственность за результат, являющаяся стимулом профессионально развиваться, не садясь на иглу поточных схем.

понедельник, 19 марта 2018 г.

Лайфхак №3.1. Еще один альтернативный метод определения аффилиатов в Яндексе с использованием документированных операторов языка запроса

Несмотря на то, что гибкий и универсальный способ определения аффилированности двух сайтов в Яндексе, предложенный мной в статье «Проверка аффилированности двух сайтов в Яндексе», на данный момент является рабочим, тот факт, что он использует оператор отрицания ~~, поддержка которого Яндексом была официально прекращена, делает его не очень надежным. В принципе, это оператор можно заменить другим оператором отрицания ~, но он также уже официально не поддерживается. А единственный оставшийся документированным оператор отрицания (минус) нужного эффекта не даёт. И несмотря на то, что на данный момент в связке с оператором url: операторы ~~ и ~ обеспечивают принудительную группировку по сайтам разгруппированной в результате использования оператора url: выдачи (что является сутью предложенного метода), в любой момент можно ожидать потери работоспособности этого функционала. Тем более, что операторы ~~ и ~ уже частично потеряли свою работоспособность, о чем я писал в своей статье «Новая логика работы операторов языка запросов Яндекса. Морфология и поисковый контекст». В связи с этим возникает необходимость поиска альтернативного метода опеределения аффилированности двух сайтов, не зависящего от операторов, поддержка которых прекращена.
Одну из альтернатив я представил в статье «Определение аффилиатов в Яндексе – поиск альтернативных способов». Сутью этого метода являлось нахождение запросов, состоящих из точных фраз, взятых из контента главных страниц исследуемых сайтов, и формирование из них поискового запроса путем компоновки их через документированный ператор | (логическое ИЛИ). Важным свойством выдачи по такому запросу должно быть ее жесткое ограничение по количеству документов (в идеале все результаты должны помещаться на одну страницу), чтобы можно было достоверно оценить наличие или отсутствие одного из сайтов в выдаче. Это существенно повышает требования к выбираемым из контента страниц фразам, и, следовательно, ограничивает возможность автоматизации данного способа.
Поэтому я продолжил поиск более гибкого и универсального способа. В отличие от документных операторов url:, site:, host: и rhost:, оператор domain: не производит разгруппировки выдачи по сайтам, и в то же время его можно использовать для построения выдачи, в которой исследуемые сайты могут находится достаточно близко к топу, что важно для анализа.
Возьмем в качестве исследуемых сайты из моей предыдущей статьи «Определение аффилиатов в Яндексе – поиск альтернативных способов», которые определяются старым методом, как аффилированные (замечу, что сейчас нет необходимости использовать оператор | между операторами url:):
При поиске с помощью оператора domain: по их доменным именам 2-го уровня, они находятся достаточно близко к тому выдачи:
Теперь компонуем выдачу из этих двух запросов. На первой странице видим только один из двух сайтов:
Попробуем разгруппировать эту выдачу по сайтам. В своей статье «Параметры URL страницы выдачи Яндекса» я упоминал про get-параметр pag=u, который обеспечивает разгруппировку результатов выдачи по сайтам и который можно использовать для поиска отфильтрованных аффилиатов в выдаче. Добавляя этот get-параметр в URL страницы поисковой выдачи, видим появление в ней второго сайта:
Таким образом можно сделать вывод об аффилированности этих двух сайтов. Данный метод представляется гораздо менее трудоемким и лучше поддающимся автоматизации, чем представленный в предыдущей статье.
Также можно разгруппировать выдачу и с помощью добавления в запрос любого оператора из группы url:, site:, host: и rhost: (чтобы не увеличивать число документов в выдаче, целесообразно будет задавать в качестве их значения какую-нибудь абракадабру). В этом случае определенное неудобство состоит в том, что запрос фактически изменяется, и анализируемые сайты могут весьма существенно смещаться в выдаче. Так, для рассматриваемого примера анализируемые сайты несколько смещаются вниз, но, тем не менее, попадают на первую страницу выдачу при выводе по 50 результатов, что существенно облегчает анализ:


вторник, 13 февраля 2018 г.

Лайфхак №5. Альтернативный способ поиска поддоменов в Яндексе с помощью документированных операторов

В начале ноября 2017 года в рассылке Searchengines.ru вышла статья SEO-специалиста интернет-магазина «220 Вольт» Павла Лукина «Поиск поддоменов в Яндексе с помощью документированных операторов», в которой был предложен метод решения заявленной задачи, в основу которого была положена идея последовательного отрицания ключевых слов, являющихся префиксами поддоменов. Я знаю Павла, как отличного специалиста в области SEO, мы одно время довольно плотно общались в рамках моих консультаций по продвижению интернет-магазина «220 Вольт», где работает Павел, но, на мой взгляд, предложенная им реализация своей идеи не совсем корректна. И я хотел бы в данной статье предложить более корректный метод реализации озвученной им идеи.
Напомню, что до произошедшей в прошлом году отмены Яндексом поддержки ряда операторов, в числе которых был оператор отрицания ~~, поставленная задача решалась способом, предложенным мною в статье «Поиск поддоменов сайта в индексе Яндекса и Google». В основу этого способа была положена идея последовательного отрицания при поиске по сайту уже известных нам поддоменов. Однако к концу прошлого года операторы отрицания ~~ и ~ частично потеряли свою работоспособность, став по сути аналогом единственного оставшегося документированным оператора отрицания (минус). Утратив при этом важное свойство – корректно работать с документными операторами, т.е. исключать из поиска страницы и сайты (о чем я писал в своей недавней статье «Новая логика работы операторов языка запросов Яндекса. Морфология и поисковый контекст»).
Павел Лукин, учитывая, что одним из текстовых факторов ранжирования является вхождение запроса в URL, предложил вместо ставшего недоступным отрицания поддоменов использовать с помощью документированного оператора (минус) отрицание ключевых слов, являющихся префиксами поддоменов. Павел обнаружил, что этот оператор некорректно работает справа от документного оператора site:, т.е. не гарантирует исключение страниц, в URL которых входит ключевое слово, к которому он применяется. Кстати, это легко видно на следующем примере:
Вместо оператора site: Павел предложил использовать другой документный оператор rhost:, предположив, что справа от этого оператора оператор отрицания (минус) работает корректно. Однако можно наглядно продемонстрировать, что это не так, на следующих примерах:
Суть моей реализации идеи, предложенной Павлом, состоит в том, чтобы использовать оператор отрицания (минус) не справа, а слева от документного оператора. А, в свою очередь, справа от оператора (минус) использовать какое-либо ключевое слово. В качестве такого ключевого слова удобно взять доменное имя 2-го уровня рассматриваемого сайта, т.к. запросу, состоящему из него, будут релевантны все страницы сайта благодаря фактору вхождения ключевого слова в URL. Т.е. для рассматриваемого примера запрос будет выглядеть следующим образом:
Справедливости ради стоит отметить, что Павел упоминал эту реализацию в своей последующей статье «Оператор «минус» в Яндексе: особенности работы, применение для SEO», но не сделал ее подробного анализа, поэтому я считаю нужным его сделать. Анализ показывает, что подобное использование оператора отрицания работает корректно для префиксов доменов, состоящих только из букв, с оператором site:
Равно как и с оператором rhost:
К сожалению, данная реализация (так же, как и реализация, предложенная Павлом), не работает для отрицания префиксов доменов, состоящих только из цифр:
Это происходит по той причине, что оператор отрицания (минус) некорректно работает при применении к ключевым словам, которые состоят только из цифр:
Если же префикс домена является цифробуквенной комбинацией, то его отрицание предложенным способом также не дает желаемого результата:
Однако для тех случаев, когда в цифробуквенной комбинации встречаются несколько букв подряд, нужный результат обеспечивает отрицание этой буквенной подстроки:
Это также связано с особенностью применения оператора отрицания (минус) к ключевым словам, являющимися цифробуквенными комбинациями.


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