Главные ошибки Рэнда Фишкина — признанного гуру в области SEO и SEM — данные в сжатой, концентрированной форме (коспект авторского видеоролика). 

1. NoFollow в robots.txt при обмене ссылками

Когда SEOMoz еще не существовал, Рэнд частенько заплывал в серые области SEO. Первая упоминаемая им ошибочная тактика заключается в следующем: сперва предлагаем обмен ссылками, а затем блокируем исходящую ссылку с помощью соответствующих тэгов в robots.txt, чтобы получить весь ссылочный вес. Тактика никогда толком не работала и в результате заставила Рэнда изрядно попотеть, чтобы восстановить хорошие отношения с обманутыми вебмастерами.

2. Покупка ссылок для клиентов

Эта тактика также использовалась до официального появления Сеомоза. Тогда Рэнд тратил часть выделенного бюджета на покупку платных ссылок. Это далеко не лучшая идея, поскольку степень полезности таких ссылок определить крайне трудно (по большому счету никто не знает, учитывает ли их Гугл вообще). Позже Рэнд узнал через своих людей в Гугле, что купленные им ссылки все-таки игнорировались поисковиком и что на самом деле они вполне могли работать во вред, не улучшая, ухудшая ранжирование сайтов. Упс!

3. Рекомендация вставлять ключевые слова внутрь H1

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

4. Рекомендация не использовать XML-карты сайта

Когда ХML-карты только появились, Рэнд и Сеомоз советовали их не использовать. Рекомендация имела вполне разумное обоснование — карта в формате XML затрудняет управление информационной структурой сайта. Однако в конце концов мы увидели, что этот недостаток с лихвой компенсируется получаемым преимуществом в ранжировании. С тех пор мы активно используем этот инструмент.

5. Некорректная переадресация с Linkscape на Open Site Explorer

(*Оставляем этот откровенно рекламный пассаж на совести автора — прим. ред.)

Недавно мы решили перейти с Linkscape на более современный Open Site Explorer, перенаправив все отчеты с помощью 301 редиректов (по принципу 1-1). В теории все было прекрасно, однако, как выяснилось, различные трекинговые компоненты, включенные в url-адреса редиректов, привели к значительной потере трафика. Мы исправили ситуацию с помощью rel=canonical, однако к тому времени ущерб уже был причинен. Ай-ай-ай!

Источник: http://www.seomoz.org/blog/whiteboard-friday-the-biggest-seo-mistakes-seomoz-has-ever-made

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

Чтобы узнать, как действуют краулеры, мы провели эксперимент, а именно — взяли домен с нулевой историей (никогда не регистрировался ранее, входящих ссылок нет) и создали на нем страницу с 250 ссылками. Ссылки вели на другие страницы, на каждой из которых имелось еще 250 ссылок, ведущих, в свою очередь, на другие страницы, на каждой из которых тоже имелось 250 ссылок. И так далее, и так далее. Тексты ссылок и адреса страниц получили в качестве имен номера от 1 до 250, в соответствии с порядком появления в исходном коде. Затем мы сделали сабмит сайта через службу «addurl» и стали ждать.

В ходе первого визита гуглбот зашел только на корневую страницу (http://example.com/). Через несколько часов он вернулся и посетил все 250 страниц, найденных на главной странице. Начало складываться впечатление, что Гугл делит найденные ссылки на три блока:

• Блок 1: ссылки с 1 по 9
• Блок 2: ссылки с 10 по 99
• Блок 3: ссылки с 100 до 250.

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

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

Полную ясность внесло исследование с использованием случайно разбросанных по страницам ссылок с URL-адресами разной длины. Эти ссылки вели на аналогичные страницы, содержащие ссылки разной длины, разбросанные в случайном порядке. И так далее. Как показали тесты, гугл-бот проходит по ссылкам в порядке увеличения их длины. Полезная информация для продвинутой оптимизации структуры сайта!

Резюме

Принимая в учет полученные результаты, следует признать: значение длины URL-адреса ссылки сильно недооценивается. Осознанный выбор длинны ссылки — хороший способ воздействия на поисковые боты Гугла. Гугл исследует короткие ссылки раньше, а длинные — позже. При этом просто делать все ссылки короткими бессмысленно , ведь если у них будет равная длинна, Гугл будет исследовать их в случайном порядке (Первую часть этого тезиса мы рискнем поставить под сомнение — если предположение об аналогичном принципе ранжирования внешних ссылок, изложенное ниже, верно, то сайты с более короткими адресами в среднем будут иметь преимущество, т.к. указывающие на них ссылки будут пользоваться большим вниманием гугл-ботов. — Прим. ред.) Это значит, что при выбор URL-адреса страницы нужно осуществлять с учетом ее приоритетности и желаемой скорости индексирования.

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

Источник: http://www.onetomarket.com/seo/google%E2%80%99s-crawl-order.html

Спешите узнать, что думает Мэтт Каттс о порнухе, http-заголовках, последовательных редиректах и прочих интересных штуковинах.

Стоит ли вебмастерам использовать HTTP-заголовки If-Modified-Since?

HTTP-заголовки If-Modified-Since позволяют самостоятельно сообщить Гуглу, меняли вы содержимое страницы, или нет. По словам Мэтта, поддержка опции была внедрена в 2003 г., когда проблема недостаточной ширины каналов стояла довольно остро. Сегодня важность HTTP-заголовков во многом сошла на нет. Мэтт по-прежнему считает их использование полезной и правильной практикой, однако замечает, что она вовсе не обязательно приведет к более оперативному краулингу вашего сайта.

Нужно ли отдавать статус-код 503 в случае даунтайма?

Статус-код 503 помогает избежать нежелательного индексирования тех страниц, которые в данный момент плохо работают или находятся в процессе восстановления. Индексирование таких документов может принести немало вреда, особенно в случае больших и популярных сайтов (Рэнд приводит сайт компании Диснея как пример типичной жертвы). Чтобы обезопасить себя от подобных потерь, Мэтт советует использовать код 503.  Вы не сможете указать Гуглу желаемое время повторного краулинга, однако рано или поздно робот вернется, при этом он не будет индексировать страницу до тех пор, пока она не будет к этому готова.

Влияет ли количество исходящих ссылок на PageRank?

Допустим я хочу минимизировать потери ссылочного веса и/или отдавать вес по возможности более мелкими порциями. Существует ли разница между двумя и тремя исходящими ссылками, размещенными на странице? В изначальной формуле рассчета PageRank разница бы присутствовала — в ней отдаваемый вес равнялся сквозному PR (Passable PR), поделенному на количество исходящих ссылок, — однако сейчас для расчета PR применяются куда более сложные алгоритмы, включающие в себя множество хитрых циклов и итераций. Мэтт утверждает, что «на самом деле разница гораздо меньше, чем принято думать». Вообще не стоит пытаться запереть весь ссылочный вес на одной странице. Более того, вы можете даже выграть за счет добавления внешних ссылок.

Роботы гугла видят триллион адресов. Какие страницы привлекут их внимание?
Поскольку краулеры двигаются в соответствии с приоритетом PageRank, они в попадают в первую очередь на на  «лучшие» страницы и избегают значительной части малоценного мусора. Главная проблема здесь — отсев дублированного и прежде забаненного контента. Мэтт говорит, что 28% всех найденных в сети материалов оказываются копиями. Он также четко разграничивает понятия «качественного» и «популярного» контента и впоследствии поясняет, что траффик сам по себе не является значимым фактором ранжирования: «PR не является показателем популярности, хотя бы потому, что порно крайне популярно, однако никто на него не ссылкается.  PR [порно-сайтов] значительно ниже того значения, которое мы могли бы прогнозировать, исходя из их фактической посещаемости».

Насколько важен закрывающий знак / в url-адресах?
Мелочь, но все-таки: адреса какого типа — url.com/folder или url.com/folder/ — вы используете? Мэтт настоятельно рекомендует ставить закрывающий слеш. Просто протому, что слеш однозначно указывает — перед нами адрес папки, а не адрес документа. При этом Гугл и сам прекрасно отличает одно от другого, поэтому в целом момент следует считать несущественным.

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

Мэтт подтверждает, что «Гугл собирает данные по всему миру с одного IP, т.к. его индекс является общим для всего мира. Компания не создает отдельный индекс для каждой отдельной страны.»

Следовательно, ситуации, когда пользователям из разных стран показывается сильно различный контент, необходимо избегать. Мэтт говорит: «проблема в том, что если вы начинаете отображать разные тексты разным категориям пользователям (к примеру, французский контент для пользователей с французскими IP), гуглбот может этого не увидеть».

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

Цепочки из редиректов (например 301–>301–>301) это плохо?

«Да, плохо.»

По словам Мэтта, Google способен успешно обработать один, максимум два редиректа. Цепочка из трех редиректов будет уже явным перебором — дальше бот скорее всего уже не проследует. Мэтт также напомнил, что 302-е редиректы должны использоваться только для временного перенаправления. Впрочем, это вы и сами наверняка знаете.

Источник: http://www.seomoz.org/blog/whiteboard-interview-googles-matt-cutts-on-redirects-trust-more

Автор: Matt Leonard

Одной из тактик, успешно применяемых для seo-оптимизации с географической привязкой (в оригинале используется термин local seo; мы выбрали свой вариант перевода исходя из того, что термин «локальный поиск» в русском языке тесно ассоциируется с поиском по локальной машине или в локальной сети, но не с поиском в интернете с привязкой к определенному географическому региону — прим. пер.), является использование множественных url-адресов, или микро-сайтов. В качестве примера, помогающего понять суть метода, я буду использовать реально существующую сеть сайтов, никак не связанную ни со мной, ни с Search Engine Journal.

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

История началась с поискового запроса [Warminster carpet cleaning] (чистка ковров в Варминстере).

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

Для тех, кто не бывал в Варминстере, спешу сообщить: Варминстер (Пенсильвания) — очень маленький городок. В природе не может существовать бизнес, занимающийся чисткой ковров только в Варминстере и нигде больше. В пределах нескольких миль от Вармнстера вы найдете множество аналогичных городков, однако на сайте о них не говорится ни слова. И это далеко не случайно.

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

Я начал искать «чистку ковров» в других городах, расположенных неподалеку от Варминстера — вдруг удастся обнаружить нечто подобное? В конце концов, если кто-то использовал подобную тактику применительно к Варминстеру, он наверняка владеет и другими url-адресами с локальной гео-привязкой.

Я решил прозвонить городок Лэнсдейл (Lansdale).

Введя запрос [Lansdale carpet cleaning] (чистка ковров в Лэнсдейле) я получил полностью аналогичный результат:

Единственное отличие заключалось в замене «Warminster» на «Lansdale» в адресе сайта.

Оба сайта были практически идентичны, являя собой пример дублированного контента.

Тогда я решил выяснить, сколько сайтов входят в данную сеть гео-дубликатов (в оригинале используется термин geos, придуманный, по-видимому, самим авторов — прим. пер.) и как у них обстоят дела с линковокой. Другими словами, мне захотелось узнать: насколько велика эта штуковина и насколько она хорошо работает.

Я использовал Yahoo Site Explorer, чтобы посмотреть, какую роль здесь может играть внутренняя перелинковка (если она вообще играет какую-либо роль). Плюс к этому мне, если честно, было интересно узнать, из-за чего сайты ранжируются так высоко — из-за точного соответствия url-адреса поисковому запросу, или из-за банальной покупки ссылок.

Попросив Site Explorer показать ссылки «Except from this domain» (не из этого домена), я получил следующий результат:

Из него было ясно видно: единственным сайтом, ссылающимся на «Warminstercarpetcleaning.com», является «AllClean1.com». Для «Lansdalecarpetcleaning.com» это также верно.

Я понял, что перейдя на сайт «AllClean1.com», я попаду в центральный элемент сети.

В подвале сайта AllClean1.com обнаружился список населенных пунктов, охваченных сетью сайтов-дубликатов. Каждый элемент списка представлял собой исходящую ссылку формата  <топоним>CarpetCleaning.com. Текст ссылок состоял из названий соответствующих населенных пунктов.

Теперь я мог вплотную заняться чем-то вроде промышленного шпионажа — прозвонить сайты-сателлиты и проверить, как они ранжируются. Результатом этой деятельности стало выяснение тактики, которую компания успешно использовала для SEO-оптимизации с географической привязкой.

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

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

Источник: http://www.searchenginejournal.com/local-seo-using-multiple-urls-for-rankings/11863/

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

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

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

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

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

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

Чтоб дать сервису показать себя, советуем попробовать запросы [planets] или [romantic movies]. Goolge Square теперь доступен в лабораториях Гугла для всех желающих.

Источник: http://googleblog.blogspot.com/2009/06/square-your-search-results-with-google.htm

Поисковая система – например, Google – может решить, что ваша страница релевантна пользовательскому запросу, основываясь на ее содержимом и на тексте ссылок, указывающих на данную страницу.

Она также может попытаться составить некое представление об «отношениях» между страницами, посмотрев на структуру их ссылочных связей. Для этой цели Google использует систему Pagerank, которая вычисляет меру важности отдельных страниц посредством анализа сети ссылок. Эта мера важности может быть упрощенно представлена как вероятность того, что пользователь окажется на данной странице, случайным образом кликая по ссылкам в процессе  свободного интернет-серфинга.

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

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

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

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

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

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

Для  объявлений, расположенных прямо над результатами поиска, выявлена следующая закономерность: на разглядывание адреса пользователи тратят в три раза больше времени, чем на текстовое описание объявления (0,53 сек. против 0,15 сек.) Более того, URL объявлений, расположенных на первой позиции, сравнялся по популярности с заголовком объявлений (по 0,65 сек.) Вот таблица с более полными данными:

Среднее время просмотра за один визит на страницу выдачи Google

Вполне ожидаемо то, что URL-адреса трех центральных объявлений получили гораздо больше внимания, чем адреса в правом боковом блоке. Их популярность разнится почти в три раза — 0,53 сек. против 0,19 сек. Более примечателен тот факт, что в боковых объявлениях адреса теряют почти всю свою значимость. Здесь они проигрывают в популярности как заголовкам, так и текстовым описаниям (0.19 сек. против 0,27 сек. и 0.30 сек. соответственно).

Дополнительные изыскания позволили выявить две интересные закономерности. Во-первых:

• Добавление описательных ключевых слов к URL-адресу может уменьшить кликабельность.

Коль скоро пользователи так любят разглядывать адреса, почему бы не продублировать в адресе важное ключевое слово из заголовка объявления, добавив его к адресу основного домена (в виде подстраницы или поддомена). Если пользователь лишний раз увидит важное ключевое слово в столь важном для него месте, разве это не будет дополнительным стимулом для клика? Оказывается, нет. Рассмотрим пример подобной манипуляции. Перед нами три одинаковых объявления с немного отличными адресами:

Eye Tracking Research
Learn about benefits of measuring
gaze activity. View white papers.
www.UserCentric.com

Eye Tracking Research
Learn about benefits of measuring
gaze activity. View white papers.
www.UserCentric.com/Eye_Tracking

Eye Tracking Research
Measure user gaze activity. Get a
full analysis, not just heat maps.
EyeTracking.UserCentric.com

Добавление ключевой фразы «Eye Tracking» после имени домена (второе объявление) привело к уменьшению кликабельности на 5%. Аналогичное действие с созданием субдомена (третье объявление) обрушило кликабельность на 25%.

Вторая закономерность:

• Имя домена, отображаемое в объявлении, оказывает сильное влияние на кликабельность. Для достижения наилучших результатов, оно должно быть по возможности релевантно теме объявления.

New Homes & Home Builders

Find new homes and home builders
1% cash back buyer rebate program.
www.iNest.com
New Homes & Home Builders
Find new homes and home builders
1% cash back buyer rebate program.
www.RealEstate.com

Тема объявления — новенькие дома и строительство домов. Второе объявление, снабженное адресом RealEstate.com (недвижимость.com), оказалось на 20% более кликабельным, нежели первое, где имя домена совпадает с названием (но не сферой деятельности!) компании.

Десятка важнейших запросов 2008 г – абсолютная категория

1. Britney Spears (певица, кумир молодежи)
2. WWE (компания, организующая трансляции соревнований по реслингу).
   
3. Barack Obama (новоявленный президент США)
4. Miley Cyrus (молодая певица, внезапно ставшая сенсацией)
   
5. RuneScape (многопользовательская ролевая игра в стиле фентези)
   
6. Jessica Alba (актриса, звезда плейбоя и общественная активистка)
   
7. Naruto (популярный японский аниме сериал и одноименный герой)
   
8. Lindsay Lohan (популярная актриса).
   
9. Angelina Jolie (популярная актриса)
   
10. American Idol (ТВ-шоу а-ля «Народный артист»)

Новости

Те, кто следили за фондовыми рынками и данными предвыборных опросов (имеются ввиду выборы президента США, разумеется – прим. ред.), прекрасно знают: 2008 г. был годом взлетов и падений. Как и в общей категории, здесь доминируют различные знаменитости. Хотя плохая погода, военные неурядицы и медицинские химеры также стали неплохим поводом пожужжать.

1. Hurricanes (ураганы)
2. Caylee and Casey Anthony
   (Речь идет о маленькой американской девочке, пропавшей при весьма загадочных обстоятельствах и о ее матери, арестованной по подозрению в убийстве первой степени).
3. Elections 2008 (выборы 2008)
4. Pakistan (Пакистан)
5. Pregnant Man (беременный мужчина)
6. China (Китай)
   
7. Iraq (Ирак)
8. Shelley Malil
   (Американский актер индийского происхождения, популярный телеведущий. В августе 2008 арестован по подозрению в убийстве своей бывшей девушки).
9. Patrick Swayze (популярный танцор и певец, заболевший раком поджелудочной железы)
   
10. Afghanistan (Афганистан)

Знаменитости

Голливуд по настоящему интересуют только две вещи – очередной кино-шедевр и последний скандал с участием звезд. В 2008 г. таблоиды приправили их игру принудительным опекунством (Бритни Спирс), официальным обязательством соблюдать трезвость (Линдсей Лоан), счастливым материнством (Николь Ричи), и так далее, и так далее.

1. Miley Cyrus
2. Vanessa Anne Hudgens
3. Chris Brown
4. Jonas Brothers
5. Rihanna
6. Taylor Swift
7. Jamie Lynn Spears
8. Hayden Panettiere
9. Zac Efron
10. Selena Gomes

Олимпийцы

Олимпийский девиз «Citius, Altius, Fortius», если кто не знает, переводится как «быстрее, выше, сильнее». Про олимпиаду выпуска 2008 г. можно сказать, что по сравнению со своими предыдущими изданиями она стала как минимум больше. Встречаем самых отличившихся спортсменов:

1. Michael Phelps
2. Leryn Franco
3. Serena Williams
   
4. Kobe Bryat
5. Shawn Johnson
6. Jennie Finch
7. Misty May Treanor
8. Ronaldinho
9. Alicia Sacramone
   
10. Nastia Liukin

Политики
Годик выдался еще тот. Не можете отдышаться? И все-таки несмотря на все ужасы Уолл-стрит он запомнится людям прежде всего как год президенстких выборов.

1. Barack Obama
2. Sarah Palin
3. Hillary Clinton
4. Gina Garano
   
5. George Bush
6. Ron Paul
7. John Edwards
8. Mike Huckabee
9. Arnold Schwarzenegger
10. Mitt Romney

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

1. Angelina Jolie
2. Sarah Palin
3. Oprah Winfrey
4. Hillary Clinton
5. Gina Garano
6. Tina Fey
7. Michelle Obama
8. Katie Couric
9. Barbara Walters
10. Dara Torres

Экономика
С экономикой у нас сами знаете что. Антикризисные вливания в размере 700 миллиадров долларов. Банкротства и просроченные закладные. Фондовый рынок камнем идет ко дну. В конце 2008 г. финансовые неурядицы вполне успешно конкурировали с президентскими выборами в плане количества пользовательских запросов.

1. IRS Stimulus Checks
   (Термин можно перевести как «стимулирующие чеки налоговой службы». Антикризисная мера правительства США, суть которой заключается в следующем: государство раздает гражданам деньги, — в районе 600 долларов на брата, — чтобы стимулировать потребительский спрос.)
2. Oil Prices (цены на нефть)
3. Gold Prices (цены на золото)
4. Gas Prices (цены на бензин)
5. Dow Jones (индекс Доу Джонса)
6. Sallie Mae (крупная финансовая компания, выдающая кредиты на обучение в колледжах)
7. Stock Market (фондовый рынок)
8. AIG (крупнейшая страховая компания США)
9. Foreclosure (лишение права выкупа имущества по закладной)
10. Debt Consolidation (консолидация долгов)

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

1. Heath Ledger
2. Bernie Mac
3. Paul Newman
4. Randy Paish
   
5. George Garlin
6. Estelle Getty
7. Tim Russert
8. Brad Renfo
9. Isaac Hayes
10. Boyd Coddington

Рядом с каждым элементом выдачи выводится две кнопочки, позволяющие переместить позицию на первое место (стрелка вверх) или удалить ее из выдачи (крестик). В последнем случае позиция перемещается в нижнюю часть страницы, под заголовок «You have removed results from this page«  и остается видимой. Впрочем, удаленные позиции можно скрыть, нажав на соответствующую кнопочку рядом с этим заголовком.

Кроме того, пользователи теперь получили возможность оставлять комментарии к тем или иным позициям (для этого нужно нажать иконку комментария после сниппета). Оставленные отзывы — предупреждает Google — будут доступны другим пользователям. После перемещения позиции выдается сообщение о том, сколько пользователей осуществило аналогичную операцию

Важно понимать, что все изменения выдачи, осуществленные внутри аккаунта, не влияют на на результаты, показываемые остальным пользователям — по крайней мере, напрямую. Если вы хотите просмотреть сводку всех перемещений, удалений и комментариев, нажмите на ссылку  «See all notes for this SearchWiki» в подвале страницы. Увидеть выборку можно также добавив &swm=2 к адресу страницы с результатами поиска.

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

Основная цель SearchWiki — позволить пользователям подстраивать выдачу под себя посредством ручных манипуляций и обеспечить большую предсказуемость результатов поиска. Многие пользователи регулярно вводят однотипные общие запросы, такие как [mail], [weather], [news], при этом выдача по этим запросам постоянно меняется. В этой связи представляется разумной ситуация, когда пользователи могут зафиксировать свои любимые ресурсы на первых позициях выдачи. Если вы не можете найти в выдаче любимый ресурс, кликните на ссылке «Add a result«, чтобы вручную добавить сайт в топ.

SearchWiki — положительные моменты

• Вы можете подстраивать результат выдачи по типовым запросам под свои нужды, что в конечном итоге позволяет сэкономить время при поиске.
• Используйте Google вместо закладок — теперь это возможно
• При изучении выдачи по незнакомым запросам wiki может обеспечить вас ценными комментариями и альтернативным ранжированием (старайтесь не использовать wiki в случае потенциально заспамленных запросов).

Google всегда использовал данные о кликах для улучшения выдачи, поэтому SearchWiki вполне могут подключить к алгоритму ранжирования — самыми различными способами. «В настоящий момент мы не используем SearchWiki при ранжировании, однако нетрудно увидеть, как это может быть сделано в будущем,» — отметила Марисса Майер. «Поиск приспосабливается к новым требованиям по мере того, как интернет становится все более всеобщей средой. Теперь мы можем получать прицельные данные о том, какую выдачу хотели бы видеть пользователи. Нетрудно предположить, что если мы увидим некий особенный сайт, относительно которого пользователи необычайно единодушны, это может вызвать некую реакцию. Например, мы можем проверить наш механизм нейтрализации спама,» — рассуждает Цердик Дюпон, менеджер проектов SearchWiki и Google Knol.

Источник: http://googlesystem.blogspot.com/2008/11/google-searchwiki-launched.html

Общение с вебмастерами в чате позволяет выявить распространенные мнения, которые могли соответствовать действительности в прошлом, но потеряли свою актуальность к сегодняшнему дню. Примером может послужить моя недавняя беседа с несколькими приятелями на тему оптимальной структуры URL. Один из них беспокоился по поводу использования динамических адресов, поскольку (как он сказал) «поисковым системам трудно иметь с ними дело». Другой утверждал, что обработка динамических URL уже давно не представляет для поисковиков никаких трудностей. Один из них также добавил, что он никогда толком не понимал суеты, поднятой вокруг  динамических  и статических  адресов.  В этот момент мы решили написать топик, целиком посвященный данной проблеме. Сперва, давайте проясним, о чем, собственно, идет речь.

Что такое статический URL?

Статический URL — это адрес, который не меняется и, как правило, не содержит в себе никаких параметров. Статический адрес может выглядеть, например, так: http://www.example.com/archive/january.htm. Вы можете включить поиск по статическим адресам в Google, набрав filetype:htm в поисковой строке. Обновление подобных страниц зачастую  отнимает довольно много времени, особенно если количество информации быстро растет, поскольку код каждой отдельной страницы приходится приходится писать и редактировать в индивидуальном порядке. Вот почему вебмастеры, имеющие дело с часто обновляемыми сайтами — например, интернет-магазинами, форумами, блогами или системами управления контентом — нередко используют динамические адреса.

Что такое динамические адреса?

Если контент сайта хранится в базе данных и выводится на дисплей по запросу, как правило, используются динамические адреса. Сам сайт в этом случае играет роль шаблона для контента, существующего независимо от своего визуального представления. Как правило динамические URL выглядят примерно так: http://code.google.com/p/google-checkout-php-sample-code/issues/detail?id=31. Признаком динамического адреса служат символы ? = &. Динамические адреса имеют тот недостаток, что нескольким различным URL может соответствовать один и тот же контент. Таким образом, пользователи могут ссылаться на один и тот же контент с помощью разных URL, используя отличные параметры запроса. Вот почему вебмастера зачастую пытаются настроить приведение динамических адресов к статическому виду.

Нужно ли маскировать динамические URL под статические?

Перечислим несколько ключевых моментов, о которых необходимо помнить в связи с динамическими адресами:

1. Создать и поддерживать механизм, корректно преобразующий динамические адреса в статические, довольно трудно.
2. Куда проще и надежней будет использовать динамические адреса и позволить нам самим решать проблему нахождения и игнорирования ненужных параметров.
3. Если вы-таки намерены преобразовывать адреса, пожалуйста, удалите из них все необязательные параметры, но оставьте их динамическими. 
4. Если вы намерены выдавать статические адреса вместо динамических, вам следует продублировать свой динамический контент статическим эквивалентом.

Какие адреса Google легче воспринимать — статические или динамические?

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

Миф: «Динамические URL не индексируются».
Факт: Мы без проблем индексируем динамические адреса и интерпретируем различные параметры. У нас могут возникнуть проблемы с краулингом и ранжированием динамических URL в том случае, если вы приводите их к статическому виду и прячете при этом параметры, несущие ценную информацию для Google-бота. Отсюда следует рекомендация — не  преобразовывать динамические  URL в статические. Вообще лучше всего использовать статический контент со статическими адресами, однако если уж вы решили использовать динамический контент, вы должны предоставить нам возможность анализировать структуру ваших URL. Другими словами, не нужно нужно маскировать параметры, приводя их к статичному виду.

Миф: «Динамические адреса должны содержать в себе менее трех параметров».
Факт: Ограничения по количеству параметров не существует, тем не менее общим правилом должно быть стремление к  коротким  URL (это относится к любым адресам, и статическим, и динамическим). Возможно, вам стоит удалить параметры, не важные Google-боту, и предоставить пользователям более симпатичные динамические URL. Если вы не до конца уверены в том, какие именно параметры подлежат удалению, мы советуем не удалять ничего — наша система сама отбросит все ненужное. Неграмотное преобразование существенно затрудняет задачу по выделению важных параметров, то есть мешает нам правильно анализировать URL, что в конечном итоге ведет к информационным потерям.

Далее осветим несколько наиболее вероятных вероятных вопросов.

Значит ли это, что мне стоит избегать преобразования динамических URL?Таковы наши рекомендации — до тех пор, пока речь не идет об удалении необязательных и потенциально проблемных параметров. Приведение  динамических адресов к статическому виду может помешать нам корректно интерпретировать вашу информацию во всех возможных случаях. Если вы намерены предоставлять пользователям статический эквивалент вашего сайта, вам следует задуматься о преобразовании не только адресов, но и структуры самого контента — таким образом, чтобы информация на выходе и в самом деле выглядела статично. Например, можно сгенерировать по файлу для каждого из возможных адресов и сделать эти файлы доступными где-либо на сайте, чтобы пользователи и поисковики обращались именно к этим файлам. Как бы то ни было, преобразование адресов без создания статичной копии контента рискует принести больше вреда, нежели пользы. Лучше показывайте нам динамические адреса — мы сами сможем выявить в них все лишнее.

Можете привести пример?

Если стандартный формат ваших динамических адресов выглядит примерно так:  foo?key1=value&key2=value2 мы рекомендуем оставить его неизменным. Google сам определит, какие параметры можно из него удалить. Вы можете и сами можете удалить из URL необязательные для пользователей параметры, однако будьте предельно осторожны, чтобы случайно не удались что-нибудь важное. Вот еще один пример динамического адреса с несколькими параметрами:

www.example.com/article/bin/answer.foo?language=en&answer=3&sid=98971298178906&query=URL

• language=en — указывает на язык статьи
• answer=3 — статья имеет порядковый номер 3
• sid=8971298178906 — идентификатор сессии равен 8971298178906
• query=URL — статья была найдена по запросу следущего типа: [URL]

Далеко не все параметры данного запроса несут в себе полезную информацию, поэтому приведение URL к виду www.example.com/article/bin/answer.foo?language=en&answer=3 вероятно, не создаст никаких проблем — из адреса были удалены только необязательные параметры.

Далее следует несколько адресов, выглядящих как статические, но вместе с тем способных затруднить краулинг гораздо сильнее, нежели стандартные динамические адреса:

• www.example.com/article/bin/answer.foo/en/3/98971298178906/URL
• www.example.com/article/bin/answer.foo/language=en/answer=3/sid=98971298178906/query=URL
• www.example.com/article/bin/answer.foo/language/en/answer/3/sid/98971298178906/query/URL
• www.example.com/article/bin/answer.foo/en,3,98971298178906,URL

Преобразование динамического адреса в нечто подобное может привести к тому, что краулеру придется по несколько раз индексировать один и тот же контент, доступный по разным адресам — с различными идентификаторами сессий и типами запроса.  Подобный формат адресов мешает  Google понять, что URL и  98971298178906 не имеют прямого отношения к контенту, лежащему по данному адресу. Далее — пример правильного преобразования, при котором все необязательные параметры были удалены:

• www.example.com/article/bin/answer.foo/en/3

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

• www.example.com/article/bin/answer.foo?language=en&answer=3

Мы надеемся, что статья окажется вам полезна, и что в конечном итоге она поможет развеять разнообразные домыслы, связанные с проблемой динамических URL.  Если у вас остались какие-либо вопросы, пожалуйста, присоединяйтесь к нашей дискуссионной группе.
Источник: http://googlewebmastercentral.blogspot.com/2008/09/dynamic-urls-vs-static-urls.html