среда, 23 июня 2010 г.

Интервью Мэтта Катса (Matt Cutts) 14 марта 2010 года.

Это интервью я перевел довольно давно. Впервые ссылка на него мне попалась на форуме searchengines.ru, его начинала переводить участник форума webcat, но потом по каким то причинам дело застопорилось. Мне это интервью показалось интересным и важным, и я стал его внимательно, "с карандашом в руке" изучать. В результате получился полный перевод. Я предложил его Ольге для публикации в ее сео-блоге. Во-первых, потому, что начинала перевод она, а во-вторых, потому что тогда у меня и блога то не было :)

Перевод был опубликован по обоюдному согласию. Ольга еще доработала его, внесла кое-какие изменения и разделила на несколько частей. Мой вариант валялся у меня в гугл-доках и сейчас вот решил выложить его тут. Основная причина - чтобы было одним постом. Мне, по крайней мере, так удобнее и читать и искать.

Выделения в тексте - мои. Отметил моменты, наиболее меня заинтересовавшие.

Интервью Мэтта Катса (Matt Cutts), руководителя команды веб-спама компании Google.Проводил интервью Эрик Энге (Eric Enge).

Опубликовано: 14 марта, 2010 года.
Оригинал: http://www.stonetemple.com/articles/interview-matt-cutts-012510.shtml
Перевод: Виталий Богомолов.

Eric Enge: Давайте поговорим о концепции лимитов на сканирование. Мое понимание этой концепции заключается в том, что зашедший на сайт Googlebot заранее знает, сколько страниц ему нужно скачать сегодня, и покидает сайт после того как заберет эти страницы.

Matt Cutts: Я попробую рассказать о вещах, которые нужно принимать во внимание. Во первых, понятия лимита на сканирование не существует. Многие считают, что на каждом домене сканируется только определенное количество страниц, но робот-паук работает по другому.

Для нашего робота нет жесткого лимита. Можете считать, что количество забираемых им страниц примерно зависит от вашего PageRank. Если у вас много внешних ссылок на главную страницу, то он ее безусловно скачает. Если главная страница ссылается на другие страницы сайта, они будут получать PageRank и бот тоже их заберет. Но по мере углубления в структуру сайта PageRank страниц будет убывать.

С другой стороны, страницы с низким PageRank вашего сайта соревнуются с большим количеством страниц с таким же либо более высоким PageRank. Очень много страниц в Сети имеют очень маленький либо близкий к нулю PageRank . Страницы, на которые имеется много ссылок, обнаруживаются и сканируются довольно быстро. Страницы с низким PageRank будут сканироваться не так часто.

Рассматривая понятие лимитов на сканирование, нужно понимать, что нет жестких ограничений для сканирующего бота, есть концепция "нагрузки на хост". Нагрузка на хост определяется максимальным количеством подключений, которое конкретный веб-сервер может обслуживать одновременно. Представим, что ваш веб-сервер может обслуживать только одного бота. Это позволит нам забирать каждый раз по одной странице. Это будет очень-очень низкая нагрузка на хост, по сравнению с такими сайтами как Facebook или Twitter, которые могут выдерживать очень высокую нагрузку на хост, потому что они обслуживают очень много одновременных подключений.

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



Eric Enge: Т.е. два основных фактора. Первый - это PageRank, влияющий на определение количества страниц, которое нужно забрать с сайта. Но и нагрузка на хост тоже влияет.

Matt Cutts: Правильно. Для большинства сайтов определяющим является первый фактор, когда PageRank и другие данные определяют, насколько глубоко мы пойдем внутрь вашего сайта. Однако, возможно что нагрузка на хост тоже повлияет. Это подводит нас к теме дублирующегося контента. Допустим, мы забрали с сайта три страницы и обнаружили, что они являются дубликатами. Мы выкинем две страницы из трех и оставим только одну. Такой контент не выглядит слишком хорошим. Мы можем решить, что не стоит забирать слишком много страниц с такого сайта.

Если вы сталкиваетесь с ограничениями по нагрузке на хост, и мы можем забирать с вашего сайта только конечное количество страниц, тот факт, что у вас есть дублирующийся контент, страницы с которым мы отбрасываем, означает что вы не даете другим своим страницам с хорошим, уникальным контентом появиться в нашем поисковом индексе.

Eric Enge: Классический совет, который мы всегда даем людям, что расплатой за дублирующийся контент является ухудшение сканирования сайта.

Matt Cutts: Да. При наличии у вас определенного PageRank, мы готовы сканировать очень много с вашего сайта. Отбрасывание некоторых страниц означает бесцельное расходование ресурсов. И это может происходить в условиях ограничений по нагрузке на хост, когда мы не можем забирать слишком много страниц.

Eric Enge: Другая базовая концепция, о которой мы хотим поговорить, это потерянный ссылочный вес (link juice). Я буду использовать термин PageRank, но имею в виду более общее понятие "веса ссылки", связанное с трастом и авторитетностью, выходящее за пределы изначальной концепции PageRank. Когда вы ссылаетесь с одной страницы на страницу-дубликат, вы разбазариваете некоторое количество своего PageRank, правильно?

Matt Cutts: Это может работать следующим образом. Обычно, дублирующийся контент не является главным фактором при определении того, сколько страниц загружать с сайта, но он может оказывать влияние. Мой общий совет заключается в том, что лучшим решением будет разработка правильной архитектуры сайта, потому что тогда не надо будет переживать по поводу дублирующегося контента и связанных с этим проблем. Также можно использовать 301 редирект для склейки нескольких дубликатов на один URL. Если вы не можете использовать 301 редирект, тогда можно применить rel=canonical.

Некоторые люди не имеют возможности для настройки 301 редиректа на веб-сервере, например школьные аккаунты, бесплатные хостинги и т.п. Но если они могут исправить архитектуру сайта, то это предпочтительнее, чем патчить при помощи 301 или атрибута rel=canonical.

Eric Enge: Да, это наилучшее решение. Скажем, у вас есть страница со ссылками на десять других страниц. Если три страницы из этих десяти - дубли, отброшенные Google, это означает, что вы потеряли три голоса?

Matt Cutts: Не обязательно. Это область, где люди могут экспериментировать. Мы пытаемся склеить такие страницы, а не отбрасывать их полностью. Если вы ссылаетесь на три одинаковые страницы, поисковик может распознать такую ситуацию и передавать входящий ссылочный вес на такие склеенные страницы.

Не обязательно, что в этом случае PageRank будет полностью потерян. Это зависит от поисковика. Каждый поисковик может реализовать эти вещи по-своему. Но если на вашем сайте ссылки будут указывать на одну страницу, то это точно предпочтительнее.

Eric Enge: Коснемся немного идентификаторов сессий?

Matt Cutts: Не используйте их. На сегодня существует много путей сделать сайт, не нуждающийся в Session IDs. Производители программного обеспечения должны думать об этом не только ради поисковиков, но и с точки зрения удобства пользователя. Пользователи лучше кликают на ссылках, выглядящих привлекательно, и лучше запоминают привлекательные URL.

Если вы не можете отказаться от идентификаторов сессий, Google предлагает инструмент для работы с Session IDs. Он дает возможности, аналогичные тем что применялись в Yahoo!. Если параметр URL должен быть проигнорирован, не используется, или не влияет на содержание, можно переписать URL в нормальный вид. Google предлагает такую возможность, и хорошо что мы делаем это. Некоторые другие поисковики также делают это, но если вы можете обойтись вообще без Session IDs, это будет еще лучше.

Eric Enge: Определенно, есть риск, что это когда-нибудь начнет выглядеть как дублирующийся контент.

Matt Cutts: Да, точно, и поисковики обычно нормально справляются с этим. Обычно проблем не возникает, но я встречал случаи, когда несколько версий страниц были проиндексированы с разными идентификаторами сессий. Всегда лучше самому заботиться о своем сайте, чем возлагать эту обязанность на поисковики.

Eric Enge: Давайте затронем партнерские программы. Другие люди направляют вам свой трафик, и они помещают свой параметр в URL. Вы поддерживаете этот параметр в течение всей сессии на своем сайте, это обычная практика. Эту ситуацию поисковики обрабатывают нормально, или здесь есть реальный риск образования дублированного контента?

Matt Cutts: Дублирование контента может произойти. Если вы работаете с чем-то типа совместного бренда, где страницы различаются только логотипом, то для пользователя это является по существу одной и той же страницей. Поисковикам обычно хорошо удаются попытки склеить этот тип контента, но в других сценариях конечно могут возникнуть проблемы с дублированием контента.

Eric Enge: В СЕО есть классический совет, который говорит о том, что пусть параметры партнера будут в URL его ссылки, но когда пользователь переходит по ней на ваш сайт, вы 301 редиректом перебрасываете его на страницу без этого параметра, и устанавливаете этот параметр в cookie.

Matt Cutts: Так можно делать. Точно так же можно работать с целевыми страницами рекламных кампаний, например. Можно поместить целевые страницы партнерской рекламы в каталог с отдельным URL, который запретить индексировать в robots.txt. Многие вещи типа рекламы, партнерских ссылок обычно предназначены для конечных пользователей, а не для поисковиков. Таким способом можно их держать под контролем, не опасаясь того, что дополнительные параметры в URL создадут проблемы дублирования контента и такие страницы не будут сканированы на их изначальных адресах.

Eric Enge: Если Googlebot видит партнерскую ссылку, он считает ее рекомендацией или рекламой?

Matt Cutts: Обычно мы обрабатываем такой тип ссылок надлежащим образом. В большинстве случаев это означает, что ссылка поставлена за деньги, так что мы не считаем ее рекомендацией.

Eric Enge: Давайте немного поговорим о каталожной навигации. (Прим. переводчика: В оригинале используется термин "faceted navigation", для которого мне неизвестен устоявшийся русский термин.) Например, в Zappos люди могут выбирать для покупки обувь по размеру, по цвету, по марке, и один продукт может присутствовать в 20 различных путях, что создает большие сложности. Что вы думаете об этом типе сценариев?

Matt Cutts: Каталожная навигация в общем может быть запутанной. Некоторые обычные пользователи не всегда могут в ней разобраться, и они немного теряются, где же они находятся. Может быть много способов навигации по контенту, но каждая страница контента должна иметь единственный URL, если вы хотите помочь своим пользователям. Есть много способов нарезать и дробить данные. Если вы решили для себя, что задуманный вами способ наиболее удобен для выдачи конечного фрагмента контента, то можно пытаться реализовать этот способ в какой-то иерархии URL.

Категория может быть первым параметром, а цена вторым, например. Кто-то может идти от цены, а потом выбирать категорию. Вы можете создавать эту иерархию согласно вашим представлениям о том, как данные должны быть разбиты по категориям и отображать ее в параметры позиций в URL.

Наиболее важная категория первая, следующая по важности - вторая. Это может помочь некоторым поисковикам находить контент немного лучше, потому что они могли бы рассчитывать на получение полезного или схожего контента при отбрасывании последнего параметра в URL. В общем, каталожная навигация это серьезная проблема, потому что вы создаете кучу разных маршрутов для попадания на страницу. Вам нужно сделать множество промежуточных шагов, прежде чем вы доберетесь до цели.

Если есть возможность уменьшить количество промежуточных страниц, то это будет хорошим решением. Если кто-то должен сделать семь промежуточных шагов для выбора нужного продукта, то он может потерять терпение. Это также может быть роковым моментом с точки зрения поисковиков, если для получения информации о продукте нужно сделать семь или восемь промежуточных переходов. В некотором смысле, куча PageRank уходит на эти промежуточные страницы, на которых нет ничего, что пользователь может купить. Каждый из этих кликов предоставляет возможность для рассеивания небольшого процента PageRank.

Каталожная навигация может быть полезна некоторым пользователям, если вы разработали иерархию, которая отражает разбивку страниц по категориям и убедились, что она относительно проста, и это также может помочь поисковикам находить информацию о реальных продуктах немного лучше.

Eric Enge: Если у вас есть страницы с одинаковыми продуктами или по сути аналогичными продуктами с разными порядками сортировки, эта ситуация подходит для использования тега canonical?

Matt Cutts: Вполне возможно, или вы можете придумать собственную перестановку параметров. В общем, тег canonical разработан для того, чтобы дать вам возможность сообщить поисковикам, что две страницы по сути имеют одинаковое содержание. Возможно, вам нет необходимости описывать различия между черной и красной версиями продукта, если у вас есть продукт 11 различных цветов. Возможно, вам нужна одна страница продукта, с опцией указания цвета через выпадающий список или что-то вроде этого. Показ страниц с вариантами незначительных модификаций продукта и использование для них тега rel=canonical с указанием на основную страницу продукта - это подходящий способ использования этого тега.

Eric Enge: Давайте немного поговорим о влиянии на PageRank, сканирование и индексирование при помощи некоторых инструментов. Давайте начнем с наших любимых 301 редиректов.

Matt Cutts: Обычно 301 редирект будет передавать PageRank. Он может быть очень полезным инструментом при перемещении страниц в структуре сайта, или при миграции между сайтами. Много людей используют его, и кажется он работает хорошо, давая эффект довольно быстро. Я сам использовал его, когда хотел переехать с mattcutts.com на dullest.com (Прим. переводчика: Сюдя по всему, в оригинале опечатка, речь идет о переезде в обратном направлении.), и переезд прошел определенно удачно. Мой собственный опыт показал, что все прошло успешно. Фактически, если вы сейчас запросите site:dullest.com, то не получите ни одной страницы. Все страницы перенесены с dullest.com на mattcutts.com. По крайней мере, для меня, 301-ый сработал так, как я ожидал. Если вам нужен постраничный перенос на новый сайт, то в вашем арсенале есть мощный инструмент для этого.

Eric Enge: Скажем, вы переезжаете с одного домена на другой, и вы написали маленькую инструкцию для поисковиков и остальных посетителей, как заменить адрес одного домена на адрес другого. В таких ситуациях будет какая-то потеря PageRank из-за того, что ранее созданная ссылка со старым адресом домена не будет исправлена на новый домен?

Matt Cutts: Это хороший вопрос, и я не на 100% уверен в ответе. Я могу конечно посмотреть, какие там могут быть потери PageRank. Я не на 100% знаю, как команда сканирования и индексации реализовала такой случай потери PageRank, я уточню у них про такую ситуацию. (Примечание. Позднее Мэт через email подтвердил, что факт имеет место. Некоторые потери PageRank через 301-ый есть.)

Eric Enge: Давайте кратко обсудим 302 редирект.

Matt Cutts: 302-ой предназначен быть временным. Если вам нужно изменить что-то на небольшой период времени, тогда хорошо использовать 302-ой. Обычно он не передает PageRank, но он может быть очень полезным. Если сайт делает что-то короткое время, 302-ой наиболее предпочтителен для такого случая.

Eric Enge: Что насчет серверных редиректов, которые не возвращают код статуса HTTP или возвращают код 200?

Matt Cutts: Если мы видим 200-ый код, то мы считаем что контент, возвращенный сервером, расположен по URL-адресу, который мы запросили. Если ваш веб-сервер делает какие-то манипуляции на своей стороне, мы не можем это знать. Все что мы знаем, это то, что мы запросили URL, получили в ответ какой-то контент, и мы проиндексируем этот контент. Мы проиндексируем его для запрошенного нами URL адреса.

Eric Enge: То есть это, по сути, как 302 редирект?

Matt Cutts: Нет, не совсем. Вы химичите на сервере, чтобы вернуть другое содержимое для той страницы, которую мы запросили. Что же касается нас, то мы увидели ссылку, мы перешли по ссылке на эту страницу, и мы запросили содержимое этой страницы. Вы возвращаете нам контент, и мы индексируем этот контент по этому URL адресу.

Можно всегда создавать содержимое динамически на стороне сервера. Можно представить себе CMS на веб-сервере, которая не использует 301 и 302 редиректы, но она была бы весьма сложной и подвержена возникновению ошибок.

Eric Enge: Можете дать краткий обзор тега canonical?

Matt Cutts: Здесь есть пара вещей, которые нужно помнить. Если вы можете уменьшить количество дублированного контента, используя архитектуру сайта, то это предпочтительнее. Применяйте тег для страниц, которые не являются полными дублями, но являются "концептуальными дублями" одного продукта, или очень близки к этому. Можно использовать кросс-доменный тег rel=canonical, о котором мы объявили в прошлом декабре.

Например, я могу использовать тег rel=canonical в моем старом школьном аккаунте, указывая на мой mattcutts.com. Можно использовать тег rel=canonical, если у вас нет доступа к веб-серверу для настройки серверных редиректов. Большинство людей, однако, использует его для дублированного контента, чтобы быть уверенными в том, что в индекс будет включена каноническая версия страница, а не какая-то другая ее версия, которую вы не хотите включать в индекс.

Eric Enge: Так если кто-то ссылается на страницу, на которой есть тег canonical, можно считать это по сути разновидностью 301 редиректа на каноническую версию этой страницы?

Matt Cutts: Да, можете считать его 301 редиректом для бедных. Если ваш веб-сервер может делать 301 редирект, просто используйте его. Но если у вас нет доступа к веб-серверу или при настройке 301 слишком много проблем, тогда можете использовать rel=canonical.

Нет никакого криминала иметь на странице ссылку на саму себя при помощи тега rel=canonical. Также абсолютно нормально, по крайней мере для Google, иметь тег rel=canonical на каждой странице вашего сайта. Думают, что этот тег нужно использовать очень экономно, но не в этом дело. Мы специально спрашивали себя о ситуации, когда каждая страница сайта имеет тег rel=canonical. До тех пор пока эти теги указывают на правильную страницу, никаких проблем не будет.

Eric Enge: Мне помнится, вы ранее говорили, что не стоит называть тег canonical директивой. Вы называли его по сути подсказкой.

Matt Cutts: Да. Обычно, команда разработки сканирования принимает во внимание такие подсказки, и в большинстве случаев мы учтем подсказку и будем действовать соответственно. Если называть это директивой, тогда мы обязаны строго соблюдать эти указания, но мы оставляем за собой полное право решить, что владелец сайта случайно прострелил себе ногу, и не слушать указаний тега rel=canonical. В большинстве случаев вы увидите эффект от использования тегов rel=canonical. Если мы можем утверждать, что они, вероятно, делают не то, что ожидалось, мы можем их игнорировать.

Eric Enge: Инструмент "игнорируемые параметры" в панели вебмастера Google это другой эффективный способ сделать то же самое, что и при использовании тега canonical.

Matt Cutts: Да, это по существу так. Это лучше, потому что robots.txt может оказаться неудобным, поскольку если вы закрываете в нем страницу от сканирования, и мы не скачиваем ее, мы не сможем распознать ее как дублированную версию другой страницы. Но если вы укажете нам через панель вебмастера, какие параметры URL не используются, тогда мы сможем извлечь из этого пользу.

Eric Enge: Давайте поговорим о файлах KML. (Прим. переводчика: файлы географических данных для программ Google Earth и Google Maps) Допустимо помещать такие страницы в robots.txt для улучшения сканирования других страниц сайта?

Matt Cutts: Обычно я это не рекомендую. Лучший совет, который может дать команда разработки сканирования и индексации - дайте Google сканировать страницы сайта, о которых вы переживаете, и мы попробуем расклеить их. Вы можете попробовать устранить проблему, заранее продумывая архитектуру сайта, или при помощи 301 редиректа, но если вы попытались заблокировать что-то в robots.txt, часто мы находим ссылку на этот URL и оставляем эту ссылку в нашем индексе. Так что нет необходимости экономить на сканировании. Google пытается сканировать много разных страниц, даже не html типов, и, фактически, Google будет сканировать и KML файлы.

Обычно мы рекомендуем просто развивать свой сайт дальше и дать Google сканировать эти страницы и затем обработать их на нашей стороне. Или, по возможности, устраните проблемы дублирования заранее, продумав архитектуру сайта. Если ваш сайт наполовину состоит из KML файлов или у вас непропорционально большое количество шрифтов и вам действительно не требуется их сканирование, вы можете использовать robots.txt. Robots.txt разрешает использование масок имен внутри директив, так что вы можете заблокировать сканирование этих данных. Для большинства сайтов, содержащих в основном html и небольшое количество файлов других типов, я бы рекомендовал разрешить Google сканировать их.

Eric Enge: Вам не надо прибегать к махинациям, если такие файлы составляют небольшой процент от общего числа страниц сайта.

Matt Cutts: Правильно.

Eric Enge: Google делает запросы заголовков для определения типа контента?

Matt Cutts: Для тех, кто не в курсе, есть разные способы скачивания и проверки контента. При использовании GET вы делаете запрос к веб-серверу для получения контента. При использовании запроса HEAD вы запрашиваете веб-сервер о том, изменился контент или нет. Веб-сервер может ответить подробно или кратко (да/нет), и он не отсылает контент в ответ. На первый взгляд, можно подумать, что запрос HEAD самый подходящий для поисковиков способ сканировать веб и скачивать только те страницы, которые изменились со времени последнего сканирования.

Оказывается однако, что большинство веб-серверов делают примерно такой же объем работы для выяснения изменилась ли запрашиваемая через метод HEAD страница. Мы проверили и обнаружили, что в реальности более эффективно всегда делать GET запросы, и не делать предварительных HEAD запросов для сканируемой страницы. Но есть несколько задач, для которых мы используем запрос HEAD. Например, наш сканер картинок может использовать HEAD запросы, поскольку изображения могут быть гораздо больше по размерам, чем веб-страницы html. Если говорить о сканировании html и другого текстового контента, мы обычно используем просто GET и не делаем предварительных HEAD запросов. Мы пока используем вещи типа If-Modified-Since, где веб-сервер может ответить, изменилась страница или нет. Есть еще рациональные способы для сканирования веба, но HEAD запросы в действительности не экономят ресурсы, если говорить о сканировании html контента, хотя мы используем их при сканировании графического контента.

Eric Enge: Возможно, вы используете их также для видео-контента, правильно?

Matt Cutts: Это так, но надо бы проверить.

Eric Enge: Вернемся к дискуссии о каталожной навигации. Мы работаем с сайтом, имеющим очень развитую схему каталожной навигации. Она действительно удобна для пользователей. Они получили существенное увеличение конверсии после реализации такой схемы на их сайте. И это привело к улучшению показателя размер прибыли с посетителя, это хороший результат.

Matt Cutts: Безусловно.

Eric Enge: С другой стороны, они обнаружили, что у сайта существенно снизилось количество проиндексированных страниц. Предположительно потому, что страницы представляют из себя по большей части просто списки продуктов с разными порядками сортировки.

На страницах мало текста; ботам там особо нечем поживиться, так что они выглядят как некачественные страницы или дубликаты. Как лучше поступить тем, кто столкнулся с подобной проблемой. Нужно запретить сканирование таких страниц?

Matt Cutts: В некотором смысле, каталожная навигация может выглядеть для поисковиков почти как мини-лабиринт, потому что имеется множество путей, по которым вы дробите свои данные. Если поисковики не могут пройти через этот лабиринт к реальному продукту, тогда могут быть сложности, если говорить об алгоритме определения важности (value add) индивидуальных страниц.

Возвращаясь к ранее данному мной совету, если вы можете ограничить число сущностей или признаков по которым вы делить данные, то это может отчасти помочь и иногда избегать путаницы. Это то, куда стоит посмотреть. Если есть категория, иерархия по умолчанию, или наиболее эффективный либо удобный для пользователя способ навигации, это стоит попробовать.

Вы можете попробовать при помощи тега rel=canonical на страницах каталожной навигации сослаться на страницы, образующие обычную ниспадающую иерархию. Это поле для экспериментов для нахождения подходящего решения. Я думаю, что это может помочь объединить множество страниц каталожной навигации в один путь к множеству разных продуктов, но вам нужно следить за тем, как на это реагируют пользователи.

Eric Enge: Если гуглбот видит на сайте 70% страниц с редиректом или тегом rel=canonical на другие страницы, что произойдет? Когда вы сталкиваетесь с таким случаем, вы уменьшаете время на сканирование таких страниц, потому что уже встречали этот тег ранее?

Matt Cutts: Не так уж много, чтобы rel=canonical повлял на это, но наши алгоритмы попытаются сканировать сайт, чтобы выяснить полезность и ценность этих страниц. Если мы обнаружим большое количество малоценных страниц, тогда мы можем не сканировать так много страниц с этого сайта, но это не зависит от rel=canonical. Это может произойти и с обычной каталожной навигацией, если видим ссылки и только ссылки.

Это действительно та область, где каждый сайт может пробовать разные подходы. Я не думаю, что есть что-то обязательно неправильное в том, чтобы используя rel=canonical, попробовать направить поисковик по одному предпочтительному пути навигации сквозь набор разнообразных разделов и категорий. Просто пробуйте и сокращайте количество разных вариантов путей, выстраивайте более логичную структуру путей.

Eric Enge: Это звучит как оставьте недостатки в покое, пусть сканер тратит кучу своего времени на такие страницы, которые не попадут в индекс.

Matt Cutts: Да, это так. Если подумать над этим, то каждый уровень или новый путь при помощи которых вы нарезаете и дробите данные, это еще одно измерение, в котором можно сканировать весь каталог продукции, и все эти страницы могут не иметь данных о действительных продуктах. Можно еще сделать навигацию через город, штат, профессию, цвет, цену и т.д. В действительности нужно иметь на большинстве ваших страниц описания действительных продуктов с кучей текста. Если ваша навигация слишком сложная, относящиеся к ней материалы не нужны поисковикам для поиска, индексации и ответа на запросы пользователей.

Очень часто каталожная навигация является прокладкой между пользователями или поисковиками и реальными продуктами. Это просто прокладки и наборы разных промежуточных страниц, на которых нет искомой информации. Иногда это может быть неприятно с точки зрения поисковика или пользователя.

Eric Enge: Что насчет накачки PageRank (PageRank Sculpting)? Делать редиректные ссылки через Javascript или через фреймы?

Matt Cutts: Мой совет примерно такой же, как и для изначальной идеи накачки PageRank. Точно так же, как говорилось ранее, что накачка PageRank не самый эффективный способ пытаться управлять гуглботом внутри сайта, мы скажем, что накачка PageRank не самое лучшее использование вашего времени, потому, что его лучше потратить на получение дополнительных ссылок и создание лучшего контента на вашем сайте.

При помощи накачки PageRank вы пытаетесь более эффективно распределить имеющийся у вас PageRank на нужные страницы, и есть гораздо лучшие способы сделать это. Если у вас есть продукт, имеющий высокую конверсию и приносящий фантастическую прибыль, вы можете поместить ссылку на него в корне вашего сайта на переднем плане в центре. Куча PageRank будет перетекать по этой ссылке на страницу этого продукта.

Архитектура сайта, как вы ставите ссылки и располагаете их на странице с целью увеличить количество людей, которые смогут увидеть продукт, это действительно более хороший подход, чем пытаться накачивать PageRank для ссылок. Если вы можете настроить архитектуру сайта для фокусирования PageRank на наиболее важных страницах или страницах, приносящих наибольшую прибыль, это гораздо лучший способ распределения PageRank, чем пытаться использовать iFrame или iFrame закодированный в JavaScript.

Мне кажется, что если вы изначально продумаете архитектуру сайта, у вас будет меньше хлопот в дальнейшем, или не нужно будет даже думать о накачке PageRank. Просто пусть сайт развивается и будет ясным, можно только приветствовать то, что люди реализуют свои идеи на собственных сайтах, но, исходя из моего опыта, тратить время на накачку PageRank - не самая лучшая идея.

Eric Enge: Я приводил пример сайта с проблемой каталожной навигации, и как я уже говорил, они заметили уменьшение числа проиндексированных страниц. Им нужно найти способ сообщить гуглботу, чтобы он не тратил время на страницы, которые не нужны им в индексе. Что вы думаете об этом?

Matt Cutts: Для примера можно начать с десяти наиболее продаваемых продуктов, поместив их на главную страницу, и затем на страницах этих продуктов разместить ссылки на следующую десятку или сотню наиболее продаваемых продуктов. Каждый продукт может иметь десять ссылок, и каждая из этих ссылок может указывать на десять других продуктов, которые продаются относительно хорошо. Подумайте о таких сайтах, как YouTube или Amazon; это замечательный пример того, как пользователям предлагаются связанные страницы и продукты, которые они скорее всего захотят купить.

Если вы находитесь на одной из таких страниц и видите что-то выглядящее действительно привлекательным, вы переходите туда и видите еще пять полезных и подходящих продуктов. Вы сразу направляете как пользователей, так и поисковики на ваши важные продукты, а не начинаете погружение в глубокую каталожную навигацию. Это такие вещи, где сайты могут экспериментировать и искать то, что лучше работает.

Есть способы построения архитектуры вашего сайта, а не накачки PageRank, где вы представляете продукты, которые по вашему мнению лучше продаются или наиболее важны, на переднем плане и в центре. Если они выделяются среди прочих вещей, людям захочется перейти туда. Вы можете очень аккуратно перераспределять PageRank между связанными продуктами, и использовать подходящие ссылки на страницы продуктов, а не на навигационные страницы. Я думаю, что эти способы лучше, чем использование накачки PageRank.

Eric Enge: Если кто-то все-таки выбрал такой способ (ссылки через JavaScript или использование iFrame), это будет рассматриваться как спаммерская деятельность или просто они будут зря терять свое время?

Matt Cutts: Я не уверен, что это будет считаться спаммерской деятельностью, но первоначальные изменения с NoFollow для снижения эффективности накачки PageRank по крайней мере частично вызваны тем, что команда качества поиска хотела, чтобы пользователи и поисковики видели одинаковый или похожий набор ссылок. В общем, я думаю, вам нужно, чтобы ваши пользователи переходили туда, куда переходят поисковики и наоборот.

В некотором смысле, я думаю, что накачка PageRank является попыткой уклониться от этого. Если вы думаете о том, чтобы сделать такой шаг, вы должны спросить себя, почему я хочу направить ботов на одни страницы, а пользователей на другие. По-моему, обычно нам нужно, чтобы боты видели те же страницы и перемещались примерно по тем же маршрутам, что и пользователи поисковых систем. Если iFrames или странный JavaScript распространятся настолько широко, что повлияют на качество поиска, то я могу представить себе вариант, что мы изменим правила перетекания PageRank по ссылкам такого типа.

Это не означает, что мы думаем об этом как о спаме, все что мы хотим, это чтобы те ссылки и страницы, которые находят поисковики, имели то же самое окружение и качество, что и ссылки и страницы, которые видят пользователи при посещении сайта.

Eric Enge: Что с PDF файлами?

Matt Cutts: Мы полностью обрабатываем PDF файлы. Я не буду говорить о том, передают ли PageRank ссылки в PDF файлах. Но вы можете думать о PDF файлах, как о разновидности Flash, как о файлах в не родных для веба форматах, но которые могут быть очень полезными. По тем же причинам, по которым мы пытаемся искать полезную информацию внутри файлов Flash, мы пытаемся найти полезный контент в PDF файлах. В то же время, пользователям не всегда нравиться переходить по ссылке на PDF файл. Если вы можете перевести ваш контент в веб-формат, такой как чистый html, это будет приятнее для пользователей, чем просто PDF файл.

Eric Enge: Есть классический случай, когда нужно сделать документ без возможности его изменения, но с возможностями распространения и использования, например электронная книга (eBook).

Matt Cutts: Я не поверю, что мы можем индексировать запароленные PDF файлы. Также есть PDF файлы, основанные на сканированных изображениях. Но здесь, однако, в некоторых ситуациях мы можем запускать OCR (Прим. переводчика: программы распознавания текста в изображениях) для таких PDF.

Eric Enge: Иметь текстовый PDF файл лучше, чем такой же, но со сканированным изображением?

Matt Cutts: Люди конечно будут пользоваться им, если он им нужен, но я думаю, что PDF файлы ищут в последнюю очередь, и пользователи считают, что нужно больше усилий, чтобы открыть его. Нужно помнить об удобстве для пользователя.

Eric Enge: Что вы в действительности делаете после ввода новой обработки JavaScript ? Вы действительно выполняете JavaScript?

Matt Cutts: Пока что мы сканируем JavaScript и ищем там ссылки. Google стал лучше понимать JavaScript и может выполнять некоторые фрагменты JavaScript. Я не могу сказать, что мы выполняем весь JavaScript код, есть некоторые условия, при которых мы не выполняем JavaScript. Конечно, есть некоторые распространенные, хорошо известные JavaScript сценарии вроде Google Analytics, которые не нужно исполнять, потому что вам не нужны фантомные посещения гуглбота в вашей гугл-аналитике.

У нас есть возможность выполнять большие объемы JavaScript когда нам это нужно. Помните о том, что если вы создаете рекламные ссылки через JavaScript, то вы можете использовать NoFollow на таких ссылках.

Eric Enge: Если на сайте есть рекламные объявления, Google нужно, чтобы их закрывали в NoFollow, правильно?

Matt Cutts: Да, безусловно. Наша философия не изменилась, и я не думаю, что измениться. Если вы купили объявление, это замечательно для пользователей, но нам не нужно, чтобы реклама влияла на ранжирование. Например, если ваша ссылка показывает на редирект, этот редирект можно закрыть в robots.txt, что даст уверенность, что мы не перейдем по этой ссылке. При использовании JavaScript вы можете использовать NoFollow внутри сценария. Очень много объявлений используют 302 редирект, из-за того, что они временные. Эти объявления не должны быть постоянными, так что мы стараемся обрабатывать их соответственно.

В этом плане наша позиция не изменилась, и фактически мы можем отказаться от призыва сообщать нам о спамных ссылках в ближайшие месяцы. У нас есть несколько новых инструментов и внедряется технология, позволяющая разрешить эти вопросы. Мы могли бы отказаться от призыва об откликах о различных типах замеченного ссылочного спама.

Eric Enge: Так что с теми, кто использует 302 редирект на ссылках в объявлениях?

Matt Cutts: Они могут быть спокойны. Обычно мы это нормально обрабатываем и понимаем, что это объявление. Мы много чего делаем, чтобы обнаружить объявления и убедиться, что они не слишком влияют на поиск, когда мы их обрабатываем. Приятно, что подавляющее большинство рекламных сетей предоставляют много различных видов защиты. Наиболее часто это 302 редирект через заблокированный в robots.txt адрес, поскольку обычно не нужно чтобы бот переходил по рекламным ссылкам, так как это не дает конверта из-за низкого кредитного рейтинга ботов или отсутствия у них кредитной карты. Вы не хотите возиться с веб-аналитикой в любом случае.

Eric Enge: Ссылочный вес расходуется в таком сценарии?

Matt Cutts: Я уточню; Я специально не обсуждал это с командой сканирования и индексирования. В таких ситуациях обычно наибольшую часть вашего контента составляет html, и рекламный контент составляет небольшую часть, так что обычно это не будет важным фактором вообще.

Eric Enge: Спасибо Мэтт!

Matt Cutts: Спасибо Эрик!

1 комментарий:

  1. Спасибо за перевод.
    Что-то интересно, но в основном одно и тоже уже который год..

    ОтветитьУдалить