Доступность
Отвечает ли сервер корректно и получает ли робот нужный HTML без блокировок и бесконечных цепочек.
Практическое SEO · чек-лист
Технический SEO-аудит сайта: что и как проверять
Технический SEO-аудит показывает, может ли поисковый робот нормально получить страницу, понять её адрес и содержание, пройти по внутренним ссылкам и не потеряться среди дублей, редиректов и ошибок сервера.
Коротко
Хороший аудит заканчивается не списком ошибок, а планом действий
Смысл технического аудита не в том, чтобы собрать максимально длинный отчёт. Нужен ответ на четыре вопроса: что мешает обходу, что мешает индексации, что искажает сигналы страниц и какие исправления дадут наибольший эффект.
Индексация
Какие страницы должны быть в поиске, какие исключены и совпадает ли это с задачей сайта.
Однозначность
Нет ли дублей, конфликтующих canonical, лишних параметров и нескольких URL для одного документа.
Приоритет
Сначала исправляем проблемы, которые затрагивают важные разделы и реально мешают поиску или пользователю.
Основа
Что входит в технический SEO-аудит
Технический SEO-аудит — это проверка того, как сайт выглядит не только в браузере пользователя, но и на уровне URL, HTTP-ответов, правил обхода, внутренней структуры и индексируемых версий страниц. Он не заменяет работу с семантикой, контентом или спросом, но определяет, может ли эта работа вообще нормально участвовать в поиске.
Типичный аудит затрагивает доступность сайта для роботов, robots.txt, Sitemap, коды ответа, редиректы, canonical, дубли, параметры URL, пагинацию и фильтры, внутренние ссылки, мобильную версию, скорость, HTTPS, ошибки сервера и корректность рендеринга контента.
Важно разделять симптом и причину. «Страница пропала из поиска» — симптом. Причиной может быть 404, редирект, noindex, закрытие в robots.txt, дубль, неверный canonical, серверная ошибка или просто то, что робот ещё не обнаружил URL.
Шаг 1
Сверяем обход сайта и фактическую индексацию
Начинать аудит удобнее с инвентаризации. Нужно понимать, какие URL существуют по мнению CMS или файловой системы, какие находятся во внутренних ссылках, какие перечислены в Sitemap, какие видит поисковая система и какие действительно должны участвовать в поиске.
Что проверяем в первую очередь
Смотрим важные коммерческие страницы, категории, карточки, статьи, служебные URL, пагинацию, фильтры и параметры. Отдельно ищем «сироты» — страницы, на которые нет внутренних ссылок. Яндекс прямо указывает, что робот узнаёт о документах через ссылочную структуру; если на страницу никто не ссылается, её обнаружение становится проблемой.
В Яндекс Вебмастере полезны отчёты о страницах в поиске, исключённых страницах и структуре сайта. Они помогают увидеть не только количество URL, но и причины исключения: дубль, редирект, неканоническая страница, ошибка сервера и другие состояния.
Шаг 2
Проверяем robots.txt и Sitemap без мифов
robots.txt управляет обходом: какие участки сайта робот может запрашивать. Файл должен находиться в корне сайта и быть доступен корректно. Ошибка здесь способна закрыть от робота целые разделы, CSS или JavaScript, которые нужны для нормального отображения страницы.
Sitemap сообщает поисковой системе об актуальных URL сайта, но наличие адреса в Sitemap не гарантирует его попадание в результаты поиска. В карту стоит включать канонические страницы, которые действительно должны индексироваться, а не все технические адреса, которые способна сгенерировать CMS.
robots.txt
Проверяем доступность файла, синтаксис, случайные Disallow и доступ робота к ресурсам, влияющим на отображение.
Sitemap
Ищем 404, редиректы, неканонические и закрытые URL, а также страницы, которые важны, но отсутствуют в карте.
Совпадение
URL не должен одновременно объявляться важным через Sitemap и блокироваться техническими правилами без понятной причины.
Актуальность
После удаления или переноса страниц карта должна обновляться, иначе робот продолжит получать шум.
Официальные требования можно сверить в документации Яндекса: robots.txt и Sitemap.
Шаг 3
Разбираем HTTP-коды и цепочки редиректов
Поисковый робот принимает решение не только по содержимому HTML, но и по ответу сервера. Страница, которую мы хотим видеть в поиске, обычно должна отвечать 200 OK. Постоянный перенос адреса требует постоянного редиректа, временный — временного, а удалённый документ не должен притворяться обычной рабочей страницей.
| Код | Что означает | Что проверяем на аудите | Типичная ошибка |
|---|---|---|---|
| 200 | Страница доступна | Нужный ли контент отдаётся и не является ли это soft 404 | Несуществующий URL возвращает шаблонную страницу с кодом 200 |
| 301 / 308 | Постоянный перенос | Цель редиректа, отсутствие цепочек и циклов | Старый URL ведёт на промежуточный адрес, а затем ещё на один |
| 302 / 307 | Временный перенос | Действительно ли перенос временный | Постоянный переезд годами работает через временный редирект |
| 404 / 410 | Ресурс отсутствует | Нет ли внутренних ссылок и записей в Sitemap | Удалённые страницы продолжают массово фигурировать в структуре |
| 5xx | Ошибка сервера | Частота, конкретные URL, нагрузка, логи | Важные страницы периодически недоступны для робота и пользователей |
Яндекс отдельно рекомендует использовать 301 для постоянного перемещения и 302 — только когда перенос действительно временный. Для диагностики удобно проверять конкретный URL инструментом «Проверка ответа сервера» и параллельно смотреть серверные логи.
Справочник HTTP-кодов Яндекса полезен как контрольная таблица, но на аудите важнее увидеть поведение сайта целиком: от входного URL до финального ответа.
Шаг 4
Ищем дубли, canonical и лишние версии страниц
Один документ часто оказывается доступен по нескольким адресам: со слешем и без, с параметрами, UTM-метками, сортировкой, фильтром, дублем главной через index.php или техническим адресом CMS. Если система не задаёт единый вариант, поисковику приходится самостоятельно решать, какой URL считать основным.
rel="canonical" помогает указать предпочитаемую версию, но это рекомендация, а не приказ. Поэтому на аудите мы проверяем не только наличие canonical, но и его согласованность с редиректами, Sitemap, внутренними ссылками и фактической версией страницы.
Самоканоникал
Индексируемая страница обычно должна указывать на свой основной URL, если архитектура сайта использует canonical.
Цепочки canonical
Страница A → B, а B → C создаёт неоднозначность. Предпочтительнее сразу указывать конечный адрес.
Параметры
UTM, сортировка и фильтры могут создавать множество адресов с одинаковым или почти одинаковым содержимым.
Внутренние ссылки
Если сайт сам массово ссылается на неканоническую версию, canonical становится попыткой исправить собственную архитектурную ошибку.
Яндекс описывает canonical как рекомендацию и отдельно указывает на дубли из-за параметров и разных URL. Полезные первоисточники: канонический адрес страницы и дублирование страниц.
Шаг 5
Проверяем структуру URL и внутреннюю перелинковку
Технически доступная страница всё равно может быть плохо встроена в сайт. Если до неё нельзя добраться обычными HTML-ссылками или она спрятана слишком глубоко, робот получает слабый сигнал о её роли. Поэтому аудит должен связывать техническую проверку со структурой.
Мы смотрим глубину клика, хлебные крошки, меню, ссылки из категорий и статей, наличие битых внутренних ссылок, циклические переходы, анкоры и то, не ведёт ли сайт на редиректы вместо конечных URL.
Что особенно важно для больших каталогов
Фильтры, сортировки, пагинация и фасетная навигация способны генерировать огромное число комбинаций. Не каждая комбинация должна становиться индексируемой посадочной. Решение нужно принимать на основе реального поискового спроса и самостоятельного интента, а не потому, что CMS умеет создать URL.
Шаг 6
Проверяем мобильную версию как полноценный сайт
Мобильная проверка — это не только «влезает ли макет в экран». Нужно убедиться, что на мобильном устройстве доступен тот же важный контент, навигация работает, формы не ломаются, ресурсы не закрыты от робота, а страница не требует горизонтальной прокрутки.
Для адаптивных сайтов проверяем viewport, ширину элементов, размер текста и интерактивных зон, появление скрытых меню, загрузку изображений и JavaScript. Если используется отдельная мобильная версия, дополнительно проверяем связь между соответствующими URL и отсутствие расхождений в ключевом контенте.
В актуальных рекомендациях Яндекс указывает, что мобильному роботу должны быть доступны CSS и JavaScript, а страницы должны корректно открываться без горизонтальной прокрутки. Рекомендации Яндекса для мобильных сайтов.
Шаг 7
Скорость, доступность и стабильность сервера
Медленный сайт — не одна цифра из теста. На аудите важно понять, что именно тормозит: серверный ответ, тяжёлые изображения, блокирующие ресурсы, слишком много JavaScript, внешние виджеты, неоптимальный кэш, медленная база данных или нестабильная инфраструктура.
Проверяем несколько типов страниц, а не только главную: категорию, карточку, статью, форму, страницу с тяжёлой логикой. Отдельно смотрим поведение под нагрузкой и периодические 5xx — они могут не проявиться в разовом лабораторном тесте.
TTFB и backend
Если HTML начинает приходить слишком поздно, оптимизация картинок не решит корневую проблему.
Изображения
Размеры, современные форматы, lazy loading и отсутствие загрузки огромного оригинала в маленький контейнер.
CSS и JavaScript
Блокирующие ресурсы, тяжёлые библиотеки, лишние запросы и код, который не нужен конкретной странице.
Стабильность
Логи, пики нагрузки, 502/503, таймауты, DNS и TLS — часть технического SEO, если они мешают получить страницу.
Шаг 8
Проверяем JavaScript и то, что реально видит робот
Современный сайт может успешно открываться у разработчика и при этом отдавать роботу почти пустой HTML, ошибку API или интерфейс, который появляется только после сложной цепочки JavaScript. Поэтому для динамических проектов недостаточно посмотреть исходный код глазами браузера.
Сравниваем исходный HTML и итоговый DOM, проверяем, доступны ли без взаимодействия основной текст, ссылки, Title, canonical и другие критические элементы. Для SPA и тяжёлых frontend-приложений особенно важно не прятать важные ссылки за событиями, которые робот может не воспроизвести так же, как пользователь.
Здесь нет универсального требования «весь JavaScript плох». Задача аудита проще: убедиться, что важный контент и маршруты действительно доступны поисковой системе и не зависят от хрупкого сценария загрузки.
Практический пример
Что может показать аудит после переноса сайта
Типичный сценарий: сайт визуально работает после переезда, но поисковый трафик начал снижаться. Вместо предположений проверяем цепочку от старого URL до новой страницы и ищем конкретные точки потери.
| Наблюдение | Что проверяем | Почему это важно | Исправление |
|---|---|---|---|
| Старые URL возвращают 404 | Карту старых адресов и соответствие новым | Ссылки и накопленные сигналы ведут в несуществующие документы | Настроить прямые 301 на релевантные новые URL |
| Часть редиректов ведёт на главную | Есть ли точное соответствие старой и новой страницы | Массовый редирект всего на главную стирает смысл конкретных URL | Редиректить на максимально близкий по назначению документ |
| В Sitemap остались старые адреса | Карту сайта после deploy | Поисковику одновременно сообщают о старой и новой структуре | Оставить только актуальные канонические URL |
| Canonical указывает на тестовый домен | Шаблоны head и конфигурацию окружения | Сайт сам рекомендует поисковику другой адрес | Исправить canonical на боевой домен и проверить все типы страниц |
| Внутренние ссылки ещё ведут через редиректы | Меню, хлебные крошки, карточки и контент | Робот постоянно проходит лишний промежуточный шаг | Обновить ссылки сразу на конечные URL |
| На новом сервере появляются 502 | Логи, PHP-FPM, БД, proxy и нагрузку | Часть обходов заканчивается ошибкой сервера | Устранить инфраструктурную причину до дальнейшего SEO |
Симптомтрафик и страницы просели
Причиныредиректы, canonical, Sitemap, сервер
Планисправляем по влиянию, затем перепроверяем
Именно поэтому технический аудит после миграции полезнее проверки «открывается ли главная». Поисковая история привязана к конкретным адресам и сигналам, а не к визуальному сходству старого и нового сайта.
После диагностики
Как расставлять приоритет исправлений
Не каждая найденная ошибка одинаково опасна. Приоритет зависит от масштаба, типа затронутых страниц, вероятности потери индексации и того, мешает ли проблема пользователю прямо сейчас.
Критично
Сайт или важный раздел закрыт, отдаёт 5xx, массовые 404, неверные редиректы или canonical на другой адрес.
Высокий
Дубли и параметры создают большое число лишних URL, важные страницы плохо связаны или отсутствуют в структуре.
Средний
Скорость, изображения, лишние переходы и ошибки разметки ухудшают качество, но не блокируют индексирование.
Низкий
Косметические замечания и единичные проблемы на незначимых URL, которые не влияют на пользовательский путь.
| Проблема | Масштаб | Риск | Приоритет | Контроль после исправления |
|---|---|---|---|---|
| Категория закрыта robots.txt | Весь раздел | Робот не может нормально обходить страницы | Критичный | Проверка robots.txt + обход URL |
| Цепочка из трёх редиректов | Шаблон URL | Лишние переходы и сложная миграционная логика | Высокий | Один прямой переход к финальному 200 |
| Изображения по 2–4 МБ | Карточки каталога | Медленная загрузка страниц | Средний | Вес, формат и реальные размеры после deploy |
| Один битый URL в старой статье | Одна ссылка | Локальная проблема навигации | Низкий | Исправить ссылку и повторно проверить страницу |
Хороший отчёт должен содержать не только «ошибка найдена», но и затронутые URL, предполагаемую причину, способ исправления, приоритет и способ проверки результата.
Инструменты
Чем проверять техническое состояние сайта
Нет одного сервиса, который полностью заменяет аудит. Обычно приходится сочетать поисковые отчёты, краулер, браузер, командные HTTP-проверки, анализ HTML, серверные логи и данные аналитики. Инструмент выбирается под вопрос, а не наоборот.
Яндекс Вебмастер
Страницы в поиске, исключения, диагностика, Sitemap, проверка ответа сервера и другие данные со стороны поисковой системы.
Краулер
Массово собирает URL, коды ответа, Title, canonical, глубину, внутренние ссылки и другие технические признаки.
Браузер
Показывает итоговый DOM, сетевые запросы, ошибки JavaScript, мобильную вёрстку и фактическое поведение страницы.
Сервер и логи
Помогают увидеть таймауты, 5xx, обращения роботов, проблемы PHP/БД и то, что невозможно понять только из HTML.
Чек-лист
Технический SEO-аудит: последовательность проверки
- Собрать список важных URL: услуги, категории, карточки, статьи, служебные типы страниц.
- Проверить HTTP-ответы: 200, редиректы, 404/410, 5xx и цепочки переходов.
- Сверить robots.txt: нет ли случайных запретов для нужных разделов и ресурсов.
- Проверить Sitemap: только актуальные канонические URL, без 404 и лишних редиректов.
- Проверить индексацию: какие страницы в поиске, какие исключены и почему.
- Найти дубли: параметры, слеши, регистр, index-файлы, фильтры, технические версии.
- Проверить canonical: один корректный адрес, без цепочек и конфликтов с внутренними ссылками.
- Проверить структуру: важные страницы доступны по обычным ссылкам и не являются сиротами.
- Проверить мобильную версию: viewport, контент, меню, формы, горизонтальный overflow.
- Проверить производительность: backend, изображения, CSS/JS, внешние ресурсы и стабильность.
- Проверить рендеринг: основной контент и ссылки действительно присутствуют в итоговой странице.
- Составить приоритеты: сначала блокирующие и массовые проблемы, потом улучшения качества.
- Исправить и перепроверить: аудит заканчивается контрольным обходом после deploy.
Вопросы
Короткие ответы о техническом SEO-аудите
Как часто нужен технический SEO-аудит?
Для стабильного небольшого сайта нет смысла делать полный аудит каждый месяц. Повторная глубокая проверка особенно полезна после миграции, смены CMS, редизайна, крупного изменения структуры, появления проблем с индексацией или заметного изменения поискового трафика. Критические технические показатели при этом можно контролировать постоянно.
Можно ли провести аудит только через Яндекс Вебмастер?
Вебмастер показывает важную часть картины со стороны Яндекса, но не заменяет краулинг, браузерную проверку и серверные данные. Например, он не объяснит все причины медленного PHP, ошибки приложения или конкретную логику внутренних ссылок.
Нужно ли исправлять вообще все найденные ошибки?
Нет. Некоторые замечания могут относиться к служебным или незначимым страницам и почти не влиять на результат. Поэтому аудит без приоритизации часто превращается в дорогой список задач с низкой отдачей.
Что важнее: скорость или индексация?
Если важная страница недоступна роботу, закрыта или возвращает ошибочный код, сначала решаем это. Производительность важна, но оптимизировать страницу, которая технически не участвует в поиске, нелогично.
Нужен ли SEO-аудит перед переносом сайта?
Да, если перенос затрагивает домен, URL, CMS или структуру. До переезда нужно зафиксировать старые адреса и состояние сайта, чтобы после запуска проверить редиректы, canonical, Sitemap, внутренние ссылки и доступность новой версии.
Практика NIC-SEO
Сначала причина, затем исправление
Технический аудит полезен, когда за каждой проблемой можно проследить цепочку: где она возникает, какие страницы затрагивает, что нужно изменить и как проверить результат после deploy.
Если проблема связана с индексированием, редиректами, сервером или последствиями переноса, можно начать с технического SEO и подключить поддержку или миграцию по ситуации.