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

Что вы получите из статьи:

• чек-лист из 15 проверок с точными порогами "норма/не норма"
• расшифровку метрик скорости LCP, INP, CLS человеческим языком
• список бесплатных инструментов вместо платного софта
• порядок починки, если времени на всё не хватает

Из практики: применить можно за один вечер, 1-2 часа на базовый прогон, экономит деньги на платном аудите и зависимость от подрядчика "на слово".

Короткий ответ: технический аудит сайта - это проверка того, что мешает поисковикам показывать сайт, а посетителям - оставить заявку, по списку из 15 пунктов. Базовый прогон своими руками занимает один вечер, 1-2 часа, и не требует программиста: почти все инструменты бесплатны. По оценкам практиков (блог Toolfox), полный ручной технический аудит с расширенным охватом для сайта до 100 страниц занимает 8-15 часов - самостоятельный чек-лист ниже сокращает это время, потому что закрывает только критичное, а не 50 пунктов подряд.

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

Каждую неделю разбираем в блоге, как устроено SEO и техническая часть сайтов - реальные пороги, инструменты, ошибки. Подпишитесь на блог ARTGK, чтобы не пропустить новые чек-листы.

Что такое технический аудит сайта простыми словами?

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

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

Какие инструменты нужны и сколько это стоит?

Коротко: покупать ничего не нужно. Яндекс.Вебмастер, Google Search Console и PageSpeed Insights бесплатны без ограничений, а краулер Screaming Frog SEO Spider бесплатен до 500 URL - платная версия за $279 в год нужна только сайтам с большим количеством страниц. Бесплатных инструментов хватает почти для всех 15 пунктов чек-листа ниже.

Для сайта малого и среднего бизнеса лимита в 500 URL хватает почти всегда: если у вас каталог на несколько тысяч товаров - тогда платная версия оправдана, но начинайте с бесплатной. Из 15 проверок ниже платный краулер пригодится только для трёх пунктов - поиска битых ссылок, дублей заголовков и цепочек редиректов - и только на сайтах крупнее 500 страниц.

Если сайт стоит на 1С-Битрикс, часть проверок (скорость, дубли, редиректы) завязана на настройки самой платформы - подробнее об этом в разделе про дубли ниже.

Как проверить, есть ли сайт в поиске?

Коротко: откройте вкладки «Ошибки» и «Рекомендации» в разделе «Диагностика сайта» Яндекс.Вебмастера - самые серьёзные из перечисленных там проблем могут означать, что сайт частично или полностью исключён из поиска. В Google Search Console то же самое показывает отчёт индексирования страниц (Page Indexing): он прямо называет причину исключения - страница закрыта в robots.txt, стоит запрет noindex, сервер отвечает ошибкой или страница просто "просканирована, но не в индексе".

На форуме searchengines.guru регулярно всплывает одна и та же ситуация: сайт выпал из индексации, а владелец не понимает, с чего начать восстановление. Часто причина оказывается банальной. Участник разбора такого случая, форумчанин Дмитрий Удимов, прямо указал автору на находку: «У вас даже тупо нет Robots.txt... отдает 404» - то есть сайт годами жил без базовой технической гигиены, и никто не проверял её до момента исчезновения из поиска.

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

Как проверить robots.txt и sitemap.xml без программиста?

Коротко: наберите в браузере адрес вашего сайта плюс /robots.txt и плюс /sitemap.xml. Оба файла должны открываться и отвечать кодом 200; типовая ошибка - директива Disallow: / целиком, которая закрывает от поисковика весь сайт разом, а не одну служебную папку. Sitemap должен укладываться в лимит 50 000 адресов и 50 мегабайт на файл - лимит одинаковый и у Google, и у Яндекса.

Правила протокола sitemap жёсткие: по спецификации sitemaps.org, один файл карты сайта не может содержать больше 50 000 адресов и весить больше 50 мегабайт в несжатом виде - это общий стандарт, а не рекомендация конкретного поисковика. Если у сайта страниц больше, карта разбивается на несколько файлов с общим индексом.

С robots.txt у Google свои технические ограничения: файл кэшируется до 24 часов, а сам поисковик, по официальной документации, учитывает не более 500 кибибайт содержимого файла. Если файл отдаёт ошибку сервера вместо нормального ответа, первые 12 часов Google вообще перестаёт обходить сайт, а до 30 дней использует последнюю сохранённую копию файла. У Яндекса лимит почти такой же: справка Вебмастера прямо требует, чтобы «размер файла не превышал 500 КБ» и чтобы сервер отвечал кодом 200 OK. Практический вывод: robots.txt - прямой рычаг влияния на то, что вообще увидит поисковик.

Как проверить скорость сайта и что считать нормой?

Коротко: вставьте адрес сайта в PageSpeed Insights и смотрите на три метрики - LCP, INP, CLS. Норма Google: LCP не больше 2,5 секунды, INP не больше 200 миллисекунд, CLS не больше 0,1; итоговый балл 90 и выше - хорошо, от 50 до 89 - нужно улучшать, ниже 50 - плохо.

Расшифровка метрик человеческим языком: LCP - это сколько секунд посетитель ждёт, пока прогрузится основной контент страницы. INP - насколько быстро сайт реагирует на клик или нажатие. CLS - не "прыгает" ли вёрстка во время загрузки, когда кнопка вдруг съезжает под палец в момент нажатия. Официальная документация Google задаёт оба порога именно в таком виде: LCP должен укладываться в 2,5 секунды с начала загрузки страницы, а отзывчивость (INP) - в 200 миллисекунд или меньше.

Важный нюанс: PageSpeed Insights показывает два разных набора цифр - лабораторный балл (симуляция на одном устройстве) и полевые данные (реальные визиты из Chrome). Оценивать нужно именно полевые данные по 75-му перцентилю реальных загрузок отдельно для мобильных и десктопных посетителей - лабораторный балл 90 не гарантирует, что у живых пользователей всё так же быстро.

Почему мобильная версия важнее десктопной?

Коротко: Google индексирует и ранжирует сайт по мобильной версии, а не по десктопной - «Google uses the mobile version of a site's content, crawled with the smartphone agent, for indexing and ranking». Красивый десктоп ничего не гарантирует, если с телефона сайт разъезжается.

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

У Яндекса есть встроенный инструмент «Проверка мобильных страниц» с чётким порогом провала: сайт не признаётся оптимизированным для мобильных, если «удалось загрузить менее 90% запрошенных для проверки страниц». То есть Яндекс тестирует целую выборку страниц по сайту - если у десятой части мобильная версия не загружается, весь сайт помечается как не готовый к мобильным.

HTTPS, битые ссылки и дубли: три проверки на технические ошибки

Коротко: проверьте, что в адресной строке горит замок с валидным сертификатом, что на сайте нет неработающих ссылок, и что сайт открывается только по одному адресу - без параллельного дублирования www и без-www, http и https. Каждая из трёх проверок занимает по 5-10 минут и не требует специальных знаний.

HTTPS проверяется визуально - в браузере и через встроенный сертификат, срок действия которого не истёк. Битые ссылки и дубли ищет краулер вроде Screaming Frog SEO Spider - бесплатная версия сканирует до 500 адресов, чего малому и среднему сайту обычно достаточно. Дубли по адресу (сайт открывается и по www.site.ru, и по site.ru одновременно, как две разные страницы) - частая находка на сайтах после переезда или смены платформы; лечится постоянным редиректом 301 на единственный правильный вариант.

Один битый или потерянный внешний редирект способен ощутимо ударить по авторитету сайта в глазах поисковика. В разборе блога Ahrefs один правильно настроенный редирект вернул сайту 1800flowers.com 225 ссылок с 59 разных сайтов - то есть починка редиректов возвращает не только посетителей, но и накопленный вес ссылок.

Отдельная ловушка для сайтов на 1С-Битрикс: платформа "из коробки" создаёт дубли по адресу вида site.ru/page/ и site.ru/page/index.php - для поисковика это две разные страницы с одинаковым содержимым. Разборы на Хабре и в блоге Intervolga подтверждают: без ручной настройки эти дубли не исчезают сами, для них нужен 301-редирект в .htaccess, константа BX_DISABLE_INDEX_PAGE или тег canonical. Если сайт на Битриксе никогда не проверяли на этот тип дублей - подробности в статье «Техническая поддержка сайта на Битрикс».

Доходят ли заявки: проверка форм, о которой все забывают

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

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

Юридическая сторона форм - согласие на обработку данных, cookie-баннер, политика конфиденциальности - отдельная большая тема: подробный чек-лист есть в статье «Как проверить сайт на 152-ФЗ». Здесь фокус только на том, доходит ли заявка технически.

Всё, что разобрано выше и ниже - ручная версия базовых проверок. Наш собственный сервис автоматического аудита бесплатно и без регистрации прогоняет 8 критичных пунктов - HTTPS, robots.txt, sitemap, Title, description, H1, скорость и мобильную адаптацию - за минуту и отдаёт оценку от 0 до 100 со списком проблем по приоритету. Форму заявки и статистику посещений он не проверяет - это остаётся на вашей ручной части чек-листа.

Чек-лист: 15 проверок по шагам

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

1. Сайт отдаёт код ответа 200, а не ошибку сервера - откройте главную страницу в браузере в режиме инкогнито.
2. Во вкладках «Ошибки» и «Рекомендации» раздела «Диагностика сайта» Яндекс.Вебмастера нет серьёзных проблем.
3. Страницы сайта в индексе - отчёт Page Indexing в Google Search Console показывает, сколько страниц проиндексировано, а сколько исключено и почему.
4. robots.txt открывается по адресу /robots.txt и не закрывает сайт директивой Disallow: / целиком.
5. sitemap.xml открывается по адресу /sitemap.xml, укладывается в лимит 50 000 адресов и 50 мегабайт.
6. HTTPS работает без предупреждений браузера и без "смешанного контента" (часть ресурсов страницы загружается по http вместо https).
7. Скорость по порогам Core Web Vitals: LCP не больше 2,5 секунды, INP не больше 200 миллисекунд, CLS не больше 0,1 - проверка через PageSpeed Insights.
8. Мобильная версия открывается и читается без масштабирования - проверка с собственного телефона.
9. Битых ссылок и страниц с ошибкой 404 внутри сайта нет - проверка краулером вроде Screaming Frog.
10. Сайт открывается по одному адресу без дублей www/без-www и http/https.
11. Редиректы работают напрямую, без цепочек из нескольких перенаправлений подряд.
12. Title и description уникальны для каждой страницы, без массовых дублей на разных URL.
13. На каждой странице ровно один тег H1, а не два и не ноль.
14. Тестовая заявка через форму сайта реально доходит - до почты, CRM или мессенджера, куда она должна прийти.
15. Счётчик аналитики (Яндекс.Метрика или аналог) установлен на всех страницах - откройте отчёт по визитам за сегодня и убедитесь, что цифра не нулевая.

Что чинить первым, если времени мало?

Коротко: сначала фатальное - сайт недоступен, закрыт в robots.txt целиком, нет HTTPS. Затем критичное - скорость, мобильная адаптация, битые ссылки. И только потом - мета-теги и остальные мелочи. Если поменять порядок местами и сначала полировать мета-теги при недоступном сайте, эффекта не будет вообще: поисковик физически не увидит правки, пока не пройдёт первые два уровня.

Влад Андрюхин из PR-CY формулирует этот принцип прямо: «Быстрее всего дают эффект технические правки. Доступность, SSL, коды ответа, дубли, robots.txt и sitemap.xml напрямую влияют на обход и попадание страниц в поиск». Схожей логики придерживается и Patrick Stox из блога Ahrefs: страницы должны быть доступны для обхода и индексации хотя бы для того, чтобы у них в принципе был шанс попасть в выдачу. А дальше усилия эффективнее вкладывать в контент и ссылки, чем бесконечно полировать уже рабочую техническую базу.

Ручная проверка или автоматический аудит: что выбрать?

Коротко: вопрос не "или-или", а "с чего начать". Автоматический аудит сайта за минуту снимает базовый срез по 8 критичным пунктам, а полный технический аудит руками по 15 пунктам из этой статьи дополнительно проверяет то, что автоматика физически не видит - формы, реальные заявки, аналитику. Удобная связка: сначала автоматика, потом руками добираете остальное.

Честно: автоматический аудит не видит форму заявки и не проверяет, доходят ли реально обращения до вашей почты или CRM, - пункты 14 и 15 чек-листа остаются только за ручной проверкой. Остальные 13 пунктов он закрывает частично: даёт быстрый срез по 8 критичным из них, а более тонкие детали (например, все ли страницы сайта без битых ссылок, а не только главная) всё равно требуют ручного прогона краулером.

Как часто повторять аудит и что делать с найденными ошибками?

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

Влад Андрюхин описывает этот цикл так: «После исправлений важно запустить перепроверку. Отмечайте «Я все исправил» в Диагностике сайта и отправляйте измененные URL на переобход». Без этого шага правки могут неделями ждать, пока поисковик их заметит сам: справка Яндекс.Вебмастера прямо указывает срок - «робот придет в течение двух недель» после отправки страницы на переобход.

Анастасия Курдюкова, руководитель группы оптимизаторов «Ашманов и партнёры»: «Базовую проверку необходимо проводить регулярно - сканировать сайт на предмет 404 ошибок, лишних редиректов, дублей страниц. Также необходимо мониторить Яндекс Вебмастер и Google Search Console, чтобы видеть, какие страницы попадают или выпадают из индекса».

Если чинить руками найденное некому, есть два пути: разово - разобраться, что вообще входит в постоянное сопровождение сайта, в статье «Сопровождение сайта: что это» и что входит в помесячное обслуживание - в статье «Обслуживание сайта: что входит и сколько стоит». Если сайт уже отдан подрядчику, а результата не видно - отдельный чек-лист «работает или делает вид» есть в статье «Как проверить SEO-подрядчика».

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

Источники

• Google, web.dev, «Core Web Vitals»
• Google, «PageSpeed Insights - о шкале и данных»
• Google, «Спецификация robots.txt»
• Sitemaps.org, «Протокол sitemap»
• Google, «Mobile-first indexing»
• Блог Яндекса для вебмастеров, «Диагностика сайтов»
• Яндекс, справка Вебмастера, «Требования к robots.txt»
• Яндекс, справка Вебмастера, «Диагностика ошибок сайта»
• Яндекс, справка Вебмастера, «Проверка мобильных страниц»
• Screaming Frog, «SEO Spider»
• Ahrefs, Patrick Stox, «Technical SEO»
• PR-CY, Влад Андрюхин, «Топ ошибок в Яндекс.Вебмастере»
• Ашманов и партнёры, «Технический аудит сайта»
• Intervolga, «Как убрать дубли страниц в 1С-Битрикс»
• searchengines.guru, форум, «Где провести аудит сайта»

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