вторник, 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-специалистам и владельцам сайтов удачи и высоких мест в поисковой выдаче по релевантным запросам. И не забывать, что залог успеха лежит в первую очередь в работе над сайтом, а не в «косметических процедурах» и поисках чудесной кнопки.

вторник, 6 декабря 2016 г.

«Атипичная синонимия» в выдаче Яндекса – проделки «Палеха»?

В текущем году Яндекс уже во второй раз нас порадовал внедрением нового официального «именного» алгоритма ранжирования. И если февральский «Владивосток» касался только мобильной выдачи, то ноябрьский «Палех» был анонсирован для общей формулы. Вкратце – Палех предназначен для поиска таких ответов на запросы, которые не содержат ключевых слов, входящих в запрос, но тем не менее релевантны ему. Это особенно актуально для длинного хвоста низкочастотных запросов, когда пользователь формулирует запрос достаточно нечетко, не сумев подобрать «правильных» ключевых слов, по которым поисковая система может выдать ему релевантный ответ. Поэтому поисковику приходится подбирать некоторые «ассоциации» к исходному запросу.
Впрочем, проблема с подбором расширенных результатов поиска не нова, и Яндекс уже давно пытается ее решить. Первой ласточкой было внедрение в 2008-м году в алгоритме «Магадан» первых вариантов синонимов ключевых слов – перевода и транслитерации. Затем синонимы сильно расширились за счет создания специального словаря. Также было внедрение в 2010-м году в алгоритме «Краснодар» технологии «Спектр» – попытки расширить выдачу за счет учета возможных вариантов расширения потребностей пользователя, заданных в общем, достаточно неоднозначно сформулированном, запросе.
Но все эти нововведения не решали проблему релевантной выдачи для «длинного хвоста», и вот появился «Палех». И сразу же стала весьма интересной задача определения, какие именно результаты выдачи сформированы именно этим алгоритмом.
Об идентификации различных уже известных примесей к органической выдаче Яндекса, в том числе, и сформированной технологией «Спектр», я писал в своей статье «Примеси к органической выдачи Яндекса».
Примерно месяц назад (еще до анонса «Палеха») мне показали один любопытный запрос, отдельные результаты в выдаче по которому, заставили задуматься о том, что в ней могло появиться что-то новое. Выдача по запросу по названию русскоязычной школы «Адриатик Колледж», находящейся в черногорском городе Будва, содержит ссылки на документы, касающиеся других русскоязычных школ Черногории и не имеющие подсветки ключевых слов из запроса в сниппетах:
Оказывается, что эти страницы вообще не содержат слов запроса ни в контенте, ни в текстах входящих ссылок:
В общем-то, подобная картина характерна для документов, найденных с помощью одних только синонимов слов запроса. Так, например, находящийся на первом месте документ, имеет точно такие же свойства, демонстрируя нам подсвеченные синонимы (а именно, перевод слов запроса на английский язык) в сниппете:
Однако, мне удалось найти конструкцию запроса (с добавлением оператора отрицания с термином, заведомо не содержащимся в документе, например, произвольной абракадабры), при которой выдача для данных документов ведет себя по-разному, в одном случае документ продолжает находиться, в другом - нет:
Что дает возможность предположить, что документы, для которых в таком случае выдача пуста, попали в выдачу каким-то иным способом, нежели с помощью традиционного со времен релиза «Магадан» механизма учета синонимов. Назову это явление «атипичной синонимией».
Дальнейшее исследование показало, что документы, ведущие себя в выдаче по базовому запросу [адриатик колледж] как найденные с помощью «атипичной синонимии», достаточно хорошо находятся с помощью следующего запроса (по крайней мере, такими свойствами обладают четыре документа из топ-5):
Что позволяет предположить наличие некоей связи между запросами [адриатик колледж] и [русская школа в черногории] или схожим ему по смыслу и набору ключевых слов. Документ, который мы выбрали для примера идентификации «атипичной синонимии», также находится по запросу [русская школа в черногории], хоть и по тексту входящих ссылок:
Анонс алгоритма «Палех», в котором говорится, что семантический вектор стал использоваться несколько месяцев назад, наталкивает на мысль, что подобная «атипичная синонимия» может быть не чем иным, как результатом работы «Палеха».
Еще один пример «атипичной синонимии» я обнаружил у запросов, представляющих собой некоторые достаточно редко употребляемые русскоязычные варианты корейского бренда «Hyunday»:
Кроме запроса [хенде] «атипичная синонимия» наблюдается на запросах [хендей], [хэндэй], [хендеи], [хендаи], [хюнде].
Другие же (более распространенные?) русскоязычные варианты бренда, такие как [хендай] ведут себя, как «типичные» синонимы:
К ним также относятся запросы [хюндэй], [хюндай], [хюндаи] и др.
Я буду очень признателен, если кто-то из читателей найдет в выдаче подобные примеры «атипичной синонимии» и пришлет мне на е-мейл ludkiewicz@yandex.ru для исследования. А вдруг это действительно реальный способ идентифицировать примесь к органике, сформированную «Палехом».

понедельник, 7 ноября 2016 г.

Региональность в Google. Установка региона выдачи через браузер Chrome

В своей предыдущей статье «Региональность в Google. Get-параметр uule» я рассказал об одном способе получить у себя в браузере выдачу для любого интересующего вас региона посредством добавления в URL страницы поисковой выдачи get-параметра uule со значением, соответствующим  данному региону. Однако есть и альтернативный способ – убедить Google в том, что вы находитесь в интересующем вас регионе. Сделать это можно через настройки браузера Chrome.
Итак, согласно информации, представленной в Справке по веб-поиску, Google может автоматически определять местоположение пользователя на основе IP-адреса, истории местоположений (если она включена) или истории поисковых запросов. Для начала мы должны в браузере Chome позволить Google учитывать наше местоположение по IP-адресу, если это еще не было сделано. Допустим, вы видите внизу страницы поисковой выдачи, что ваше местоположение определяется исходя из вашей истории поиска. Нужно нажать ссылку «Указать мое местоположение» и в появившемся всплывающем окне дать сайту www.google.ru разрешение на доступ к данным о вашем местоположении:
Итак, я физически нахожусь в Туле, и после выданного разрешения местоположение в командной строке браузера Chrome появляется значок означающий, что загруженный сайт отслеживает ваше местоположение, а в низу страницы поисковой выдачи Google местоположение сменяется на «Тула – С этого компьютера» – это автоматически определяет Google на основании моего IP-адреса. Обновив страницу, я получаю выдачу для своего региона – Тулы:

Чтобы получить в браузере Chrome выдачу Google для другого региона (в качестве примера возьмем Брянск), необходимо знать географические координаты интересующего вас места. Это можно сделать разными способами. Например, в сервисах Google Maps или Яндекс.Карты, введя название населенного пункта в поисковую строку – искомые координаты содержатся в URL страницы выдачи:
А в Яндекс.Картах дополнительно еще и в контенте самой страницы:
Итак, у нас есть координаты нужного места. В настройках браузера Chome с загруженной в него страницей поисковой выдачи выбираем пункты меню «Дополнительные инструменты» – «Инструменты разработчика» (также активируются нажатием кнопки F12 или комбинации кнопок Ctrl+Chift+I).
Далее идем по цепочке пунктов меню пункт меню «Customize and control DevTools» – «More tools» – «Sensors». В открывшейся вкладке «Sensors» для пункта «Geolocation» выбираем значение «Сustom location…» и вводим имеющиеся у нас координаты широты («Latitude») и долготы («Longitude») нужного нам населенного пункта (в нашем случае – Брянска). После этого еще раз нажимаем ссылку «Учитывать моё местоположение» (вместо неё так же может быть ссылка «Обновить»):
Теперь еще раз задаем поисковый запрос и видим у себя в браузере Chrome выдачу для населенного пункта, географические координаты которого мы ввели на предыдущем шаге, в нашем случае – Брянска:

Теперь в этом окне можно задавать сколько угодно поисковых запросов и получать для них выдачу для заданного координатами региона. Закрытие этого окна и открытие нового сбросит введенные географические настройки, и вы опять будете получать выдачу для своего региона, определяемого автоматически на основе вашего IP-адреса.

вторник, 11 октября 2016 г.

Региональность в Google. Get-параметр uule.

В своей предыдущей статье «Региональность в Google» я упоминал о весьма актуальной проблеме для регионального поиска Google – возможности получения в своем браузере поисковой выдачи для произвольного региона, а не только для того, к какому автоматически отнесет ваш компьютер сам Google на основании вашего IP-адреса. В качестве одного из решений упоминался инструмент для предварительного просмотра объявлений – Ad Preview Tool. Однако в текущем виде этот инструмент имеет весьма существенные ограничения – результаты показываются в виде скриншота первой страницы выдачи, содержащей только 10 результатов, и поэтому с его помощью заглянуть дальше, чем за топ-10, нельзя.
Между тем результаты работы инструмента Ad Preview Tool не всегда выдавались в виде скриншота. Так, например, на форуме Searchengines.guru в одной из дискуссий за декабрь 2015 года упоминается о том, что можно было получить результат поиска в заданном регионе в виде URL. И приводится пример подобного URL для региона «Красноярск»:
https://www.google.ru/search?q=%D1%80%D0%B5%D0%BC%D0%BE%D0%BD%D1%82+%D0%BD%D0%BE%D1%83%D1%82%D0%B0&
newwindow=1&hl=ru&tci=p:30000,g:1011941&adtest=on&noj=1&igu=1&
uule=w+CAIQICIjS3Jhc25veWFyc2ssS3Jhc25veWFyc2sgS3JhaSxSdXNzaWE&nomo=1&nota=1&
source=lnms&sa=X&ved=0ahUKEwimqq658LrJAhUFinIKHe5tDOsQ_AUIBygA&biw=1920&
bih=961&dpr=1&glp=1&ip=0.0.0.0
И действительно, находясь в другом регионе, для данного URL мы имеем возможность наблюдать внизу страницы выдачи упоминание, что поиск осуществляется именно по региону «Красноярск»:
Осталось понять, какой из многочисленных get-параметров данного URL поисковой выдачи отвечает за указание региона. Несложные манипуляции показывают, что удаление из URL параметра &uule=w+CAIQICIjS3Jhc25veWFyc2ssS3Jhc25veWFyc2sgS3JhaSxSdXNzaWE приводят к тому, что регион выдачи меняется на определяемый Google автоматически (в моем случае это Тула):
Теперь для другого запроса сами построим URL выдачи, содержащий только get-параметры q (текст запроса) и uule с обозначенным выше значением, и убеждаемся, что опять видим выдачу для Красноярска:
Итак, теперь остается понять, каким образом построить нужное значение параметра uule для произвольного региона.
Для этого я хочу вас отослать к замечательной статье https://moz.com/ugc/geolocation-the-ultimate-tip-to-emulate-local-search , где подробно рассказывается о том, каким образом строится значение этого параметра. Для этого нужно:
  1. Определить каноническое название на латинице интересующего региона с помощью инструмента Google Geographical Targeting.
В случае Красноярска получаем значение
Krasnoyarsk,Krasnoyarsk Krai,Russia
  1. Определить длину канонического названия в символах.
В нашем случае это значение будет равно 35.
  1. Определить значение спецсимвола (<secretkey>) с помощью таблицы
В нашем случае это будет символ j.
  1. Перекодировать каноническое название в формат Base64 (<base64encode>). Например, это можно сделать с помощью инструмента на сайте https://www.base64encode.org/.
В нашем случае мы получим строку
S3Jhc25veWFyc2ssS3Jhc25veWFyc2sgS3JhaSxSdXNzaWE
  1. Скомпоновать значение параметра uule по формуле
w+CAIQICI плюс <secretkey> плюс <base64encode>
Итого имеем:
w+CAIQICIjS3Jhc25veWFyc2ssS3Jhc25veWFyc2sgS3JhaSxSdXNzaWE
Что полностью совпадает со значением параметра uule из рассмотренного нами ранее примера.
Таким образом по данному алгоритму можно сконструировать значение параметра uule для любого региона, имеющего каноническое название в системе географического таргетинга Google, и добавив этот параметр со сконструированным значением в URL страницы поисковой выдачи Google, получить в своем браузере выдачу для этого региона.
В качестве контрольного примера возьмем любой другой регион, например, «Брянск», и пройдем по шагам алгоритма:
  1. Bryansk,Bryansk Oblast,Russia
  2. 29
  3. d
  4. QnJ5YW5zayxCcnlhbnNrIE9ibGFzdCxSdXNzaWE
  5. w+CAIQICIdQnJ5YW5zayxCcnlhbnNrIE9ibGFzdCxSdXNzaWE
Подставив полученную строку в качестве значения get-параметра uule, получаем у себя в браузере выдачу для Брянска, что подтверждается пометкой внизу страницы поисковой выдачи:


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