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

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

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

А что может?

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

• Обе ПС практически избавились от проблем с обработкой JS в общем смысле. Но в результате растёт количество проблем с ошибками этой обработки;
• Сайты стали сложнее: когда сайт фактически раскидан по нескольким хостам, это осложняет процессы и способно подкинуть нетривиальные задачки, которые нельзя выловить стандартными средствами;
  
• Проблемы с поведенческими ботами привели к тому, что вебмастера стали интенсивно внедрять способы защиты от роботов. Не каждый способ разумен, и почти каждый сам по себе может создавать проблемы;
  
• Интеграция сторонних сервисов и систем аналитики также может стать причиной появления странных багов.
  

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

• То, что не даёт роботу полноценно просканировать странички
• То, что мешает выстроить общую структуру сайта
  
• Возросшие требования к ресурсам, необходимым для полноценного функционирования сайта
  
• Расход лимитов на обход сайта поисковыми роботами впустую
  

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

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

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

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

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

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

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

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

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

• Ошибки перелинковки на уровне CMS. Например, категория у вас есть, а входных ссылок на неё – нет
• Ошибки настроек сканирования
  
• Общие ошибки структурирования сайта
  

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

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

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

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

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

• Использовать правила реального поискового робота
• Понять, доступен ли URL c IP, реально используемого поисковой системой
  

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

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

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

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

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

• метатегом noindex
• директивами в robots.txt
• наличием канонического адреса
  
• наличием тегов альтернативной мобильной версии
  

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

• Карту сайта в формате sitemap.xml. Там не должно быть ничего, чего не должно быть в индексе: закрытых в robots.txt URL, запрещенных для индексирования страниц, отдающих что-то кроме 200, альтернативных ссылок на мобильную версию, неканонических и т.п.
• Проверяем HTTP-заголовок. Да, canonical и мета robots могут быть заданы и там – через X-Robots-Tag. И их значения могут противоречить метатегам в области HEAD
  
• Область HEAD в HTML. Она вторична по отношению к тегам в заголовке.
  
• Если сайт использует JS – убедитесь, что ничего не меняется в настройках сканирования и индексации его средствами.
  
• Проверяйте настройки консолей вебмастеров: что-то может быть загружено в настройки непосредственно туда (например, карты сайта). Кроме того, есть настройки, отвечающие за обработку параметров и локальных настроек. Важно убедиться, что там ничего не конфликтует с настройками сайта и сервера.
  

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

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

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

• Робот может разово за считанные минуты обойти тысячи страниц
• Краулинг отличается от просмотра страницы человеком
  
• Роботы не спят ночью, у них нет человеческого распорядка
  
• Порядочный поисковый робот вежливо представляется. Непорядочный - может и наврать
  

• Под блокировку поведенческих и сервисных ботов могут попадать и поисковые роботы
• Сервер может искусственно сдерживать активность роботов, ограничивая скорость или предоставляя оптимизированные варианты страниц
  
• Производительность сервера также меняется в зависимости от времени суток: например, у вас на CRON могут висеть какие-то периодически выполняемые задачи, сброс кэша, выгрузки из CRM и т.п. Всё это способно повлиять на производительность сайта и доступность его контента.
  

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

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

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

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

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

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

• Гуглобот сканирует страницы очищая куки между запросами

• Для рендеринга гуглобот использует Chromium версии 74, который не в полной мере понимает современные версии JS

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

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

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

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

• Перегруженный сервер может банально глючить, отдавая самые неожиданные ответы или страницы. Типичный пример – soft 404. Вы получаете страничку 404, или пустую страницу, при этом ответ сервера - 200.
• JS обрабатывается отдельным процессом, в отличие от инструментов для тестирования
  
• Есть ещё проблема кэшей: серверных, на уровне CMS, браузерных. Притом эти кэши могут сильно отличаться в зависимости от пользователя и его прав.
  

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

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

• Медленная или плохо настроенная CDN, где лежат картинки, css, js
• Часть сайта размещена на другом сервере (скажем, на субдомене, который перенаправляет на основной сайт)
  
• Проблемы на стороне базы данных
  

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

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

• Оценка исходного кода. Проблема: нужно отключать JS, иначе браузер при открытии кэшированной версии запустит все JS, и вы будете оценивать искаженную информацию.
• Поиск определенного контента: вам нужно оценить отдельные шинглы. В этом случае надо искать контент, выводимый средствами JS. Для этого используется запрос типа inurl:сайт.ру/url вместе с цитатным запросом в кавычках вида "тут у нас проблемный фрагмент".
  
• Оценка визуализированного DOM из Search Console. В общем, нельзя сказать, что это точный инструмент: это уже не тот скриншотер, что был раньше, но не факт, что сделан по тем же принципам, что реальный гуглобот.
  

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

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

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

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

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

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

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

• Уникализировать свой контент
• Жаловаться кому-то
  
• Отправлять людей с битами по адресу негодяя
  

и т.п.

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

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

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

• В область head воткнуты теги, которых там быть не должно. Робот-краулер встречает такое и не понимает, что тут ещё не про область основного контента. Ошибка не слишком часто встречается, но достаточно, чтобы её упомянуть. Буквально пару дней назад мне попалось даже задваивание тегов head и body, а «сломанная» область head попадается куда чаще.
• Страничка сильно изменяется средствами JS, и стоит внимательно изучить, насколько именно и правильно ли формируется структура и оформление. Да, основные поисковые системы сейчас без особых проблем отрисовывают JS-контент, притом в реальном времени. Но убедиться, что тут всё в порядке – просто необходимо.
  

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

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

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

• Кривой редирект на уровне сервера (со слешем и без слеша) в сочетании с 301 редиректом на главную вместо честной 404 создавал бесконечное кольцо редиректов. По итогам треть большого каталога была просто недоступна гуглоботу (бот Яндекса с проблемой не столкнулся – но там другие правила сканирования).

• Левые теги (div, iframe) в области head приводили к преждевременному завершению заголовка, и метатеги попадали в область body, где их никто не станет читать и учитывать. Таким образом, в выдачу залетали технические дубли, создавая проблему каннибализации по запросам.

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

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

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