Технический SEO-аудит сайта: что проверить самостоятельно
Технический аудит сайта помогает найти препятствия, из-за которых поисковик не получает нужные страницы, а посетитель не может нормально пользоваться ресурсом. Его результат — понятная очередь исправлений с доказательствами и критериями проверки. Список предупреждений из сервиса становится полезным только после того, как вы связали каждую находку с конкретной страницей, её назначением и масштабом проблемы.
Ниже — последовательный чек-лист для самостоятельной проверки: от доступности и индексации до скорости, мобильной версии и оформления результатов поиска. Он подходит для первого разбора сайта и подготовки задачи разработчику. Примеры адресов на example.com условные; приведённая таблица отчёта не является результатом проверки какого-либо реального проекта.
Что такое технический аудит сайта и какой результат нужен
Технический SEO-аудит — проверка того, как сайт отдаёт страницы, позволяет обнаруживать их и передаёт поисковым системам содержимое и настройки. Он не заменяет исследование спроса, качество предложения и работу с текстами. Исправная страница может не отвечать запросу покупателя, а полезный материал — оставаться недоступным из-за ошибочного запрета. Эти ситуации требуют разных решений.
Сразу разделяйте четыре состояния: адрес известен поисковику, робот его обошёл, содержимое проиндексировано, страница показывается по конкретным запросам. Одно не доказывает другое. Google описывает эти этапы в руководстве о работе поиска и не гарантирует индексирование даже при соблюдении технических требований.
Для бизнеса полезный итог выглядит конкретно: «ключевые услуги закрыты noindex в шаблоне; нужно изменить правило и проверить выбранные URL». Формулировка «SEO-оценка низкая» не объясняет, что исправлять. В отчёте должны быть подтверждённые факты, отдельные гипотезы, приоритеты, ответственные и способ приёмки. Рост трафика оценивают позднее вместе с другими изменениями, сезонностью и спросом.
Как определить объём: страницы, шаблоны и источники URL
Начните с цели проверки: запуск нового раздела, снижение посещаемости, смена CMS, переезд или регулярный контроль. Затем выпишите важные пользовательские задачи: найти услугу, сравнить товары, узнать условия, отправить заявку. Это поможет выбрать страницы, сбой которых действительно влияет на работу сайта.
Составьте выборку по типам: главная, категория, карточка, услуга, статья, контакты, форма и её подтверждение. Добавьте новую и старую страницу, вложенный адрес, пагинацию, фильтры и версии на других языках, если они есть. Одна удачно открытая главная не характеризует весь каталог. Запишите, какие шаблоны проверены и какие пока остались за пределами аудита.
| Источник адресов | Что даёт | Что может пропустить |
|---|---|---|
| CMS и перечень опубликованных материалов | Страницы, которыми управляет команда | Технические варианты URL и старые маршруты |
| Sitemap | Адреса, заявленные как важные для поиска | Забытые страницы и неучтённые копии |
| Обход по ссылкам | Доступную структуру и связи между страницами | Сиротские URL, закрытые области и часть динамических переходов |
| Google Search Console и Яндекс Вебмастер | Известные поисковикам URL, причины исключения и историю | Новые изменения, которые ещё не обработаны |
| Журналы сервера, если доступны | Фактические обращения к адресам за выбранный период | Страницы, к которым за этот период никто не обращался |
Объединяйте источники, сохраняя точные адреса и происхождение каждой записи. Не удаляйте все параметры автоматически: они могут обозначать другой товар или страницу списка. Отдельно фиксируйте предполагаемые дубли. Сиротской может оказаться важная посадочная страница, которая существует в CMS, но не находится при обходе от главной.
Перед массовым сканированием своего сайта согласуйте нагрузку и границы: домены, поддомены, параметры, глубину и объём обхода. Бесконечные календари и комбинации фильтров способны расширить очередь без пользы. Для первого разбора часто разумнее начать с представительной выборки, а затем расширить проверку найденного шаблонного дефекта.
Инструменты для самостоятельного технического SEO-аудита
Не требуется сразу покупать большой набор сервисов. Начните с инструментов, которые дают разные виды доказательств, и не смешивайте их результаты. Внешний анализатор видит публичный ответ, кабинет поисковика — обработанные им данные, а панель CMS — намерение владельца. Эти сведения могут различаться по времени и охвату.
| Инструмент | Для какой задачи | Как читать результат |
|---|---|---|
| Браузер и инструменты разработчика | Переходы, HTML, сеть, мобильное отображение | Показывают текущую загрузку в конкретных условиях |
| Google Search Console | Состояние индексирования, проверка URL и сообщения | Отделяйте сохранённые данные от текущего теста |
| Яндекс Вебмастер | Диагностика сайта, страницы в поиске и проверки URL | Сверяйте дату данных и применимость предупреждения |
| PageSpeed Insights | Полевые показатели и лабораторная диагностика скорости | Не объединяйте разные режимы в один вывод |
| Сканер сайта, например Screaming Frog SEO Spider | Массовая проверка ссылок и технических полей | Результат ограничен настройками, режимом и доступными URL |
Для проверок собственного ресурса подключите подтверждённые кабинеты поисковых систем. В Яндексе начните с «Оптимизация сайта → Диагностика сайта → Ошибки». Название ошибки помогает выбрать направление, но не заменяет проверку конкретного адреса. При нехватке доступа отметьте ограничение в отчёте вместо предположения, что проблем нет.
Онлайн-проверка сайта на ошибки удобна для первичного обзора публичных страниц. Не передавайте в открытые формы ссылки с секретными токенами и приватные документы. Бесплатный режим сканера может ограничивать объём или отдельные функции: фиксируйте фактический охват, не называя неполную выгрузку аудитом всего сайта. Цены и лимиты лучше проверять перед выбором инструмента.
Первый этап: доступность и правила индексирования
Сначала разберите препятствия, которые мешают получить нужный материал. Улучшение описаний и значков не устранит ошибку сервера или случайный запрет целого раздела. Используйте точные URL из выборки и сохраняйте дату, условия и результат каждого наблюдения.
HTTPS, ответы сервера и конечная страница
Откройте важные страницы без входа в CMS. Проверьте HTTPS, соответствие сертификата имени сайта, отсутствие предупреждений и загрузку необходимых ресурсов. Посмотрите фактический HTTP-статус и всю цепочку перенаправлений. Ответ 200 не доказывает успех, если вместо услуги показаны пустой шаблон, ошибка или форма входа.
Разделяйте отсутствующий материал с 404/410, временные серверные ошибки, ограничение запросов и отказ доступа. Не удаляйте ссылки на работающие страницы только потому, что сканер получил 403. Для поисковой доступности важны ответ, содержимое и возможность обхода; минимальные условия собраны в технических требованиях Google.
Robots.txt, noindex и приватные разделы
Сопоставьте назначение страницы с ограничениями: публичная услуга должна быть доступна индексированию, а кабинет — защищён от неавторизованного доступа. Проверьте robots.txt, метатеги robots и HTTP-заголовки, включая правила, добавляемые CMS, сервером или CDN. Опасная ошибка шаблона может затронуть много страниц одновременно.
Не снимайте все запреты ради увеличения числа URL в поиске. Robots.txt управляет обходом, noindex — участием страницы в поиске, авторизация — доступом к данным. Если обход закрыт, робот может не прочитать noindex. Эти различия объясняет руководство Google для разработчиков. Приватный материал нельзя открывать только ради SEO-проверки.
Состояние URL и Sitemap
Для важных адресов изучите причины исключения и дату последнего обхода. В проверке URL Search Console сохранённая версия и live-тест отвечают на разные вопросы. Текущий тест не подтверждает обновление индекса и не определяет выбранный Google canonical. В Яндексе сравните свои ожидания с отчётом «Страницы в поиске».
Проверьте, что Sitemap доступен, читается и содержит актуальные адреса, предназначенные для поиска. Найденные редиректы, ошибки и исключённые URL разберите по причине. Карта сайта помогает обнаружению страниц, но не является приказом индексировать каждую из них. Число записей в ней не должно автоматически совпадать с числом результатов поиска.
Второй этап: адреса, дубли и внутренняя навигация
После проверки доступа выясните, как разные маршруты связаны с содержимым. Задача — сохранить самостоятельные полезные страницы и правильно объединить настоящие копии. Механическое сокращение числа URL может убрать нужные категории и посадочные страницы.
Canonical, параметры и редиректы
Сравните основную версию материала с адресами с метками, печатными вариантами и альтернативными путями. Заявленный canonical должен вести на содержательно соответствующую доступную страницу. Проверьте цели редиректов, цепочки, циклы и внутренние ссылки на промежуточные адреса. Не направляйте разные товары или всю пагинацию на первую страницу каталога.
Canonical — рекомендация о представителе дублей, а не перенаправление посетителя. При реальном переносе нужна отдельная карта соответствий. Для подробного разбора используйте руководство Google по каноническим URL. В аудите зафиксируйте ожидаемую цель, фактическое значение и причину расхождения, а не только отметку о наличии тега.
Ссылки, глубина и сиротские страницы
Пройдите от главной к важной услуге или товару через обычную навигацию. Проверьте меню, хлебные крошки, карточки, подборки и пагинацию. Важен понятный путь пользователя; универсального числа кликов, после которого любая страница становится ошибкой, здесь недостаточно. Сопоставьте обход со списком CMS, чтобы заметить потерянные из навигации материалы.
Переходы должны иметь доступные поисковику адреса: Google описывает обычные ссылки с href и осмысленным анкором. Для битой ссылки сохраняйте и назначение, и страницу-источник. Исправлять нужно место, откуда человек попадает в ошибку. Отдельно проверьте якоря разделов: HTTP 200 не подтверждает существование нужного идентификатора внутри страницы.
Третий этап: мобильная версия, JavaScript и содержимое
Проверьте важные действия на телефоне или в подходящем режиме браузера: меню, фильтр, выбор товара, форму и переход к контактам. Посмотрите, не перекрывает ли баннер основной текст и не появляется ли горизонтальная прокрутка. При этом визуальное удобство и возможность поискового робота получить содержимое оценивайте отдельно.
Что получает мобильный робот
Google использует мобильную версию содержимого для индексирования. Сравните основные тексты, ссылки и метаданные на мобильной и настольной версиях; различаться может оформление. В рекомендациях Google по мобильному индексированию отдельно указана доступность ресурсов и контента, который не требует клика или другого пользовательского действия для загрузки.
У сайта с JavaScript сравните исходный ответ и результат отрисовки: есть ли название, описание, товары и ссылки, не заменяется ли материал общей заглушкой. Успешный просмотр в вашем авторизованном браузере не доказывает, что тот же документ получил поисковый инструмент. Если данные расходятся, передайте разработчику точный URL и условия, при которых исчезает содержимое.
Title, description, заголовки и изображения
Проверьте, что заголовок страницы и description описывают именно этот материал, а шаблон не подставляет одно название во все карточки. Длина поля сама по себе не показывает его полезность. Просмотрите основной видимый заголовок и структуру разделов: пользователь должен понимать тему и находить нужный ответ. Не сводите аудит заголовков к счётчику H1.
Для содержательных изображений оцените уместное текстовое описание; декоративные элементы не нужно набивать ключевыми словами. Проверьте, загружаются ли важные иллюстрации, заданы ли размеры блоков и работают ли ссылки-картинки. Затем выполните ключевое действие: отправьте согласованную тестовую заявку или проверьте путь покупки без реальной оплаты. Факт срабатывания формы и запись события аналитики фиксируйте отдельно: наличие кнопки не подтверждает получение обращения.
Скорость: как оценить Core Web Vitals без погони за баллом
Выберите несколько характерных шаблонов и проверьте мобильный и настольный режимы отдельно. Не переносите результат лёгкой главной на карточку с галереей или тяжёлый каталог. В PageSpeed Insights есть полевые данные CrUX о реальном опыте и лабораторная проверка в моделируемых условиях. Последняя удобна для поиска причин, но не описывает все реальные устройства и действия.
| Показатель | Что характеризует | Ориентир хорошего результата |
|---|---|---|
| LCP | Появление крупнейшего видимого элемента основного содержимого | Не более 2,5 секунды |
| INP | Отзывчивость страницы на взаимодействия | Не более 200 миллисекунд |
| CLS | Неожиданные смещения элементов | Не более 0,1 |
Эти пороги приведены в документации Web Vitals; оценка опирается на 75-й процентиль, отдельно для мобильных и настольных устройств. Обычный загрузочный тест Lighthouse не измеряет полевой INP: лабораторный TBT помогает диагностике, но не является его заменой. Общий зелёный балл также не гарантирует удобства всех сценариев.
Полевые показатели PSI отражают предыдущий 28-дневный период. Проверьте, относится ли результат к конкретной странице или к origin — группе страниц с одинаковыми протоколом, именем хоста и портом. Когда данных недостаточно, это ограничение выборки, а не доказательство идеальной скорости. После правки лабораторный результат может измениться сразу, а полевые сведения ещё будут включать прежние посещения.
В отчёте запишите URL, устройство, режим, дату и воспроизводимый симптом. Например, сдвиг кнопки после появления баннера — полезная задача для разработчика. Указание «сделать 100 баллов» не определяет причину, объём работ и то, какое действие посетителя должно стать удобнее.
Микроразметка, favicon и языковые версии
Когда основные страницы доступны и содержимое корректно, проверьте представление сайта. Структурированные данные должны описывать фактический материал и подходить выбранному типу страницы. Сравните разметку с видимыми ценами, названиями и другими сведениями. Для углубления есть руководство Google по структурированным данным. Успешная проверка не гарантирует расширенный результат.
Для favicon проверьте файл, объявление на главной и доступность поисковому роботу. Значок во вкладке браузера и значок в выдаче обновляются разными механизмами; отсутствие одного не доказывает неисправность другого. Требования к поисковому варианту собраны в документации Google о favicon. В обзорном аудите достаточно зафиксировать этап, на котором обнаружено расхождение.
Если есть языковые или региональные версии, включите их в выборку. Проверьте соответствие языка основного текста, адресов, canonical и связей hreflang. Не объединяйте полноценные переводы в один URL автоматически. Правила взаимных ссылок между вариантами описаны в руководстве Google по локализованным страницам; для одноязычного сайта этот пункт может быть неприменим.
Проверьте сообщения о безопасности и нарушениях
В Search Console изучите отчёт о проблемах безопасности и отдельно меры, принятые вручную. Первый касается обнаруженных опасных состояний, второй — нарушений правил поиска, установленных проверкой. Не считайте любое снижение трафика доказательством санкции.
Сопоставьте сообщения с уведомлениями Яндекс Вебмастера и наблюдаемым поведением сайта. При обнаружении посторонних страниц, подозрительных перенаправлений или предупреждений передайте сведения ответственному за безопасность. SEO-аудит не заменяет поиск причины взлома и восстановление защиты. Отсутствие сообщений в кабинетах также не гарантирует безопасность ресурса.
Как расставить приоритеты и оформить пример технического аудита
Оценивайте находку по трём вопросам: какую важную задачу она нарушает, сколько страниц затрагивает и насколько уверенно подтверждена причина. Ошибка общего шаблона услуг обычно требует большего внимания, чем единичное неточное описание старой статьи. Однако масштаб сначала нужно проверить: похожие URL не доказывают одинаковую неисправность.
Разделите подтверждённый факт и гипотезу. «В ответе страницы присутствует noindex» — наблюдение. «Его добавляет SEO-плагин» — гипотеза, пока источник правила не найден. Исполнитель должен видеть, какую часть вывода уже доказали и какую ещё предстоит проверить. Не объединяйте несколько несвязанных причин в задачу «исправить индексацию».
Ниже — учебный пример отчёта. Короткие пути относятся к условному https://example.com; значения показывают структуру записи, а не реальные замеры. Приоритеты здесь относительные: П1 — существенное препятствие, П2 — важное исправление, П3 — плановая доработка.
| URL и факт | Доказательство | Охват | Влияние | Приоритет | Действие | Критерий приёмки |
|---|---|---|---|---|---|---|
/services/repair/: случайный noindex | HTML и заголовки выбранной страницы | Шаблон услуг; границы уточнить | Препятствие участию нужных услуг в поиске | П1 | Найти источник и исправить правило | Нужные URL открыты, служебные исключения сохранены |
Ссылка из подвала на /old-guide/ ведёт к 404 | Источник, href и ответ конечного адреса | Общий подвал | Посетитель не получает инструкцию | П2 | Указать актуальную соответствующую инструкцию | Переход работает на разных шаблонах |
/articles/check/: общий title вместо названия материала | Фактический HTML | Проверить другие статьи | Непонятное представление содержания | П3 | Исправить генерацию названия | Title соответствует каждой проверенной статье |
К рабочей таблице добавьте ответственного, зависимость от других задач, дату выпуска и статус. Для большого шаблонного дефекта достаточно объяснить правило и приложить репрезентативные примеры, сохранив полную выгрузку отдельно. Не заставляйте разработчика угадывать адреса по обрезанным скриншотам и пересобирать доказательства с нуля.
Как передать задачи и проверить исправления
До изменения согласуйте ожидаемое поведение и способ возврата прежней конфигурации. Исправление должно решать установленную причину. Массовое удаление страниц, закрытие раздела или перенаправление всех ошибок на главную нельзя считать автоматическим ответом на большой список предупреждений.
- Проверьте тот же набор URL. Сохраните сопоставимые условия и добавьте соседние страницы, которые изменение не должно затронуть.
- Повторите пользовательский путь. Убедитесь, что навигация, форма, скачивание и мобильное действие работают после публикации.
- Подтвердите фактический ответ. Кэш или другой серверный слой может продолжать отдавать старые значения.
- Разделите техническую и поисковую приёмку. Правильный текущий ответ не означает, что поисковик уже обработал изменение.
- Сохраните историю. Дата, изменённый компонент, доказательство и ответственный помогут разобраться при повторении проблемы.
Статус «разработчик исправил» заменяйте результатом проверки. Для индексирования следите за свежими данными обхода и причинами включения или исключения. Для скорости сравнивайте одинаковые режимы и учитывайте период полевых данных. Для аналитики проверяйте саму запись события, а не только сообщение об успешной отправке формы.
С чего начать самостоятельно и когда привлекать специалиста
Первый проход можно построить так: определить важные страницы, проверить доступность и кабинеты поисковиков, затем пройти пользовательские маршруты и собрать подтверждённые проблемы. После этого расширяйте проверку каждого затронутого шаблона. Такой порядок помогает получить пригодный для работы список даже без глубокого знания серверной конфигурации.
Специалист нужен, когда расходятся ответы для пользователей и роботов, есть сложная JavaScript-отрисовка, много вариантов URL, нестабильные серверные ошибки или требуется массовое изменение правил. Передайте ему цель, выборку, ограничения доступа и доказательства. Это позволяет оценить именно вашу задачу, а не обсуждать абстрактный «полный аудит» без границ.
После исправлений назначьте повторные проверки при важных изменениях: запуске раздела, обновлении CMS, смене шаблона, переезде и изменении каталога. Периодичность регулярного контроля выбирайте по частоте публикаций и цене сбоя. Один отчёт описывает состояние на момент проверки и не заменяет последующее наблюдение.
Частые вопросы о техническом аудите сайта
Можно ли провести технический аудит сайта онлайн бесплатно?
Значительную часть первичной проверки можно выполнить через браузер, кабинеты поисковых систем и PageSpeed Insights. Бесплатность инструмента не определяет полноту результата. Важно понимать его охват и вручную проверить находки, влияющие на нужные пользователю страницы.
Нужно ли исправлять все предупреждения сканера?
Каждое предупреждение нужно оценить, но не каждое требует изменения. Удалённая страница без замены может правильно отдавать 404, а ожидаемый дубль — не участвовать в поиске отдельно. Решение принимают по назначению URL и фактическому поведению.
Почему в поиске меньше страниц, чем в Sitemap?
Sitemap сообщает об адресах, которые вы считаете важными. Он не гарантирует их обработку и показ. Разберите причины по группам: дубли, ограничения, недавние публикации, содержание и технические ошибки. Простое увеличение числа URL в карте не исправляет эти причины.
Достаточно ли высокого балла PageSpeed Insights?
Нет. Отдельно нужны работающие пользовательские сценарии, корректная индексация и доступное содержимое. В оценке скорости учитывайте полевые показатели, шаблон страницы и устройство. Один лабораторный запуск не описывает весь сайт.
Должен ли аудит гарантировать рост заявок?
Он помогает найти и устранить технические препятствия. Число заявок зависит также от спроса, предложения, трафика и работы аналитики. В задаче по аудиту фиксируйте проверяемые технические результаты; коммерческий эффект оценивайте на данных после внедрения.
После технического аудита сохраните список важных страниц и включите их в регулярный контроль доступности. Познакомьтесь с SiteGuard и оцените возможности мониторинга для своего проекта. Назначьте ответственного за сигналы о сбоях и повторяйте проверки после обновления CMS, шаблонов и настроек сервера.