Технический SEO-аудит — это проверка того, могут ли поисковые роботы найти, открыть и понять полезные страницы сайта. Его результатом должен стать список конкретных исправлений: проблемный URL, факт ошибки, её последствия и способ проверки после релиза.
Ниже — рабочая последовательность, основанная на нашем внутреннем регламенте SEO-аудита. Начните с доступности и индексации, затем переходите к шаблонам страниц и качеству ссылок. Так вы не потратите день на описания изображений, пока весь каталог закрыт от обхода.
Подготовьте выборку страниц и исходные данные
Запишите основной домен, регион продвижения, CMS и дату последнего изменения сайта. Выберите по несколько URL каждого важного типа: главная, категория, карточка товара или услуги, статья, контакты, страница фильтра и пагинация. Включите страницы с органическим трафиком и заявки из поиска. Проверка одной главной не показывает состояние всего проекта.
Выгрузите данные о страницах из Google Search Console и Яндекс Вебмастера. Дополните их картой сайта и результатом обхода. Эти источники отвечают на разные вопросы: sitemap содержит заявленные URL, обход — найденные ссылки, кабинеты поисковиков — состояние страниц в конкретной системе. Несовпадения между списками часто полезнее общего балла аудита.
Запустите обход в ITSEO
Откройте аудитор сайта, укажите адрес и лимит страниц. Для первой проверки используйте режим с соблюдением robots.txt. Подберите лимит так, чтобы в выборку попали разные шаблоны, а не только первые страницы одного раздела. Сохраните настройки и дату: они понадобятся для повторного замера.
Аудитор анализирует полученный HTML. Если основной контент появляется только после выполнения JavaScript, дополнительно сравните исходный HTML с отрисованной страницей в браузере. Автоматический обход также не заменяет данные об индексации из кабинетов поисковых систем.
Чек-лист из 20 проверок
| № | Что проверить | Какой результат нужен |
|---|---|---|
| 1 | Главная и ключевые посадочные | Страницы доступны, отвечают ожидаемым HTTP-кодом. |
| 2 | HTTPS и сертификат | Нет предупреждений браузера и смешанного контента. |
| 3 | Зеркала домена | HTTP и альтернативное зеркало ведут на выбранную версию. |
| 4 | robots.txt | Важные разделы доступны для обхода. |
| 5 | Meta robots и X-Robots-Tag | Нет случайного noindex у посадочных страниц. |
| 6 | Sitemap | Карта доступна и содержит актуальные канонические URL. |
| 7 | Статус индексации | Причины исключения полезных страниц изучены. |
| 8 | Canonical | Адрес существует и соответствует содержанию страницы. |
| 9 | Фильтры и параметры | Для дублей и самостоятельных посадочных заданы разные правила. |
| 10 | Пагинация | Следующие страницы и товары доступны по ссылкам. |
| 11 | Битые внутренние ссылки | Меню и контент не отправляют посетителя на ошибочные URL. |
| 12 | Редиректы | Нет циклов и ненужных промежуточных переходов. |
| 13 | Title | Каждая посадочная имеет понятное название. |
| 14 | Description | Описание отражает содержание и условия предложения. |
| 15 | H1 и структура текста | Заголовки помогают понять тему и разделы страницы. |
| 16 | Изображения | Файлы доступны, содержательные изображения имеют подходящий alt. |
| 17 | Микроразметка | Данные валидны и совпадают с видимым содержанием. |
| 18 | Мобильная версия | Меню, формы и содержимое работают на реальном телефоне. |
| 19 | Скорость | Проверены важные шаблоны и пользовательские метрики. |
| 20 | Контакты и конверсионные действия | Заявка отправляется, а событие фиксируется в аналитике. |
По находкам переходите к профильным проверкам: HTTP-коды и цепочки редиректов, robots.txt и sitemap, валидатор микроразметки. Ошибка в одном шаблоне может повторяться на тысячах URL — проверяйте причину в CMS, а не только отдельный адрес.
Расставьте приоритеты по последствиям
Срочно исправляйте проблемы, которые мешают открыть страницу, пройти к покупке или попасть в индекс: массовые 5xx, случайный запрет индексации, редирект каталога на главную, сломанная форма. Следом идут ошибки важного шаблона, дубли и ссылки на недоступные страницы. Локальные улучшения описаний и оформления выполняйте после устранения блокирующих проблем.
Не каждое предупреждение сканера — дефект. Пустой alt у декоративного изображения бывает корректным решением; одинаковые фрагменты description могут быть частью осмысленного шаблона; исключённая из поиска служебная страница может не требовать индексации. Для каждого замечания установите ожидаемое поведение.
Оформите задачу, которую можно принять
Учебный пример: страница /catalog/chairs/ отвечает 200, но содержит noindex. В задаче укажите сам URL, список затронутых категорий, место настройки в шаблоне и ожидаемый результат: индексируемые категории больше не содержат запрета в HTML и HTTP-заголовках. Добавьте проверку других шаблонов, чтобы исправление не открыло служебные разделы.
У каждой задачи должны быть ответственный, приоритет и критерий приёмки. После релиза повторите обход с сопоставимыми настройками, проверьте изменённые URL вручную и наблюдайте за состоянием индекса. Изменение HTTP-кода видно сразу; реакция поисковой системы требует нового обхода.
Что делать после первого аудита
Разберите отдельно robots.txt и sitemap, дубли и canonical и битые ссылки. Для контроля между релизами используйте регламент еженедельного мониторинга.
Как построить аудит, который охватывает весь сайт
Инвентаризация шаблонов вместо случайных URL
Для большого сайта сначала составьте список типов страниц и источников их появления. У магазина это категории, подкатегории, карточки, бренды, фильтры, поиск и служебные страницы заказа. У образовательного проекта — направления, программы, преподаватели, расписание и статьи. У сайта услуг — услуги, региональные страницы, портфолио и информационные материалы. Для каждого типа запишите, кто управляет шаблоном и какие поля доступны редактору.
Затем подберите примеры с разными состояниями. Карточка товара в наличии и карточка снятого с продажи товара могут иметь разные правила индексации. Категория с десятью товарами отличается от пустой категории. Опубликованная статья отличается от черновика или архивной версии. В выборку полезно включить давно существующие и недавно созданные URL: иногда старые страницы работают на прежнем шаблоне, а ошибка возникает только в новом.
Отдельный столбец «Источник обнаружения» помогает объяснить пропуски. Если важный URL есть только в sitemap, но на него нет внутренних ссылок, это одна задача. Если ссылка присутствует в меню, но сканер не дошёл до неё из-за лимита, это другое ограничение проверки. Не записывайте «страницы нет на сайте», пока не выяснили, какие источники использовал обход и на каком этапе он остановился.
Оценка покрытия и ограничений
Рядом с итоговым количеством проверенных адресов укажите покрытие по шаблонам. Например, в учебной выборке проверены десять категорий и тридцать карточек, но ни одна страница фильтра. Такой отчёт полезнее формулировки «проверили сорок страниц». Когда один тип URL составляет большую часть сайта, используйте отдельную выборку для остальных типов, чтобы не принять нормальное состояние карточек за состояние всего проекта.
Зафиксируйте, какие разделы остались недоступны: авторизация, антибот-проверка, JavaScript-навигация, ограничения robots.txt, тайм-аут. Для каждой причины нужен дальнейший способ проверки. Закрытый кабинет можно пройти вручную с разрешённой тестовой учётной записью; динамический каталог — сравнить в исходном и отрисованном виде. Отсутствие автоматических находок внутри непроверенного раздела не означает, что там всё исправно.
Как разбирать находки по четырём слоям
Доступность и маршруты
Проверяйте цепочку от ссылки в источнике до конечного содержимого. Успешный код ответа не подтверждает правильный маршрут: адрес услуги может вести на главную, а карточка — на общую категорию. Сравните название, основной текст и ожидаемое действие на конечной странице. Если перенаправление предусмотрено бизнесом, запишите это как ожидаемое поведение, чтобы следующая проверка не создавала ту же задачу повторно.
Серверные ошибки разбирайте с датой и временем запроса. Единичный ответ 503 во время обслуживания отличается от постоянного сбоя важной категории. Воспроизведите проблему, сохраните условия и передайте разработчику конкретные примеры. Для нестабильного дефекта полезен дополнительный ряд наблюдений, но частота проверок должна учитывать нагрузку: технический аудит не требует бесконтрольного повторения запросов к одному адресу.
Правила обхода и выбор страниц для поиска
Составьте небольшую матрицу для каждой группы: должен ли раздел сканироваться, должен ли индексироваться, какой адрес считается предпочтительным и должен ли он попадать в sitemap. Это превращает противоречия между robots.txt, noindex, canonical и картой сайта в понятные решения. Написать «убрать все запреты» проще, но такая задача способна открыть поиск по сайту и технические параметры, которые не нужны в поисковой выдаче.
Сравнивайте намерение владельца с фактическим состоянием в кабинетах поисковиков. Если полезная категория исключена как дубль, изучите сходство содержимого и выбранный основной URL. Если служебная страница не индексируется по запланированной причине, не включайте её в список критических ошибок. Отчёт должен показывать отклонение от целевой модели, а не любое отсутствие URL в индексе.
Содержимое и шаблонные элементы
Для метатегов проверьте, какое значение приходит из CMS и что добавляет общий шаблон. Повторяющийся бренд в Title часто исправляется в одном месте. Пустые описания только у нового типа услуг могут указывать на забытое поле. Одинаковый заголовок у разных карточек бывает связан с неверной переменной. В каждом случае укажите, нужен ли редакторский ввод данных или изменение кода, иначе задача попадёт не тому исполнителю.
У изображений различайте отсутствие файла, неправильные размеры и текстовую альтернативу. Для содержательной схемы нужен alt, который передаёт её назначение; для декоративной детали допустима пустая альтернатива. Проверяйте также изображения, подставленные CSS или скриптом. В отчёте сканера они могут отображаться иначе, чем обычные теги img, поэтому важно посмотреть реальную страницу и понять роль элемента.
Пользовательские действия
Пройдите хотя бы по одному основному маршруту на каждом важном шаблоне: товар — корзина, услуга — заявка, статья — связанный материал. Убедитесь, что кнопка действительно выполняет действие, сервер принимает данные и человек видит подтверждение. Автоматический HTML-аудит может обнаружить ссылку, но не подтверждает завершение многошагового сценария. Такой контроль стоит включить в приёмку технических изменений, затрагивающих формы и навигацию.
Учебный разбор: от списка ошибок к трём задачам
Представим сайт услуг, где обнаружены двенадцать категорий с пустым Title, пятьдесят ссылок через старый путь и четыре страницы с noindex. Количество находок само по себе не задаёт приоритет. Сначала выясняем: noindex появился у коммерческих страниц случайно или это служебные разделы? Если запрет случайный, исправление становится срочным независимо от того, что таких URL меньше остальных.
Далее выясняем происхождение пустого Title. Если все двенадцать категорий используют один новый шаблон, создаём одну задачу на шаблон и прилагаем список примеров. Не нужно двенадцать несвязанных просьб «прописать заголовок». Пятьдесят старых ссылок тоже можно исправить одним изменением меню, если они идут из общего компонента. Масштаб определяется источником, а не числом строк в выгрузке.
| Задача | Что меняем | Как принимаем |
|---|---|---|
| Случайный noindex | Настройку коммерческого шаблона | Проверяем HTML и заголовки затронутых страниц и контрольного служебного раздела. |
| Пустые Title | Вывод названия категории и редакторское поле | Проверяем заполненную, пустую и длинную формулировку. |
| Старые ссылки меню | Общий источник навигации | Новые ссылки ведут напрямую, а старые адреса сохраняют осмысленный ответ. |
Этот сценарий условный: числа показывают способ группировки находок, а не результаты реального клиента. После приёмки отчёт хранит связь между исходными строками и исправлениями. Тогда повторный обход позволяет быстро увидеть, какие находки исчезли, какие изменились и какие появились впервые. Исчезновение строки без проверенного ожидаемого поведения ещё не означает, что причина устранена правильно.
Что включить в итоговый отчёт и повторную проверку
В начале отчёта опишите границы проверки: дата, адрес, режим robots.txt, лимит, охваченные шаблоны и ограничения. Далее дайте короткий список срочных задач, затем технический реестр с доказательствами. Приложения могут содержать полные выгрузки и дополнительные URL, но основной документ должен позволять понять, что делать первым, даже если человек не откроет каждую таблицу.
У находки сохраняйте фактическое значение, ожидаемое значение, источник и критерий приёмки. Для повторного аудита оставьте контрольные URL из каждой изменённой группы и из соседних шаблонов. Проверка соседей ловит регрессии: исправляя метатеги категорий, разработчик может случайно изменить карточки; открывая услуги, — снять запрет у служебного раздела. Отмечайте также, какие наблюдения требуют времени после нового обхода поисковиком.
Когда исправления приняты, передайте регулярные контрольные задачи в существующий регламент мониторинга. Полный технический аудит нужен при существенных изменениях и для исследования структуры; еженедельный контроль отслеживает заранее выбранные сигналы. Разделение этих задач помогает поддерживать сайт без повторного полного исследования каждой мелкой правки.
Сложные случаи: внешние ресурсы и границы отчёта
У страницы могут быть корректные собственные ответы, но не загружаться внешний шрифт, карта, изображение или виджет. Проверьте, как она выглядит без каждого критического ресурса. Если исчезает только декоративная деталь, это одна задача; если посетитель не видит цену или не может отправить форму — другая. В реестре укажите, относится ли причина к вашему серверу, стороннему сервису или настройке браузерной защиты.
Для технической проверки важно различать ссылку и ресурс. Обычная ссылка предлагает перейти на другой документ; скрипт и стиль участвуют в работе текущего. Одинаковый код ошибки имеет разные последствия в этих случаях. Отдельно проверьте изображения, которые служат кнопками или несут единственную информацию об условиях: отсутствие такого файла может повредить пользовательский путь сильнее, чем отсутствие иллюстрации в архивной статье.
Сканер может получать другое состояние страницы из-за географии, защиты или cookie. Сравните точный URL и необходимые условия, прежде чем объявлять вывод инструмента неверным или страницу исправной. В отчёте сохраните различие между фактом «проверяющий запрос получил запрет» и выводом «страница недоступна всем посетителям». Второй вывод требует дополнительного подтверждения, которого первый сам по себе не даёт.
Не превращайте проверку в соревнование за отсутствие любых предупреждений. Некоторые ограничения обусловлены архитектурой и должны быть описаны как принятые решения. Для каждого такого случая нужны основание, ответственный и условие пересмотра. Например, закрытый личный кабинет не требует публичного обхода, а важная динамическая посадочная требует отдельного подтверждения доступности основного содержимого. Ясное решение лучше бессмысленной попытки сделать весь сайт одинаково доступным.
На этапе приёмки полезно собрать минимальный набор доказательств: исходный ответ, нужный фрагмент HTML, снимок пользовательского состояния и запись выполненного действия. Не требуется прикладывать десятки одинаковых кадров к одному шаблону. Доказательства должны позволять другому специалисту повторить проверку и увидеть, какое конкретное поведение изменилось. Это делает аудит рабочим документом, а не длинным перечнем оценок без объяснения.
Владелец проекта получает два результата: актуальную картину технического состояния и согласованный порядок работ. Если какой-то раздел не проверен или изменение пока не обработано поиском, оставьте соответствующий статус. Завершённый аудит не означает завершение всех исправлений; он означает, что причины, ограничения и дальнейшие действия понятны. После устранения задач повторная проверка закрывает каждую из них по заранее установленному критерию.
Частые вопросы
Можно ли доверять итоговому SEO-баллу?
Используйте его как указатель для просмотра отчёта. Решение о приоритете принимайте по затронутым страницам и реальным последствиям.
Исправления гарантируют рост трафика?
Они убирают обнаруженные технические препятствия. Дальнейший результат зависит также от спроса, содержания, конкуренции и обработки изменений поисковой системой.
