Технический аудит сайта своими руками: 20 проверок за вечер

Технический аудит сайта своими руками занимает 3-4 часа и обходится без платных сервисов: хватает Яндекс Вебмастера, curl и Screaming Frog в бесплатном лимите на 500 адресов. Двадцать проверок закрывают доступность, индексацию, дубли, содержание страниц и скорость. Результат оформляется таблицей находок с приоритетами: адрес, симптом, что чинить, срок.

Статья для владельца сайта на WordPress, Битриксе или Тильде, который получил счёт за аудит на 30 000 рублей и хочет сначала понять, что там вообще проверяют. Ниже двадцать проверок с командами, порогами и признаками нормы. Аудита семантики, конкурентов и юзабилити тут нет: это другие работы и другая методика.

Чек-лист технического аудита сайта и схема структуры страниц

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

Чем технический аудит отличается от других аудитов

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

Коммерческий аудит смотрит на цены, карточки товара, условия доставки и кнопки заказа. Аудит юзабилити разбирает путь человека до заявки. Контентный работает с текстами и семантикой. С техническим они пересекаются в паре пунктов (скорость мешает и роботу, и человеку), но методика у каждого своя.

Смысл разделения практический. Когда подрядчик присылает «комплексный аудит» на 60 страниц, где вперемешку скриншоты редиректов и рассуждения про цвет кнопки, проверить его работу нельзя. Технический аудит проверяется: находка либо воспроизводится командой в терминале, либо не находка.

Что понадобится

Четыре инструмента, все бесплатные.

Яндекс Вебмастер. Индексация, ошибки обхода, дубли, статус зеркал. Нужны подтверждённые права на сайт.
curl. Коды ответа, редиректы, заголовки, тайминги. В macOS и Linux стоит из коробки, в Windows вызывается как curl.exe из PowerShell.
Screaming Frog SEO Spider. Бесплатная версия обходит 500 адресов. Визитке и корпоративному сайту хватает с запасом, магазину на 5 000 товаров нет.
PageSpeed Insights. Скорость и Core Web Vitals по данным реальных пользователей.

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

Доступность: проверки 1-5

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

Проверка 1. Коды ответа ключевых страниц

Главная, две-три внутренние, контакты, страница услуги. Нормальный ответ один: 200. Всё прочее разбираем.

curl -sI https://example.ru/ -o /dev/null -w "%{http_code} %{time_total}n"
curl -sI https://example.ru/uslugi/ -o /dev/null -w "%{http_code} %{time_total}n"

Что означают частые коды: 301 постоянный редирект (нормально, если ведёт куда надо), 302 временный (для переезда навсегда это ошибка), 403 сервер запретил доступ, 500 упало приложение, 504 сервер не дождался ответа от бэкенда.

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

Проверка 2. Склейка зеркал

Сайт обязан открываться по одному адресу. Четыре варианта (http, https, с www, без www) сводятся к одному 301-редиректом, а не отдают 200 каждый.

for u in http://example.ru https://example.ru http://www.example.ru https://www.example.ru; do
  echo -n "$u -> "
  curl -sI -o /dev/null -w "%{http_code} %{redirect_url}n" "$u"
done

Правильная картинка: три строки с 301 и одна с 200. Если 200 приходит с двух разных адресов, у поисковика два сайта с одинаковым контентом.

Отдельно проверяю цепочки. Бывает так: http://www ведёт на https://www, тот на https без www. Два прыжка вместо одного. Работает, но каждая ступень это лишние миллисекунды и лишний шанс потерять путь по дороге.

Проверка 3. Сертификат и смешанный контент

Срок действия, полнота цепочки, отсутствие http-ресурсов на https-странице.

echo | openssl s_client -connect example.ru:443 -servername example.ru 2>/dev/null | openssl x509 -noout -dates -issuer

Смешанный контент ищется в консоли браузера (F12, вкладка Console) по предупреждениям «Mixed Content». Обычно это картинки со старого адреса и виджет, подключённый по http ещё в 2019 году.

Проверка 4. Несуществующая страница отдаёт 404

Классика жанра: на выдуманный адрес сайт показывает главную с кодом 200. Робот делает вывод, что страниц с одинаковым содержимым у вас бесконечно много.

curl -sI https://example.ru/etoy-stranicy-net-12345 -o /dev/null -w "%{http_code}n"

Ждём 404 или 410. Пришло 200 или 302 на главную, значит перед вами soft 404, и это чинят в первую очередь.

Проверка 5. Ошибки сервера за месяц

В Вебмастере разделы «Диагностика» и «Статистика обхода» показывают, сколько раз робот получил 5xx. Единичные всплески бывают у всех, регулярные означают, что сервер не тянет нагрузку.

Если есть доступ к логам, считаю руками:

awk '{print $9}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head

Доля 5xx выше половины процента от всех запросов это повод идти к хостеру или менять тариф.

Индексация: проверки 6-10

Проверка 6. robots.txt

Открываем https://example.ru/robots.txt и читаем целиком, а не по диагонали. Ищем три вещи: нет ли Disallow: / для всех роботов, есть ли строка Sitemap: с полным адресом, не закрыты ли заодно нужные разделы.

Самая дорогая ошибка, которую я видел: сайт переехал с тестового домена вместе с robots.txt, где стояло Disallow: /. Три недели этого никто не замечал, трафик уполз в ноль. Рабочий файл и типовые ошибки разобраны в статье про robots.txt для WordPress.

curl -s https://example.ru/robots.txt | head -30

Проверка 7. sitemap.xml

Карта отдаёт 200, содержит только страницы с кодом 200 и не содержит адресов, закрытых в robots.txt.

curl -s https://example.ru/sitemap.xml | grep -c "<loc>"

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

Проверка 8. noindex в мете и в заголовках

Тег meta robots видно через просмотр кода страницы. А вот заголовок X-Robots-Tag не видно вообще, и это любимое место, где прячется noindex после переезда со staging.

curl -sI https://example.ru/uslugi/ | grep -i "x-robots-tag"

Пустой ответ это хорошо. Строка X-Robots-Tag: noindex объясняет, почему страница не появляется в выдаче, сколько бы вы ни жали кнопку переобхода.

Проверка 9. Страницы в поиске против страниц на сайте

В Вебмастере раздел «Индексирование», пункт «Страницы в поиске». Берём число и сравниваем с количеством строк в sitemap.

В поиске меньше, чем в карте: часть страниц не проиндексирована, идём в «Исключённые страницы» читать причины.
В поиске больше: в индекс попал мусор, обычно адреса с параметрами и служебные разделы.
Совпало: редкость, но случается.

Раздел «Исключённые» полезнее всех остальных вместе взятых. Там прямым текстом написано, почему страница выпала: дубль, недостаточно качественная, ошибка при обходе, запрет в robots.

Проверка 10. Скорость и глубина обхода

«Статистика обхода» показывает, сколько страниц робот скачивает в сутки. Если на сайте 300 страниц, а робот берёт пять, новые материалы будут появляться в поиске месяцами. Причина почти всегда в скорости ответа сервера: робот сам снижает темп, когда сайт отвечает медленно.

Дубли и мусорные адреса: проверки 11-13

Дубли это то, из-за чего у сайта на 50 страниц в индексе оказывается 4 000 адресов.

Проверка 11. Адреса с параметрами

utm-метки, сортировки, фильтры, идентификаторы сессий. Каждый параметр рождает новый адрес с тем же содержимым.

Проверяется руками. Открываем https://example.ru/?test=1 и смотрим, отдаётся ли 200 и та же самая страница. Отдаётся почти всегда. Дальше вопрос в том, закрыты ли такие адреса тегом rel=canonical и директивой Clean-param в robots.txt.

Clean-param: utm_source&utm_medium&utm_campaign&yclid&gclid

Как искать дубли системно, я разбирал отдельно: дубли страниц и способы их найти.

Проверка 12. Слэш, регистр и технические адреса

Четыре пары, которые должны сводиться к одному адресу:

/uslugi и /uslugi/
/Uslugi/ и /uslugi/
/index.php и /
/?p=123 и /blog/statya/

Инструмент тот же, curl с выводом кода. Ждём 301 на канонический вариант. Код 200 на обоих адресах это дубль, который поисковик считает двумя страницами.

Проверка 13. Дубли title и h1

Быстрый способ найти дубли содержимого, не выкачивая сайт целиком: прогнать Screaming Frog и открыть вкладки Page Titles и H1 с фильтром Duplicate. Если у двадцати страниц одинаковый title «Главная», у вас либо не заполнен шаблон, либо страницы действительно повторяют друг друга.

То же самое в Вебмастере лежит в «Диагностике», пункт про отсутствующие и дублирующиеся теги.

Содержание страниц: проверки 14-17

Проверка 14. title и description

Смотрю пустые, дублирующиеся и обрезанные. Ориентиры: title до 60-70 символов, description 120-160. Это не правило поисковика, а ширина сниппета в выдаче. Длиннее не запрещено, просто не покажется.

Красный флаг, который встречается через раз: title вида «Главная | Мой сайт» и description, автоматически собранный из первых строк текста вместе с хлебными крошками.

Проверка 15. Заголовки h1 и h2

Один h1 на страницу, он есть везде и не повторяет title дословно. Заголовки h2 расставлены по смыслу, а не потому, что шрифт покрупнее. Пустые и множественные h1 Screaming Frog показывает в один клик, вкладка H1.

Проверка 16. Битые ссылки и цепочки редиректов

Screaming Frog, вкладка Response Codes, фильтр Client Error 4xx. Смотрю на битый адрес и сразу на колонку Inlinks: откуда на него ведут ссылки. Чинить надо источник, иначе через месяц всё вернётся. Что делать с найденным, расписано в разборе про битые ссылки и 404.

Рядом лежит вкладка Redirect Chains. Это внутренние ссылки на адрес, который редиректит куда-то дальше. Робот пройдёт, но потратит бюджет обхода на пустое место.

Проверка 17. Сироты, тонкие страницы и alt

Страница-сирота это страница без единой внутренней ссылки на неё. Робот попадает туда только из карты сайта, вес она не получает. В Screaming Frog видно по нулю в колонке Inlinks.

Тонкая страница: меньше 300 слов при том, что страница претендует на поисковый запрос. Карточка контакта на 40 слов это нормально, страница услуги на 40 слов нет.

Про alt отдельная оговорка. Заполнять его надо там, где картинка несёт смысл. У иконки рядом с видимой подписью alt оставляют пустым намеренно, иначе скринридер читает подпись дважды. Автоматические аудиторы вроде Labrika считают это предупреждением, и это как раз тот счётчик, который в ноль не выводят.

Скорость и мобильная версия: проверки 18-20

Проверка 18. TTFB и вес страницы

TTFB это время до первого байта: сколько сервер думает перед ответом. Меряется тем же curl, только с полным набором таймингов.

curl -s -o /dev/null -w "dns %{time_namelookup} connect %{time_connect} ttfb %{time_starttransfer} total %{time_total}n" https://example.ru/

Вес страницы смотрю в браузере: F12, вкладка Network, перезагрузка, строка transferred внизу. Для визитки норма до 2 МБ, для магазина до 3. Всё, что тяжелее, обычно объясняется одной картинкой на 4 МБ, которую загрузили с телефона прямо в медиатеку.

Проверка 19. Core Web Vitals

Пороги, по которым метрика считается хорошей:

Метрика	Хорошо	Терпимо	Плохо
LCP, отрисовка главного элемента	до 2,5 с	2,5-4 с	больше 4 с
INP, отклик на действие	до 200 мс	200-500 мс	больше 500 мс
CLS, сдвиг вёрстки	до 0,1	0,1-0,25	больше 0,25
TTFB, ответ сервера	до 0,8 с	0,8-1,8 с	больше 1,8 с

Важный момент про PageSpeed Insights. В отчёте две части: сверху данные реальных пользователей за 28 дней, снизу лабораторный прогон на эмуляторе слабого телефона. Ориентироваться надо на верхнюю. Цифра «34 балла» из лабораторной части пугает владельцев сильнее всего и при этом значит меньше всего. Что стоит за каждой метрикой, разобрано в статье про Core Web Vitals простыми словами.

Проверка 20. Мобильная версия

Ломается чаще всего в трёх местах: горизонтальный скролл, мелкие элементы управления и вьюпорт.

Вьюпорт проверяется в коде страницы. Там должен быть <meta name="viewport" content="width=device-width, initial-scale=1">. Без него мобильный браузер рисует десктопную ширину и ужимает её в три раза, а поисковик помечает страницу как неудобную для мобильных.

Горизонтальный скролл ловится в консоли одной строкой, она выведет элементы, вылезающие за экран:

[...document.querySelectorAll('*')].filter(el => el.getBoundingClientRect().right > document.documentElement.clientWidth)

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

Как оформить находки

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

Приоритет	Находка	Где	Что делать	Оценка
Критично	404-страница отдаёт код 200	весь сайт	поправить обработку в шаблоне 404	1 ч
Критично	https://www открывается без редиректа	зеркала	301 в .htaccess на основное зеркало	0,5 ч
Важно	1 240 адресов с utm в индексе	параметры	Clean-param плюс canonical	2 ч
Важно	18 битых внутренних ссылок	блог	правка ссылок в текстах	2 ч
Можно позже	пустые alt у 60 картинок каталога	каталог	заполнить в медиатеке	3 ч

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

Чек-лист готового отчёта:

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

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

По моему опыту, на среднем сайте малого бизнеса из двадцати проверок срабатывает 6-9, из них два-три критичных. Работы выходит на 8-15 часов.

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

Сколько стоит технический аудит сайта у подрядчика?

Ориентир на 2026 год: визитка 8 000-15 000 рублей, корпоративный сайт 15 000-35 000, интернет-магазин от 40 000. Разброс объясняется числом страниц и глубиной работы. Разовый прогон краулера с выгрузкой в Excel стоит дешевле, чем разбор логов сервера и проверка шаблонов руками. В абонентском обслуживании аудит обычно уже входит в тариф.

Можно ли обойтись бесплатными инструментами?

Для сайта до 500 страниц да. Яндекс Вебмастер, curl и бесплатная версия Screaming Frog закрывают все двадцать проверок из этой статьи без единого рубля. Платные сервисы нужны на объёмах: магазин на 20 000 карточек бесплатный краулер не обойдёт. А выгрузка позиций и разбор конкурентов это уже не технический аудит.

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

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

Что делать, если аудит нашёл сорок ошибок?

Чинить по приоритету, а не всё сразу. Сначала критичные: коды ответа, зеркала, случайный noindex, robots.txt. Это обычно два-три пункта и один рабочий день. Дальше по два-три пункта в неделю. Массовая правка за один заход опасна тем, что при поломке непонятно, какое именно изменение её вызвало.

С чего начать сегодня

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

Если результат не понравился или разбираться некогда, приходите. Аудит с таблицей находок и планом работ я делаю в рамках абонентского обслуживания: годовой тариф 35 000 рублей, помесячный от 15 000, либо отдельной задачей по смете. Разработки и редизайна тут нет: привожу в порядок то, что уже работает. А если сайт уже выпал из выдачи и счёт идёт на дни, напишите сразу, возьму в работу первым.