В данной статье разберем, что делать с висячими узлами на сайте. Подписчик спрашивает: «Интересно узнать про висячие узлы. Так ли необходимо закрывать их или не так много веса по ним уходит?».
Что такое висячие узлы?
Если вы обойдете сайт каким-нибудь краулером (программой для сканирования сайта), он построит паутинку из ссылочных связей внутри сайта: страница А ссылается на страниц В, та в свою очередь на страницу С, а последняя жадничает и ни на кого не ссылается. И вот это вещь с нессылающейся ни на кого страницей называется «висячим узлом».
На данный момент висячии узлы встречается не так часто на реальных сайтах — просто потому, что структура стандартного построения сайта поменялась. Например, раньше, в двухтысячных годах, очень часто делали версию для печати. Нельзя было нормально печатать страницу, просто нажав на кнопку. Сейчас это можно сделать с помощью стилей, а тогда то ли нельзя было, то ли так не делали. И поэтому делалась отдельная страница для печати: то есть была какая-нибудь статья, и в уголке принтер был нарисован, на него кликали и попадали на страницу для печати. Так как эта страница была без обвязки — без менюшки, технических элементов, — то ссылок с нее обычно не было, то есть она как раз была висячим узлом. И таких страниц было очень много. И в те времена об этой проблеме можно было говорить.
Сейчас такие страницы обычно означают, что на сайте есть какая-нибудь проблема. Висячий узел — это признак того, что какая-то техническая страница попала на индексацию и никак не закрыта. И как правило это те, которые не должны ранжироваться.
Поэтому, если вы нашли у себя такой висячий узел, то сразу проверяете, нужна ли такая страница в поиске, будет ли она полезна пользователям. И обычно ответ — нет. И если так, то просто закрываете ее от индексации и дело с концом.
Влияют ли они на вес
Когда мы считаем условный классический PageRank, а именно сколько страниц вашего сайта накапливает на себе веса, который может передать дальше. Он ей помогает ранжироваться, и она передает его дальше. И что происходит в этот момент? Когда вы составили перелинковку страниц, то есть они у вас ссылаются друг на друга, то если говорить про классический PageRank, который имеет несколько проходов, происходит такой момент: страница А ссылается на В и передает ему вес с некоторым дисконтом. Грубо говоря: на А был вес ,она передала В 0,85, то есть чуть меньше. Когда страница В ссылается на С, то еще чуть меньше, но плюс свой вес. То есть таким образом с некоторым дисконтом оно начинает разгонять друг друга, и если много раз так происходит, то дисконтирование каждый такой круг передачи будет все меньше и меньше веса передавать. Поэтому, когда рассчитывается PageRank в разных анализаторах, то кто-то делает один проход (один такой круг), кто-то 2-3, но никто не делает 100, потому что смысла это не имеет, каждый раз будет затухание.
Что происходит, когда в этой красивой системе ссылок страниц друг на друга появляются висячие узлы? То есть, когда цикл прерывается, и страница С перестает ссылаться на А? Тогда страница С набирает на себя вес, но никому его не передает, и в этом случае цикличность перестает работать и не добавляет свой вклад в вес других страниц, на которые могла бы ссылаться. Причем, если брать вариант из 3 страниц, то здесь все понятно: все получили свой вес. Но когда сайт большой и много страниц, которые не передали другим свой вес, то в целом общий вес, который сосредоточен на сайте — немножко меньше. Не в 2-3 раза, а на 10%, например.
Формально это немного мешает продвижению: страницы на себя вес забрали, а другим не отдали. То есть, условная страница отдала 1/20 веса, а могла бы 119, если бы «жадины» среди них не было. А учитывая, что висячие узлы обычно ненужные для продвижения страницы, то вообще вес утек на них просто в никуда.
Поэтому сами эти страницы вес не уводят, но немного на них утекает, однако для продвижения это практически никак не заметно. Так что с точки зрения веса это проблем особых не приносит, а вот с точки зрения того, что это как правило мусорные страницы, которые в индексе не нужны — на это стоит обратить внимание. То есть висячие узлы — это не такая большая проблема, как принято об этом говорить.
[hi]
15 Основных Методов Повышающих Уровень Page Rank
Google pagerank alexa rank domain age — это алгоритм анализа ссылок, который используется поисковыми системами для того, чтобы оценить вес Ваших ссылок относительно других. Как Рассчитывается Page Rank? Page Rank рассчитывается через различные алгоритмы разработаны конкретные поисковые системы (Google, Yahoo и т. д.). В общем говоря, Page Rank рассчитывается на основе ссылок, связанных с Вашей страницей, в том числе:
Содержание:
- Pagerank висячий узел как исправить
- Как поднять pagerank сайта?
- Domain age alexa rank google pagerank seitend
[yw]Входящих ссылок Исходящих ссылок Ссылки между страницами на Вашем сайте Ссылка типа No-Follow Ссылки типа Do-Follow[/yw] Так как Google и другие поисковые системы, анализируют эти ссылки, чтобы назначить Вашему сайту Google pagerank alexa rank domain age от 1 до 10. Ниже я представлю 15 Основных Методов, Повышающих уровень Page Rank.
Как поднять pagerank сайта?
1.Высокое Качество Контента на Сайте В целях повышения google pagerank alexa rank domain age Вашей страницы, все тексты должны быть уникальными и хорошего качества. Должны быть так хороши, чтобы люди сами делились ими с другими. 2.Продвижение Сайта Если зависит на повышении google pagerank alexa rank domain age group, Ваш сайт должен иметь качественные ссылочные массы. Самый простой способ узнать как поднять pagerank сайта, чтобы реализовать это предположение, является добавление сайта в различные интернет-каталоги компаний. Отличной идеей является размещение интересных статей на страницах » Presell Pages. Не забудьте о добавлении ссылки на ваш веб-сайт в, или под статьей!
Вот некоторые каталоги в которые стоит добавить ваш сайт:
[yw]DMOZ Каталог компаний Onet.pl Каталог компаний wp.pl Каталог Gazeta.pl 3.Добавление комментария как гость[/yw] Это один из самых популярных методов, используемых для повышения pagerank. Большинство блогов имеют функцию публикации комментариев, к которым можно также добавить ссылку на Ваш блог. Получение таких ссылок очень помогает, особенно, если они связаны тематически с Вашей деятельностью. 4.Обмен Ссылками Один из старейших методов, но дальше работает. Для получения хорошего pagerank вы должны регулярно получать ссылки с других сайтов с высоким показателем PR. Влияет также положительно на количество людей, посещающих Вашу страницу.
Смотрите на эту же тему: Как поднять тиц самостоятельно
5. Активно обновляйте сайт
Google действительно любит и ценит сайты, которые имеют свежий и уникальный контент. Чем больше новостей вы размещаете, тем больше Google будет посещать ваш сайт, что в свою очередь увеличит Ваши шансы получить более высокий PR (pagerank). 6.Социальные Закладки Социальные Закладки, это очень эффективная методика, помогающая увеличить pagerank. Она заключается в обмене вашего сайта с помощью различных социальных сетей. Вы получите посещения благодаря тому, что размещаете бесплатные ссылки, а также улучшите движение на вашем веб-сайте. Вот некоторые из самых популярных социальных сетей для поднятия Google pagerank alexa rank domain age: Facebook Google Plus Stumble Upon 7. Высокое Качество Стороны
Domain age alexa rank google pagerank seiten
Если Ваш сайт загружается долго, Google может снизить его рейтинг. Всегда имейте в виду высокая доступность сайта. Позаботьтесь о чистом и исправном коде. 8.Используйте Низко конкурентные ключевые слова как это делается описано в этой статье Вы наверняка знаете, что люди в процессе поиска в Интернете используют ключевые слова, а не целые предложения. Старайтесь использовать эти слова для вашего сайта. Делай, но в меру! Слишком частое использование выбранных ключевых слов может принести больше вреда, чем пользы. 9.Продвижение Сайта Вы можете подготовить объявление или баннер Вашего сайта и рекламировать себя на других сайтах. Вы получите и хорошие бэк-ссылки, а также дополнительные источники новых посетителей. 10.Создайте Несколько Страниц Если описание каждой услуги будет находиться на отдельной странице сайта, вы увеличите силу внутренних ссылок и улучшит PageRank. 11.Участвуйте в Обсуждениях на Форумах Google любит форумы, так как они часто обновляются. Разместить ссылку на свой сайт в подписи и ведите живую беседу с другими пользователями. 12.Когда Google Обновляет Обновляет Page Rank? Google делает это от трех до пяти раз в год. Происходит это в среднем каждые 3 месяца. Существует много различных способов проверить pagerank стороны. Просто введите в поисковой системе page rank
13.Никогда Не Используйте Незаконных Методов
Применение незаконных тактики может повлечь за собой получение Бана от Google. Вопреки расхожему мнению, Google гораздо умнее, чем вы можете предположить. Никогда не думай, что удастся его обмануть. Рано или поздно каждый ощутит последствия применения незаконных методов. Что бы вы сделали, если бы Ваш сайт в один прекрасный день вылетела из Google? Ищете компанию которая отвечает за создание pagerank висячий узел как исправить, а также их продвижение? Оставьте свой комментарий в поле ниже.
]]>
Разбираем на примере трех проектов на Тильде
Внутренняя оптимизация помогает сайту с хорошим контентом занимать высокие позиции в поисковой выдаче. Но когда проект развивается и обрастает новыми страницами, можно допустить ошибки, которые негативно повлияют на рост позиций сайта. Как вовремя найти и исправить эти ошибки, расскажем в статье.
Зачем проверять настройки сайта для SEO
Чем выше позиции сайта в поисковой выдаче, тем людям проще его найти и тем больше посетителей может на него перейти. На позиции влияют разные факторы: контент, история сайта, количество упоминаний в других источниках и техническая оптимизация. Последняя играет большую роль в общем успехе продвижения в поисковых системах.
Технические настройки включают в себя настройку названий и описаний страниц (метатегов), заголовков, атрибутов у изображений, переадресаций, создание страницы для 404 ошибки и многое другое.
В Тильде все настройки можно сделать в интерфейсе. В справочном центре мы подготовили чек-лист по оптимизации сайта, который поможет проделать основную работу, связанную с SEO.
Когда вы только запускаете сайт, вы можете несколько раз проверить, чтобы все настройки были сделаны идеально. Когда проект развивается, постоянно создаются новые страницы, редактируются и удаляются старые, можно допустить ошибки, которые повлияют на продвижение. Чтобы этого не произошло, нужно периодически проводить проверку.
Руководитель турагентства открыл новое направление — фитнес-туры в Испанию. За полгода контент-менеджер Иван написал 10 статей для блога, которые нравятся читателям. Но он поставил у всех страниц со статьями одинаковые названия (метатег Title) и описания (метатег Description), а также не добавил заголовкам статьи теги H1 и H2. Статьи плохо ранжировались и не попали на первые страницы поисковой выдачи.
Иван посоветовался с SEO-специалистом и сделал все настройки. Несколько материалов поднялось на первую страницу поисковой выдачи по важным запросам: «как выбрать фитнес-тур», «фитнес-туры на море». За месяц их прочитала 1000 новых посетителей, а 10 из них заказали тур.
Краткий словарь SEO терминов
Чтобы было проще разобраться, что это за настройки и зачем они нужны, мы подготовили краткий словарь SEO терминов
Метатеги Title и Description — заголовок и описание страницы, которые отображаются в поисковой выдаче. На самой странице они не видны, но название отображается на вкладке браузера. Помимо этого, указанные вами Title и Description часто используются поисковыми системами для показа в результатах поиска.
Индексация — передача страниц и другого содержимого сайта (изображений, видео, ссылок и т. д.) роботом-пауком в индекс поисковой системы. Индекс представляет собой своеобразный список страниц, к которым поисковая система обращается во время поиска страниц, соответствующих запросам пользователей.
Код ответа сервера — трехзначное число, которым обозначается определённый статус запрашиваемой страницы. Даёт понять браузеру и поисковому роботу, как сайт отреагировал на запрос к определённой странице.
H1-H6 — шесть тегов, которые используются при создании HTML-страниц для структурирования и деления информации на блоки. Заголовок, обозначенный тегом H1, имеет наибольшую значимость для поисковых систем.
Альтернативный текст для изображений (тег ALT) — показывается на месте изображения, если само изображение не видно (например, в момент загрузки при медленном соединении). Кроме этого, поисковые системы воспринимают альтернативный текст как ключевые слова и учитывают их при индексации.
Глубина страницы — количество кликов, отделяющих страницу от главной.
Rel=canonical — атрибут, указывающий каноническую, приоритетную для индексации страницу. С его помощью все характеристики (ссылочный вес, поведенческий фактор и т. д.) передаются нужной версии документа, а копии отмечаются поисковым роботом как малозначительные и не попадают в индекс.
Внутренний PageRank — относительный показатель распределения ссылочного веса веса между страницами в пределах одного сайта. Вес передаётся при помощи ссылок с одной страницы на другую, а также атрибута rel=canonical и редиректов.
Какими бывают ошибки оптимизации и как их найти
В SEO существуют ошибки разной степени критичности, включая как очень важные, так и незначительные. Например, критическая ошибка — это дубли страниц. Если вы не указали в настройках при помощи атрибута Canonical, какая страница основная, а какую не нужно индексировать, поисковые системы могут понизить позиции обеих страниц.
Критические
- Важная страница закрыта от индексации
- Дубли страниц
- Бесконечный редирект
- Максимальная длина URL
- Нет адаптивной версии
- Наличие битых ссылок или битых изображений на сайте
- У страницы нет названия и/или описания (метатеги Tiltle и Description)
- Ссылка на логотипе в верхней части страницы ведет на другой сайт
- Купленный домен находится в черном списке
Важные
- Цепочка переадресаций (редиректов)
- На странице отсутствует тег заголовка H1 Нет страницы 404 ошибки
- Большой размер изображений
- Системный URL вместо понятных слов
- Не прописан альтернативный текст у изображений
- Низкая скорость ответа сервера и загрузки страницы
Незначительные
- Короткий Title и/или Description
- Слишком длинный заголовок H1
- На сайте не настроено безопасное соединение по про протоколу HTTPS
Лучше устранять все виды ошибок, но к критическим нужно относиться особенно внимательно. Допустив их, вы можете упустить шанс оказаться в зоне видимости пользователя или серьёзно понизить уже имеющиеся позиции в выдаче. Вернуть всё назад будет сложно.
Чеклист для проверки сайта на ошибки
Поиск дубликатов страниц. Проверка настроек переадресации, канонического атрибута страницы
На сайте не должно присутствовать страниц с одинаковым контентом. Если нужно оставить страницы с частично или полностью повторяющимся контентом, у второстепенных страниц должен присутствовать атрибут rel=canonical.
Проверка доступности страниц для индексации. Проверка кодов ответа сервера
Страницы с важным контентом должны быть открыты для индексации и отдавать код ответа сервера 200 OK.
Проверка времени загрузки страниц сайта и скорости ответа сервера
Скорость ответа сервера должна быть меньше 500 мс.
Проверка метатегов Title и Description, тега заголовка H1
У каждой страницы должен быть уникальный Title и Description. Длина Title должна быть от 10 до 70 символов, Description — от 60 до 260 символов в среднем.
На каждой странице должен быть назначен тег H1 главному заголовку. Не рекомендуется делать его длиннее 65 символов.
Проверка структуры URL-адресов и глубины страниц
URL должны состоять из понятных слов. Глубина страниц — количества кликов, отделяющих страницу от главной. Рекомендуется, чтобы она не превышала 4.
Проверка оптимизации изображений
Оптимальный размер изображений — 100 кб. У изображений должен присутствовать альтернативный текст. Он должен соответствовать содержимому изображения и содержать от 70 до 250 символов.
Анализ внутреннего PageRank
PageRank — внутренний показатель распределения ссылочного веса между страницами в пределах одного сайта. На сайте не должно быть недостижимых страниц и страниц без исходящих ссылок.
Внутри Тильды есть встроенный инструмент для быстрой проверки следующих критических ошибок: наличие Title, Description, тега H1, читаемого URL, неопубликованных или закрытых от индексации страниц.
Чтобы запустить проверку, откройте Настройки сайта > SEO > SEO-рекомендации.
Проверка сайта на наличие технических ошибок
Чтобы наглядно показать, как искать ошибки, мы попросили Александру Метизу провести проверку трех разных проектов, сделанных на Тильде:
Сервис для клиентской поддержки Юздеск
Александра Метиза
Для проверки использовали Netpeak Spider — инструмент для комплексного внутреннего SEO-аудита сайта. Фактически программа «обходит» выбранные для сканирования страницы или весь сайт целиком, переходя по внутренним ссылкам.
В процессе Spider анализирует свойства страницы, проверяя метаданные, атрибуты, редиректы, инструкции для поисковых роботов, а также множество других данных, важных для поисковой оптимизации.
Выбор анализируемых параметров зависит от целей сканирования: можно выбрать их вручную, или воспользоваться одним из шаблонов.
1. Мастер-классы грузинской кухни Another Georgia
Сайт: another-georgia.com
Тип компании: малый бизнес
География: Москва
Краткое описание: практические мастер-классы по грузинской кухне
Контент и основные метаданные
Всего в сайте 16 страниц, ни одна из которых не дублируется. Важные проблемы были обнаружены всего на двух страницах: на них отсутствуют заголовки первого порядка H1, а длина Description — меньше рекомендованной.
Как исправить
Добавить тег H1 к заголовкам на страницах.
Инструкция →
Составить более развёрнутый Description (Описание) и указать его в настройках страницы.
Инструкция →
Настройки переадресации и атрибут Canonical
На сайте используются серверные редиректы, которые перенаправляют на зеркала без слеша в конце. Но отсутствует переадресация на единую версию с префиксом www. или без него. Есть вероятность, что это повлечёт за собой появление дублей, которые крайне негативно воспринимаются поисковыми системами. Поисковые роботы воспринимают атрибут rel=”canonical” не как строгую директиву, а как рекомендацию, то есть указанный URL может быть проигнорирован.
Нет переадресации и на HTTP-версию сайта при попытке ввести адрес сайта с https://, хотя имеется ведущий на неё атрибут Canonical.
Как исправить
В настройках сайта настроить переадресацию: Настройки > SEO > Редиректы страниц.
Инструкция →
Проверка кодов ответа сервера. Открытость к индексации
Ни одна из стратегически важных страниц не была закрыта от поисковых роботов: все отдают код ответа 200 OK, а значит, могут быть проиндексированы поисковыми роботами. Исключение составляют несколько служебных страниц.
Время загрузки страниц сайта и скорость ответа сервера
Время ответа сервера в пределах сайта варьируется от 93 до 234 мс, скорость загрузки контента — от 1 до 108 мс. Показатели близки к идеалу.
Структура URL и глубина страниц
Все URL составлены грамотно: их вид отвечает структуре сайта и смыслу каждой отдельно взятой страницы. Нет проблем ни с кодировкой, ни с излишней глубиной: до любой страницы сайта можно добраться в 2 клика.
Распределение внутреннего PageRank
Внутренний PageRank распределяется между страницами равномерно. Перелинковка сделана грамотно, тупиковых страниц нет. Нет таких проблем, как «Висячий узел», «Отсутствуют связи», «Отсутствуют исходящие ссылки».
Висячий узел. Так определяются страницы, на которые ведут ссылки, но на них самих отсутствуют исходящие ссылки, из-за чего нарушается естественное распределение ссылочного веса по сайту.
Отсутствуют связи. Это страницы, на которые не было найдено ни одной входящей ссылки.
Отсутствуют исходящие ссылки. Показывает URL, у которых не были найдены исходящие ссылки.
На сайте не было обнаружено проблем с оптимизацией изображений. Но у 15 из них не прописан атрибут ALT, который мог бы поспособствовать продвижению сайта в поиске по картинках.
Как исправить
Добавить альтернативный текст к изображениям.
Инструкция →
2. Интернет-магазин пряностей Kitchen Ceremony
Контент и основные метаданные
Первая проблема, которая бросается в глаза по итогу сканирования сайта, — несколько битых ссылок, отдающих 404 код ответа.
Кликнув по одной из обнаруженных ссылок, мы неизменно попадаем на страницу «Пряности», однако битый URL не меняется на http://www.kitchenceremony.com/spices/.
В действительности абсолютно нормальная страница имеет код ответа сервера 404 Not Found, что подтверждает даже консоль разработчика в Chrome. Возможно, всё дело в том, что владельцы сайта не создали выделенную страницу для 404 ошибки и назначили на её роль страницу «Пряности».
Как исправить
Создать отдельную страницу 404 ошибки и указать её в настройках сайта: Настройки > Еще > Страница 404.
Инструкция →
Следующая проблема — обилие дубликатов. Netpeak Spider обнаружил несколько одинаковых Title, Description и заголовков первого порядка, использованных для страниц с несколькими разными рецептами и товарами.
Также, просматривая ссылки с дублями, мы обнаружили, что страницы /decor/05 и /decor/06 фактически дублируют друг друга: программа не определила их как полные дубли только потому, что в тексте есть несущественное различие, которое можно обнаружить лишь целенаправленно.
Как исправить
Создать для всех страниц уникальный Title и Description.
Инструкция →
Удалить дубликаты страниц.
Также на некоторых страницах были обнаружены слишком короткие или слишком длинные H1, Description и Title. Эти проблемы имеют низкий уровень критичности, но лучше не оставлять их без внимания.
Как исправить
Привести H1, Title и Description к нужной длине:
- Title — от 10 до 70 символов,
- Description — от 60 до 260 символов в среднем,
- H1 — не более 65 символов.
Настройки переадресации и атрибут Canonical
Не настроены серверные редиректы на одну основную версию сайта, так что внутри сайта смешиваются страницы с префиксом www. и без него.
Страница «Пряности» отдаёт разный код ответа в зависимости от наличия слеша и префикса в адресе. На этом, кстати, проблемы страницы не завершаются: её каноническая версия (http://www.kitchenceremony.com/spices/) закрыта при помощи запрещающей директивы Disallow в robots.txt. Это происходит из-за того, что страница «Пряности» установлена в качестве страницы 404 ошибки.
Как исправить
Настроить редирект с версии сайта без www. на версию с www., или наоборот.
Инструкция →
Создать отдельную страницу 404 ошибки и указать её в настройках сайта: Настройки > Еще > Страница 404.
Инструкция →
Проверка кодов ответа сервера. Открытость к индексации
Согласно результатам сканирования, 77,3% процента обнаруженных на сайте страниц могут быть проиндексированы. Это те страницы, которые открыты для индексации, отдают код ответа 200 OK и не перенаправляют поисковых роботов на канонические URL-адреса. Большинство стратегически важных страниц попадают в их число, но всё же результат мог бы быть значительно лучше.
Скорость ответа сервера и загрузки контента
Минимальное время ответа сервера составляет 49 мс, максимальное — 578 мс, что незначительно превышает допустимую норму. Время загрузки контента также колеблется в рекомендуемых пределах — от 0 до 540 мс.
Структура URL и глубина страниц
Как и в случае с Another Georgia, URL на сайте формируются согласно иерархии страниц. В большинстве случаев адреса страниц включают в себя краткие версии русскоязычных заголовков, прописанных латиницей. Почти на всех из них можно попасть в 2 клика. Но есть и исключения, которые портят идеальную картину.
Как исправить
Проставить ссылки на страницы с глубоким уровнем вложенности таким образом, чтобы «сократить» к ним путь от главной.
Распределение внутреннего PageRank
На сайте есть некоторые проблемы с распределением внутреннего PageRank:
Внутри сайта есть недостижимые страницы
Это касается товарных страниц с описаниями кориандра, хмели-сунели и жёлтого цветка. Клик по миниатюрам этих товаров из каталога специй не перенаправляет пользователя на страницу — он просто добавляет артикул в корзину.
Как исправить
Добавить ссылки на недостижимые страницы. Например, можно добавить ссылки на описание специй в статьи с рецептами.
Страницы, отдающие 404 код ответа, создают так называемые «висячие узлы»
«Висячие узлы», на которых не только теряется ссылочный вес, но и «тормозятся» поисковые роботы. И наличие подобных страниц может негативно сказаться на пользовательском опыте.
Как исправить
Добавить на тупиковые страницы исходящие ссылки, например, на главную или на другие связанные страницы.
Размер имеющихся на сайте изображений не превышает рекомендуемой нормы. Но в то же время у большинства картинок отсутствует атрибут ALT, необходимый для ранжирования в поиске.
Как исправить
Добавить альтернативный текст к изображениям.
Инструкция →
Сайт: usedesk.ru
Тип компании: онлайн-сервис
География: международный рынок
Краткое описание: сервис для общения с клиентами во всех цифровых каналах (чат на сайте, электронная почта, мессенджеры, соцсети).
Контент и основные метаданные
На сайте есть несколько битых ссылок. Некоторые размещены на важных лидогенерирующих страницах. Нужно заменить их корректными рабочими ссылками без потери смысловой связи.
Как исправить
Заменить битые ссылки на соответствующие рабочие.
На сайте существует сразу несколько вариантов ссылок с разными GET-параметрами на страницы авторизации и регистрации, которые открыты для индексации. Они могут определяться поисковыми роботами как дубли из-за того, что страницах не настроен атрибут Canonical. К тому же, на этих же страницах отсутствуют метатеги Description.
Как исправить
Настроить атрибут Canonical, указав в качестве канонических страницы авторизации и регистрации без GET-параметров и дополнительных атрибутов в адресе.
Инструкция →
Прописать Description.
Инструкция →
Примерно у десятка страниц Description короче, чем рекомендуется.
Редиректы и атрибут Canonical
На сайте исправно работают редиректы на основное зеркало сайта (с HTTPS, без слеша и префикса www.).
Директивы по индексации. Индексируемость страниц
В robots. txt от индексации закрыто всего несколько страниц, хотя по большому счёту, нет особенного смысла скрывать их от поисковых роботов.
Все ссылки на страницах, связанных с клиентами компании, и ещё нескольких лендингах закрыты при помощи rel=nofollow, хотя в данный момент в этом нет необходимости. Атрибут nofollow больше не помогает «сохранить» ссылочный вес от передачи другим сайтам.
Скорость ответа сервера и загрузки контента
Время ответа сервера для абсолютного большинства страниц варьируется в рекомендуемых пределах от 47 до 496 мс. Всего 2 страницы составили исключение и превысили планку в 600 мс.
Структура URL и глубина страниц
URL в большинстве случаев отвечают принципу ЧПУ (человеко-понятные URL), а их строение соответствует общей структуре сайта. Средняя глубина страниц составляет от 1 до 4, что не превышает допустимой нормы.
Распределение внутреннего PageRank
Использование вышеупомянутого атрибута rel=nofollow на нескольких десятках страниц привело к неравномерному распределению внутреннего PageRank. Как следствие, 8 страниц сайта были определены краулером как «Висячие узлы», то есть, как страницы без открытых исходящих ссылок.
Как исправить
Убрать атрибут rel=nofollow и добавить на тупиковые страницы исходящие ссылки, например, на главную или на другие связанные страницы.
Все изображения на сайте имеют размер не более 100 кбайт, но при этом ни у одного из них нет сопутствующего атрибута ALT.
Как исправить
Добавить альтернативный текст к изображениям.
Инструкция →
Мы провели базовый аудит трёх работающих сайтов. У двух из них выявили критические ошибки, которые влияют на потенциальную индексацию и ранжирование в поисковой выдаче. Но исправить их можно довольно быстро.
Чтобы избежать проблем с ранжированием сайта, для каждой новой страницы не забывайте делать необходимые настройки по чек-листу и проверяйте весь сайт на критические ошибки не реже раза в месяц.
Текст: Александра Метиза, Роман Яковенко
Верстка, дизайн и иллюстрации: Юля Засс
Если материал вам понравился, поставьте лайк — это помогает другим узнать о нем и других статьях Tilda Education и поддерживает наш проект. Спасибо!
*Компания Meta Platforms Inc., владеющая социальными сетями Facebook и Instagram, по решению суда от 21.03.2022 признана экстремистской организацией, ее деятельность на территории России запрещена.
Статья для тех, кто хочет исправить технические недоработки на сайте, но не знает, с чего начать. Следуйте нашим советам и поисковые роботы увидят на вашем сайте, что должны, а что не должны — не увидят.
В идеальном мире количество страниц сайта, которое должно быть в индексе, равно количеству страниц самого сайта. Но так не бывает. Гораздо чаще краулинговый бюджет расходуется на старые и невостребованные страницы, более важные остаются незамеченными роботами и не попадают в выдачу.
Оптимизация краулингового бюджета нужна, чтобы не растрачивать его впустую, а привлечь сканирующих ботов на важные и нужные разделы и страницы, исключить весь мусор из индекса.
В первой части статьи рассказывали, как посчитать краулинговый бюджет, а в этой — остановимся на советах, которые помогут предотвратить или устранить технические ошибки на сайте. Это оптимизирует краулинговый бюджет и положительно повлияет на ваши позиции в выдаче.
Наращивайте ссылочную массу
Обратные ссылки, которые ведут на наш сайт с других источников, помогают установить доверие с поисковыми системами и улучшить авторитет страницы, что приводит к повышению авторитетности сайта.
Это один из самых важных факторов для SEO-продвижения. Наличие у страницы обратных ссылок покажет поисковой системе, что сайту доверяют. Поисковый робот будет чаще посещать эти страницы, и бюджет сканирования увеличится.
Получить ссылки с других сайтов можно разными способами. Вот самые популярные:
- покупать ссылки на биржах;
- развивать крауд-маркетинг — размещать ссылки на форумах и блогах.
Если речь о крауд-маркетинге, ссылки необходимо размещать только на трастовых сайтах, которым доверяют поисковики. Делать это нужно как можно более естественно — без анкора. И даже если пользователю кажется, что анкорная ссылка выглядит более естественно, увы, поисковые системы считают наоборот — они ценят безанкорные ссылки.
Мы в KINETICA придерживаемся универсальной формулы анкор-листа: 20% анкорных ссылок и 80% безанкорных. На проектах стараемся сводить безанкорные ссылки к минимуму, миксуя их с брендовыми и анкорами-ключевиками.
Увеличьте скорость сайта, чтобы ускорить проверку страниц роботами
Чем быстрее загружается сайт, тем быстрее его просканирует бот. Это повлияет на количество обработанных URL — оно увеличится. Краулинговый бюджет, как правило, изменяется прямо пропорционально времени, потраченному на одну страницу.
Скорость сайта можно проверить в Google PageSpeed Insights. Сервис подскажет конкретные действия, которые можно предпринять для увеличения скорости загрузки.
На одном из наших проектов мы обнаружили, что бот тратил на проверку одной страницы 6 секунд. Это довольно много — напомним, пользователь закрывает страницу спустя примерно 3 секунды. Мы стремимся уменьшить это время до 2 секунд.
В Google PageSpeed Insights низкие результаты были по 2 показателям из 6: сервис отметил большой вес изображений и неподходящий формат — jpeg вместо webp и avif.
Мы детально углубились в вопрос и выяснили: часть карточек товаров индексировалась, а часть нет — из-за того, что в каждой из них было от пяти изображений. Количество фотографий, их вес и формат затрудняли ботам сканирование.
Чтобы увеличить скорость загрузки, мы использовали ускоренные страницы. А для быстрой загрузки картинок мы их сжали и конвертировали, затем сохранили их в соотношении 0,25х, 0,5х, 0,75х, 1х, а затем настроили теги для выдачи картинки в соответствии с размером экрана устройства.
Спустя полтора месяца мы отметили, что все карточки товаров начали индексироваться в поисковиках. Бот начал тратить на проверку одной страницы 2 секунды. А так как на сайте уже присутствовало много полезного контента, отвечающего запросам пользователей, это вкупе с увеличением скорости загрузки повлияло на краулинговый бюджет — он увеличился в 3 раза.
Избавьтесь от проблемных кодов ответа, чтобы не тратить время ботов на их проверку
Если контент присутствует на странице, код ответа будет 200 («ОК»). Если необходима переадресация на другую страницу, код будет 301 («Перейти сюда вместо»). Эти коды считаются идеальными, так как ведут бота к полезному контенту.
Но есть и проблемные коды, которые не показывают контент, а просто тратят время бота. К ним относятся:
- 302 редирект — контент временно недоступен, но обязательно появится. Например, летом вы убрали раздел с шубами и пуховиками. А робот все лето будет стучаться к вам на сайт в ожидании контента на этих страницах. Если на вашем сайте есть страницы с кодом ответа 302, рекомендуем проверить их и настроить на 301 редирект. Со временем 301 перестанут сканироваться и заменятся на целевые, и бот не будет каждый раз проверять страницу в ожидании контента.
- 404 код — страница не найдена. По факту это битые ссылки, от которых надо избавляться. Бот будет периодически посещать эти страницы, ведь ему дается сигнал, что, возможно, страница появится позже.
- 500 код — сервер недоступен. Это явный признак некачественного ресурса, на который робот будет заходить все реже для сканирования.
Такие коды тратят время краулера на определение их ответа. Это приводит к тому, что на обход нужных страниц у бота не хватает времени.
А еще рекомендуем удалить малоценные страницы с сайта. Проверить их наличие можно в Яндекс.Вебмастер. Сервис посчитает страницу малоценной, если она является дублем, не содержит видимый роботу контент или контент просто не востребован.
Заходим в «Индексирование» → «Страницы в поиске» → «Исключенные».
Затем находим в списке показатель «Малоценная или маловостребованная страница». На проекте по продвижению интернет-магазина одежды и обуви он оказался 3,77%. Это неплохой результат и представлен он был, в основном, битыми ссылками (код 404), которые мы впоследствии удалили.
Если ваш показатель от 20%, рекомендуем бить тревогу — вероятно, к битым ссылкам добавятся дубли страниц и скрытый контент. Когда четверть сайта представляет собой малоценные страницы, боты могут потерять к нему доверие. Необходимо как можно скорее выявить причины и устранить их, чтобы не терять в индексации.
Актуализируйте robots и sitemap, чтобы робот понял структуру сайта
Robots и sitemap — это xml-файлы, которые помогают поисковым ботам правильно просканировать сайт и лучше понять его структуру:
- В файле robots.txt закрывают мусорные страницы, дубли, страницы пагинации. Роботы поймут, что не нужно тратить на их проверку время. Так мы сэкономим краулинговый бюджет.
- В файле sitemap прописывают все страницы сайта, которые необходимо проиндексировать. Он носит рекомендательный характер и дает понять роботу приоритет по сканированию.
На одном из проектов, который зашел к нам на аудит, мы обнаружили полное отсутствие robots и sitemap. Сканирование и индексация сайта проходили очень медленно и неэффективно из-за переезда с одного домена на другой и большого количества редиректов. Пользователям это было незаметно, а роботы пытались сканировать все страницы, тратя на это бюджет.
После внедрения robots и sitemap количество обращений роботов к сайту со 100 выросло до 300. Краулинговый бюджет увеличился в 3 раза, отчего улучшилось сканирование сайта в целом.
Удалите цепочки редиректов
Редиректы остаются отличным решением проблем с переадресацией:
- При наличии дублей страниц дают понять роботу, на какую страницу смотреть. Если раньше бот индексировал по одному запросу две страницы, то теперь он будет знать, что есть одна трафиковая страница, а все остальные переехали на нее.
- Поможет отправить бота или пользователя на действующую страницу. Актуально, если мы удалили страницу с ошибками (код 404), но с хорошими поведенческими факторами и которую смотрели боты. Так мы сохраняем трафик на нужной нам странице.
Однако робот при получении редиректа 301 пройдет по всем URL в цепочке и израсходует ваш краулинговый бюджет. Поясняем — бот увидит первую ссылку, а вторую — после перехода на нее. И только после этого перейдет на страницу с правильным URL.
Цепочка редиректов запутает робота и не позволит ему сразу попасть на нужную страницу. Повторимся, речь здесь именно о нескольких страницах с кодом 301, а не об одном редиректе.
А представьте, что таких цепочек будет много — пользователю это не заметно, но робот будет вынужден переходить от ссылки к ссылке, чтобы найти нужную страницу.
Мы в KINETICA настраиваем редиректы так, чтобы они отправляли бота сразу на релевантную страницу. То есть не создаем цепочки, а используем код 301 только один раз перед конечным URL. Помимо этого мы убираем все ссылки с сайта на страницу с кодом 301.
Со временем страницы редиректов уходят из поля зрения поисковиков и индексируются только конечные URL. Это позволяет сохранить краулинговый бюджет.
Настройте перелинковку на важные страницы сайта
При сканировании и индексировании сайта бот чаще всего отдает предпочтение страницам, которые имеют вес. Чтобы его создать, необходимо настраивать перелинковку между страницами.
Мы используем уникальные и разнообразные анкоры с ключевыми словами и добавляем ссылки на страницы, соответствующие тематике. По нашему опыту оптимальное число внутренних ссылок на страницу — от 7 штук.
Грамотная структура усиливает значимость страниц, направляя ссылочный вес в нужный раздел при помощи перелинковки. Краулерам это помогает находить нужные страницы без лишнего расходования бюджета, а пользователю — быстро достигнуть нужную страницу. Это улучшает юзабилити сайта и поведенческие метрики, что будет сигналом для ПС к увеличению бюджета.
Разместите заголовок Last-Modified, чтобы рассказать роботам об изменениях на странице
Заголовок Last-Modified сообщает браузеру пользователя или роботу ПС информацию о дате и времени последнего изменения текущей страницы.
Вот как он выглядит:
Шаблон Last-Modified: <день недели>, <число> <название месяца> <год> <час>:<минута>:<секунда> GMT
Пример Last-Modified: Thu, 19 May 2022 13:23:00 GMT
Оптимизация краулингового бюджета в этом случае происходит за счет того, что бот изначально понимает, какие страницы добавлялись недавно или редактировались. И вместо того, чтобы обходить весь сайт, индексация происходит точечно. Это особенно важно для сайтов с большим количеством страниц.
При добавлении заголовка ускоряется загрузка страницы и снижается нагрузка на сервер, а значит, значительно ускоряется скорость индексации страницы.
Определите основную страницу и склейте дубли, чтобы робот просканировал страницу с большим трафиком
Во время сканирования бот может найти дубли страниц — одну и ту же страницу под разными URL-адресами. В конечном счете он отдаст предпочтение одной из них.
Казалось бы, все хорошо, но пока идет сканирование и индексация сайта, на дубли расходуется краулинговый бюджет. Если таких страниц немного, это не критично. Но для крупных сайтов наличие дублей может заметно сказаться на скорости индексации. К тому же, бот может сам выбрать в качестве основной страницу, которую нам продвигать не нужно.
На проекте по продвижению светового оборудования мы определили пул дублей страниц. К одним и тем же товарам пользователь мог дойти разными путями. Например, к определенному светильнику — через категорию светильников либо через категорию брендов. То есть товар один, а карточки разные.
Мы определили страницы, которые среди дублей приносили больше трафика и сделали их основными. На остальные же поставили атрибут rel=”canonical” с адресом основной страницы. Кстати, это не единственный вариант работы с дублями страниц, подробнее мы рассказывали в одной из прошлых статей.
Склейка дублей позволила сохранить число страниц в индексе, при этом не навредить репутации сайта большим количеством неуникального контента.
Поправьте оставшиеся недочеты технической оптимизации
Недочеты внутренней оптимизации могут быть некритичны для малого сайта, но с ростом их количества и масштаба сайта они будут создавать проблему — тратить время поискового бота и ухудшать индексацию сайта. Их нужно устранить.
Избавьтесь от цикличных ссылок, чтобы не вводить в заблуждение пользователей
Цикличная ссылка — та, что ссылается сама на себя.
Например, вы находитесь на странице с белой футболкой → чуть ниже вам предлагают перейти на страницу с другой белой футболкой → вы переходите и попадаете на прежнюю страницу и никакой другой футболки не видите.
Во-первых, это вводит в заблуждение пользователя и раздражает его, так как он тратит свое время на поиск. Во-вторых, это приводит к трате ссылочного веса и расходу краулингового бюджета.
Для больших сайтов это является критическим моментом, так как может существенно повлиять на скорость обхода и индексирование страниц.
Чаще всего циклические ссылки встречаются в хлебных крошках — навигационной цепочке, когда ее хвост заканчивается активной ссылкой на текущую страницу. Так делать не нужно — цикличную ссылку необходимо убрать.
Проставьте ссылки на потерянные страницы, чтобы пользователи и боты смогли вас найти
Потерянные страницы — это страницы, на которые невозможно попасть через внутренние ссылки. Из-за этого пользователи и боты не смогут их найти.
Наглядно они выглядят так:
При обнаружении таких страниц проанализируйте их:
- если потерянная страница нужна, проставьте на нее ссылки и передайте тем самым внутренний вес с сайта;
- если потерянная страница не нужна, удалите ее.
Удалите висячие узлы, чтобы не терять ссылочный вес страниц
Висячий узел — это страница без исходящих ссылок. Она принимает ссылочный вес, но никуда его не отдаёт. Вы словно видите на сайте список со статьями на разные темы, переходите на эти страницы и доходите до страницы, с которой никуда не перейти.
Пользователю в этом случае просто неудобно — чтобы вернуться на предыдущую страницу, ему придется нажать кнопку «назад» или зайти в поиск. А робот в этом случае окажется в тупике, ведь ему некуда переходить со страницы, а нажать на кнопку «назад» он не может.
Чаще всего висячие узлы не представляют серьезной проблемы, но нужно проанализировать характер такой страницы и по возможности внести корректировки:
- если на странице содержится контент, который не поместился на основную страницу, удалите висячий узел, полностью перенеся контент на основную страницу;
- если на странице содержится нужный контент, добавьте на нее внешние ссылки на важные разделы сайта.
Наглядно они выглядят так:
Приготовьтесь к регулярной оптимизации
Поддержание технической оптимизации сайта — процесс бесконечный, поэтому надо быть готовым постоянно вносить правки и отслеживать улучшения.
Ловите наш чек-лист технической оптимизации и используйте его в работе. Это повлияет на краулинговый бюджет и дальнейшее ранжирование вашего сайта.
В блоге Кинетики мы рассказываем о своих процессах, делимся опытом, инсайтами и шаблонами внутренних инструментов
С того момента, когда PageRank был впервые представлен в 1998 году, было потрачено немало усилий, чтобы улучшить его качество и скорость вычисления. В этой обзорной и достаточно популярной статье я опишу основные направления исследований вокруг PageRank и варианты алгоритма.
Я разрабатываю систему оценки важности web-страниц на основе входящих и исходящих ссылок в компании Нигма, поэтому смотрю на PageRank с математической стороны, со стороны разработчика а не seo.
Я не буду пересказывать здесь многократно описанные основы PageRank. Предполагается, что читатель знает, что это вообще такое. Если же нет, то для начала могу порекомендовать статью Растолкованный PageRank.
На следующей картинке схематически представлены основные направления исследований, окруживших PageRank. Каждому овалу на схеме будет соответствовать отдельная глава статьи.
PageRank с математической стороны
PageRank основан на математической модели случайного блуждания «пользователя» в сети интернет. В некоторый момент он находится на одной странице, затем случайным образом выбирает одну из ссылок и переходит по ней на другую. «Пользователь» произвольно выбирает ссылки, не отдавая предпочтение каким-либо из них.
PageRank страницы – это вероятность того, что блуждающий «пользователь» находится на данной странице.
Сделаем небольшой набросок того, как рассчитать эту вероятность.
Пронумеруем web-страницы целыми числами от 1 до N.
Сформируем матрицу переходов P, содержащую вероятность перехода «пользователя» с одной страницы на другую. Пусть deg(i) – количество исходящих ссылок на странице i. В таком случае, вероятность перехода со страницы i на страницу j равна:
P[i, j] = 1 / deg(i), если i ссылается на j
P[i, j] = 0, если i не ссылается на j
Пусть p(k) – это вектор, содержащий для каждой страницы вероятность того, что в момент k на ней находится «пользователь». Этот вектор – распределение вероятностей местоположения «пользователя».
Предположим, что «пользователь» может начать своё бесцельное блуждание с любой страницы. То есть, начальное распределение вероятностей равномерно.
Зная распределение вероятностей в момент k, мы можем узнать распределение вероятностей в момент k+1 по следующей формуле:
В основе этой формулы не более чем правила сложения и умножения вероятностей.
Математически мы пришли к цепи Маркова с матрицей переходов P, где каждая web-страница представляет собой одно из состояний цепи.
Но нам нужно знать вероятность нахождения «пользователя» на странице независимо от того, сколько шагов k он сделал от точки начала блуждания.
Мы берём начальное распределение вероятностей p(0). Считаем по представленной выше формуле распределение p(1). Затем по той же формуле считаем p(2), затем p(3) и т.д. до тех пор, пока некие p(k-1) и p(k) не будут отличаться лишь незначительно (полное равенство будет достигнуто при k стремящемся к бесконечности).
Таким образом, последовательность p(1), p(2), p(3) … сойдётся к некому вектору p = p(k). Интересно, что вектор p на самом деле не зависит от начального распределения (т.е. от того, с какой страницы начал своё блуждание воображаемый «пользователь»).
Вектор p таков, что в любой момент (начиная с некоторого момента k), вероятность того, что «пользователь» находится на странице i, равна p[i]. Это и есть искомый PageRank.
Этот алгоритм называется методом степеней (power method). Он сойдётся только в том случае, если выполняются два условия: граф страниц должен быть сильно связным и апериодическим. Как достигается выполнение первого условия, будет рассмотрено далее. Второе же без дополнительных усилий справедливо для структуры web.
Примечание
При выполнении условий сильной связности и апериодичности, согласно эргодической теореме, цепь Маркова с матрицей перехода P имеет единственное стационарное распределение p:
PageRank и является стационарным распределением цепи Маркова.
Также это выражение представляет собой собственную систему, а вектор p — собственный вектор матрицы A. Поэтому и применяется метод степеней — численный метод для поиска собственных векторов.
Висячие узлы (dangling nodes)
Висячие узлы – это страницы, которые не имеют исходящих ссылок. Страница может не иметь исходящих ссылок просто потому, что у неё их нет, либо потому, что она не была прокраулена (crawled) – т.е. страница попала в базу, т.к. на неё ссылаются другие прокрауленные страницы, но сама прокраулена не была, и о её исходящих ссылках ничего не известно.
Для вычисления PageRank в графе страниц не должно быть висячих узлов. Сумма каждого ряда матрицы переходов должна быть равна единице (row-stochastic), для висячих же узлов она окажется равной 0 – входные данные алгоритма будут некорректными.
По статистике, даже если поисковая система имеет достаточно большой индекс, 60% страниц оказывается висячими. Поэтому то, как с ними поступать, оказывает большое влияние на ранжирование.
Метод удаления
Изначальный подход, предложенный Пэйджем, заключается в том, чтобы удалить висячие узлы перед вычислением PageRank. В качестве обоснования предлагается то, что висячие узлы не оказывают влияния на другие страницы. Но это не совсем так – удаляя их, мы уменьшаем количество исходящих ссылок страниц, которые на них ссылаются. Тем самым мы увеличиваем значение PageRank, которое эти страницы передают через свои ссылки.
Кроме того, удаление висячих узлов, может создать новые висячие узлы. Таким образом, требуется проделать несколько итераций удаления (обычно 5 или что-то около того).
В качестве развития этого подхода, было предложено после вычисления PageRank возвращать удалённые узлы назад в граф и проделывать ещё столько же итераций алгоритма PageRank, сколько было проделано итераций удаления. Это позволяет получить значение PageRank и для висячих узлов.
Считать связанными со всеми другими страницами
Наиболее популярный трюк заключается в том, чтобы считать висячие узлы связанными со всеми другими страницами. В модели случайного блуждания данный метод находит подходящее объяснение: попав на страницу без исходящих ссылок, «пользователь» перескакивает на любую другую страницу сети случайным образом.
Можно считать вероятность попадания «пользователя» на страницу из висячего узла в результате такого перескока распределённой равномерно среди всех страниц сети. Но можно и не считать её таковой. Например, можно исключить попадание из висячего узла на другой висячий узел. Или распределить вероятность между страницами по аналогии с аристократическим вектором телепортации, о котором будет рассказано ниже в главе Телепортация.
Матрица переходов модифицируется следующим образом:
d[i] = 1, если i – висячий узел, и 0 в противном случае
v[j] – вероятность попадания «пользователя» на страницу j из висячего узла
Шаг назад (step back)
Проблему висячих узлов можно решить, добавив каждому такому узлу обратные ссылки на страницы, которые на него ссылаются. В модели блуждания это соответствует нажатию кнопки назад в браузере «пользователем», попавшим на страницу без исходящих ссылок. Этот метод критикуют за то, что он поощряет страницы с большим количеством ссылок на висячие узлы. Однако в некоторых моих экспериментах такой подход давал лучшее ранжирование.
Петля (self-link)
Упомяну кратко ещё один способ. Каждому висячему узлу можно добавить ссылку на самого себя – это приведёт в порядок матрицу переходов. Но после вычисления PageRank, результат придётся определённым образом скорректировать. Подробности описаны в G. Jeh and J.Widom “Scaling Personalized Web Search.”
Телепортация
Решение проблемы висячих узлов ещё не даёт сильную связность графа. Поэтому вводится телепортация.
В модели случайного блуждания это выглядит так: «пользователь», находясь на некоторой странице, с вероятностью c переходит по одной из её ссылок и с вероятностью (1 – c) * v[j] перескакивает (телепортируется) на страницу j. Стохастический вектор v описывает вероятность телепортации на ту или иную страницу и называется вектором телепортации.
c как правило выбирается в диапазоне 0.85 – 0.9. Большие значения дают более точные результаты, но более медленную сходимость. Меньшие значения – быструю сходимость, но менее точные результаты.
Плюс ко всему, чем меньше значение с, тем больше возможностей для поискового спама – достаточно создать на сайте огромное количество страниц и они будут, как зонтик, собирать значительный PageRank, получаемый за счёт телепортации.
Существует два способа выбора вектора телепортации: демократический и аристократический. Демократический вектор содержит одинаковые значения вероятности для всех страниц. Это стандартный вариант. Аристократический содержит низкую вероятность для обычных страниц и более высокую для избранных достоверно качественных неспамерских страниц. Последний способ явно поощряет избранные страницы в ущерб остальным, зато более устойчив к поисковому спаму.
В одной из статей предлагалось делать более высокую вероятность телепортации для главных страниц сайтов, но мне не известно, каковы были результаты.
Значение v[j] не должно быть равно 0. Иначе может оказаться, что j недосягаема из некой другой страницы, что означает нарушение сильной связности.
Телепортация модифицирует матрицу переходов следующим образом:
v – вектор телепортации
Мы ещё вернёмся к вектору телепортации, когда будем обсуждать персонализацию PageRank.
Ускорение метода степеней
Многие исследователи пытались ускорить сходимость метода степеней. Посмотрим на самые удачные способы.
Для удобства повторю формулу, которую мы используем на каждой итерации. Назовём её формулой А:
Метод Гаусса-Зейделя (Gauss-Seidel method)
На каждой итерации в методе степеней мы используем значения элементов вектора p(k) чтобы рассчитать вектор p(k+1). Отличие метода Гаусса-Зейделя в том, что мы сразу используем значения вычисленных элементов вектора p(k+1) для вычисления его остальных элементов.
В методе Гаусса-Зейделя мы последовательно элемент за элементом вычисляем вектор p(k+1). При это там где, согласно формуле А, нам нужно использовать значение p(k)[i] мы используем p(k+1)[i], если этот элемент вектора уже был вычислен.
Согласно экспериментам этот метод способен сократить необходимое количество итераций на 40%. Его недостаток в том, что его достаточно сложно вычислять параллельно.
Методы экстраполяции (Extrapolation methods)
В этой группе методов мы проделываем некоторое количество d обычных итераций метода степеней. Затем на основе результатов этих итераций строим аппроксимацию решения и используем её вместо p(k) для следующей итерации. Через следующие d итераций повторяем трюк. И так далее пока алгоритм не сойдётся.
Исследователям удавалось достичь сокращения необходимого количества итераций на 30%.
Адаптивный метод (Adaptive method)
Этот метод основан на наблюдении, что значительная часть элементов вектора p сходится гораздо быстрее остальных и затем почти не меняется. Ускорение в этом методе достигается за счёт того, что мы не пересчитываем значения таких элементов.
Если в какой-то момент k для некоторого элемента i обнаруживается что p(k+1)[i] – p(k)[i] меньше определённого порога, мы считаем, что значение PageRank для страницы i найдено и более не пересчитываем i-тый элемент вектора p.
Исследователям удавалось достичь сокращения времени работы метода степеней на 20% при помощи этого трюка.
Однако данный метод требует периодически переупорядочивать данные, чтобы избежать вычисления тех элементов, значения которых считаются уже найденными. Поэтому адаптивный метод плохо подходит для больших графов – переупорядочить огромный объём данных становится слишком дорогой задачей.
Метод блочной структуры (Block Structure Method)
Web имеет блочную структуру. Это открытие столь интересно, что я намерен посвятить ему отдельный пост. Там же и обсудим этот метод.
UPD: пост о блочной структуре web.
Численные методы
Вычисляя значение PageRank, мы ищем такой вектор p, что
Это выражение является так называемой собственной системой, а p – собственный вектор матрицы A. Задача поиска собственного вектора может быть представлена системой линейных уравнений. В нашем случае это будет огромная, но всё же обычная система, которая может быть решена при помощи численных методов линейной алгебры.
Тем не менее, вычисление PageRank численными методами ещё находится в экспериментальной области. Каковы будут характеристики и свойства этих методов на реальных графах web пока не понятно.
Стоит отметить, что существуют уже готовые решения для параллельного вычисления крупных линейных систем.
Параллелизация
Вычисление PageRank параллельно на нескольких машинах позволяет существенно ускорить работу.
По сути методы параллелизации можно разделит на два типа.
Первые разделяют граф страниц на плотно связные компоненты – группы страниц плотно связанных ссылками между собой и имеющие относительно немного ссылок на страницы вне группы. PageRank для каждой такой группы вычисляется параллельно. Процессы/потоки периодически обмениваются информацией, когда дело доходит до ссылок между страницами разных групп.
Ко второму типу относятся методы, использующие блочную структуру web. О них мы поговорим в уже обещанном выше посте о блочной структуре.
UPD: пост о блочной структуре web.
Оптимизация ввода-вывода
Это довольно интересная тема, которую я приберегу для одного из следующих постов. Я представлю три алгоритма, которые будут интересны не только с точки зрения вычисления PageRank, но и вообще с точки зрения обработки больших объёмов информации.
Эволюция графа
Довольно естественной кажется идея не пересчитывать PageRank для всех страниц целиком, а найти способ обновлять его по мере эволюции графа страниц (по мере эволюции web).
В «Incremental Page Rank Computation on Evolving Graphs» Prasanna Desikan и др. предлагают следующий способ.
Сперва выделить часть графа, состоящую из страниц, до которых не существует путей от новых страниц, исчезнувших страниц, либо страниц, ссылки которых были изменены. Удалить эту часть графа, оставив только граничные узлы (т.к. они влияют на PageRank оставшихся страниц). Посчитать PageRank для оставшегося графа. Затем отмасштабировать значения PageRank с учётом общего количества страниц – т.к. количество страниц влияет на часть PageRank, получаемую за счёт телепортации.
Замечу, что полученный в результате PageRank не является точным, а всё же некой аппроксимацией.
По различным данным от 25% до 40% ссылок между web-страницами меняются в интернет в течение недели. Такая скорость изменения, на мой взгляд, оправдывает полный пересчёт PageRank всех страниц.
Персонализация
Представление о важности той или ной страницы во многом субъективно. То, что покажется одному отбросом, другой сочтёт изумрудом. Пусть есть очень качественная страница об игре керлинг, но я совершенно не хочу, чтобы она вылезала лично мне в топ. Чтобы учитывать в ранжировании интересы конкретного человека был придуман персонализированный PageRank.
Выбирается какое-то количество категорий, по которым можно классифицировать тематику тех или иных страниц (или сайтов). Например: культура, спорт, политика и т.п.
Пусть T[j] – множество страниц, принадлежащих к категории j (или расположенных на сайте, принадлежащем к данной категории).
Для каждой категории формируется особый вектор телепортации v (см. главу Телепортация).
v[i] очень мало, если страница i не принадлежит T[j], и значительно больше если принадлежит.
Для каждого тематического вектора телепортации вычисляется тематический PageRank pj. Вычислить сто тематических PageRank для ста категорий вполне реально.
Допустим, у нас есть вектор k, сумма элементов которого равна единице. Значение k[j] отражает степень заинтересованности пользователя (реального, а не того из модели блуждания) в категории j.
Степень заинтересованности пользователя может быть указана явно, или она может быть сохранена в его профиле. Или она может быть выведена исходя из того, какие слова входят в запрос. Например, если запрос содержит слово fairtrade то можно вывести, что пользователь заинтересован на 0.4 в теме общество, на 0.4 в теме экономика и на 0.2 в теме политика.
Во время ранжирования результатов запроса пользователя для страниц используется следующее итоговое значение PageRank:
k[0] * p0 + k[1] * p1 + … + k[n] * pn , где n – количество категорий
Таким образом, рейтинг страницы будет зависеть от того, что реально интересно пользователю.
Темы, которые будут рассмотрены в следующих постах
Оптимизация ввода-вывода
Это довольно интересная тема, которую я приберегу для одного из следующих постов. Я представлю три алгоритма, которые будут интересны не только с точки зрения вычисления PageRank, но и вообще с точки зрения обработки больших объёмов информации.
Siterank
UPD: Эта тема освещена в посте о блочной структуре web.
