вторник, 18 апреля 2017 г.

Лайфхаки к выдаче Яндекса. Узнаем возраст документа без get-параметра how=tm.

В связи с тем, что Яндекс в последнее время основательно взялся за урезание языка запросов и прочих возможностей исследования выдачи, всё чаще встречаю в профессиональных сообществах вопросы об альтернативах тем или иным утраченным возможностям. Поэтому решил открыть рубрику «Лайфхаки», где буду в лаконичной форме предлагать искомые альтернативы для некоторых случаев.
Итак, лайфхак #1. Одной из наиболее востребованных является задача установления возраста страницы в Яндексе. Раньше она решалась с помощью применения get-параметра к URL страницы поисковой выдачи Яндекса how=tm – сортировки выдачи по времени документа. В сниппете сформированной таким образом выдачи для каждого документа указывалась дата, которая и идентифицировалась, как возраст документа с точки зрения Яндекса. С некоторых пор индикация даты документа в выдаче с использованием такой сортировки отсутствует (за исключением стандартной индикации «свежести» документов из «быстроботовской» примеси), хотя, сама сортировка, судя по всему, продолжает осуществляться корректно.  

Однако альтернативная возможность узнать возраст документа с точки зрения Яндекса на данный момент имеется. Для этого нужно воспользоваться сервисом Яндекс.XML и извлечь значение параметра <modtime> для нужной страницы в формате YYYYMMDDThhmmss ISO 8601:2004:


пятница, 14 апреля 2017 г.

Безвременная кончина операторов intext и inlink

Яндекс планомерно закручивает гайки реверс-инжинирингу алгоритма ранжирования. На днях тихой сапой почили в бозе недокументированные операторы intext: и inlink:
Они в своё время были упомянуты только в документации к продукту Яндекс.Сервер  - приложению для поиска в корпоративных сетях и поиска по сайту. Тем не менее оператор intext: полноценно работал и в большом поиске по вебу. Он обнулял значения ссылочных факторов. Если еще и несколько модифицировать базовый запрос таким образом, чтоб обнулились и поведенческие факторы, то можно было получить выдачу, более-менее пригодную для анализа текстовых факторов ранжирования.
Что же касается оператора inlink:, то работал он с некоторыми ограничениями, и полноценно его использовать удавалось только по правую сторону от оператора << (неранжирующее И). Однако это позволяло решить ряд интересных исследовательских и прикладных задач, например, задачу поиска по анкор-файлу.
Сейчас же, единственный заметный эффект от применения этих операторов заключается, похоже, только в отрубании «спектральной» примеси.

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

Поиск поддоменов сайта в индексе Яндекса и Google

В данной статье я хочу рассмотреть один из способов применения операторов языка запроса поисковых машин Яндекс и Google для решения полезной практической задачи – поиска поддоменов сайта, проиндексированных этими поисковыми машинами. Не редки случаи, когда разработчики сайта забывают закрыть от индексации поддомены сайта, на которых содержится бесполезная для поиска информация – копии текущей версии сайта, неактуальные версии сайта, отчеты анализаторов логов и прочая техническая и служебная информация. Захламление поискового индекса подобными данными в ряде случаев может негативно повлиять на позиции сайта. Поэтому желательно все подобные случаи выявить и запретить к индексации поисковыми роботами.
Решение задачи поиска поддоменов в поисковом индексе базируется на простой логической операции – последовательном отрицании при поиске по всему сайту уже известных нам поддоменов. Поиск по всему сайту и в Яндексе и в Google осуществляется с помощью одинакового оператора site:, для которого в качестве значения необходимо указать домен сайта. Например, site:yandex.ru или site:google.com.
Что же касается поиска по определенному поддомену, то в Яндексе это можно сделать с помощью документированного оператора host:. Необходимо иметь ввиду, что указание домена без www и c www дает разные результаты – проиндексированные страницы только с домена второго уровня и только с поддомена www соответственно :
Особенность оператора host: заключается в том, что он не чувствителен к виду протокола http или https, то есть с помощью этого оператора невозможно отделить в выдаче страницы с протоколами http и https друг от друга.
Таким образом, для поиска поддоменов сайта в Яндексе с помощью оператора отрицания ~~ на первом этапе убираем из поиска по всему сайту документы из корневого домена и/или поддомена www и получаем в выдаче документы с других поддоменов:
Отмечу, что здесь есть некоторая особенность. Дело в том, что, в случае достаточно большого количества поддоменов этот список может быть неполным (вообще связка операторов ~~ и host: весьма странным способом то ли группирует, то ли фильтрует результаты поиска), и его необходимо будет уточнять последовательным отрицанием имеющихся в списке поддоменов (при этом в выдаче могут появляться новые поддомены):
Соответственно возможности метода в общем случае ограничены вместимостью поисковой строки (на сегодня ограничение на длину поискового запроса в Яндексе составляет 400 символов).
Рекомендую использовать в URL страницы поисковой выдачи get-параметр &rd=0, который позволяет снять ограничение на показ документов с одинаковыми сниппетами (подробнее см. в моей статье «Параметры URL страницы выдачи Яндекса»).
В Google нет аналога яндексовскому оператору host:, однако поиск по конкретному поддомену там можно осуществлять с помощью недокументированного оператора inurl:, указав в качестве значения полный (включая протокол) адрес поддомена. Например: inurl:https://google.com или inurl:http://www.google.com. Здесь надо иметь ввиду, что оператор inurl: ищет вхождение заданной подстроки в URL документа:
Соответственно, данный способ подразумевает разделение в выдаче страниц с http и https протоколами. А если же указывать в качестве значения просто доменное имя без прокола, то нужного результата мы можем не добиться, т.к., к примеру, все поддомены в качестве подстроки будут включать в себя доменное имя.
Итого для поиска поддоменов сайта в Google с помощью оператора отрицания (минус) на первом этапе убираем последовательно из поиска по всему сайту документы из корневого домена и/или поддомена www по обоим проколам (в случае необходимости) и получаем в выдаче документы с других поддоменов:
В отличие от ситуации с Яндексом здесь какой-либо особой фильтрации результатов не замечено, кроме страндартной фильтрации результатов, которые «очень похожи на уже представленные выше». Стандартная фильтрация обходится добавлением в URL страницы выдачи get-параметра &filter=0 (подробнее см. в моей статье «Параметры URL страницы поисковой выдачи Google»). Равно как не замечено и группировок, поэтому также в случае большого количества поддоменов для большей информативности результатов будет полезно применение последовательного отрицания уже известных поддоменов, т.к. страницы с одного-двух поддоменов могут забить видимую выдачу.  Опять же, здесь мы, как и в случае с Яндексом, ограничены лимитом на длину поискового запроса, в Google он составляет 32 слова.
Кстати, в Яндексе есть также оператор inurl: (бывший некогда документированным, затем прошлым летом исчезнувший из официальной документации, но на данный момент корректно функционирующий) с точно такой же функцией поиска в адресе документа, но по причине того, что он в отличие от гугловского, полностью игнорирует заданный протокол (по сути вырезая его из подстроки), он не годится для решения поставленной задачи:


среда, 1 марта 2017 г.

Кастрация языка запросов Яндекса

31 января 2017 года в блоге разработчиков поисковой системы Яндекс появилась новость об изменении языка запросов, а именно, о прекращении поддержки ряда операторов:
  • & – поиск документов, в которых слова запроса, объединенные оператором, встречаются в одном предложении;
  • && и << – поиск заданных слов в пределах документа;
  • ~ – поиск документов, в которых заданное слово не содержится в одном предложении со словом, указанным до оператора;
  • () – группировка слов при сложных запросах;
  • !! – поиск слова, начальная форма которого указана в запросе.
На моей памяти предыдущее подобное объявление Яндексом о прекращении поддержки операторов случалось всего однажды – в сентябре 2007-го года – и было довольно резонансным, так как касалось операторов link (поиск страниц, ссылающихся на заданную) и anchor (поиск в текстах ссылок, ведущих на заданную страницу), являвшихся важным инструментов для аналитики ссылочного ранжирования.
После этого громких заявлений на данную тему уже не делалось, но часть операторов языка запросов прекратила свое существование, тихо исчезнув из документации (такие, например, как операторы задания веса для слова из запроса : и :: или оператор настройки мягкости для фильтрации по кворуму softness). С другой стороны, до сих пор поддерживаются операторы, никогда не входившие в официальную документацию для большого веб-поиска, а упоминавшиеся, например, только в документации к сервису поиска по сайту или корпоративной сети Яндекс.Сервер. О подобных операторах я писал в своих статьях «Сеанс поисковой магии. Недокументированные операторы языка запросов Яндекса» и «Недокументированные операторы языка запросов Яндекса. Продолжение сеанса поисковой магии».
Звоночки о том, что в языке запросов будет что-то меняться, начали поступать уже некоторое время назад. Так, например, оператор << не так давно стал некорректно работать справа от оператора url: (скриншот сделан до появления обсуждаемой новости):
Для сравнения – пример корректной работы оператора << справа от оператора site:
Операторы, о прекращении поддержки которых было объявлено 31 января, относились к операторам морфологии и поискового контекста и упоминание о них уже исчезло из документации по языку запросов Яндекс.Помощи.
К слову, последние изменения в документации языка запросов были зафиксированы примерно полгода назад, летом 2016 года. Тогда из документации по операторам поискового контекста безо всяких анонсов исчезли операторы расстояния /n, /+n, /-n, /(m n), &&/ n.
А из списка документных операторов исчезло упоминание об операторах:
  • title: - поиск по заголовкам документов (тег title);
  • inurl: - поиск по страницам, в адресе которых есть заданный фрагмент.
При этом обращает на себя внимание тот факт, что два последних оператора допускали применение в связке с официально упраздненным сейчас оператором группировки (), который использовался в случае, если запрос, который нужно было найти в соответствующем фрагменте страницы (заголовке или адресе), состоял из нескольких слов. Руководитель службы Яндекса по работе с веб-мастерами Михаил Сливинский в одном из обсуждений данной новости в соцсетях подтвердил, что последние изменения повлияют также на операторы title: и inurl:, они также будут отключены. Хотя, полагаю, что, возможно, не исключен вариант с частичной работоспособностью данных операторов, когда они будут корректно работать только в применении к единичным словам без использования оператора ().
Примечательно, что все тихо исчезнувшие из официальной документации прошлым летом операторы по факту продолжают на момент написания этой статьи работать корректно. Впрочем, как и операторы, официально упраздненные 31 января (за редким исключением, упомянутым выше). Однако сам факт появления новости о прекращении их поддержки неумолимо свидетельствует о том, что в любой момент можно ожидать изменений в их работе.
Несмотря на то, что в новости о прекращении поддержки операторов упомянуто, что они являются редко используемыми, думаю, что не ошибусь, предположив, что многочисленные SEO-сервисы активно использовали некоторые из них в промышленных масштабах. Возможно, это явилось одной из причин отключения операторов с целью уменьшить нагрузку на поиск от автоматических запросов. Причем, даже если задать вручную буквально несколько подряд запросов с использованием различных операторов, перед вами непременно появится капча, требующая подтвердить, что вы не робот. Это достаточно красноречиво свидетельствует о том, что Яндекс считает подобные запросы, скажем так, не совсем естественными. В любом случае, Яндекс оптимизирует производительность поиска, и посчитал поддержку части операторов слишком большой роскошью. По крайней мере, я не думаю, что отмена операторов связана исключительно с целью лишить SEO-специалистов инструментов для анализа поисковой выдачи, как это было с отключением операторов link и anchor без малого десять лет назад.
Обращает на себя внимание тот факт, что прекращается поддержка операторов, не имеющих прямых аналогов в задокументированном списке операторов языка запросов Google - главного конкурента Яндекса на российском поисковом рынке. Впрочем, в официальном списке Google есть небольшая оговорка о «часто используемых функциях». И реально работающих операторов поиска Google несколько больше, среди недокументированных операторов есть такие как
  • intitle: и allintitle: – поиск в заголовке страницы по одному слову и по фразе соответственно;
  • inurl: и allinurl: – поиск в адресе страницы по одному слову и по фразе соответственно;
  • intext: и allintext: – поиск только в тексте страницы по одному слову и по фразе соответственно;
  • inanchor: и allinanchor: – поиск только в тексте ссылок на страницу по одному слову и по фразе соответственно;
И так вот с учетом недокументированных, но работающих операторов Google, язык запросов Яндекса с отключением операторов title: и inurl: становится еще беднее, чем у основного конкурента.

Итак, язык запросов Яндекса, некогда бывший невероятно мощным, продолжает планомерно урезаться, что, несомненно, осложняет решение задач аналитических исследований поисковой выдачи. Из отключаемых в этот раз операторов особенно жаль терять операторы << и (), которые использовались для построения запросов, решающих ряд важных задач, в частности поиска по анкор-файлу (подробнее см. в моей статье «Сеанс поисковой магии. Поиск по анкор-файлу»). Судя по всему, придется искать новые варианты построения подобных запросов с использованием оставшихся в распоряжении операторов. И вполне возможно, что эта задача не относится к разряду невыполнимых.

вторник, 7 февраля 2017 г.

Синонимы в поисковой выдаче Google

Еще в 2010-м году в официальном блоге Google была опубликована статья «Helping computers understand language», в которой рассказывалось об учете синонимов ключевых слов запроса (в том числе и расшифровок аббревиатур) при ранжировании. Характерной особенностью учитываемых синонимов является то, что они «подсвечиваются» жирным шрифтом в сниппетах точно так же, как и базовые ключевые слова, входящие в запрос. Эта особенность существенно облегчает идентификацию синонимов для конкретного запроса. И сегодня я хотел бы поделиться одним способом, существенно облегчающим поиск всевозможных вариантов синонимов ключевых слов запроса.
Способ этот заключается в постепенном сужении поисковой выдачи путем исключения из поиска базовых ключевых слов и уже известных нам синонимов.
Итак, возьмем пример из упомянутой выше статьи – запрос [pictures developed with coffee]. Сразу же находим в сниппетах на первой странице выдачи подсвеченные синонимы для слова pictures photos и photographs:
Исключим с помощью оператора ‘‘ («минус») слова pictures, photos и photographs. В сниппетах наблюдаем подсвеченными различные вариации слова pictures, образованные с помощью замены букв на их аналоги с различными подстрочными и надстрочными (диактритическими) знаками:
Последовательно исключая подобные синонимы, мы обнаружим все возможные их значения. Единственный минус – синонимов может быть так много, что можно не уложиться в ограничение на 32 слова для поискового запроса. Именно это происходит для рассматриваемого базового запроса с последовательным исключением слова coffee и его синонимов, которые правда, все являются разнообразнейшими вариациями базового слова с добавлением диакритических знаков. Вот, к примеру, наиболее экзотические из них: Ĉõfféê, Cøffëë, Çófféé, Çófféé, Cøffęę, Çøffëé, čøffęë, Cøffęę.
В русскоязычных запросах, конечно же, вариантов синонимов с диактирическими знаками встречается намного меньше (в основном, в виде обозначения ударений), но зато есть своя особенность – зачастую приходится «минусовать» различные словоформы базового слова. Например, по запросу [дизайн сайта], чтобы «добраться» до обнаружения подсветки в сниппете слова site, надо «отминусовать» несколько словоформ слова сайт:
Ну и вообще, набор синонимов для базовых слов в русскоязычных запросах у Google довольно скудный, в основном это перевод на английский язык или транслитерация, расшифровка аббревиатур, а также переход из одной части речи в другую (например, достопримечательность -> достопримечательный). Но иногда встречаются и довольно любопытные варианты образования синонимов:
Какой логикой руководствовался Google, назначая синонимом для слова bgoperator (сайт bgoperator.ru принадлежит туроператору «Библио Глобус») слово Черногория, остается только догадываться, но больше ни одна из стран, куда организует туры «Библио Глобус», такой чести не удостоилась:


среда, 11 января 2017 г.

SEO-итоги 2016 года: В поисках кнопки «В ТОП»

Самое время подвести итоги событий, повлиявших на развитие отечественной SEO-индустрии в ушедшем году. 2016-й год оказался не так богат на громкие события, как 2015-й, но стал интересен тем, что начал проявлять более-менее устойчивые тенденции после встрясок «бурного» 2015-го.
В предыдущем 2015-м году Яндекс дал четко понять, что покупка ссылок, являвшаяся основным методом поискового продвижения сайтов практически целое десятилетие, объявлена им «вне закона». Неестественные (в подавляющем большинстве своем – платные) ссылки нейтрализуются в плане воздействия на ранжирование, покупатели и продавцы оных наказываются действенными методами. Однако, в 2016-м году команда Яндекса не предприняла практически никаких действий в плане продолжения психологического давления на данном направлении, посему пиар-эффект от энергичных действий предыдущего года несколько нивелировался. Платные ссылки, конечно же, не заработали в Яндексе, как пытаются представить представители ссылочной индустрии, но многие SEO-специалисты по инерции продолжают их покупать. Отчасти потому, что не представляют себе, как продвигать сайты, не покупая ссылок, отчасти потому, что в Google, в отличие от Яндекса, платные ссылки все еще достаточно эффективно оказывают влияние на ранжирование. Но тем не менее, годами работавшая парадигма «купил ссылок – попал в топ» по крайней мере в случае Яндекса потеряла своё сакральное значение.
Да и с собственно с устойчивым нахождением продвигаемого сайта в топе Яндекса стали возникать определенные сложности. Дело в том, что выдача на разных компьютерах и даже в разных браузерах, открытых на одном компьютере, стала довольно заметно различаться. Сначала грешили на пресловутую персонализацию выдачи, но даже при отключенных настройках персонализации данный эффект продолжал наблюдаться. В конце 2015 года сотрудники Яндекса сделали анонс нового подхода к релевантности документов. Подход этот заключается в искусственном подмешивании к топу выдачи документов, размеченных асессорами, как релевантные запросу, но по какой-то причине плохо ранжируемых самообучающимся алгоритмом. Это подмешивание осуществляется с целью собрать полезный пользовательский сигнал, позволяющий сделать более адекватным ранжирование подобных документов. Данный подход по названию статьи «Gathering Additional Feedback on Search Results by Multi-Armed Bandits with Respect to Production Ranking» получил название «многорукого бандита». И теперь практически любые пертурбации выдачи с легкой руки написавших данную статью яндексоидов объявляются многими SEO-специалистами как результаты «бандитских» проделок. Насколько в том или ином случае это имеет под собой основание – вопрос в общем-то открытый, действенных методов идентификации «бандитской» примеси так и не было найдено. Но, тем не менее, выявился непреодолимый факт, что фиксация позиций определенного сайта по определенному запросу на текущий момент перестала быть устойчивой величиной в промежуток между апдейтами.
Этот факт еще больше обострил проблему фиксации продаваемого SEO-специалистами результата. Позиции стали очень неустойчивой величиной. И все чаще возникают предложения фиксировать некую среднюю величину результатов измерения позиций.
На этой волне некоторые игроки SEO-рынка стараются развить тему фиксации результата по SEO-трафику. Тема, в общем-то небезынтересная, но имеющая некоторые проблемы – во-первых, со стороны заказчика нет понимания прозрачности того, что продаваемый поисковый трафик является естественным, а не искусственно сгенерированным «мотивированными» тем или иным образом пользователями. Во-вторых, как правило, SEO-специалистами не предлагается четких механизмов дифференциации поискового трафика по степени конвертируемости, и есть соблазн «выжечь семантику», то есть собрать максимально возможное количество трафика без его очистки от шлака, бесполезного в плане решения задач, стоящих перед сайтом. Зачастую, максимум, что делается – это исключается из учета собственных заслуг так называемый «брендированный» трафик, то есть, запросы, включающие в себя упоминание бренда клиента, по которым он должен быть в топе выдачи естественным образом (так называемые витальные ответы).
Но, по большому счету, проблема фиксации результата есть часть проблемы продаваемости услуг SEO-специалистов, и лежит гораздо глубже. Годами заказчик был приучен к тому, что собственно качество его сайта не играет большой роли в поисковом продвижении. Задача SEO-специалиста заключалась в косметических правках – «подшаманить» тайтлы, добавить SEO-текстов куда-нибудь поближе к подвалу да закупить ссылочек. Причем «ссылочки» действительно в достаточной мере позволяли решить задачу поискового продвижения. Но их время ушло, а методы работы с заказчиком остались прежними. И тут на сцену стали вылезать различные SEO-сервисы, пытающиеся закрыть нишу «косметического воздействия» – различные кластеризаторы, текстовые анализаторы и прочие измерители разнообразнейших «пузомерок», по большей части выдуманных их создателями и старательно продвигаемых ими в массы. В общем, в отечественной индустрии наступила эпоха сервисов ради сервисов. Эдакая борьба за вдруг освободившуюся вожделенную нишу большой красной кнопки «В ТОП».
Ну, а в сухом остатке среднестатистический заказчик не понимает и не желает понимать, что успех поискового продвижения его сайта лежит в глубокой переработке самого сайта как средства представления информации пользователю и взаимодействия с ним, а ищет счастья в «косметических процедурах», обильно предлагаемых со всех сторон.
Что же касается тенденций в деятельности разработчиков поисковых систем, то тут в 2016-м году на сцену вышел учет «мобильности» сайта, вернее мобильной адаптивности, то есть удобства его использования пользователями на экранах мобильных устройств с ограниченным разрешением. «Мобильная» выдача стала отличаться от основной как в Яндексе, так и в Google (в последнем – чуть раньше), получившей название «десктопной». В мобильной выдаче стали все чаще получать преимущество сайты, адаптированные к показу на мобильных устройствах. Вместе с тем бытует мнение, что мобильный трафик намного хуже конвертируется в продажи, чем десктопный, поэтому многие владельцы коммерческих сайтов не придают особого значения мобильной адаптируемости своих сайтов. Однако довольно интересным фактом является то, что Яндекс, судя по всему, не разделяет на данный момент учет поведенческих факторов в мобильной и декстопной выдаче. То есть у сайта, который очень неудобен для пользователей мобильных устройств, в виду ухудшения поведенческих характеристик их пользовательских сессий могут возникнуть проблемы с ранжированием и в десктопной выдаче. Этот факт делает проблему мобильной адаптивности сайта более насущной.
2016-й год ознаменовался анонсом Яндексом двух «именных» алгоритмов – «Владивосток» и «Палех». «Владивосток» как раз-таки касался учета мобильной адаптивности сайтов, а вот «Палех» имел целью улучшить качество выдачи по длинному хвосту низкочастотных запросов. Подобные запросы, как правило, состоят из нескольких слов, и далеко не всегда релевантные им документы имеют вхождения всех эти слов. Поэтому традиционные алгоритмы ранжирования на основе контекстуального сходства документа и запроса, не всегда хорошо отрабатывают подобные запросы. Сотрудники Яндекса поставили целью научиться понимать в первую очередь смысл запроса, а не искать контекстуальное сходство.  Насколько хорошо это у них получилось – покажет время, но пока что подобные изменения касаются довольно ограниченного пласта запросов, и, пожалуй, потенциально интересны только «выжигателям семантики».
В Google на мой взгляд, одним из самых интересных событий в плане изменений алгоритмов ранжирования, стало объявление о том, что алгоритм «Penguin», имеющий своей целью борьбу с поисковым спамом  (как текстовым, так и ссылочным, хотя среди SEO-специалистов принято часть алгоритма антиспама, касающегося текстовых факторов, называть «Пандой» по названию одного из первых релизов алгоритма борьбы с поисковым спамом, носившего название «Panda changes», а термин «Пингвин» употреблять только по отношению к ссылочному антиспаму), из надстройки стал обновляющейся в режиме реального времени частью ядра алгоритма.
В заключение хочу традиционно пожелать SEO-специалистам и владельцам сайтов удачи и высоких мест в поисковой выдаче по релевантным запросам. И не забывать, что залог успеха лежит в первую очередь в работе над сайтом, а не в «косметических процедурах» и поисках чудесной кнопки.

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