Интервью с Мэттом Каттсом
2010-03-26 23:46 melnikoff_kc@list.ru (Bormaley)

Мэт Катс (Matt Cutts) — один из ведущих программистов Google. В прошлом был инженером NASA, считается одним из основных разработчиков поискового движка Google. Matt Cutts начал работать в Google в январе 2000 года.   До Google, он работал над докторской степенью в компьютерной графике в University of North Carolina at Chapel Hill, а также имеет  степени бакалавра, как в математике так и в компьютерных науках University of Kentucky.

Интервью Эрика Энджа с Мэттом Каттсом.

Эрик Эндж: давай немного поговорим о таком понятии как «краулинговый бюджет». Мое понимание состоит в том, что Googlebot приходит на сайт с заданным количеством страниц, которые надо записать за день, и сразу его покидает как только выполняет заданное количество.

Мэтт Каттс: я постараюсь объяснить несколько вещей, которые стоит иметь в виду. Первое – на самом деле нет такого понятия как «потолок индексации». Многие люди думают, что с домена проиндексируется только определенное число страниц, но это работает немного не так.

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

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

С точки зрения краулингового бюджета интересна следующая вещь: несмотря на то, что жестких лимитов на краулинг нет, существует понятие нагрузки на ведущий узел (host load). Нагрузка на ведущий узел это максимальное число одновременных соединений, которое может выдержать конкретный сервер. Представьте, что ваш веб-сервер может принять только одного бота за раз. Это позволит достигать сайты только постранично, и будет очень-очень большая нагрузка на ведущий узел, в тоже время такие сайты как Facebook или Twitter могут иметь высокую нагрузку на ведущий узел, потому что они могут принять множество соединений одновременно.

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

Эрик Эндж: таким образом, в основном, у вас есть два фактора. Один - чистый PageRank, который заранее устанавливает объем краулинга, который будет выполнен на вашем сайте. Но также на него может повлиять нагрузка на ведущий узел.

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

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

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

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

Эрик Эндж: Другим основополагающим понятием, о котором мы поговорим, является понятие «растраты ссылочного веса». Я собираюсь использовать термин PageRank, но в более широком смысле я подразумеваю ссылочный вес, который, возможно, больше соотносится с такими понятиями как доверие и авторитетность сайта, чем оригинальная концепция PageRank. Когда с одной страницы вы ссылаетесь на страницу-дубликат, вы рассеиваете часть вашего PageRank, правильно?

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

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

Эрик Эндж: Правильно, это определенно «золотой стандарт». Скажем, у вас есть страница, на которую ссылаются другие десять страниц. Если три из них на самом деле являются дубликатами, которые выбракуются, значит ли это, что вы потеряли три рекомендации?

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

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

Эрик Эндж: Мы можем немного поговорить о Session ID?
Мэтт Каттс: не используйте их. Сегодня у многих людей должна быть кипа идей о том, как сделать сайт, который не требует Session ID. На этом этапе многие производители программного обеспечения должны думать об этом, не только с точки зрения поисковиков, но также с точки зрения юзабилити. Пользователи склонны кликать по ссылкам, которые лучше выглядят и они склонны запоминать ссылки, которые лучше выглядят.

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

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

Мэтт Каттс: Да, именно, поисковики хорошо справляются с этим в большинстве случаев. Простые случаи, как правило, не проблема, но я видел случаи, когда множественные версии страницы были проиндексированы с различными Session ID. Всегда лучше позаботиться об этом на своем сайте самому, а не ждать, когда об этом позаботятся поисковики.

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

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

Эрик Эндж: Существует классический SEO-совет, который гласит, что нужно позволить поставить параметр в URL, но когда пользователь кликает по ссылке на ваш сайт, сделать 301 редирект на страницу без параметра, а параметр «сбросить» в куки.

Мэтт Каттс: так можно сделать. Аналогичный прием может сработать для целевых страниц в рекламе, к примеру. Вы можете сделать рекламу целевых страниц в партнерской программе в отдельной URL директории, которую затем можете заблокировать, к примеру, через robots.txt. Как и реклама, в большинстве своем партнерские ссылки создаются для пользователей, а не поисковых систем. Поэтому их очень легко отследить, и вам не нужно волноваться о том, что партнерские коды «просочатся» и создадут проблемы дублированного контента, если эти страницы никогда не краулируются в первую очередь.

Эрик Эндж: Если Googlebot видит партнерскую ссылку, как он рассматривает ее: как поддержку или как рекламу?

Мэтт Каттс: Обычно, мы будем рассматривать такой вид ссылок соответственно. В огромном количестве случаев это значит, что ссылка в основном ставится ради денег, поэтому обычно мы не будем рассматривать ее как поддержку.

Эрик Эндж: Давай поговорим о фасетированной навигации. К примеру, на Zappos, люди могут купить обувь по размеру, цвету, бренду, и один и тот же продукт перечислен в разных списках 20 раз, что может быть затруднительно. Что вы думаете по поводу таких видов сценариев?

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

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

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

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

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

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

Мэтт Каттс: Возможно, или вы можете представить изменение позиций параметров самостоятельно. В общем, идея canonical tag состоит в том, чтобы дать вам возможность показать поисковым системам, что две страницы контента являют собой одно и то же. Возможно, вы не хотите ставить различия между красной и черной версиями продуктов, если у вас в наличии продукт 11 разных цветов. Вы можете хотеть создать только одну страницу продукта по умолчанию, которая будет умно организована с выпадающим меню или чем-то в этом роде. Хороший способ использования rel=canonical tag – это показывать минимальные различия продукта и отметить все эти страницы rel=canonical.

Эрик Эндж: Давай поговорим о влиянии на PageRank, краулинг и индексирование основных инструментов. Начнем с любимого 301 Redirect.

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

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

Мэтт Каттс: это хороший вопрос, и я на уверен на 100% по поводу ответа. Я понимаю, где именно может быть некоторая потеря PageRank. Я не уверен на 100%, что команды краулинга и индексирования внедрили такой вид натурального снижения PageRank, поэтому мне нужно будет проверить этот конкретный случай. (Примечание: в последующем письме Мэтт подтвердил, что в этом случае действительно так происходит. Существует определенная потеря PR через 301).

Эрик Эндж: давай вкратце поговорим о 302 Redirect.

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

Эрик Эндж: а что по поводу редиректов на стороне сервера, которые отвечают «no HTTP Status Code» или «200 Status Code»?

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

Эрик Эндж: То есть, он работает практически как 302?

Мэтт Каттс: нет, не совсем. По сути вы «химичите» с настройками веб-сервера, чтобы отобразить контент другой страницы, вместо той, которую мы запрашивали. С нашей стороны мы видим ссылку, мы переходим по ссылке на эту страницу и запрашиваем эту страницу. Вы возвращаете нам контент и мы индексируем этот контент под той ссылкой.
Люди всегда могут делать динамические решения на стороне сервера. Можно представить CMS, которая установлена на веб сервер и не делает 301 и 302, но она будет достаточно усложнена и весьма склонна к ошибкам.

Эрик Эндж: можешь дать краткий обзор canonical tag?

Мэтт Каттс: по этому поводу стоит принять во внимание две вещи. Если вы можете снизить количество дублированного контента при помощи архитектуры сайта, это будет предпочтительней. Страницы, которые вы комбинируете не должны быть полными дубликатами, но должны повторять концепцию одного и того же продукта, или рассказывать о тесно взаимосвязанных вещах. Люди могут использовать кросс-доменный rel=canonical, который мы анонсировали в декабре.

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

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

Мэтт Каттс: да, «301 для бедных» - неплохое определение. Если ваш веб-сервер может делать 301 напрямую, вы можете просто установить его, но если у вас нет доступа к веб-серверу, или настроить 301 чересчур хлопотно, то можно использовать rel=canonical.

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

Эрик Эндж: мне кажется, я слышал когда-то, как ты говорил, что это чересчур называть тэг canonical «директивой». Ты назвал его «подсказкой».

Мэтт Каттс: Да. Обычно команда краулинга хочет рассматривать эти вещи как «подсказки», и подавляющее количество времени мы тратим на совещания по этому поводу. Если вы назовете это «директивой», вы будете чувствовать что-то вроде обязательства, во что бы то ни стало придерживаться ее, но команда краулинга и индексирования хочет зарезервировать финальное право определять, когда владелец сайта случайно вредит себе и не прислушивается к правилам rel=canonical. Подавляющее количество времени люди должны понимать эффекты rel=canonical. Если мы можем сказать, что они не понимают, мы можем его игнорировать.

Эрик Эндж: Инструмент Webmaster Tools “ignore parameters” другой способ эффективно делать то, что делает «канонический» тэг.

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

Эрик Эндж: Давай немного поговорим о KML-файлах. Допустимо ли помещать эти страницы в robots.txt, чтобы сэкономить краулинговый бюджет?

Мэтт Каттс: я бы не рекомендовал делать это. Лучший совет, который исходит от команды краулинга и индексирования состоит в том, чтобы дать Google прокраулировать страницы сайта, которые вам нужны, а мы постараемся де-дублировать их. Вы можете попытаться исправить это заранее при помощи архитектуры или 301, но если вы стараетесь заблокировать что-то из robots.txt, зачастую мы все равно увидим эту ссылку и сохраним ее в нашем индексе. Поэтому, это не обязательно сэкономит бюджет краулинга. Это достаточно интересно, потому что Google попытается прокраулировать кучу разных страниц, даже не HTML расширения, и по факту, он прокраулирует также и файлы KML.

Что мы можем рекомендовать, это просто разрешить Googlebot прокраулировать эти страницы и затем де-дублировать их с нашей стороны. Или, если у вас есть такая возможность, вы можете использовать архитектуру сайта для исправления всех проблем с дублированием контента. Если на вашем сайте болееs 50% KML-файлов или у вас есть диспропорционально большое количество шрифтов, которые вы не хотите краулировать, вы, конечно, можете использовать robots.txt. Robots.txt действительно позволяет поставить символ обобщения внутри индивидуальных директив, так, чтобы вы могли блокировать их. Для большинства сайтов, которые состоят практически из одних HTML-страниц с небольшими вкраплениями страниц другого формата или файлов другого расширения, я бы рекомендовал позволить Googlebot прокраулировать их.

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

Мэтт Каттс: Верно.

По материалам: SearchEngines.ru (Автор - Анна Стусь)

Перевод расшифровки интервью Matt Cutts Interviewed by Eric Enge, Stone Temple Consulting

Google объединил все сервисы Google Docs
2010-04-15 02:39 melnikoff_kc@list.ru (Bormaley)
Google произвел некоторые изменения в коде сервиса Google Docs, что приведет к ускорению работы сервиса и всех инструментов коллективной работы в режиме реального времени.

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

Изменения коснутся реализации многих потребностей пользователей сервиса Google Docs, включая более высокую скорость и совместимость с такими оффлайн продуктами как Microsoft Word и Excel, сообщил продакт-менеджер Google Apps Джонатан Рошель.

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

По материалам: SearchEngines.ru