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

Марина С.

3 мин.

89

Дата публикации: 27.08.2026

Обновлено: 30.08.2026

Самостоятельный аудит сайта помогает понять, почему страницы плохо индексируются, загружаются медленно, получают мало переходов или не приводят посетителя к целевому действию. Для первичной проверки не обязательно сразу покупать сложные программы: многие проблемы можно найти с помощью браузера, систем веб-аналитики, Google Search Console, Яндекс Вебмастера и бесплатных валидаторов.

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

Что входит в самостоятельный аудит сайта

Базовую проверку удобно разделить на несколько направлений. Такой подход не даёт сосредоточиться только на SEO-тегах и пропустить техническую ошибку или неработающую форму.

• Техническая доступность: коды ответа, HTTPS, редиректы, дубли, robots.txt, sitemap.xml и канонические адреса.
• Индексация: какие страницы известны поисковым системам, какие исключены и по какой причине.
• Структура и ссылки: вложенность разделов, понятность URL, хлебные крошки, внутренние и внешние ссылки.
• Поисковая оптимизация страниц: Title, Description, H1, подзаголовки, соответствие поисковому намерению и отсутствие конкурирующих страниц.
• Контент: полнота ответа, достоверность, актуальность, авторство, таблицы, инструкции, изображения и другие полезные элементы.
• Скорость и мобильная версия: загрузка основного контента, отзывчивость интерфейса и стабильность макета.
• Удобство и коммерческие элементы: навигация, контакты, формы, условия работы, доверительные элементы и понятный следующий шаг.
• Аналитика: показы, клики, позиции, входы, конверсии и технические события.

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

Что подготовить перед проверкой

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

1. Соберите список действующих URL из CMS, sitemap.xml и отчётов поисковых систем.
2. Получите доступ только на чтение к Google Search Console, Яндекс Вебмастеру и системе веб-аналитики.
3. Зафиксируйте показы, клики, CTR, среднюю позицию, органические входы и целевые действия за выбранный период.
4. Отметьте даты релизов, смены шаблона, переезда, массовой правки метатегов и других изменений.
5. Сделайте резервную копию перед будущими техническими исправлениями. На этапе аудита ничего массово не меняйте.

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

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

Откройте сайт на компьютере и смартфоне, проверьте основные страницы и выполните тестовую отправку формы. Затем посмотрите HTTP-коды важных URL с помощью краулера, панели разработчика браузера или сервиса проверки ответа сервера.

Какие ответы сервера должны насторожить

• 200 — страница успешно открывается. Для действующей индексируемой страницы это обычный ответ.
• 301 или 308 — постоянное перенаправление. Оно уместно после смены адреса, но длинные цепочки редиректов нужно сокращать.
• 302 или 307 — временное перенаправление. Проверьте, действительно ли оно должно быть временным.
• 404 или 410 — страница не найдена или удалена. Исправьте внутренние ссылки, а для заменённого материала настройте перенаправление на наиболее близкий по смыслу адрес.
• 5xx — ошибка сервера. Повторяющиеся ответы этой группы требуют диагностики хостинга, приложения или базы данных.

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

Что проверить у HTTPS и зеркал

Все варианты адреса — с http и https, с www и без него, со слешем и без слеша — должны приводить к одному выбранному варианту. Сертификат должен быть действующим, а страница не должна загружать изображения, скрипты или стили по небезопасному протоколу.

Шаг 2. Проверьте robots.txt, sitemap.xml и индексацию

Файл robots.txt управляет обходом сайта, но не является надёжным способом удалить страницу из поиска. Если URL закрыт в robots.txt, поисковая система всё равно может узнать о нём по ссылкам. Для исключения обычной HTML-страницы используют доступную роботу директиву noindex, защиту авторизацией или удаление страницы — в зависимости от задачи. Подробные ограничения этого файла описаны в официальной документации Google.

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

Проверка карты сайта

В sitemap.xml включайте предпочтительные индексируемые URL с ответом 200. Не добавляйте страницы с редиректом, ошибкой, запретом индексации или дублирующим содержанием. Для адресов внутри самой карты сайта используются полные абсолютные URL. Дата lastmod должна меняться только после существенного обновления страницы, а не при каждом открытии или технической пересборке. Дополнительные требования содержатся в официальной справке Google по картам сайта.

Наличие URL в sitemap.xml помогает сообщить поисковой системе о странице, но не гарантирует её индексацию. Причину исключения нужно смотреть в Google Search Console и Яндекс Вебмастере.

Как проверить отдельную страницу

1. Введите точный URL в инструмент проверки страниц поисковой системы.
2. Сравните заявленный и выбранный поисковиком canonical.
3. Проверьте разрешение индексации, дату последнего обхода и обнаруженные ресурсы.
4. Запустите проверку опубликованной версии, если инструмент её поддерживает.
5. После исправления отправьте страницу на повторный обход, но не ожидайте немедленного появления в выдаче.

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

Шаг 3. Найдите дубли и выберите канонические адреса

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

Для каждой группы дублей определите один канонический адрес. Внутренние ссылки, sitemap.xml и тег rel="canonical" должны указывать на него согласованно. Если дубль не нужен посетителям, лучше устранить причину его появления или настроить постоянный редирект. Тег canonical — подсказка поисковой системе, а не гарантия выбора; способы его использования описаны в официальной документации Google.

Отдельно проверьте технические дубли главной страницы, URL с метками и адреса, которые CMS создаёт при размещении одного материала в нескольких разделах.

Шаг 4. Оцените структуру, URL и внутренние ссылки

Пользователь и поисковый робот должны добираться до важного материала по обычным HTML-ссылкам. Страница, которая есть только в sitemap.xml и не связана с разделами сайта, остаётся изолированной.

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

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

Шаг 5. Проверьте Title, Description, H1 и подзаголовки

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

Минимальная проверка одной страницы

1. Title точно описывает страницу, не повторяется на других URL и не состоит из перечня ключевых фраз.
2. Description кратко объясняет пользу страницы и не обещает того, чего в материале нет.
3. H1 размечен настоящим тегом <h1>, виден пользователю и обычно используется один раз.
4. H2 и H3 раскрывают последовательные смысловые части, а не служат декоративными строками.
5. Основной текст доступен в полученном или отрисованном HTML. JavaScript можно использовать для интерфейса, но важное содержание должно корректно отображаться для робота и пользователя.

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

Шаг 6. Сопоставьте страницы с поисковыми запросами

Выгрузите запросы и целевые страницы из Google Search Console и Яндекс Вебмастера. Для каждой важной темы определите одну основную страницу. Если по одному запросу показываются разные URL, проверьте, не конкурируют ли они друг с другом.

Смотрите не только на частотность, но и на намерение пользователя:

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

Информационную статью не стоит превращать в копию страницы услуги. Она должна решать самостоятельную задачу читателя, а коммерческая страница — объяснять состав работы, результат, сроки и условия заказа. Между ними можно поставить одну уместную внутреннюю ссылку.

Шаг 7. Проведите аудит содержания

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

Что оценивать в тексте

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

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

Шаг 8. Проверьте изображения и другие материалы

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

• Используйте современный формат, например WebP, и разумное сжатие без заметной потери качества.
• Задавайте фактические width и height, а адаптивное отображение обеспечивайте шаблоном сайта.
• Не фиксируйте высоту CSS так, чтобы картинка искажалась на узком экране.
• Заполняйте alt коротким описанием содержания и функции изображения. Для чисто декоративной картинки допустим пустой alt="".
• Не загружайте в alt список ключевых запросов.
• Не применяйте отложенную загрузку к основному изображению первого экрана; для материалов ниже первого экрана она обычно уместна.
• Проверьте читаемость текста на скриншотах со смартфона.

Шаг 9. Оцените скорость и мобильную версию

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

Для Core Web Vitals ориентиром «хорошо» на 75-м процентиле служат следующие значения. Актуальные определения и пороги необходимо сверять с официальной документацией web.dev.

• LCP не более 2,5 секунды — скорость появления основного содержимого;
• INP не более 200 миллисекунд — отзывчивость страницы на действия пользователя;
• CLS не более 0,1 — визуальная стабильность макета.

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

Шаг 10. Проверьте формы, доверие и измерение целей

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

На странице услуги или товара дополнительно проверьте:

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

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

Шаг 11. Проверьте структурированные данные

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

1. Определите подходящий тип: например, Article, Organization, BreadcrumbList, Product или другой тип по назначению страницы.
2. Сравните свойства разметки с видимым текстом, ценой, автором, датой и изображением.
3. Проверьте синтаксис в Schema Markup Validator.
4. Для поддерживаемых Google типов дополнительно используйте инструмент проверки расширенных результатов.
5. После публикации отслеживайте предупреждения и ошибки в панелях вебмастера.

Пошаговый чек-лист аудита сайта

Как оформить отчёт по аудиту сайта

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

1. ID и направление: например, TECH-014, «индексация».
2. Проблема: одно проверяемое утверждение без общих оценок.
3. Затронутые URL: один адрес, перечень или правило выбора страниц.
4. Доказательство: код ответа, скриншот, выгрузка, данные панели или фрагмент HTML.
5. Возможное влияние: что именно затрудняется — обход, понимание страницы, использование сайта или измерение результата.
6. Рекомендация: конкретное действие и ожидаемое состояние после исправления.
7. Приоритет: критический, высокий, средний или низкий с пояснением.
8. Ответственный и срок: кто исправляет и когда нужна повторная проверка.
9. Результат: дата внедрения, контрольный тест и изменение показателя.

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

Как оценить эффект после исправлений

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

Для рабочего журнала удобно делать контрольные срезы через 7, 28, 56 и 90 дней. Сравнивайте показы, клики, CTR, среднюю позицию, органические входы и конверсии. Учитывайте сезонность, обновления поисковых систем, рекламу, изменение спроса и другие работы на сайте.

Когда самостоятельной проверки недостаточно

Чек-лист помогает обнаружить типовые ошибки, но внешняя проверка не показывает всё. Без доступа к серверным журналам, аналитике, CRM, CMS и истории изменений нельзя надёжно оценить причины резкого падения трафика, массовых исключений из индекса, взлома или ошибок после переезда.

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

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