Технический аудит сайта: пошаговая проверка своими силами

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

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

Базовую проверку небольшого корпоративного сайта можно выполнить самостоятельно. Для крупного интернет-магазина, агрегатора, международного проекта или сайта с JavaScript-рендерингом потребуется более глубокая работа с серверными логами, базой данных, шаблонами и системой аналитики.

Когда нужно проводить технический аудит

Проверка особенно важна:

• перед запуском нового сайта;
• после переноса на другую CMS;
• после смены домена или структуры URL;
• после редизайна;
• после внедрения фильтров, каталога или многоязычности;
• при резком падении поискового трафика;
• при появлении большого числа исключённых страниц;
• после изменения шаблонов;
• при росте ошибок 404 и 5xx;
• после обновления серверной инфраструктуры;
• перед началом активного SEO-продвижения.

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

Что должен дать аудит

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

Для каждой проблемы необходимо указать:

• затронутые URL;
• описание ошибки;
• способ обнаружения;
• возможное влияние;
• приоритет;
• рекомендуемое исправление;
• ответственного;
• срок;
• способ повторной проверки;
• статус выполнения.

Замечание «плохой robots.txt» почти бесполезно. Нормальная задача выглядит так: «Директива Disallow: /services/ закрывает от обхода 18 страниц услуг. Удалить правило, проверить доступность URL и отправить приоритетные страницы на повторный обход».

Какие инструменты понадобятся

Для базового самостоятельного аудита достаточно нескольких групп инструментов.

Панели поисковых систем

• Google Search Console;
• Яндекс Вебмастер.

Они показывают известные поисковой системе URL, причины исключения страниц, состояние файлов Sitemap, ошибки сканирования, поисковые запросы и отдельные проблемы сайта.

Краулер

Краулер обходит сайт по внутренним ссылкам и собирает данные о страницах.

Можно использовать:

• Screaming Frog SEO Spider;
• Netpeak Spider;
• SiteAnalyzer;
• другой инструмент, который показывает коды ответа, метаданные, canonical и внутренние ссылки.

Инструменты браузера

• Chrome DevTools;
• Lighthouse;
• вкладка Network;
• вкладка Performance;
• проверка мобильного отображения;
• просмотр HTML и HTTP-заголовков.

Инструменты производительности

• PageSpeed Insights;
• отчёт Core Web Vitals в Search Console;
• Chrome UX Report;
• серверный мониторинг;
• система веб-аналитики.

Валидаторы

• Rich Results Test;
• валидатор микроразметки Яндекса;
• HTML-валидатор;
• проверка XML-карт сайта;
• проверка SSL и TLS.

Серверные данные

• access log;
• error log;
• журнал PHP;
• журнал приложения;
• статистика ответов 4xx и 5xx;
• данные о времени ответа;
• журнал редиректов;
• логи CDN и WAF.

Подготовка к аудиту

До запуска краулера соберите исходные данные.

Определите проверяемые версии сайта

Зафиксируйте:

• основной домен;
• вариант с www или без www;
• HTTP и HTTPS;
• поддомены;
• языковые версии;
• тестовые домены;
• старые домены;
• мобильные версии;
• отдельные сервисы и кабинеты.

Составьте список важных страниц

Минимальный контрольный набор:

• главная;
• основные разделы;
• страницы услуг;
• категории;
• карточки товаров;
• статьи;
• контакты;
• формы;
• страницы пагинации;
• фильтры;
• страница 404;
• страницы входа и личного кабинета.

Сохраните исходные показатели

До исправлений зафиксируйте:

• число индексируемых страниц;
• число исключённых URL;
• поисковый трафик;
• показы и клики;
• среднее время ответа;
• показатели Core Web Vitals;
• количество ошибок 4xx и 5xx;
• число страниц в Sitemap;
• количество страниц, найденных краулером.

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

Шаг 1. Проверьте доступность сайта

Начните с того, может ли пользователь и поисковый робот получить страницы.

Проверьте основной URL

Основная страница должна:

• открываться по HTTPS;
• возвращать код 200;
• не требовать авторизации;
• не содержать случайный noindex;
• не быть закрыта в robots.txt;
• не перенаправляться через длинную цепочку;
• загружать основные стили и скрипты.

Проверьте варианты домена

Все альтернативные варианты должны вести на один основной адрес:

• http://example.ru;
• http://www.example.ru;
• https://www.example.ru;
• https://example.ru.

Выберите канонический вариант и настройте прямой постоянный редирект с остальных. Желательно избегать цепочки, в которой HTTP сначала переходит на HTTPS с www, а затем ещё раз на адрес без www.

Проверьте сертификат

• сертификат действует;
• соответствует домену;
• полная цепочка установлена;
• нет смешанного контента;
• HTTP перенаправляется на HTTPS;
• страницы не вызывают предупреждение браузера.

Проверьте тестовые версии

Тестовый сайт не должен индексироваться. Надёжнее закрывать его авторизацией, а не только robots.txt.

Проверьте:

• stage-домен;
• старую версию сайта;
• копии на технических поддоменах;
• IP-адрес сервера;
• временные каталоги;
• демонстрационные версии.

Шаг 2. Проверьте состояние индексации

Индексация — это не просто наличие страницы в поиске. Необходимо понять, какие URL поисковая система знает, сканирует, считает каноническими и допускает к показу.

Google Search Console

Используйте:

• отчёт об индексировании страниц;
• проверку конкретного URL;
• отчёт Sitemap;
• статистику сканирования;
• ручные меры;
• проблемы безопасности.

Яндекс Вебмастер

Проверьте:

• страницы в поиске;
• исключённые страницы;
• статус URL;
• диагностику сайта;
• статистику обхода;
• файлы Sitemap;
• анализ robots.txt;
• проблемы безопасности.

Не используйте оператор site: как точный счётчик

Запрос site:example.ru полезен для быстрого просмотра выдачи, поиска странных страниц и проверки сниппетов. Но число результатов нельзя считать точным количеством проиндексированных URL.

Сравните несколько наборов

Сопоставьте:

• страницы, которые должны индексироваться;
• URL в Sitemap;
• страницы, найденные краулером;
• URL, известные Google;
• страницы в поиске Яндекса;
• страницы с поисковым трафиком.

Несовпадение наборов помогает найти:

• сиротские страницы;
• устаревшие URL;
• дубли;
• технические параметры;
• страницы с ошибочным noindex;
• страницы, не включённые в навигацию;
• удалённые материалы, которые продолжают сканироваться.

Шаг 3. Проверьте robots.txt

Файл robots.txt сообщает роботам, какие URL разрешено или запрещено запрашивать. Он не является универсальным средством удаления страниц из поисковой выдачи.

Что проверить

• файл доступен по адресу /robots.txt;
• возвращает код 200;
• не перенаправляется без необходимости;
• кодировка и синтаксис корректны;
• нет случайного Disallow: /;
• не закрыты стили и скрипты, необходимые для рендеринга;
• не закрыты основные разделы;
• указан актуальный Sitemap;
• правила соответствуют текущей структуре;
• нет ссылок на старый домен.

Минимальный пример

User-agent: *
Disallow: /manager/
Disallow: /search/
Disallow: /cart/
Sitemap: https://example.ru/sitemap.xml

Этот пример нельзя копировать без проверки путей. Каталог административной панели, корзины и поиска зависит от конкретной CMS.

Robots.txt и noindex решают разные задачи

Если страница закрыта в robots.txt, робот может не получить её HTML и не увидеть noindex или canonical.

Выберите средство по цели:

Не публикуйте секретные пути в robots.txt

Файл открыт всем. Запись Disallow: /secret-backup/ не защищает архив, а сообщает его адрес любому посетителю.

Шаг 4. Проверьте Sitemap.xml

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

В Sitemap должны находиться

• канонические URL;
• страницы с кодом 200;
• индексируемые материалы;
• актуальные страницы;
• адреса основного домена;
• приоритетные типы контента.

В Sitemap не должны находиться

• редиректы;
• 404 и 410;
• страницы с noindex;
• дубли;
• технические параметры;
• случайные фильтры;
• служебные страницы;
• результаты поиска;
• административные URL;
• страницы другого домена.

Проверьте lastmod

Дата изменения должна отражать реальное существенное обновление страницы. Ежедневная подстановка текущей даты для всех URL не делает страницы свежее, зато делает поле бесполезным.

Большие сайты

Для большого проекта удобнее создавать индекс Sitemap и отдельные файлы:

• страницы;
• статьи;
• товары;
• категории;
• изображения;
• видео;
• языковые версии.

Сравните Sitemap с краулером

Так обнаруживаются:

• URL в карте, на которые нет ссылок;
• страницы сайта, отсутствующие в карте;
• старые адреса;
• редиректы;
• неканонические страницы;
• ошибки генератора.

Шаг 5. Выполните полный обход сайта

Запустите краулер с главной страницы и разрешите ему пройти по внутренним ссылкам.

Соберите минимум следующие данные

• URL;
• код ответа;
• тип содержимого;
• title;
• description;
• H1;
• canonical;
• robots meta;
• размер страницы;
• глубину;
• число входящих ссылок;
• число исходящих ссылок;
• время ответа;
• язык;
• hreflang;
• данные пагинации;
• структурированные данные.

Проведите два обхода

Для JavaScript-сайта полезно сравнить:

• обычный HTML-обход;
• обход с рендерингом JavaScript.

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

Не делайте вывод только по одной выборке

Отдельно проверьте:

• страницы из Sitemap;
• URL из Search Console;
• страницы с трафиком;
• страницы из серверных логов;
• старые адреса;
• параметрические URL.

Шаг 6. Проверьте коды ответа

Проверьте soft 404

Soft 404 возникает, когда страница фактически сообщает об отсутствии содержимого, но сервер возвращает код 200.

Примеры:

• пустая карточка товара с текстом «товар не найден»;
• страница ошибки с кодом 200;
• невалидный маршрут SPA;
• пустой результат фильтра без полезной информации;
• массовый редирект удалённых страниц на главную.

404 не является катастрофой

Нормальный сайт имеет 404 для несуществующих адресов. Проблемой становятся:

• внутренние ссылки на 404;
• массовая потеря важных страниц;
• ошибки после миграции;
• 404 в Sitemap;
• внешние ссылки на URL, для которого существует замена;
• неправильный код страницы ошибки.

Шаг 7. Проверьте редиректы

Найдите цепочки

старый URL
→ HTTP
→ HTTPS с www
→ HTTPS без www
→ новый URL

Настройте прямой переход на конечный адрес.

Найдите циклы

/page-a
→ /page-b
→ /page-a

Цикл делает страницу недоступной.

Проверьте соответствие назначения

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

Проверьте внутренние ссылки

Даже при рабочем редиректе внутренние ссылки следует обновить на конечный URL. Иначе робот и пользователь постоянно проходят лишний переход.

Не используйте редирект для временной маскировки ошибки

Если страницы никогда не существовало и замены нет, верните 404. Массовое перенаправление всего неизвестного трафика на главную затрудняет диагностику и создаёт soft 404.

Шаг 8. Проверьте canonical

Canonical указывает предпочтительный адрес среди одинаковых или близких страниц.

Проверьте наличие self-canonical

На канонической странице допустима ссылка на саму себя:

<link
    rel="canonical"
    href="https://example.ru/services/audit.html"
>

Найдите ошибки

• canonical ведёт на 404;
• canonical ведёт через редирект;
• указан HTTP вместо HTTPS;
• указан тестовый домен;
• в Sitemap находится другой URL;
• страница закрыта в robots.txt;
• разные страницы канонизируются на одну без сходства содержимого;
• canonical формируется из текущего URL вместе с UTM-метками;
• языковая страница указывает на другой язык;
• страница пагинации указывает на первую страницу.

Canonical не является абсолютной командой

Если внутренние ссылки, Sitemap, редиректы и содержимое противоречат canonical, поисковая система может выбрать другой адрес.

Когда лучше редирект

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

Шаг 9. Найдите дубли

Технические дубли

• HTTP и HTTPS;
• www и адрес без www;
• слэш и отсутствие слэша;
• верхний и нижний регистр;
• index.php и корневой URL;
• UTM-параметры;
• сортировки;
• идентификаторы сессий;
• версии для печати;
• разные пути к одному документу.

Содержательные дубли

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

Не оценивайте дубли по проценту уникальности

Универсального требования «изменить текст на 30%» не существует. Нужно оценивать, решает ли страница самостоятельную задачу и имеет ли уникальную ценность.

Варианты решения

• объединить страницы;
• настроить редирект;
• указать canonical;
• добавить noindex;
• изменить поисковый интент;
• расширить содержание;
• удалить лишнюю таксономию;
• ограничить создание параметрических URL.

Шаг 10. Проверьте URL и параметры

URL должны быть стабильными и единообразными.

Проверьте

• использование HTTPS;
• нижний регистр;
• понятные слова;
• единое правило слэшей;
• отсутствие сессионных идентификаторов;
• отсутствие случайных параметров;
• стабильность адресов;
• соответствие структуры сайта;
• правильное кодирование символов.

Параметры

Разделите параметры на группы:

• аналитические: utm_source;
• сортировка: sort=price;
• фильтры;
• пагинация;
• состояние интерфейса;
• идентификаторы сессий;
• служебные параметры.

Для каждой группы определите:

• создаётся ли отдельный URL;
• должен ли он индексироваться;
• какой canonical используется;
• попадает ли адрес в Sitemap;
• есть ли на него внутренние ссылки;
• не создаёт ли он бесконечные комбинации.

Шаг 11. Проверьте фильтры и фасетную навигацию

Фильтры способны создать тысячи и миллионы URL.

Индексируемый фильтр оправдан, если

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

Технические комбинации

Для неценных сочетаний можно:

• не создавать crawlable-URL;
• использовать noindex;
• ограничить обход;
• указывать canonical для настоящих дублей;
• не добавлять URL в Sitemap;
• не размещать ссылки на все комбинации;
• использовать Clean-param для Яндекса в подходящих случаях.

Не закрывайте все фильтры одинаково. Среди них могут находиться полезные посадочные страницы.

Шаг 12. Проверьте пагинацию

Страницы пагинации должны иметь отдельные URL и доступные обычные ссылки.

Пример:

/blog/?page=2
/blog/?page=3

Проверьте

• каждая страница открывается по собственному URL;
• следующая страница доступна через <a href>;
• элементы не повторяются хаотично;
• сортировка стабильна;
• пустые номера возвращают корректный код;
• canonical указывает на текущую страницу;
• первая страница не создаёт дубль с ?page=1;
• бесконечная прокрутка имеет доступную URL-пагинацию.

Не канонизируйте все страницы пагинации на первую: они содержат разные наборы элементов.

Шаг 13. Проверьте внутреннюю перелинковку

По внутренним ссылкам поисковые роботы находят страницы и понимают отношения между ними.

Найдите сиротские страницы

Сравните URL из Sitemap, CMS и поисковых панелей со страницами, найденными краулером. Документ, на который не ведут внутренние ссылки, слабо связан с сайтом.

Проверьте глубину

Важно не механическое правило трёх кликов, а доступность приоритетных страниц.

Проверьте:

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

Проверьте анкоры

Текст ссылки должен объяснять назначение страницы.

Полезный вариант:

<a href="/blog/seo/semantic-core.html">
    сбор семантического ядра
</a>

Менее информативный:

<a href="/blog/seo/semantic-core.html">
    читать далее
</a>

Проверьте ссылки внутри шаблонов

• логотип;
• меню;
• хлебные крошки;
• карточки;
• похожие материалы;
• футер;
• CTA;
• ссылки в тексте.

Шаг 14. Проверьте title, description и заголовки

Title

Проверьте:

• наличие;
• уникальность;
• соответствие странице;
• отсутствие шаблонных дублей;
• корректную длину;
• отсутствие перечисления запросов;
• отсутствие случайных технических значений.

Для данного проекта title контролируется в диапазоне 50–60 символов.

Description

Проверьте:

• уникальность;
• соответствие содержанию;
• понятное описание пользы;
• отсутствие одинакового шаблона;
• отсутствие кавычек и переменных, ломающих HTML.

Для данного проекта используется диапазон 140–160 символов.

H1

На странице должен быть один основной H1. В текущей архитектуре проекта он выводится из menutitle, а при его отсутствии — из title.

Проверьте:

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

H2–H3

Подзаголовки должны формировать логическую структуру. Не используйте заголовочный тег исключительно ради размера текста.

Шаг 15. Проверьте мобильную версию

Основное содержимое и ссылки должны быть доступны на мобильном устройстве.

Проверьте содержимое

• H1 присутствует;
• текст не урезан;
• метаданные совпадают;
• canonical не меняется;
• структурированные данные присутствуют;
• внутренние ссылки доступны;
• изображения имеют alt;
• формы работают.

Проверьте интерфейс

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

Не задавайте универсальный минимальный размер шрифта

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

Шаг 16. Проверьте JavaScript-рендеринг

Если содержимое загружается через JavaScript, проверьте исходный и отрендеренный HTML.

Поисковому роботу должны быть доступны

• основной текст;
• title;
• description;
• H1;
• canonical;
• robots meta;
• ссылки;
• изображения;
• структурированные данные.

Проверьте прямое открытие маршрута

Любой индексируемый URL должен корректно открываться после ввода в адресную строку или обновления страницы.

Проверьте коды ответа SPA

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

Ссылки должны иметь href

Навигация вида:

<div onclick="openPage('/services/')">
    Услуги
</div>

хуже обычной ссылки:

<a href="/services/">
    Услуги
</a>

Шаг 17. Проверьте скорость и Core Web Vitals

Текущие Core Web Vitals включают:

Оценка проводится по 75-му процентилю пользовательских сессий отдельно для мобильных и компьютерных устройств.

Полевые и лабораторные данные

PageSpeed Insights может показывать:

• полевые данные реальных пользователей;
• лабораторный тест Lighthouse.

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

Если полевых данных нет

Это не обязательно ошибка. Страница или группа страниц могла не накопить достаточный объём пользовательских данных. Используйте лабораторные измерения и собственную аналитику производительности.

Проверьте TTFB

Высокое время ответа сервера ухудшает загрузку всей страницы.

Причины:

• медленные SQL-запросы;
• отсутствие кэширования;
• перегруженный сервер;
• внешние API;
• длинные PHP-операции;
• неподходящая конфигурация PHP-FPM;
• удалённый origin;
• цепочка редиректов.

Оптимизация LCP

• уменьшить время сервера;
• не загружать главное изображение лениво;
• указать размеры изображения;
• использовать WebP или AVIF;
• предварительно загрузить критический ресурс, если это обосновано;
• сократить блокирующие стили;
• не скрывать LCP-элемент до выполнения JavaScript.

Оптимизация INP

• сократить длинные задачи JavaScript;
• разделить тяжёлые вычисления;
• уменьшить количество сторонних скриптов;
• обработать события без лишнего DOM;
• отложить некритичную работу;
• проверить меню, формы, фильтры и модальные окна.

Оптимизация CLS

• задавать размеры изображений;
• резервировать место для рекламы и виджетов;
• не вставлять блоки выше уже загруженного содержимого;
• правильно загружать шрифты;
• избегать позднего изменения высоты компонентов;
• стабилизировать сообщения форм.

Шаг 18. Проверьте изображения

Изображения влияют на скорость, доступность и отображение в поиске.

Проверьте

• файл существует;
• возвращает код 200;
• размер соответствует отображению;
• используется современный формат;
• указаны width и height;
• содержательное изображение имеет alt;
• декоративное изображение не получает бессмысленный alt;
• главное изображение не загружается лениво;
• остальные изображения используют lazy loading осознанно;
• нет изображений весом в несколько мегабайт;
• нет дублирующих файлов разных размеров;
• URL стабилен.

Alt не является полем для списка запросов

Он должен кратко описывать смысл изображения в контексте страницы.

Шаг 19. Проверьте CSS, JavaScript и шрифты

CSS

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

JavaScript

• некритичные скрипты используют defer или загружаются позже;
• нет повторного подключения библиотек;
• сторонние виджеты обоснованы;
• ошибки отсутствуют в консоли;
• скрипты не блокируют основной интерфейс;
• отслеживание событий не отправляется дважды.

Шрифты

• используются только нужные начертания;
• формат оптимизирован;
• настроен font-display;
• локальные файлы кэшируются;
• нет длинной цепочки внешних запросов;
• замена шрифта не вызывает сильное смещение.

Шаг 20. Проверьте микроразметку

Структурированные данные помогают поисковым системам понимать сущности и тип страницы. Они не гарантируют расширенный результат.

Часто используемые типы

• Organization;
• LocalBusiness;
• BreadcrumbList;
• Article;
• BlogPosting;
• Product;
• Offer;
• VideoObject;
• JobPosting.

Проверьте соответствие содержанию

Разметка должна совпадать с тем, что видит пользователь:

• название;
• цена;
• наличие;
• автор;
• дата;
• изображение;
• рейтинг;
• адрес;
• вопросы и ответы.

Проверьте валидаторами

• Rich Results Test;
• валидатор микроразметки Яндекса;
• проверка отрендеренного HTML;
• отчёты Search Console.

FAQ

Если на странице используется FAQ-разметка, вопросы и ответы должны быть доступны посетителю. Не добавляйте скрытые ответы, отсутствующие в интерфейсе.

Шаг 21. Проверьте hreflang

Этот этап нужен для многоязычных и мультирегиональных сайтов.

Проверьте

• каждая версия имеет отдельный URL;
• коды языка и региона корректны;
• ссылки взаимны;
• используются абсолютные URL;
• canonical указывает на текущую языковую версию;
• страницы являются аналогами;
• нет ссылок на редиректы и ошибки;
• при необходимости указан x-default;
• hreflang совпадает в HTML и Sitemap.

Шаг 22. Проверьте безопасность и техническое доверие

Технический SEO-аудит не заменяет аудит безопасности, но явные проблемы необходимо зафиксировать.

Проверьте

• HTTPS;
• срок сертификата;
• смешанный контент;
• доступность административной панели;
• отсутствие резервных копий в web-root;
• отсутствие индексируемых тестовых страниц;
• отсутствие секретов в HTML;
• актуальность CMS;
• наличие вредоносных перенаправлений;
• отчёты поисковых систем о безопасности;
• корректные cookie-флаги;
• защитные HTTP-заголовки.

HSTS

Включайте HSTS только после полной проверки HTTPS на основном домене и поддоменах. Ошибочная настройка способна сделать часть сайта недоступной.

Шаг 23. Проверьте серверные логи

Логи показывают фактический обход, а не только теоретическую структуру.

С помощью логов можно узнать

• какие URL запрашивают роботы;
• как часто обходятся важные страницы;
• сканируются ли параметры;
• какие коды ответа получают роботы;
• есть ли длинные цепочки;
• какие страницы отвечают медленно;
• возникают ли 5xx;
• продолжается ли обход старых URL;
• тратится ли ресурс на бесконечные фильтры.

Проверяйте подлинность роботов

Один User-Agent недостаточен: злоумышленник может назвать себя Googlebot или YandexBot. Для серьёзного анализа проверяйте IP и обратную DNS-запись по правилам поисковой системы.

Шаг 24. Проверьте поисковые шаблоны

Ошибка шаблона затрагивает сразу множество страниц.

Проверяйте выборку для каждого типа:

• главная;
• раздел;
• услуга;
• рубрика;
• статья;
• категория;
• товар;
• пагинация;
• фильтр;
• страница поиска;
• 404.

Для каждого шаблона проверьте

• title;
• description;
• H1;
• canonical;
• robots;
• хлебные крошки;
• микроразметку;
• внутренние ссылки;
• изображение;
• коды ответа;
• мобильную версию.

Шаг 25. Проверьте аналитику

Ошибки аналитики не влияют напрямую на обход, но мешают оценивать результат.

Проверьте

• один счётчик Метрики;
• один Google tag;
• отсутствие дублирующих контейнеров;
• отслеживание успешной отправки формы;
• исключение внутреннего трафика;
• корректные UTM-метки;
• события кликов по телефону;
• электронную торговлю;
• переходы между доменами;
• согласия на аналитику;
• отсутствие персональных данных в событиях.

Как приоритизировать найденные ошибки

Критический приоритет

• сайт закрыт от индексации;
• основные страницы возвращают 5xx;
• HTTPS не работает;
• канонический домен настроен неправильно;
• после миграции отсутствуют редиректы;
• страницы услуг имеют noindex;
• обнаружено заражение;
• важные страницы возвращают 404;
• робот не может получить основной контент.

Высокий приоритет

• массовые дубли;
• неправильные canonical;
• сиротские страницы;
• цепочки редиректов;
• серьёзные проблемы мобильной версии;
• очень медленный сервер;
• массовые soft 404;
• неуправляемые фильтры;
• ошибки шаблона title или H1.

Средний приоритет

• дубли description;
• неоптимальные изображения;
• слабая перелинковка;
• неполная микроразметка;
• лишние страницы в Sitemap;
• неудачные анкоры;
• неиспользуемые CSS и JavaScript.

Низкий приоритет

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

Как составить отчёт

Типичные ошибки самостоятельного аудита

Ориентация только на автоматический сервис

Инструмент находит технические признаки, но не знает бизнес-ценность страницы и поисковый интент.

Попытка исправить все предупреждения

Не каждое предупреждение требует работы. Приоритет зависит от влияния и масштаба.

Использование site: как точной статистики

Оператор подходит для ручного просмотра, но не заменяет отчёты поисковых систем.

Закрытие страниц одновременно в robots.txt и noindex

Робот может не увидеть noindex.

Canonical на главную для всех дублей

Каноническая страница должна быть содержательно близким аналогом.

Перенаправление всех 404 на главную

Так появляются soft 404 и теряется смысл старых адресов.

Оценка скорости только по баллу Lighthouse

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

Исправление title без проверки интента

Механическое добавление ключевой фразы не решает проблему неподходящей страницы.

Игнорирование шаблонов

Исправление одной страницы не поможет, если ошибка создаётся общим шаблоном.

Отсутствие повторного обхода

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

Финальный чек-лист технического аудита

• Основной домен определён.
• HTTP перенаправляется на HTTPS.
• Варианты www обрабатываются единообразно.
• Сертификат действителен.
• Тестовые сайты защищены.
• Главная возвращает 200.
• Основные разделы доступны роботам.
• robots.txt возвращает 200.
• В robots.txt нет случайных запретов.
• Sitemap доступен и валиден.
• В Sitemap находятся только канонические URL.
• В Sitemap нет 404, noindex и редиректов.
• Проведён полный обход сайта.
• Найдены и исправлены внутренние 404.
• Нет циклов редиректов.
• Цепочки редиректов сокращены.
• Страница ошибки возвращает 404.
• Удалённые страницы возвращают 404, 410 или подходящий редирект.
• Canonical ведёт на страницу с кодом 200.
• Canonical согласован с Sitemap.
• Технические дубли устранены.
• Параметры классифицированы.
• Фильтры не создают бесконечные URL.
• Пагинация доступна через ссылки.
• Страницы пагинации имеют собственный canonical.
• Нет сиротских страниц.
• Важные страницы получают внутренние ссылки.
• Title уникальны.
• Description заполнены и уникальны.
• На каждой странице один H1.
• Структура H2–H3 логична.
• Мобильная версия содержит основной контент.
• Нет горизонтальной прокрутки.
• Мобильное меню работает.
• JavaScript-страницы открываются по прямому URL.
• Несуществующие маршруты возвращают 404.
• Проверены LCP, INP и CLS.
• Проверены полевые и лабораторные данные.
• Главные изображения оптимизированы.
• У изображений заданы размеры.
• CSS и JavaScript не дублируются.
• В консоли нет критических ошибок.
• Микроразметка соответствует содержанию.
• Микроразметка прошла проверку.
• Hreflang настроен взаимно.
• Нет смешанного контента.
• CMS и расширения обновлены.
• Проверены серверные логи.
• Аналитические счётчики не дублируются.
• Составлен план исправлений.
• После изменений проведён повторный аудит.

Вывод

Самостоятельный технический аудит следует начинать с доступности и индексации, а не с попытки получить сто баллов в PageSpeed Insights. Сначала необходимо убедиться, что поисковые роботы могут найти нужные страницы, получить корректный ответ и понять предпочтительный URL.

После этого проверяются служебные файлы, коды ответа, редиректы, canonical, дубли, фильтры, пагинация и внутренняя перелинковка. Затем можно переходить к мобильной версии, JavaScript-рендерингу, Core Web Vitals, изображениям и микроразметке.

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

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