Партнерский материал
Чем больше сайт, тем больше проблем с внутренней оптимизацией может быть даже в банальных вещах. Когда мы имеем проект как Depositphotos с миллионами страниц, он становится достаточно неповоротлив, его трудно контролировать и проверять. Но мы не спешим расстраиваться, потому что Netpeak Spider помогает находить баги, которые появились, даже несмотря на постоянные автотесты.
Кейс будет полезен тем, кто хочет постоянно мониторить наличие проблем, а особенно в тот момент, когда Product-отдел их вовсю плодит.
Определите пул страниц для отслеживания
Здесь важно определить не количество страниц, а их тип и разнообразие. К примеру, если у вас на сайте присутствуют такие типы страниц как:
То вам наверняка приходилось сталкиваться с поочередной выкаткой этих самых страниц в релиз или уже в live-режиме (зачастую это все делается по неведомой никому причине в пятницу часов так в 6–7 вечера), чтобы утром в понедельник SEO-специалист не расслаблялся. Да и кто ему даст, если уже на выходных он видит просадку?
В процессе сбора страниц для отслеживания важно еще понимать, что если сайт мультиязычный, то необходимо также включать страницы языков, которые являются приоритетными. К примеру, мы отслеживанием лендинги, страницы товаров, категорий, подкатегорий на разных языках: Ru, SP, Fr, Pt, EN. Список можно расширять, но скорость обработки всех этих страниц будет замедляться.
Используйте мультиоконность в Netpeak Spider
Непременно наступит момент, когда найти все баги по списку страниц попросту не выйдет. В таком случае советую открыть еще одно окно в Netpeak Spider и спокойно в 2–10 потоков (а может и больше, если ваш проект сможет выдержать нагрузку) делать переобход страниц в обычном порядке. В обычном сканировании мы чаще всего сталкиваемся с проблемой в hreflang:
Да, как мы видим hreflang отсутствуют там, где они должны быть. Для обработки по списку первым делом загружаем список этих страниц. Я люблю задавать вручную:
Далее учитывая специфику проекта, я выбираю бота, которым буду краулить. Снижаю количество потоков, чтобы сайт успел все обрабатывать, иначе мы будем получать 503. Что можно найти при сканировании по списку?
Создав предварительный фильтр по 404 ошибкам, я обнаружил, что Product-менеджер удалил лендинг /crello.html, а SEO-отдел узнал об этом на выходных. Немало ошибок и ниже по списку.
Я для себя выделяю момент с отсутствующими hreflang, весьма интересно делать связку с Netpeak Checker и смотреть, когда Googlebot закешировал страницу, и видел ли на ней изменения.
Берем список страниц из Netpeak Spider и идем проверять по ним параметры индексации и кеш. Вот что видим:
Не дожидаясь окончания, я уже понял, что с индексацией есть проблемы. Googlebot прошелся и закешировал страницу, тем не менее она не в индексе. Открываем код страницы:
В hreflang есть значение pt-br домена (которого к слову у нас нет, есть отдельно PT и BR), далее путем несложных манипуляций в Netpeak Spider просмотрим каждую страницу в разрезе hreflang:
Помимо несуществующих языковых версий еще и обнаружим висячие узлы, когда на странице А есть языковой атрибут на страницу В, а на странице В нет:
Выделяем URL всех языковых версий в hreflang и снова запускаем сканирование, при этом преследуем уже немного другие цели:
Что видим? Шаблон title / description явно слетел, так как отличается друг от друга. Какие выводы делаем? Скорее всего, фиксы привели к десинхронизации базы данных, и возможно, есть некоторые моменты с базой и шаблонами переводов.
Также можно увидеть проблемы с внутренними ссылками – мы очень плотно с ними работаем, допускать пустые анкоры нам совсем ни к чему:
В случае, когда страница имеет пустой анкор – это либо это картинка, либо ошибка, которая приведет к тому, что робот будет ходить по ней, на нее будет идти вес, но в конечном итоге она создаст дополнительный путь для бота, и в итоге он может устать ходить.
Но если уже смотреть на ситуацию под углом внутреннего веса, то ссылки без анкоров, как заметила SEO-команда Depositphotos, передают вес куда хуже, чем те, что будут обозначены текстом (если ссылка это не картинка).
Дальнейшие действия
Данные можно крутить как душе угодно, самое правильное – это делать хотфиксы. На больших сайтах нужно взять за привычку делать схожие манипуляции, которые помогут быстро обнаружить подобные баги, исправление которых сможет как минимум не резать органический трафик своего же проекта.
Очень важно понимать принцип, по которому та или иная ошибка появляется, и бороться непосредственно с ним. В случае с UGC это все становится намного интереснее, ведь обычные зарегистрированные юзеры куда опаснее всех продактов вместе взятых. Нужно каждый день мониторить, что они там написывают, и что в итоге видит Google.
В случае с большими массивами данных не всегда нужно обрабатывать миллионы страниц сразу. Да, это полезно, да, информативно, но порой, чтобы обнаружить проблемы, которые лежат на поверхности, достаточно запустить Netpeak Spider за чашкой кофе, немного поперхнуться от найденных данных, и пойти их фиксить. Если бы Netpeak Spider умел обрабатывать логи, то думаю здоровье SEO-специалистов пошатнулось бы еще больше.
Узнать больше о том, как повысить качество работы вашей команды над техническим SEO с помощью Netpeak Spider можно по ссылке:
Теги:
