Внутренний Seo-аудит 🚀 — как правильно оптимизировать сайт
Зачем нужен внутренний аудит? Ваш сайт скрывает много неиспользуемых возможностей. Важно их найти и задействовать, чтобы подняться в поисковой выдаче. Это в свою очередь повысит трафик и конверсию. Поэтому не спешите закупаться ссылками, сперва определите состояние вашего сайта.
Desktop vs. SaaS — что выбрать?
Когда речь заходит о внутреннем аудите своими руками, вам не обойтись без хорошего ПО. Выбор лежит между SaaS и desktop продуктом. Конкретно под внутреннюю оптимизацию лучше заточены десктопы в силу своей скорости и детальности анализа. Их сейчас немало, но отличия существенны: начиная от места обработки информации (только на операционке, только на жёстком диске или на операционке и жёстком — это напрямую влияет на скорость аудита), заканчивая адекватным юзабилити. В этой статье мы рассмотрим внутренний аудит с помощью одного из десктопов — Netpeak Spider.
Структура страниц
Сперва рекомендуем провести мониторинг архитектуры сайта:
- Расстояние между главной и основными страницами должно исчисляться 1 кликом.
- Глубина сайта должна быть продумана (пользователь не проходит квесты в поиске нужной страницы). Волшебной формулы расчёта нет. Просто постарайтесь максимально упростить задачу пользователя в поиске информации.
Программное исполнение
- Код ответа сервера: 200, 301/302, 4xx, 5xx. Очень часто случается, что склейку страницы проводят с помощью 302 редиректа — не надо так. Постоянное перенаправление проводим с помощью 301-го, временное — 302-го. Совсем «не ок», когда внутренние ссылки на вашем сайте ведут к несуществующей странице с 404-й ошибкой.
- Дубли. Даже самый качественный контент можно убить, не проставив на частично похожих или повторяющихся страницах canonical. В таком случае вас ожидает ухудшение индексации, выявление нерелевантной страницы роботом (он выбирает на своё усмотрение), утрата доли естественных ссылок (пользователи ссылаются на дублированную страницу).
- Sitemap. Поисковому роботу нередко тяжело проиндексировать весь сайт (в особенности, если у вас крупный интернет-магазин). В таком случае направьте его, указав с помощью sitemap, что именно нужно индексировать.
- Robots.txt. Неверно прописанный robots.txt может закрыть доступ к целым тематическим категориям. И тогда вам не поможет ни уникальный контент, ни правильная разметка — всё это тщетно, если страницы скрыты от поисковых роботов.
- Висячие узлы. Внутренние ссылки позволяют пользователю ориентироваться в структуре сайта, направляют по его страницам. Висячими узлами называют ссылки на такие страницы, которые сами никуда не ведут. В итоге вы теряете ссылочный вес и повышаете вероятность потери пользователей, которые просто уйдут на другие сайты.
- Внутренний PageRank. Вам нужно знать, как распределяется ссылочный вес в пределах вашего сайта. Так вы пойметес, какие страницы, являясь неважными, напрасно получают избыточный вес. Грамотная схема перелинковки внутри сайта может сэкономить приличный бюджет.
Проверить PageRank можно так:
Контент
- Заголовки h2-h6. Здесь важно избегать дублирования заголовков, наличия нескольких сразу или полного их отсутствия.
Это не критические ошибки, но ваш контент наверняка направлен на информирование и привлечение пользователей. Скорее всего, не видя заголовка и не понимая, о чём статья, юзер просто закроет страницу. О спам-заголовках и вовсе промолчим. Здесь и так всё понятно: ни в коем случае.
- Оформление текста. Даже если у вас уникальный и крутой контент, это не гарантирует, что пользователь его прочтёт. Ему может просто не понравиться оформление текста. Так что структурируйте его, выделяйте заголовки, подзаголовки, прикрепляйте изображения. Помните: вы пишете для людей.
- Заспамленность. Проводя «сео-оптимизацию своего сайта бесплатно за 2 минуты», помните, что «сео-оптимизация сайта бесплатно за 2 минуты» должна обходиться без избытка ключевых слов.
- Изображения. Отсутствие атрибута ALT (подписи к изображению), непроработанные километровые инфографики без сжатия, замедляющие загрузку страницы, — это не понравится ни вашим пользователям, ни поисковикам.
Подытожим. Проводя внутренний аудит, обязательно проверяйте:
- структуру сайта, глубину ключевых для продвижения страниц;
- дубли, коды ответа сервера, robots.txt, sitemap, висячие узлы;
- оформление и заспамленность контента;
- распределение ссылочного веса с помощью внутреннего PageRank.
Не забывайте, что внутренний аудит следует проводить регулярно. Проверяйте изменения в перелинковке сайта, возможном дублировании страниц и их canonical — всё это непосредственно влияет на место вашего сайта в поисковой выдаче. В этой статье мы рассмотрели некоторые важные параметры, однако внутри программы Netpeak Spider их больше 60-ти. Изучайте их, экспериментируйте, применяйте.
А как считаете вы, какие параметры аудита заслуживают первостепенного внимания?
Технический аудит сайта программой Netpeak Spider
Обзор программы Netpeak Spider начну с банального: главное для продвижения сайта – seo-оптимизация. Только когда техническое состояние, контент, скорость загрузки и другие составляющие доведены до нормального уровня, можно вступать в борьбу за позиции с конкурентами. В противном случае не помогут никакие инструменты (читайте: ухищрения) в виде закупки ссылок, добавления в каталоги, краунд-маркетинга и прочего. Технический аудит сайту требуется не меньше, чем человеку профилактические осмотры врачей. Чем раньше выявляются и устраняются ошибки, тем быстрее ресурс завоюет доверие поисковиков и получит стабильность в ранжировании.
Массив информации сложно обработать без ПО. Созданы онлайн сервисы и программы, которые помогают в проведении диагностики сайтов, бесплатных и платных. Каждый из таких инструментов полезен оптимизаторам, вебмастерам или владельцам сайтов, которые самостоятельно поддерживают жизнеспособность блога, интернет-магазина, электронной витрины и проч. Netpeak Spider – программа платная, но с двухнедельным периодом тестирования, причем, функционал полный. Тарифы предлагаются разные, зависимо от срока использования. Лицензией можно обзавестись и на год, и на месяц, и это хорошо, потому что есть программы только с годовой подпиской и ценами, что не каждому по карману.
Параметров, включенных во внутренний технический аудит, более 60-ти. Опущу описание процесса авторизации и установки (у разработчиков прекрасная презентация https://netpeaksoftware.com/spider), но не спешите уходить — поделюсь впечатлением.
Настройка Netpeak Spider
Первое, с чего следует начать работу с программой по внутреннему аудиту, это с внимательного изучения настроек и выставлению их по своим потребностям – оставить только те характеристики или области, которые нужно проверить. Например, требуется получить информацию о внешних ссылках – запускаем проверку только внешних ссылок. Обратите внимание, есть параметры обязательные, есть использующиеся по умолчанию. Выставляем тип контента и вид урлов (изображения кликабельны).
Задаем количество потоков во вкладке «Скорость». Если к серверу будет много запросов, он ответит кодом 429. Ставим галочку в чекбокс – и проверка в таком случае приостановится, но сервера Beget, на котором расположено большинство моих сайтов, превышение нагрузки от ботов Netpeak Spider не испытали.
Как Netpeak Spider отображает информацию о скорости
Начну с того, что сам Netpeak Spider сканирует сайты быстро даже на минимальном количестве потоков практически со всеми включенными параметрами. Обратила внимание, что дольше проверяются сайты, загружающиеся медленно и в браузере пользователя, и по результатам сервисов проверки скорости загрузки. Но в отличие от, например, гугловского PageSpeed, в Netpeak Spider видно время загрузки и ответа сервера по каждой странице, а это шанс поработать над ускорением конкретной.
Скорость — исключительно серьезная характеристика сайта, и большую роль играют изображения. Картинки часто грузят сервер, не считая скриптов и стилей, хотя проблема легко устраняется на большинстве CMS простой заменой файла на сжатый. Благодаря Netpeak Spider обнаружила на одном проверенном-перепроверенном много раз сайте пяток картинок, которые очевидно загружались в оригинальном виде. Но что характерно для программы, она показывает и те изображения, которые не подгружаются с сервера. Например, загрузили на WordPress изображение размерами 4000*3000 пикселей, вывели на страницу 400*300 (к сожалению, такое часто встречается в работе с клиентскими сайтами) и дали ссылку, чтобы медиафайл открывался в полном размере. Netpeak Spider нашел эту большую и тяжеловесную картинку (изображения были сжаты пакетно, но, вероятно, файл не перезаписался). После замены одной картинки диск на сервере освободился на полтора мегабайта. А иногда речь идет о ГБ.
Проверка заголовков, мета-тегов, альтов
Параметры относятся к оптимизации контента, поэтому объединила заголовки, тайтлы, дескрипшены и альты вместе. В результатах проверки отображается количество пустых тегов, дублей, наличие нескольких заголовков h2. Соотношение text/html покажет страницы, где контента недостаточно. Из сводного отчета можно переключаться на детальный. Программа показывает и объем мета-тегов, и выгружает содержимое. Для этих целей использовала таблицы Гугла (мета-теги парсились с помощью заданных формул, но у Диска Гугл есть минус – в ячейках случается error, что тормозит работу).
Висячий узел – фишка Netpeak Spider
Работа с техническими параметрами
Код 404, редиректы, канонические адреса, корректность файла robots.txt — под контролем желательно держать все. Бывает, страницы нет в поиске, а на нее просто установлен запрет для поисковых ботов. Но встречаются и другие случайные ошибки, когда стоит 301 перенаправление или canonical на удаленную страницу. Отследить вручную эти недочеты проблематично, а наличие таких косяков на web-ресурсе нежелательно. Паучок глазастый все обнаруживает и предоставляет в отчете.
Заключение
Статья содержит краткий обзор программы. Большего не требуется. Юзабилити продумано до мелочей. Всплывают подсказки. Во вкладке «Все результаты» отражено количество просканированных адресов (в первой, после нумерации, колонке отчета). Ссылки, при необходимости, открываются в браузере с помощью правой клавиши мыши. Напротив каждого URL проверенные параметры разбиты также по колонкам, в том числе и количество ошибок. Справа сгруппированные ошибки, и оттуда можно извлечь часть отчета.
Результаты как сохраняются, так и экспортируются в форматах CSV и Ecxel для работы. Нужно быть внимательными при экспорте: если нужно экспортировать весь отчет, а до этого мы просматривали детали, нужно вернуться на вкладку «Все результаты». Иначе будет выгружена только та часть данных, находясь на которой, мы затребовали экспорт.
Функционала Netpeak Spider достаточно, чтобы привести в порядок даже запущенный сайт и поддерживать его в отличном состоянии, если проверки проводить регулярно и оперативно принимать меры к исправлению новых ошибок.
No birds: Развитие PageRank
С того момента, когда 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.
Две техники SEO, которые дадут рост трафика уже через месяц. Читайте на Cossa.ru
Показываем, как с помощью рассчитанной на основе алгоритма PageRank перелинковки и рассчитанных на основе алгоритма BM25 текстов повысить позиции сайта по ключевым словам и привлечь больше трафика.
Техника 1. Перелинковка сайта на основе PageRank
Перед перелинковкой мы внимательно изучили статью Александра Садовского «Растолкованный PageRank» и решили применить знания на сайте клиента.
Внутренняя перелинковка — это метод внутренней оптимизации сайта, выполняемый для перераспределения ссылочного веса сайта на продвигаемые страницы. Статический вес сайта всегда равен 100%. Когда одна страница ссылается на другую, она передает некоторую часть своего веса, так называемый ссылочный сок. Таким образом, чем больше ссылочного сока передается страницам, тем более важными они считаются и для посетителей, и для поисковых систем.
Проще говоря, перелинковка выполняет две задачи.
- Внутренние ссылки передают вес с одной страницы на другую.
- Направляют посетителей на важные и ценные страницы.
Алгоритм перелинковки сайта
Рассмотрим алгоритм перелинковки на примере сайта производителя плитки ПВХ для промышленных и спортивных помещений.
1. Выбираем страницы, которые хотим видеть в топе поисковых систем.
В нашем случае это:
- главная;
- полы ПВХ для цеха, склада, производства;
- плитка ПВХ для тренажерного зала;
- полы для гаража, автосервиса и паркинга;
- полы для бассейна, душевой, ванной комнаты;
- плитка ПВХ для офиса;
- полы для кафе и ресторанов;
- полы для ледовых дворцов;
- полы для магазинов и супермаркетов;
- плитка ПВХ для автосервиса;
- полы для технических этажей.
2. Далее узнаём по каждой странице, какие ссылки ведут на страницу и со страницы.
Для этого можно использовать различные сервисы, например: сервис saitreport.ru или программы Xenu1 и PageWeight. Не забываем, что нам нужны только открытые для индексации ссылки, никаких тегов nofollow и noindex там быть не должно. Закрытые ссылки не участвуют в передаче внутреннего веса и нужны исключительно для удобства пользователя, помогая найти нужный раздел, склонить к прочтению дополнительной информации и уменьшить количество отказов.
3. Теперь рассчитываем текущее распределение веса по всему сайту.
Берём отчёт по внутренним ссылкам, которые мы получили в Xenu1 или PageWeight, и вносим данные в таблицу. Мы использовали отчёт по ссылкам в Saitereport.
Так выглядит отчёт по внутренним ссылкам в Excel с Saitereport.
Отчёт по внутренним ссылкам
Для этого используем Excel. Открываем калькулятор, по горизонтали и вертикали вносим все страницы, которые есть на сайте. Для удобства это можно сделать по определённой иерархии. Таких страниц 45 с каждой стороны.
Текущее распределение ссылочного веса по сайту
Заполнили таблицу и получили PageRank для каждой страницы. Квадратики с заливкой показывают, что на определённую страницу ссылаются отдельные страницы. На скриншоте видно, что вес всех страниц практически одинаковый, все страницы ссылаются друг на друга в приблизительно одинаковом количестве, а некоторые не продвигаемые страницы имеют непомерно высокий вес.
Наша задача — сделать такую перелинковку на сайте, чтобы вес был самым высоким на продвигаемых страницах.
Выполнять нужную перелинковку нам поможет та же таблица в Excel.
Запомним, каких ссылок быть не должно:
- Висячих узлов: страниц без исходящих ссылок.
- Зацикливающих страниц: ссылающихся на самих себя.
- Дублирующих ссылок.
- Ссылок на не продвигаемые и страницы с ответом 404.
- Несвязных узлов: страницы без входящих ссылок.
После нескольких итераций у нас получилось такое распределение веса: главная и продвигаемые страницы получили в среднем 7,6% ссылочного веса, в сумме — почти 84% всего PageRank сайта. Остальные страницы сайта получили около 0,5%. То есть модель перелинковки, согласно теории PageRank, сделана правильно. Вес сосредоточен на продвигаемых страницах!
Готовая модель перелинковки
Техника 2. Подготовка текстов на основе алгоритма семантического анализа
Следующий этап — это проведение оптимизации текстов по вхождению ключевых слов.
Для этого мы выполнили семантический анализ всех текстов: определили соответствие поискового запроса документу как на продвигаемых, так и на служебных страницах. Мы применили метод оценки релевантности TF-IDF.
Метод заключается в следующем: чем больше частота запроса в документе, тем значимей будет данный текст по отношению к запросу. То есть вероятность показа этого текста по запросу возрастает. Например:
|
Предложения в тексте | Всего слов | Плитка | ПВХ | Покрытие |
|
---|---|---|---|---|---|---|
Текстура плитки ПВХ ЭКО-ТЕХНО имеет выступающие прямоугольники | 7 | 1 | 1 |
|
||
Плитка обеспечивает сцепление для транспортных средств и для пешеходов | 9 | 1 |
|
|
||
ПВХ-покрытия не взаимодействуют с кислотами, щёлочами, маслами, бензином и другой активной «химией» | 11 |
|
1 | 1 | ||
Плитка ПВХ легко режется | 4 | 1 | 1 |
|
||
Итого | 31 | 3 | 3 | 1 |
Например, из этой таблицы мы понимаем, что запрос «покрытие» используется 1 раз, в то время как «плитка» и «ПВХ» используется по 3 раза. Мы можем заменить вхождение слова «плитка» на слово «покрытие». В таком случае не будет заспамленности, и эту страницу можно будет продвигать по двум запросам — «плитка ПВХ» и «покрытие ПВХ».
В текстах мы выявили чрезмерную заспамленность по ключевым словам. Чтобы уменьшить вхождение фраз, а также расширить его, мы воспользовались подбором ключевых слов Yandex.Wordstat, выделили нужные ключевые запросы и внедрили их в тексты, а чрезмерное количество одинаковых ключевиков — уменьшили. Затем написали подробное техническое задание копирайтеру. Полное ТЗ находится в GoogleDocs. Не все ключевые слова были использованы копирайтером в тексте, так как текст был бы слишком ими перенасыщен. А тексты в первую очередь должны быть написаны для людей.
Результат
В среднем трафик с поисковых систем увеличился на 16% в июне по сравнению с апрелем. Сравнивали с апрелем, потому что в апреле такое же количество дней, как в июне, и столько же праздников. К тому же, в мае и происходили все действия, которые могли повлиять на точность данных. В итоге грамотная внутренняя перелинковка и написанные для людей уникальные тексты, ранжирование которых можно улучшить при помощи TF-IDF, дают прирост органического трафика.
Сравнение поискового трафика
Также выросли позиции по основным ключевым словам. Многие запросы стали видны в топ-100.
- Зелёный цвет — позиции выросли.
- Красный — снизились.
- Без заливки — остались неизменными.
Позиции в поисковой системе
Вывод
Даже если у вас на сайте выполнена базовая внутренняя оптимизация сайта: прописаны title и description, написаны уникальные тексты, грамотная перелинковка сайта всё равно может быть полезна. Она принесёт увеличение органического трафика уже при первой полной переиндексации сайта. Главное помнить, что перелинковка должна быть удобной и пользователям и не создаваться исключительно для перераспределения веса.
Что касается текстов — пишите их в первую очередь для людей и только потом, применяя метод TF-IDF, отрабатывайте их для поисковых систем. Такой подход точно даст результат, так как тексты будут читабельными и поисковый робот будет их правильно трактовать.
Читайте также: 11 советов SEO-шнику, которому попался сложный клиент
Мнение редакции может не совпадать с мнением автора. Ваши статьи присылайте нам на [email protected]. А наши требования к ним — вот тут.
Что умеет Netpeak Spider 3.0: мощный инструмент SEO-анализа сайта
Netpeak Spider — инструмент комплексного SEO-анализа сайта. Это десктопное приложение, с помощью которого можно оценить внутреннюю техническую оптимизацию ресурса. Подробнее об использовании Netpeak Spider читайте в обзоре.
Что такое Netpeak Spider и зачем его использовать
Netpeak Spider — программа для ПК, с помощью которой можно просканировать любой сайт с открытым доступом. Также инструмент сканирует закрытые сайты. Для этого нужен доступ к ресурсу с правами администратора. То есть Netpeak Spider можно использовать для проверки ресурсов на стадии разработки.
Программа собирает с сайта данные о технической оптимизации к требованиям поисковых систем. Netpeak Spider быстро добывает практически всю информацию, которая нужна для оценки SEO ресурса. Например, инструмент собирает данные о битых ссылках, некорректно заполненных метатегах, времени загрузки страниц и так далее.
Информацию о внутренней оптимизации сайта можно получить и без Netpeak Spider. Часть данных можно найти в Search Console и «Яндекс.Вебмастер». Часть можно собрать вручную, анализируя сайт через админку или даже без доступа к административной консоли. Но Netpeak Spider экономит время и обеспечивает доступ к комплексной информации в одном интерфейсе.
Перед обзором возможностей Netpeak Spider нужно подчеркнуть важный момент. Это инструмент для квалифицированных пользователей. Полученные данные нужно уметь интерпретировать и использовать. Некоторые функции Netpeak Spider однозначно полезные. Но есть здесь и олдскульно-сеошные инструменты, которыми нужно уметь правильно пользоваться.
То есть результат использования Netpeak Spider практически полностью зависит от того, в чьих руках этот инструмент.
Как работать с Netpeak Spider
Зарегистрируйтесь на сайте проекта и установите Netpeak Launcher. Это программа, которая загрузит и установит на ваш ПК Netpeak Spider. Активируйте тестовый период и пользуйтесь всеми возможностями программы в течение 14 дней.
Чтобы просканировать сайт, запустите программу. Укажите URL и нажмите кнопку «Старт». Для первого сканирования подойдут дефолтные настройки.
Netpeak Spider одинаково быстро сканирует сайты разных размеров. На обработку сайта «Текстерры» ушло 3 минуты. После завершения сканирования в левой части окна программы открывается дашборд с результатами, а в правой части — отчет в виде списка ошибок.
Какие данные доступны на дашборде
На дашборде отображаются ссылки на отфильтрованные результаты: просканированные URL, внутренние URL, URL с важными ошибками и индексируемые URL. По ссылке «Просканированные URL» доступны все страницы сайта, которые обошел робот Netpeak Spider.
Перейдите по ссылке, чтобы увидеть список просканированных URL. На экране откроется таблица со ссылками и данными по каждой странице. URL с критичными ошибками выделены красным маркером, с ошибками средней и низкой критичности — желтым и синим маркером соответственно. URL без ошибок маркером не выделяются.
В таблице есть данные о каждой странице: код ответа сервера, количество ошибок, время ответа сервера, внутренний PageRank, Title, Description и другая информация.
Чтобы просмотреть результаты сканирования конкретного URL, кликните по нему. В окне «Информация» появятся сводные данные.
Ошибки на странице выделены красным, желтым или голубым маркером. На выбранной странице робот нашел четыре ошибки: некорректный URL, некорректную директиву robots.txt, медленный ответ сервера и указание на канонический URL.
Ошибки URL и указание на канонический URL по всей видимости связаны с тем, что Netpeak Spider просканировал и включил в отчет URL с UTM-метками. Эта ссылка формируется при переходе на каноническую страницу со всплывающего окна, которое появляется на всех страницах блога «Текстерры». Это объясняет еще одну ошибку, которую видит Netpeak Spider — слишком большой ссылочный вес или PageRank страницы.
То есть из четырех найденных ошибок или проблем реального внимания требует только одна: высокое время ответа сервера. Это еще раз подтверждает, что результаты сканирования Netpeak Spider нужно уметь интерпретировать.
С помощью ссылок можно быстро перейти к другим отфильтрованным результатам. Например, по ссылке «URL с важными ошибками» откроется список соответствующих страниц.
На дашборде открывается список страниц с ошибками с высокой и средней критичностью. Чтобы просмотреть список ошибок на конкретной странице, кликните по ней.
Netpeak Spider нашел на странице несколько ошибок: незаполненный метатег description, большое количество внутренних и внешних ссылок, большое количество изображений, низкое соотношение текста к HTML.
Кроме ссылок на отфильтрованные результаты, на дашборде отображаются диаграммы с важными результатами сканирования. Доступны такие данные:
- Индексируемость URL. На диаграмме представлено соотношение индексируемых, неиндексируемых и non-HTML ссылок.
- Критичность ошибок. Соотношение ошибок с высокой, средней и низкой критичностью.
- Причины неиндексируемости URL. На диаграмме указаны основные причины отсутствия URL в индексе, например, запрет в robots.txt. неканонический URL и так далее.
- Время ответа сервера. На диаграмме можно оценить соотношение страниц с разным временем ответа сервера.
- Код ответа сервера.
- Глубина URL.
- Статус индексации.
- Тип контента.
Диаграммы кликабельные. Чтобы просмотреть список страниц с ошибками среднего уровня критичности, нажмите на соответствующий сегмент на диаграмме.
С помощью кнопки «Настроить сегменты» можно получить данные только по определенным URL сайта. Например, можно включить в отчет только публикации в блоге «Текстерры».
Для этого в настройках сегмента создайте фильтр с условием URL содержит. Укажите нужный URL и сохраните фильтр.
После этого на дашборде и в отчетах отобразятся результаты сканирования страниц блога.
Какую информацию найдете в отчетах
Отчеты доступны в правой части окна программы. Данные сгруппированы на разных вкладках.
На вкладке «Ошибки» представлены соответствующие сведения. В верхней части списка находятся критичные ошибки, а в нижней некритичные. Пункты в списке ошибок кликабельные. Например, если нажать на ошибку «Битые ссылки», программа выдает список недоступных страниц сайта.
В отфильтрованных результатах можно выбрать конкретный URL и просмотреть данные по нему.
На вкладке «Сводка» сгруппированы данные по статусу и типу страниц, протоколу соединения, хосту, коду ответа сервера и другим параметрам. Например, вы можете выбрать все страницы со статусом Disallowed. В отфильтрованных результатах можно просмотреть данные по конкретной странице, которая закрыта от индексации.
На вкладке «Структура сайта» отображается соответствующая информация. Здесь можно выбрать группу страниц, например, все публикации в блоге. В отфильтрованных результатах доступны данные по отдельным страницам.
На вкладке «Парсинг» отображаются данные пользовательского парсинга. О настройках этого инструмента пойдет речь ниже.
Данные отчетов можно экспортировать с помощью функции «Расширенное копирование». Для этого выберите отчет и нажмите кнопку «Расширенное копирование».
Откройте таблицу и вставьте в нее данные.
Также данные выбранного отчета можно сохранить в таблице с помощью функции «Экспорт – Результаты в текущей таблице».
Программа сохраняет таблицу с отчетом на жестком диске ПК.
Результаты сканирования можно сохранить в программе. Для этого выберите меню «Проект – Сохранить». При следующем запуске программы вы сможете сразу открыть результаты индексирования, а не тратить время на повторное сканирование сайта.
Как настроить сканирование сайта
С помощью настроек сканирования можно менять данные, которые собирает Netpeak Spider. Настройки доступны в соответствующем меню программы.
В основных настройках можно выбрать шаблон сканирования, язык программы и скорость сканирования. В базовых настройках сканирования можно включить индексирование раздела. В этом случае, если вы сканируете URL /blog/, робот обойдет только публикации в блоге. Также в базовых настройках можно выбрать тип контента, который индексирует Netpeak Spider.
В продвинутых настройках можно настроить индексирование с учетом инструкций для поисковых систем. Netpeak Spider распознает директивы в robots.txt, атрибут rel=canonical, редиректы с задержкой, X-robots-tag, Meta Robots и атрибут rel=nofollow. То есть если нужно просканировать сайт с учетом реальных директив в файле robots.txt, отметьте галочкой соответствующую опцию.
В разделе «Сканировать ссылки из тега link» можно отключить индексирование ссылок на предыдущую и следующую страницу или публикацию, ссылок на ускоренные страницы и на другие ссылки.
Также в расширенных настройках можно выбрать условия приостановки сканирования. Netpeak Spider может приостанавливать сканирование на неопределенное время, если сервер возвращает ошибку 429. В этом случае вы можете возобновить сканирование в любой момент. Также программа приостанавливает сканирование на 30 секунд, если время ожидания сервера превышено.
В расширенных настройках можно разрешить cookies и сканирование страниц с ошибкой 4xx. Первая настройка позволяет обходить страницы, которые недоступны без кукис. Вторая позволяет получить доступные данные для страниц, которые возвращают ошибку.
В разделе «Виртуальный robots.txt» можно настроить сканирование с учетом директив виртуального, а не реального файла robots.txt. С помощью этой функции можно проверить корректность файла до его публикации на сайте.
В разделе парсинг можно настроить сбор пользовательских данных. Netpeak Spider поддерживает до 15 шаблонов парсинга одновременно. Парсинг включает четыре способа поиска:
- RegExp. Поиск по регулярным выражениям. Чтобы настроить поиск, нужно владеть синтаксисом конструктора RegExp.
- Содержит. Самый простой вид поиска. Определяет количество заданных элементов на странице.
- CSS-селектор. Поиск по CSS-селектору HTML-документа. Чтобы настроить этот вид поиска, нужно владеть HTML и CSS.
- XPath. Ищет HTML-документы по XPath. Чтобы настроить поиск, нужно владеть синтаксисом XPath.
В зависимости от выбранного способа можно настроить область поиска.
Настройку парсинга стоит рассмотреть на примере. Представьте, что на сайте нужно найти страницы, на которых упоминается какой-то термин. Укажите название шаблона парсинга. С помощью выпадающего меню выберите способ «Содержит». Укажите термин, который нужно искать. С помощью выпадающего меню выберите область поиска «Только текст».
По CSS-селектору можно найти страницы с любыми элементами. Например, с помощью селектора a можно найти страницы со ссылками.
В разделе User Agent можно выбрать шаблон сканирования. По умолчанию включен User Agent Googlebot для десктопов. В контексте тестирования Mobile-First индекса имеет смысл посмотреть на сайт глазами мобильного бота Google. Для этого включите соответствующий шаблон.
При необходимости используйте других ботов.
Новая реальность в поиске: JSON-LD, Mobile-First, ПалехВ разделе «Ограничения» при необходимости измените параметры. Внимания заслуживает опция «Размер контента». По умолчанию Netpeak Spider считает ошибкой контент короче 500 и длиннее 50 000 символов. Уменьшите минимальное значение до 100, а максимально до 500 000, чтобы не тратить время на ложные ошибки. Остальные настройки можно не менять.
В разделе «Правила» настройте правила сканирования. Доступны два типа фильтров: дефолтный с логикой «или» и продвинутый с логикой «и». Первый срабатывает, когда совпадает хотя бы одно из условий фильтра. Второй предназначен для создания сложных правил, в которых совпадает два и более условий.
Например, с помощью правила можно настроить исключения для страниц из раздела «Портфолио» на сайте нашего агентства. Можно добавить в исключения три разные страницы по очереди: «Клиенты», «Отзывы» и «Работы». А можно сэкономить время и исключить все страницы из раздела с помощью одного правила «URL содержит».
Все страницы из раздела «Портфолио» начинаются с URL /progress/, поэтому после настройки фильтра программа будет их игнорировать.
В разделе «Экспорт» при необходимости поменяйте дефолтные настройки экспорта данных. В разделе «Аутентификация» добавьте данные доступа к закрытому сайту. В разделе «Прокси» при необходимости укажите прокси-сервера.
Как пользоваться дополнительными инструментами Netpeak Spider
Инструменты доступны в соответствующем разделе меню.
С помощью инструмента «Анализ исходного кода и HTPP-заголовков» можно извлечь и проанализировать соответствующие данные с любой страницы.
Исходный код страницы можно сохранить на жесткий диск. Также инструмент извлекает текст страницы.
Отдельного внимания заслуживает инструмент «Расчет внутреннего PageRank». Согласно терминологии разработчиков Netpeak Spider, PageRank — относительный ссылочный вес страницы. Расчет внутреннего PageRank нужен, чтобы понимать, «как именно распределяется ссылочный вес по сайту и где он концентрируется».
Результат анализа внутреннего PageRank выглядит так (см. иллюстрацию).
По умолчанию страницы сгруппированы по внутреннему PageRank от большего к меньшему. В столбце «Статус ссылки» указаны разные значения:
- Ok. С этими URL все в порядке.
- Висячий узел. Это страницы, на которые ведут входящие ссылки, но с которых нет исходящих ссылок.
- Перенаправление. URL с перенаправлениями или указанием на каноническую страницу.
- Несвязный узел. URL, которые не имеют входящих ссылок.
Например, Netpeak Spider определил в качестве висячего узла страницу услуги «Разработка контент-стратегии».
Это посадочная страница, в тексте которой действительно нет исходящих ссылок. Это сделано специально, чтобы пользователи не ушли со страницы и заполнили конверсионную форму внизу.
Не мешает ли отсутствие исходящих ссылок в тексте страницы распределяться так называемому ссылочному соку? Внимание на иллюстрацию.
Инструмент «Анализ внутреннего PageRank» нужно использовать аккуратно. Он формирует сеошное отношение к внутренней перелинковке. У неопытного вебмастера может появиться желание добавить на «висячие узлы» ссылки не ради удобства пользователей, а ради полумифического перетекания ссылочного сока. Из-за этого может пострадать юзабилити и конверсия. Пример с отсутствием исходящих ссылок на лендинге это подтверждает.
Моя позиция: если на сайте есть меню, реализованы хлебные крошки, навигация по категориям, забудьте про перетекание ссылочного сока. Перелинковывайте страницы ради счастья пользователей, а не ради SEO. А ссылочный сок перетечет без вашего участия. Кстати, Google давно отказался от публичного расчета PageRank.
С помощью валидатора XML Sitemap можно проанализировать карту сайта. Для этого укажите соответствующий URL и нажмите кнопку «Старт».
Чтобы просмотреть информацию об ошибках, нажмите на соответствующие ссылки в правой части экрана программы.
Инструмент «Генератор Sitemap» создает карту сайта для выбранного сайта. Дефолтные настройки корректные, но при необходимости их можно менять. Например, для больших сайтов имеет смысл разделить карту сайта на сегменты по 100 или 1000 URL. Для экономии трафика можно заархивировать карту сайта.
В разделе меню «Анализ» можно получить данные о дубликатах, входящих ссылках и цепочках канонических URL. В меню «Базы данных» можно вызвать сводку по парсингу, перейти к общим результатам сканирования и к таблице заголовков URL.
Мини-кейс: как Netpeak Spider помог устранить ошибки на сайте
Для мини-кейса использовал свою экспериментальную площадку, так как здесь не боюсь что-нибудь сломать. Перед началом работы с Netpeak Spider восстановил настройки по умолчанию.
Указал URL ресурса и запустил сканирование.
В течение минуты получил результат сканирования. В первую очередь интересуюсь ошибками с высоким уровнем критичности.
Начал с простого: добавляю дескрипшен на две страницы.
В админке сайта увидел, что описания действительно нет. Исправил ошибку на двух страницах.
Кстати, в Search Console Google уведомления об отсутствующих description нет.
Справедливости ради, в «Вебмастере» в разделе возможных ошибок висит уведомление об отсутствии description.
Анализирую критические ошибки «Битые ссылки». Первую ошибку игнорировал, так как доступ к xmlrpc.php закрыл сам из-за параноидального стремления обезопасить сайт от взломщиков.
Остальные битые ссылки указывают на виртуальный каталог REST API. Такие ссылки желательно закрывать от индексации. Например, это можно сделать через robots.txt.
Ошибки Client Error также связаны с xmlrpc.php и каталогом wp-json для REST API. Ссылки уже закрыты от индексации поисковыми системами, поэтому их можно игнорировать.
С помощью кнопки «Рестарт» повторил сканирование, чтобы увидеть реакцию программы на исправленные ошибки. На иллюстрации видно, что предупреждения об отсутствующих description исчезли. Статус битых ссылок на каталог wp-json изменился с Not Found на Not Found и Disallowed. То есть проблемные служебные ссылки закрыты от индексации поисковиками.
После устранения критичных ошибок проанализировал проблемы средней критичности.
Часть предупреждений не требует внимания, это не ошибки:
- Отсутствует заголовок h2. Я специально так настроил главную страницу блога.
- Редиректы 301. Они связаны с перенаправлением пользователей на ЧПУ.
- Заблокировано в robots.txt. Здесь действительно заблокированы служебные ссылки, которые не должны индексировать поисковики.
- Заблокировано в Meta Robots. Здесь с помощью плагина All in One SEO Pack заблокированы для ПС страницы категорий.
- Заблокировано в X-Robots Tag. Блокируем служебные ссылки.
- PageRank: перенаправление. Программа включает в этот пункт страницы пагинации. На моем сайте пагинация настроена корректно, ошибок там нет.
Другие ошибки требуют внимания. Например, ошибку «Изображения без атрибута Alt» надо исправлять. С помощью кнопки «Отчет по ошибке» я получил список страниц, на которых есть фото без атрибута Alt. Фронт работы понятен.
Также требуют исправления ошибки:
- Максимальный размер изображения. Фото можно оптимизировать с помощью сервиса Tiny PNG или плагина Compress JPEG & PNG images для WordPress.
- Большое время ответа сервера. Это тема для отдельного серьезного разговора.
После анализа ошибок со средним уровнем критичности уделил внимание некритичным ошибкам. Они не требуют немедленного исправления. Этими ошибками займусь, если будут чесаться руки.
Например, Netpeak Spider включает в ошибку «PageRank: отсутствуют связи» все ускоренные страницы сайта.
Уведомляю Google о наличии ускоренной версии страниц с помощью атрибута rel=»amphtml». Не считаю нужным уведомлять об AMP-версии сайта пользователей, которые попали на полную версию. Google сам направляет пользователей на AMP, если считает нужным. То есть ошибки нет.
Пытаюсь достать из результатов сканирования полезные данные, которые помогут работать над сайтом. На дашборде вижу, что время ответа сервера для 2 % страниц сайта превышает 2 секунды.
Ради интереса рассчитываю внутренние PageRank. Программа ранжирует страницы по ссылочному весу и присваивает им статусы Ok, «Перенаправление» или «Несвязный узел». Несвязными узлами Netpeak Spider называет AMP, на которые нет ссылок. Перелинковка на моем сайте настроена корректно и с заботой о пользователе, поэтому практически полезной информации в расчете внутреннего PageRank не вижу.
Что в итоге: с помощью Netpeak Spider нашел несколько важных ошибок. Это отсутствие description на двух страницах, индексируемые ссылки на каталог wp-json, отсутствие атрибута alt у некоторых фото и медленный ответ сервера для 2 % страниц сайта. Часть ошибок, например, отсутствующие метатеги и атрибуты alt, можно исправить быстро. Над другими, в частности, над скоростью загрузки страниц и временем ответа сервера, придется работать дольше.
При необходимости могу извлечь из результатов сканирования другие полезные данные, о которых шла речь в описании функциональности программы.
Эффективность Netpeak Spider зависит от квалификации пользователя
Netpeak Spider — инструмент для квалифицированных пользователей. Программа мгновенно собирает информацию о сайте. От владельца сайта зависит реальная польза полученных сведений.
Netpeak Spider находит серьезные ошибки, которые не видит Search Console. Также с помощью программы можно получить данные о структуре сайта, идеи для навигации и перелинковки.
Благодаря пользовательскому парсингу возможности Netpeak Spider практически безграничны. С помощью этого инструмента можно получить любые данные с публичного сайта. Это может быть список страниц с использованием определенного термина, элемента, фрагмента кода.
Неквалифицированные пользователи должны пользоваться Netpeak Spider аккуратно. В лучшем случае работа с программой грозит ламеру потерей времени. А в худшем пользователь может неверно трактовать собранную информацию и допустить ошибки в работе с сайтом. Впрочем, это справедливо в отношении любого инструмента. Про топор в руках известного литературного героя говорили выше.
Делитесь опытом использования Netpeak Spider в комментариях. Как вы используете полученные с помощью программы данные для улучшения своего сайта или конкурентного анализа? Какие функции программы нравятся, а какие кажутся непонятными или бесполезными?
chto-umeet-netpeak-spider-moshchnyy-instrument-seo-analiza-saytaHostRank или PageRank, вычисляемый по графу хостов
Как уже упоминалось в предыдущей части нашего с вами материала, в ряду случаев наличие висячих узлов может оказывать существенное влияние на ранжирование документов в органическом поиске. Ориентируясь на Рис. 14 можно сказать, что как при равномерном, так и неравномерном перемещении пользователя наша с вами виртуальная страница получает более высокое значение Google PR.
Например, при допущении равномерного перемещения с какого-либо висячего документа к прочим страницам нашей системы мы бы имели следующую матрицу переходов:
В ином случае мы можем обозначить за С={1, 2} то подмножество узлов нашей модели, которое имеет сильную связанность, а прочие узлы, на которое подмножество С ссылается лишь в одностороннем порядке обозначим за D={3}. Тогда матрица переходов (α= 0.85) принимает вид:
Отсюда, нормированное значение PageRank (x1, x2, z) = (0.31746, 0.31746, 0.365079). Надо сказать, что виртуальная страница может получать существенно большее значение веса Google PR даже при введении запрета на телепортацию в ее содержимое пользователя поисковой системы.
Мёртвые (битые) ссылки в построении выдачи
Если само по себе признание документа висячим, еще не ставит под сомнение качество содержащегося в нем контента (мы можем иметь дело с аналитическими отчетами, научными публикациями и т.д.) и поисковая система всегда может произвести все необходимые оценки его содержимого, то ситуация с теми веб-ресурсами, которые возвращают клиентские ошибки вида 404 Not Found (документ не найден и/или не существует) или 403 Forbidden (доступ к ресурсу был запрещен) обстоит совершенно по-иному. Существуют две основные причины появления подобного рода ссылок:
- Созданная ранее web-страница по тем или иным причинам впоследствии была удалена вебмастером. В таком случае мы говорим, что цитируемый сайтом-реципиентом интернет-документ устарел и более не поддерживается администратором ресурса.
- Страница никогда не существовала в принципе, и текущая исходящая ссылка со страницы сайта была создана вследствие какой-либо ошибки администратора. В таком случае, мы говорим о крайне низком уровне модерации веб-ресурса, поскольку качественный сайт предполагает тщательный отбор тех адресов, которым следует передавать нашу голосующую способность.
В обоих случаях, те интернет-документы, которые содержат в своем контенте исходящие ссылки на несуществующие или запрещенные страницы следует рассматривать как своего рода отклонение от корректно функционирующей системы и, по всей логике вещей, они не должны оказывать влияния на результаты поисковой выдачи. Все-таки основополагающий принцип Google PageRank состоит в том, что вес страницы рассчитывается исходя из ссылающихся на страницу документов, а не из тех особенностей (в данном контексте имеется в виду отдача 404 и 403 ошибок) соседей по сети, которые с нею связаны. В нашем распоряжении имеется неподтвержденная информация о том, что в современном интернете наблюдается тенденция к увеличению объема подобного рода умерших по причине своей неактуальности ссылок. Мы ознакомились с рядом исследований [2, 3], посвященных прогнозам полураспада URL-адресов на последующие 4-5 лет. В частности, [2] описывает процесс исчезновения в зоне .COM более 50% отслеживаемых web-страниц в первые 24 месяца. Более того, в процессе обхода более чем 1 млрд. документов мы обнаружили, что около 6% из них возвращают нам код 404, что натолкнуло нас на здравую мысль о том, что в перспективе проблема глобального учета подобного вида отмерших страниц будет только усугубляться. Вопрос увеличения доли битых страниц во многом перекликается с наблюдениями Najork и Wiener [4], выполнявших поиск в ширину и, соответственно, стремившихся найти наибольший ранг документа на раннем этапе обхода. Напомним, что суть данного обхода и разметки вершин веб-графа сводится к тому, что началу обхода приписывается метка 0, а смежным с ней вершинам — 1; после чего мы имеем возможность рассмотреть окружение 1-ой вершины и пометить окружающие ее узлы меткой 2, и т.д.
Если анализировать отсканированный нами 1,1 млрд. страниц, то мы обнаружим следующую картину: после значительного всплеска и незначительного затухания процента обнаруженных нами ссылок на несуществующие web-документы, их доля будет неуклонно расти по мере индексации веба. Причиной этому является то, что все большее количество страниц за время нашей работы утрачивало свою актуальность и выдавало 404 ошибку. Поскольку текущая работа обнаруживает наличие прямой корреляции между ссылками на несуществующие HTML-документы и снижением качества цитирующих их площадок, можно предположить то, что качественная оптимизация и продвижение сайтов должна ставить своей целью поддержание актуальной ссылочной структуры обслуживаемого веб-ресурса. В дальнейшем мы опишем вам некоторые поисковые алгоритмы, которые могут выполнять пессимизацию голосующей способности страниц сайтов, имеющих в своем содержимом ссылки на штрафные узлы. Мы надеемся, что учет подобного рода данных позволит нам улучшить качество персонального поиска и более эффективно управлять сайтами в процессе сканирования.
Небольшой пример
Рассмотрим теперь пример, при котором ссылки на штрафные узлы будут иметь для наших подсчетов существенное значение. На Рис. 15 показано 4 документа, один из которых является безисходным.
Если заниматься подсчетом Google PageRank с α= 0.85, то для трех сильно связанных документов и одной виртуальной страницы получаем:
Если же мы сделаем допущение, что узел 3 имеет не одну, а четыре висячие ссылки, тогда наши новые веса составят:
Как и следовало ожидать, голосующая способность виртуального узла 3 возросла, но одновременно с этим вес документа 2 существенно снизился. Таким образом, ссылки на документы, отдающие нам коды ошибок 404 и/или 403, могут оказывать значительное воздействие на своих ближайших соседей по всемирной паутине.
Ссылки на штрафные узлы
В данном блоке мы рассмотрим с вами несколько модификаций классического алгоритма PageRank, которые могут улучшить ранжирование документов, имеющих исходящие ссылки на штрафные страницы. В их число входят: алгоритм возврата, петельный алгоритм, переходы с весами и BHITS.
1. Алгоритм Возврата
Суть данного метода заключается в том, что в случае наличия на какой-либо страницы исходящей мёртвой ссылки на штрафной документ, ее голосующая способность должна быть пропорционально разделена между имеющимися рабочими ссылками, а оставшееся (штрафное) значение возвращено тем страницам, которые вызвали увеличение ее ранга на этапе предыдущей итерации. В конце концов, мы достигаем эффекта ограничения притока голосующей способности на штрафные узлы со страниц наших web-сайтов. В уже известной нам модели случайного серфинга пользователя данная методика соответствовала бы попаданию пользователя на страницу без исходящих ссылок и его последующего возврата к нужным файлам посредством использования интернет-обозревателя (браузера). В качестве наглядного примера, описывающего нам алгоритм возврата, можем представить страницу i, которая ссылается на штрафной веб-документ p. Для xi имеем:
Мы хотим вернуть часть (скажем, βi, где 0<βi<1) голосующей способности тем интернет-страницам, которые указывают на наш штрафной документ (то есть такой j, где (j,i) ∈ E). Мы можем сделать это посредством изменения расчета PageRank таким образом, чтобы
где B, как и А, представляют собой стохастическую матрицу, а сумма элементов в каждом столбце равна единице. То есть, eTB =eTA = eT. Мы полагаем, что оштрафованный голос i следует распределит между его донорами в пропорциях βiaij, оставляя нашей странице только часть (1-βi) первоначального целостного значения Google PageRank равного 1. В матричном выражении тот случай, когда мы возвращаем голос только одной странице-донору может быть представлен следующим образом:
где a1T является первым столбцом матрицы А (за исключением а11), и:
является таким нормализирующим коэффициентом, что В считается стохастической матрицей. Естественно, если голосующая способность возвращаются нескольким web-документам, мы распределяем общее значение PR в определенных соотношениях (1-βi) между донорами нашей странички. На практике, данная модификация известного алгоритма Google PageRank подразумевает дополнительный шаг не только на каждой его итерации, но и после умножения значения вектора В, хотя, стоит заметить, что вторая ситуация встречается достаточно редко. Если же заводить разговор о более конкретных примерах, то описанная выше операция может достаточно эффективно применяться к страницам, указывающим на те ресурсы, которые отдают 404 ошибку. Обозначим за gi число «хороших» исходящих ссылок со страницы i, а bi количество «плохих» (штрафных) линков. Тогда мы можем оштрафовать страницу i следующим образом:
Если мы представим, что на нашем рисунке 15 имеется 8 исходящих ссылок с документа 3, из которых 4 отдают нам 404 ошибку (мертвые ссылки), а оставшиеся 4-ре признаются рабочими, то, посредством применения данного алгоритма, получаем уже новые значения PageRank (0.292287, 0.312162, 0.1666, 0.228948) для всех (3 и 1 виртуальный узел) наших интернет-страничек. Видим, что документ 3 имеет существенно меньшее (сниженное) значение голосующей способности по сравнению с его соседями 1 и 2. Здорово? Идем дальше.
2. Петельный алгоритм
Существует утверждение, что на каждом шаге наш пользователь может как проследовать по исходящей по ссылке с вероятностью α, так и перейти на какую-либо случайную страницу в сети с вероятностью 1-α. Петельный алгоритм заключается в том, что мы добавляем нашему документу ссылку на самого себя, тем самым, создавая ребро, инцидентное одной и тоже вершине. После того, как мы это сделали (предполагается, что все возможные петли до этого шага были заранее удалены с нашего графа), мы переходим по ней с вероятностью γi, которая будет менее значительной в том случае, если веб-документ имеет множество исходящих ссылок на штрафные странички. Таким образом, те сайты, которые не имеют в своем содержимом мёртвых линков, будут сохранять свой PR в случае нашего перехода по нашей петельной ссылке, а наличие хотя бы одной единственной ссылки на несуществующий файл будет снижать их первоначальную голосующую способность. Для расчета параметра γi нам необходимо выбрать вероятность γ и использовать формулу γi=γ⋅gi/bi+gi, где bi обозначается количество исходящих линков со страницы i к штрафным документам, а gi — тех ссылок, которые ведут к актуальным интернет-сайтам. Однако для того, чтобы наша матрица была стохастической, мы должны скорректировать вероятность телепортации с 1-α до 1-α-(γbi/bi+gi). В принципе, существует несколько моделей, описывающих работу данного алгоритма, в наиболее простой из которых мы просто добавляем на каждую хорошую страницу ссылку на саму себя и всякий раз осуществляем случайный переход по исходящим линкам (в том числе и по тем, на которые являются петлями) с равномерной вероятностью. Однако мы можем усложнить себе задачу таким образом, при котором параметр γi будет подбираться для каждой странички нашего сайта индивидуально, а также, помимо вероятности перехода нашего пользователя по петельному линку, добавим в нашу модель вероятность перехода 1-γi в соответствии с классической формулой Google PageRank. Несмотря на большое обилие всевозможных модификаций данного алгоритма, все они достигают своей основной цели — поток голосующей способности к штрафным сайтам ограничивается.
3. Алгоритм весовых переходов
В предыдущей части мы уже занимались обработкой штрафных страниц (например, с кодами ответа HTTP 404 Not Found) на нашем графе под видом висячих узлов и минимизировали их воздействие (см. раздел «Обработка висячих страниц»), но в отличие от стандартной процедуры, которая предполагает последующее равномерное/выборочное перераспределение веса виртуального узла (n+1), мы предлагаем альтернативный механизм смещенного перераспределения, при котором оштрафованные документы получают меньшее значение голосующей способности. Для этого, используя приведенные выше обозначения для хороших и плохих документов, взвесим исходящие ссылки из виртуального узла к качественному документу в С (или ко всему набору) с коэффициентом p и к штрафному узлу с pgi /(gi + bi), где p подбирается таким образом, что сумма весов всех вершин нашего графа будет давать 1.
4. Алгоритм BHITS
Ниже представлена модификация классического алгоритма HITS [5], которая является производной от случайного блуждания пользователя как в прямом, так и обратном направлении, однако, наряду с этим, основными его отличительными характеристиками от более известного прототипа является то, что работа BHITS осуществляется вне зависимости от запросов и рангов интернет-документов. В этом смысле он больше напоминает методологию описанную SALSA [6] или в [7], но суть его, как и во всех описанных ранее алгоритмах, заключается в некотором снижении голосующей способности тех web-документов, которые цитируют штрафные сайты. Соответственно случайному серфингу нашего пользователя, каждый последующий шаг вперед будет рассчитываться в нашем случае по аналогии с PR, а в случае попадания на висячий узел мы будем вынуждены вернуться назад. Важно отметить, что возврат на невисячем узле обеспечивается в нашей модели посредством петельного линка, а процедура возвращения с висячего разделяется на два типа. Для первого из них мы будем передавать свой голос виртуальному узлу (справедливо для попадания на штрафной документ), а для второго типа, который учитывает нештрафной ресурс, — равномерно распределять текущую оценку страницы между всеми обратными ссылками. Мы полагаем, что все сайты представляет собой связанные между собой цифровые документы, что, безусловно, подтверждается нашими сканнерами, однако нам также следует предположить, что нашим роботам-индексаторам известны все внутренние ссылки, связывающие данный набор разрозненных интернет-страниц, поскольку в противном случае алгоритм не сможет быть запущен. Поэтому, мы будем учитывать только сильные связи, и любая страница без входящих ссылок будет расцениваться в рамках поставленной перед нами задачи как штрафная. Взамен операции возвращения по входящим на них ребрам, как и в классической модели PR, будем применять случайную телепортацию на любое множество документов в сети. Результатом этого процесса становится как «возврат» голосующей способности тем сайтам, которые цитируют из своего контента нештрафные странички, так и перераспределение рангов, присваиваемых некачественным web-узлам. Если матрицу, описывающую PageRank марковского процесса, обозначить за Р, тогда матрица для алгоритма BHITS обозначается как BP, в которой B есть ни что иное, как матрица кодирующая обратный шаг пользователя. С учетом того, что штрафные страницы, как правило, оказываются в самом конце поисковой выдачи, то давайте обозначим полустепень захода узла j через δ(j), а вероятность перехода нашего пользователя с j на i через bij = 1/δ(j). Тогда, для описания обратного шага мы получим следующую матрицу:
BP является матрицей переходных вероятностей для цепи Маркова по той простой причине, что она является продуктом двух прочих стохастических матриц. Эта марковская цепь будет создавать стационарное распределение вероятностей, то есть такое распределение, которое не будет меняться с течением времени, но вполне очевиден тот факт, что для тех веб-документов, которые ссылаются на штрафные сайты/страницы, вероятность будет меньшей, нежели чем в стандартном алгоритме Google PR.
Проблематика практической реализации
Учитывая все возрастающий объем глобальной сети, проблема эффективного практического внедрения любого алгоритма ранжирования является достаточно существенной. Первая тройка описанных выше алгоритмов, которые основываются на модификации классической модели Google PageRank, а если говорить более конкретно, на изменениях матрицы А, не потребует от нас значительных вычислительных затрат. Почему? Дело в том, что все эти дополнения по своей сути носят локальный характер и, кроме соблюдения требований нормализированности матрицы, изменения записей в i-строке будут зависеть только от количества штрафных и хороших исходящих ссылок из i-го узла, bi и gi. Отсюда, у нас появляется возможность не только предварительно вычислять модифицированные матрицы за линейное время (вектор b и g), но и вносить все необходимые изменения в процессе наших итераций. Четвертый алгоритм BHITS представляется для практического внедрения куда более сложным, и основная его проблема заключается в том, что он требует учёта всех существующих в интернете висячих узлов. Вспомнив же, что в ходе нашей исследовательской работы нами было проиндексировано только 1 из 5 млрд. HTML-страниц (думается, что число висячих узлов в пять раз превышает обнаруженный нами объем), сделаем логичный вывод о том, что такой подход явно не подходит для крупномасштабной реализации и нам следует использовать методологию, базирующуюся на PageRank.
Алгоритм HostRank
До текущего момента мы в основном затрагивали висячие узлы, игнорируя прочие особенности веба, которые также могут быть учтены при подсчете PR документов. Оригинальная парадигма данного алгоритма моделировала сеть как некоторый набор страничек, по которым пользователь может перемещаться как посредством прохождения по ссылкам, так и телепортируясь на случайные узлы по причине утрата интереса к существующим и/или для выхода на сайты прочих тематик. Безусловно, она была достаточно упрощенной и не могла отразить реального пользовательского поведения в полном смысле этого слова, в частности можно сослаться на то, что пользователь не может осуществлять равномерный случайный выбор документов или даже быть осведомленным в доступном для него наборе URL-адресов. Ряд недавних исследований предполагает, что подавляющий процент пользовательских сессий начинается с обращения к поисковым системам, далее идет сам вопрос и следование по предложенным ссылкам на странице поисковой выдачи. Продолжительность сессии складывается из прохождения по ссылкам на оригинальный веб-документ и ознакомления с его содержимым, возможного возвращения к странице результатов и/или переформулировки запроса до тех пор, пока у пользователя поисковой машины сохраняется потребность в получении необходимой ему информации. Однако в случае начала новой сессии, пользователь уже не обращается к случайному узлу, а возвращается к поисковой машине для формулирования очередного запроса и именно это поведение исключается в классической парадигме Google PageRank, особенно в той части, что в пользовательском перемещении был заложен неоднородный по своему распределению набор всевозможных узлов.
Еще одной вариацией на тему модели интернет серфинга, несколько позже положенного в классический PageRank, является то, что пользователь выбирает для своего случайного перехода страницу из ряда трастовых узлов, в принципе это то, о чем мы писали в части алгоритма доверия Google TrustRank. Впоследствии, данная схема была использована как средство для увеличения персонализирующей составляющей (алгоритм Topic-Sensitive PageRank [1]) поискового механизма Google. Согласимся, что это было бы эффективной моделью для тех пользователей, которые осуществляют свое перемещение к каким-либо URL-адресам из набора имеющихся в их браузере закладок или являются частью аудитории крупных интернет-порталов. Однако в случае с теми же самыми порталами мы будем иметь неравномерное распределение рандомных перемещений, поскольку такие интернет-ресурсы очень быстро меняют свое содержимое и генерируют огромное число новых ссылок в краткий период времени, которых с момента последнего визита пользователя просто не существовало! В [8] отмечается, что вероятностные значения, присваиваемые алгоритмом PageRank распадаются в соответствии со степенным законом распределения вероятностей, и это необходимо учитывать в модели развивающегося веба. Ими было предположено, что телепортация осуществляется равномерно на случайно избираемую страничку.
На Рис. 16 показано распределение значений PR, вычисленного посредством трастовой и рандомной телепортации (0.5) к одному из авторитетных сайтов (microsoft.com и yahoo.com). И хотя наши наблюдения во многом подтверждают данные [8], мы видим, что стратегия телепортации оказывает глубокое влияние на гипотетическое распределение вероятностей для попадания пользователей на страницу сайта. В частности, если ссылочная структура веба была бы иерархической, в которой каждая предыдущая страница, связанная с последующей, тогда бы распределение уменьшалось экспоненциально с продвижением вглубь иерархии, а окончание (кривой) распределения показывало бы результаты более близкие к экспоненциальному, нежели чем к степенному закону распределения. Попутно заметим, что было бы очень заманчиво предлагать пользователям перемещаться по страницам на основании присваиваемых им значений PR.
Использование иерархической структуры
Одним из предположений, сделанных в оригинальной работе Lawrence Page и Sergey Brin [9] было случайное перемещение к цифровым документам верхнего уровня страниц сайта, что во многом увязывается с нашей склонностью восприятия информации, построенной по иерархическому принципу. Кроме того, исходя из отсканированных нами страниц мы обнаружили, что 62,4% проиндексированных ссылок оказались внутренними, а оставшиеся исходящие линки, как правило, вели на главные страницы веб-сайтов (см. Табл. 2)
Глубина | Доля |
0 | 0.75 |
1 | 0.089 |
2 | 0.035 |
3 | 0.017 |
4 | 0.005 |
5 | 0.002 |
6 | 0.001 |
Данные структурные особенности веба показывают нам очень высокий уровень компрессии для графа хостов и позволяют использовать блок-ориентированный подход для ускорения сходимости Google PageRank. С учетом иерархической структуры самих сайтов, а также того факта, что в качестве источника цитирования вебмастера предпочитают ставить обратную ссылку не на какую-либо внутреннюю страницу сайта, а именно на главную, мы считаем необходимым исследовать страницы интернет-сайтов как элементы единого организма, а также присваивать им ранговые значения, исходя из информационной ценности. Для данных расчетов используется алгоритм HostRank. Говоря более формально, в том случае, если имеется такой URL на хосте S, которой ссылается на URL хоста D (имена хостов представляют собой узлы на нашем графе), то мы строим между ними ориентированное ребро. Помимо этого, мы можем назначить ребрам между хостами некоторые весовые значения (в сумме они будут давать нам единицу), которые отразят нам количество ссылок с URL-источника к URL-цели. Затем, в первоначальном подсчете PR заменим этими весами элементы aij = 1/dj. Несмотря на то, что включение реберных весов потребует от нас дополнительной информации для каждого ребра данного графа, они могут улучшить качество тех поисковых результатов, которые отражают сильные связи.
В качестве альтернативы мы могли бы использовать веса, состоящие из числа обособленных URL-целей. По той простой причине, что мы имеем дело с малыми графами (в нашей выборке имелось около 48 млн. хостов, хотя многие из них не были проиндексированы по разным причинам), вычисление HostRank оказывается существенно простой задачей нежели чем самого Google PageRank, а следовательно он может быть объединен с другими оптимизационными подходами, опирающиеся на более сложные алгоритмы линейной алгебры; быть более эффективным, чем диспетчеризация ввода/вывода (I/O) и аппроксимаций, использующих только локальную информацию.
Google pagerank сalexa rank domain age 15 Основных Методов
[hi]
15 Основных Методов Повышающих Уровень Page Rank
Google pagerank alexa rank domain age — это алгоритм анализа ссылок, который используется поисковыми системами для того, чтобы оценить вес Ваших ссылок относительно других. Как Рассчитывается Page Rank? Page Rank рассчитывается через различные алгоритмы разработаны конкретные поисковые системы (Google, Yahoo и т. д.). В общем говоря, Page Rank рассчитывается на основе ссылок, связанных с Вашей страницей, в том числе:Pagerank висячий узел как исправить
Содержание:- Pagerank висячий узел как исправить
- Как поднять pagerank сайта?
- Domain age alexa rank google pagerank seitend
Как поднять 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 rank13.Никогда Не Используйте Незаконных Методов
Применение незаконных тактики может повлечь за собой получение Бана от Google. Вопреки расхожему мнению, Google гораздо умнее, чем вы можете предположить. Никогда не думай, что удастся его обмануть. Рано или поздно каждый ощутит последствия применения незаконных методов. Что бы вы сделали, если бы Ваш сайт в один прекрасный день вылетела из Google? Ищете компанию которая отвечает за создание pagerank висячий узел как исправить, а также их продвижение? Оставьте свой комментарий в поле ниже. [embedheight=»360″]https://youtu.be/1G69RuHumUo[/embed] ]]>Понравилась статья? Сохраните в закладки: