Технический SEO-аудит: имитируем робота

Стандартные методики технического аудита могут давать искаженные и неполные данные. Чтобы получить полную картину, нужно пройти путями робота. На что смотреть в процессе – рассмотрим в этой статье.

Каждый первый кейс по SEO утверждает: «Мы исправили технические ошибки сайта, и получили рост в 29 раз…». А дальше перечисляются «попугаи» Google Speed Insight и ещё какая-то ерунда, не способная повлиять ровным счётом ни на что.

А что может?

Практика последнего года показывает, что подход к техническим аудитам надо корректировать с учетом следующих фактов:

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

Все эти ошибки могут стать причиной того, что в поисковую выдачу не попадёт важный контент. Кроме того, поисковая система может решить, что у вас слишком проблемный сайт, на который не стоит приводить посетителей. Представители Гугл примерно в таком духе и выражались: если на сайте есть пяток качественных страниц, а всё остальное – невнятный мусор, то как-то странно вести туда посетителя. Ткнёт он по ссылке на хорошей странице и попадёт на некачественную. Всем будет неловко.

А теперь рассмотрим последовательность действий при аудитах.

Вам в любом случае понадобится хороший парсер, предназначенный для решения задач SEO. Классика – это Screaming Frog SEO Spider или SiteAnalyzer. Есть и другие решения, выбирайте на свой вкус. Главное – чтобы парсер мог полноценно сканировать сайт по правилам выбранного поискового бота в максимально полном объёме. Без предварительного парсинга всего сайта целиком можно пропустить множество неявных ошибок, приводящим к выпадению из доступа целых разделов сайта, оценке связей между отдельными страницами и разделами и т.п.

Если нет времени на серьёзное сканирование (или нет инструментария), можно обойтись использованием браузера Chrome, браузерного расширения View Rendered Source, сторонними сервисами типа bertal.ru, плюс специализированные редакторы типа WinMerge или Diff Checker, с помощью которых можно обнаружить разницу между двумя текстами.

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

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

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

На этом этапе мы проверяем доступность основных ресурсов сайта в общем, вне зависимости от случайностей. Не очень важно, кто именно не может добраться до контента целевой странички: робот, посетитель сайта или оба. Результат будет одинаковым: вместо посещаемой и конвертирующей посадочной страницы вы получите мёртвый узел сайта. «Суслика видишь? – А он есть». Вот как этот суслик.

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

Банально: вот у вас создана товарная категория, но на неё не предусмотрены внутренние ссылки, они есть разве что в карте сайта sitemap.xml. В таком случае есть шанс, что страничка получит видимость в поиске, и даже получит трафик оттуда. Рассчитывать на такое можно, но не нужно. Убедитесь, что раздел доступен из меню или листингов, и человек может туда зайти. Люди не смотрят sitemap.xml, туда заходят только роботы – а сайт вы делали для людей.

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

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

Ответ сервера можно проверить любым удобным инструментом. Я использую bertal.ru или redbot.org. Для обоих сервисов на сайте Арсенкина можно найти удобные букмарклеты. Можно обойтись возможностями браузера, в консоли разработчика, но в этом случае вы получите данные только со своего IP.

Для нашей задачи важны два нюанса:

С эмуляцией гуглобота всё достаточно просто: открываем «Инструменты разработчика» в браузере Chrome, открываем консоль, выбираем интересующий User-Agent. К сожалению, эмуляции яндекс-бота там нет. Впрочем, он в этом смысле не очень и интересен.

Однако надо понимать, что речь опять-таки идёт об эмуляции. А хорошо бы проверить, доступен ли URL с реального IP, которым пользуется гуглобот. И тут нам на помощь придёт инструмент проверки Mobile-friendly.

В этом случае обращение к сайту будет с одного из реальных IP, с которых ходит гуглобот.

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

Однако такая проверка означает только возможность найти страницу, но ничего не говорит о возможности её просканировать и внести в индекс. А эти возможности определяются:

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

Итак, мы поняли, способен ли гуглобот получить доступ к странице. Теперь надо понять, насколько это системно, и может ли робот получать страницу регулярно.

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

А в чем, собственно, разница между роботом и человеком с точки зрения сервера?

Вручную тут разбираться будет сложно, в этом случае есть смысл привлечь техподдержку сайта или системного администратора. Как минимум, вы должны понимать, как ведет себя сервер при пиковой нагрузке, а также когда выполняются важные системные задачи. Не далее как сегодня сервисы мониторинга доступности нескольких моих сайтов на одной площадке дружно прокричали, что сайты лежат – спасибо, «Таймвеб», что всего 5 минут. Но уже понятно, что речь – о системности на стороне хостера.

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

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

Итак, мы поняли, как гуглобот сканирует страницу. Теперь надо понять, что он там видит.

В этом случае нужно сопоставлять только исходный HTML с отрисованным JS. Обязательная часть теста – использование мобильного UA. Использовать можно как Screaming Frog SEO Spider, так и специализированные инструменты типа браузерного расширения View Rendered Source или текстовые редакторы типа WinMerge или Diff Checker, которые могут сопоставлять два текстовых файла для обнаружения разницы.

Основные проблемы здесь связаны либо с JS, либо с файлами-куки:

Здесь на помощь приходит загрузка страниц без файлов куки, например, в режиме "Инкогнито" – с последующим сравнением двух DOM.

Использование инструмента мобильного тестирования с последующим сравнением данных в пользовательском браузере.

Если ошибки на этой стадии не обнаружены - переходим к следующему пункту.

Всё, что мы делаем – пытаемся посмотреть на сайт с точки зрения поискового робота. Но реальное поведение бота может сильно отличаться от нашего.

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

Ещё один вполне обычный вариант – когда при достаточно сложной структуре и архитектуре сайта робот или посетитель не получает правильного ответа от каких-то ресурсов. Примеры:

Итог один: контент, который должен быть подгружен, не подгружается – частично или целиком. Чтобы понять, в чём могут быть проблемы, нужно оценить данные в кэше поисковой системы.

Выбор средств тут небогат, но кое-что есть.

И Google, и Яндекс в настоящий момент предоставляют несколько вариантов кэшированных данных (текст, код, рендер). Это удобно.

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

Google, в отличие от Яндекса, поддерживает междоменные канонические адреса. Что это значит и чем это чревато?

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

Помимо кражи контента, такая ситуация может быть следствием взлома с внедренным редиректом или междоменным тегом link с атрибутом rel="canonical". Даже необязательно взлома: «нулленные» шаблоны того же WordPress уже частенько содержат такие редиректы. Подробнее об этом можно почитать в справке Google.

В этом случае помогает как цитатный поиск по вашему выбору, так и специализированные внешние сервисы.

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

и т.п.

Копии контента, собственно, могут быть и вне поисковой выдачи – они могут транслироваться в "Новости" или какие-то сервисы поисковых систем. Не надо думать, что «это всё равно мои учетки». Сайт может не ранжироваться, если есть другой источник этих же данных, публикующий их и предоставляющий поиску раньше, а конверсии с сайта и внешнего источника могут очень сильно отличаться.

Если существенные проблемы на этой стадии не найдены – двигаемся дальше.

В глубокой древности сервисы аудита любили прогонять заданные странички через HTML-валидатор, и несоответствие спецификациям сразу же становилось причиной вердикта: сайт не оптимизирован. Валидность кода интересна только концерну W3C, мы же можем рассматривать результаты валидатора как косвенный признак – тут могут скрываться более серьёзные ошибки. Для примера:

Используйте валидатор https://validator.w3.org/: он вывалит на вас тонну ненужной информации с кучей мелких блох. Игнорируйте: вам сейчас нужны явные ошибки. Проблемы с атрибутами пока можно отбросить, смотрите на ошибки с тегами и DOM.

Основные ошибки такого рода вам покажет и Screaming Frog при полном парсинге, как минимум – самые грубые.

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

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

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