Технический аудит сайта

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

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

Коды ответов: первое, что ломается молча

Каждый адрес на сайте обязан отдавать тот код состояния, который ему положен. Это фундамент: по коду робот решает, оставлять страницу в индексе, выбрасывать её или идти по новому адресу. Проверка занимает несколько минут, а находки бывают дорогие.

Что проверяем	Должно быть	Что означает нарушение
Рабочая страница	200	Если 3xx — лишний редирект, робот тратит обход дважды
Несуществующий адрес	404 или 410	Код 200 с текстом «не найдено» плодит пустышки в индексе
Старый адрес после переезда	301 на новый	302 не передаёт сигналы и держит в индексе старый адрес
Версия с www и без	301 на выбранную	Две копии сайта, сигналы делятся пополам
Версия по http	301 на https	Смешанный протокол, часть ссылок ведёт на незащищённую копию
Служебные файлы CMS	403 или 404	Открытые служебные адреса — и уязвимость, и мусор в обходе

Самая частая находка — так называемая мягкая ошибка 404: адреса, которых нет, отдают код 200 и страницу с надписью «ничего не найдено». Для робота это обычная страница, он добавляет её в индекс, а потом сам же помечает как малоценную. На сайтах с фильтрами и поиском такие адреса плодятся тысячами, потому что любой параметр в строке порождает новую «страницу».

Проверяется это без инструментов: добавьте к любому адресу произвольный хвост вроде /proverka-nesushhestvuyushhego-adresa/ и посмотрите код ответа. Второй обязательный тест — адрес с добавленным слэшем в конце и без него: обе версии не должны отдавать 200 одновременно.

Отдельно смотрю цепочки редиректов. Нормально, когда старый адрес ведёт на новый одним шагом. Плохо, когда цепочка выглядит как http → https → www → конечный адрес: каждый шаг это лишний запрос, а на мобильном канале ещё и лишние сотни миллисекунд ожидания. Цепочки длиннее двух шагов сокращаю до одного правила.

Индексация: почему в поиске меньше страниц, чем на сайте

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

Что смотрю по порядку:

• Раздел исключённых страниц в Вебмастере. По каждому адресу указана причина: недостаточно качественная, дубль, ошибка сервера, запрет в robots. Причины разные, лечение тоже разное — общего «сайт плохо индексируется» не бывает.
• Динамика обхода. Сколько страниц робот берёт в сутки. Если сайт на две тысячи адресов, а обход идёт по двадцать страниц, полный цикл займёт три месяца. Значит, новые материалы будут появляться в поиске с задержкой в недели.
• Соотношение кодов в обходе. Если среди обойденных адресов заметная доля 404 и 301, робот расходует квоту на несуществующее. Это лечится чисткой карты сайта и внутренних ссылок.
• Метатег robots на важных страницах. Забытый noindex после разработки — классика. Особенно после переноса с тестового домена.
• Карта сайта. Число адресов в ней должно совпадать с числом страниц, которые вы хотите видеть в поиске. Закрытые от индексации адреса в карте — противоречивый сигнал.
• Техническое SEO

Полезная деталь: страницы, закрытые в robots.txt, всё равно могут попасть в выдачу — робот не заходит внутрь, но видит ссылки на них с других сайтов. Если страницу нужно убрать из поиска гарантированно, её закрывают метатегом noindex и оставляют открытой для обхода, иначе робот не увидит запрет.

Дубли: четыре копии главной за пять минут

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

Базовая проверка делается руками. Откройте главную страницу в вариантах:

1. с www и без него;
2. по http и по https;
3. со слэшем в конце адреса и без слэша;
4. с добавленной рекламной меткой вида ?utm_source=test;
5. с заглавными буквами в адресе, если сервер их не приводит к нижнему регистру.

Все варианты, кроме одного основного, обязаны вести на него редиректом 301. Если каждый отвечает кодом 200 — у вас пять копий одной страницы, и это ещё до того, как мы дошли до каталога.

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

Источник дублей	Как проявляется	Чем лечится
Фильтры и сортировки каталога	Сотни адресов с одинаковым набором товаров	Canonical на основную категорию, запрет в robots для параметров сортировки
Рекламные метки в адресе	Один товар доступен по десяткам адресов	Директива Clean-param для Яндекса, canonical для Google
Пагинация	Вторая и третья страницы конкурируют с первой	Уникальные title, canonical на саму страницу пагинации, не на первую
Страницы вложений в WordPress	Каждая картинка создаёт отдельную страницу	Отключение в настройках темы или редирект на запись
Внутренний поиск по сайту	Тысячи адресов вида ?s=запрос	Запрет обхода в robots.txt
Один товар в нескольких категориях	Одна карточка по трём разным адресам	Единый адрес товара, canonical с остальных

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

Скорость: два разных числа, которые постоянно путают

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

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

Показатель	Ориентир	Где смотреть	Куда копать при превышении
Время до первого байта	до 500 мс, хорошо — до 200 мс	Консоль браузера, curl, вкладка «Сеть»	Кэширование, база данных, лимиты хостинга
Отрисовка основного содержимого	до 2,5 с на мобильном	PageSpeed Insights, отчёт Метрики	Вес изображений, блокирующие скрипты, шрифты
Сдвиг вёрстки при загрузке	не более 0,1	PageSpeed Insights	Не заданы размеры картинок и рекламных блоков
Отклик на действие	до 200 мс	PageSpeed Insights, отчёт по реальным пользователям	Тяжёлые скрипты, чужие виджеты, чаты

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

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

Мобильная версия: проверка руками, а не в уменьшенном окне

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

Проверку делаю на настоящем телефоне и прохожу весь путь клиента до отправки заявки:

• Читаемость без увеличения. Основной текст от 16 пикселей, контраст достаточный при дневном свете на улице.
• Размер кнопок и полей. В элемент должно попадать пальцем без прицеливания, соседние ссылки не слипаются.
• Отсутствие горизонтальной прокрутки. Чаще всего её вызывают широкие таблицы и картинки без ограничения ширины.
• Всплывающие окна. Баннер согласия, чат и предложение подписки не должны перекрывать содержимое целиком и обязаны закрываться с первого касания.
• Формы. Правильный тип поля для телефона и почты, чтобы открывалась нужная клавиатура; понятное сообщение об ошибке; подтверждение отправки.
• Поведение на слабом канале. Ограничьте скорость в инструментах разработчика и посмотрите, что видит человек в первые три секунды: пустой экран, прыгающую вёрстку или читаемый текст.
• Техническое SEO

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

Robots.txt, карта сайта и микроразметка

Три файла и один блок кода, которые определяют, как робот понимает структуру сайта. Проверяются быстро, ломаются часто.

Robots.txt. Отдаётся ли он с кодом 200, нет ли в нём запрета на служебные директории, которые нужны для отрисовки страницы (стили и скрипты закрывать нельзя — робот не увидит вёрстку так, как её видит человек). Указана ли карта сайта. Нет ли забытого Disallow: / с этапа разработки — эта строка выключает сайт из поиска целиком, и находят её обычно через месяц после запуска.

Карта сайта. Совпадает ли число адресов с числом страниц, которые должны быть в поиске. Нет ли в ней адресов, отдающих 404 или 301. Обновляется ли дата последнего изменения при правке страницы — если карта статичная и не меняется годами, робот перестаёт ей верить.

Микроразметка. Минимум — организация с контактами, хлебные крошки, для товаров цена и наличие, для статей автор и дата. Главное требование: размеченные данные обязаны совпадать с тем, что видит человек на странице. Разметка вопросов, которых нет в тексте, или цены, отличающейся от указанной, — повод для санкций, а не для расширенного сниппета.

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

Служебные проверки, о которых обычно забывают

Блок находок, которые не видны в отчётах, но стоят денег.

• Битые внутренние ссылки. Ищутся полным обходом сайта. Отдельно проверяю ссылки в меню и в подвале: они стоят на всех страницах сразу, поэтому одна ошибка там весит как тысяча.
• Формы. Отправить заявку своими руками и убедиться, что письмо дошло. Регулярная история: форма показывает «спасибо», а письмо уходит на почту, к которой давно нет доступа.
• Сертификат. Срок действия, автоматическое продление, отсутствие смешанного содержимого — когда защищённая страница подгружает картинки по незащищённому протоколу.
• Файл favicon и настройки шаринга. Мелочь, но именно она видна в выдаче и в мессенджерах: страница без картинки предпросмотра выглядит хуже соседних по ссылке.
• Ответ сервера при нагрузке. Если хостинг ограничивает число одновременных процессов, часть запросов встаёт в очередь. Признак — плавающее время ответа: утром 300 миллисекунд, вечером две секунды при той же посещаемости.
• Журнал ошибок сервера. Часто там прямым текстом лежит ответ на вопрос, почему страница периодически отдаёт 500.
• Техническое SEO

Чем проверять и что даёт каждый инструмент

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

Инструмент	Что даёт	Чего не покажет
Яндекс.Вебмастер	Индексация, исключённые страницы с причинами, статистика обхода, диагностика	Данные Google, поведение на конкретном устройстве
Google Search Console	Тот же срез со стороны Google, отчёт по основным веб-показателям	Ситуацию в Яндексе, детали внутренней перелинковки
Краулер (Screaming Frog и аналоги)	Полный обход: коды, дубли заголовков, битые ссылки, глубина вложенности	Как страницу видит поисковая система после исполнения скриптов
PageSpeed Insights	Причины медленной отрисовки, конкретные тяжёлые файлы	Скорость сайта в целом — это замер одной страницы
Яндекс.Метрика	Реальное время загрузки у живых посетителей в разбивке по устройствам	Технические причины — только следствия
Браузер и его консоль	Исходный код после исполнения скриптов, ошибки, время ответа по этапам	Массовые проблемы — руками весь сайт не обойти

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

Как расставить приоритеты по находкам

Технический аудит всегда даёт длинный список. Если чинить его подряд, первыми уйдут мелочи, а серьёзное останется на потом. Я расставляю находки по влиянию на два параметра: попадает ли страница в индекс и доходит ли посетитель до заявки.

Находка	Что ломает	Срочность
Забытый noindex или Disallow на разделе	Страниц нет в поиске вообще	Немедленно
Несуществующие адреса отдают 200	Индекс забивается пустышками, квота обхода уходит впустую	Немедленно
Дубли главной по www и протоколу	Сигналы делятся между копиями	Немедленно
Форма не доставляет заявки	Прямая потеря обращений	Немедленно
Время ответа сервера выше секунды	Медленный обход и потеря посетителей	В первую неделю
Дубли от фильтров каталога	Размывание релевантности внутри категории	В первый месяц
Одинаковые title у страниц каталога	Слабые сниппеты, конкуренция страниц между собой	В первый месяц
Отсутствие микроразметки	Сниппет беднее, чем у конкурентов	Планово
Сдвиг вёрстки при загрузке	Раздражает посетителя, влияет на оценку страницы	Планово

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

Частые вопросы

Как часто проводить технический аудит?
Полный — раз в полгода. Обязательно после переезда на другой домен, смены темы или шаблона, крупных доработок каталога и смены хостинга. Короткая проверка кодов ответов, индексации и работы форм — раз в месяц: она занимает полчаса и ловит большинство внезапных поломок.

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

Можно ли обойтись бесплатными инструментами?
Для сайта до нескольких сотен страниц — да. Вебмастер, Search Console, браузер и бесплатная версия краулера закрывают основную часть проверок. Платные инструменты экономят время на больших каталогах, но принципиально новых находок не дают.

Аудит показал сорок ошибок — это много?
Само число ничего не значит: любой автоматический отчёт выдаёт десятки замечаний, включая косметические. Значение имеет, есть ли среди них те, что мешают индексации и отправке заявок. Обычно из сорока пунктов критичны три-четыре.

Кто должен исправлять найденное?
Часть правок делается в админке и доступна владельцу: мета-теги, настройки индексации, тексты. Часть требует доступа к серверу и шаблону — редиректы, кэширование, вёрстка. Разделение обязанностей стоит определить сразу, иначе отчёт превращается в документ, который никто не берёт в работу.

Влияет ли техническое состояние на позиции напрямую?
Через доступность и поведение. Страница, которой нет в индексе, не ранжируется вовсе. Медленная страница теряет часть посетителей до загрузки, и это видно в поведенческих данных. Прямого коэффициента «минус десять ошибок — плюс пять позиций» не существует, но пока технический слой сломан, остальные работы дают меньший эффект.

Показываю, как выглядит проверка сайта и что она находит:

2:29

Коротко

• Технический аудит проверяет две вещи: доступность сайта для робота и удобство для человека. Пока они сломаны, работа над текстами и ссылками даёт слабый эффект.
• Начинают с кодов ответов: несуществующий адрес обязан отдавать 404, а не 200 с надписью «ничего не найдено».
• Дубли главной проверяются руками за пять минут — по вариантам адреса с www, по протоколу, со слэшем и с рекламной меткой.
• Скорость раскладывают на два числа: время ответа сервера и время отрисовки. Лечатся они разными способами, и путать их нельзя.
• Мобильную версию проверяют на настоящем телефоне, проходя весь путь до отправки заявки, а не сужением окна браузера.
• Находки сортируют по влиянию: сначала то, из-за чего страницы не в индексе, затем то, из-за чего теряются обращения, потом улучшения.
• Техническое SEO

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