Когда ко мне в агентство приходит проект на продвижение, я первым делом смотрю не на тексты и не на ссылки, а на то, как сайт «дышит» с технической стороны. Технический аудит — это не формальность и не повод собрать сотню скриншотов для отчёта. Это базовая диагностика, без которой любое SEO рискует упереться в невидимую стену. Если поисковик не может нормально проиндексировать страницы, если сайт тормозит, плодит дубли или разваливается на мобильных — даже идеально собранная семантика и крутой контент не вытянут проект. Поэтому аудит делают до старта активного продвижения, а не когда трафик уже просел и клиент в панике. В alfa8.ru мы не раз сталкивались с ситуациями, когда после аудита находили критический косяк, который сводил на нет месяцы работы контент-команды. Поэтому я всегда повторяю: сначала техника, потом всё остальное.
Что такое технический аудит сайта и зачем он нужен
Если совсем просто: технический аудит — это проверка того, как поисковый робот видит сайт и насколько комфортно с ним работать реальному пользователю. Мы не оцениваем дизайн или качество текстов — это задача других этапов. Здесь фокус на «фундаменте»: доступность страниц, корректность кода, скорость отклика, логика индексации и ошибки, которые могут испортить ранжирование. По сути, специалист отвечает на три вопроса: 1) Может ли робот беспрепятственно попасть на сайт и пройти по всем нужным страницам? 2) Понимает ли он, какие страницы главные, а какие — второстепенные или технические? 3) Нет ли скрытых препятствий, которые мешают индексации и передаче веса? Если хотя бы на один ответ «нет» — продвижение будет пробуксовывать, сколько ни вкладывай в контент и ссылки. В одном из проектов alfa8.ru мы обнаружили, что робот Google не мог добраться до карточек товаров из-за криво настроенной пагинации — все новые поступления висели в воздухе. Пока не поправили, трафик стоял на месте.
Когда аудит особенно нужен
Аудит не делают «на всякий случай» раз в год. Есть конкретные триггеры, когда без него не обойтись:
- перед запуском SEO на новом сайте — чтобы не начинать с исправления чужих ошибок;
- после редизайна или переезда на новый домен — тут часто теряются редиректы, ломается canonical и выпадают страницы;
- при резком падении трафика без явной причины — часто корень в технической проблеме, а не в алгоритмах;
- если в индексе болтается много мусорных URL, а важных страниц почти нет;
- когда сайт откровенно тормозит или криво выглядит на телефоне;
- при обилии дублей, битых ссылок и 404 ошибок.
В агентстве мы всегда настаиваем на аудите в этих случаях, даже если клиент уверен, что «там всё нормально, нам просто SEO нужно».
Что именно проверяет SEO-специалист
Ниже — обязательная база, которую мы смотрим в каждом проекте. На практике список может расширяться, но эти блоки — фундамент.
| Блок проверки | Что ищем | Почему это важно |
|---|---|---|
| Индексация | Какие страницы реально попали в индекс, а какие нет, и почему. Часто в индексе висят служебные страницы, отъедающие краулинговый бюджет. | Без индексации страница не существует для поиска. |
| robots.txt | Запреты, директивы, ссылка на sitemap. Ошибка здесь может закрыть от роботов целые разделы — например, категории или карточки товаров. | Критично для доступа робота к важным страницам. |
| sitemap.xml | Актуальность URL, отсутствие мусора (404, редиректов, noindex), соответствие структуре. | Помогает поисковику быстрее понять приоритеты и не тратить бюджет на мусор. |
| Статусы страниц | 200, 301, 404, 500 — что отдаёт каждая целевая страница. | Ошибочные коды мешают обходу и передаче ссылочного веса. |
| Дубликаты | Повторяющиеся страницы, одинаковые title, description, H1. | Дубли размывают релевантность и могут вытеснить основную страницу из выдачи. |
| Canonical | Корректность указания канонической версии, отсутствие конфликтов. | Нужен, чтобы явно указать главную версию URL и избежать склеек. |
| Мобильная версия | Адаптация, удобство интерфейса, ошибки отображения на реальных устройствах. | Поисковики учитывают mobile-first, а пользователи — удобство. |
| Скорость загрузки | LCP, INP, CLS и общая отзывчивость. Тяжёлые элементы, скрипты, серверный отклик. | Медленные страницы хуже ранжируются и теряют конверсию. |
| HTTPS и безопасность | SSL, mixed content, редиректы с http на https. | Безопасность влияет на доверие и может быть сигналом для поисковиков. |
| Микроразметка | Schema.org: Organization, Product, BreadcrumbList и другие типы. | Помогает поисковику точнее интерпретировать данные и получать расширенные сниппеты. |
| Внутренняя перелинковка | Глубина клика, орфанные страницы, анкоры, распределение веса. | Влияет на частоту обхода и ранжирование страниц. |
| Логи и краулинг | Как робот реально ходит по сайту, какие страницы игнорирует. | Показывает проблемы, которые не видны в интерфейсе вебмастеров. |
Индексация: с чего начинается любой аудит
Индексация — это точка входа. Можно сколько угодно вылизывать мета-теги и наращивать ссылочную массу, но если страница не попала в индекс, все усилия впустую. Поэтому я всегда начинаю аудит с того, что сравниваю реальное количество страниц на сайте с тем, что показывает поиск. Важно не только общее число, но и то, какие именно URL попали в выдачу.
Что проверяют
- Сверяем фактическое количество страниц с числом проиндексированных — большое расхождение сигнализирует о проблемах.
- Смотрим, нет ли в индексе технических, фильтровых или пустых страниц, которые не должны там быть.
- Проверяем, не выпали ли из поиска важные разделы — такое бывает после обновлений CMS или случайного закрытия в robots.txt.
- Анализируем, не исключены ли страницы массово из-за noindex, кривого canonical или запретов в robots.
- Обязательно смотрим, одинаково ли страница отдаётся роботу и пользователю — иногда сервер рендерит разный контент.
Типовая ошибка
Классика: интернет-магазин растёт, добавляются новые категории и товары, а в индексе по-прежнему болтаются только старые позиции. Владелец грешит на SEO, а реальная причина в том, что новые URL не попали в sitemap, на них нет внутренних ссылок или они случайно закрыты мета-тегом noindex. В одном проекте мы нашли 200 новых карточек, которые не были связаны ни с одной категорией — робот их просто не видел.
robots.txt и sitemap.xml: два файла, которые часто ломают продвижение
robots.txt и sitemap.xml — два маленьких файла, которые способны угробить даже самый мощный сайт. На первый взгляд всё элементарно, но практика показывает: именно здесь кроется большинство фатальных ошибок. Неправильная директива в robots.txt может скрыть от индексации весь каталог, а кривая карта сайта — запутать робота и заставить его тратить краулинговый бюджет на мусор.
robots.txt проверяют на:
- Случайные запреты важных разделов — часто разработчики закрывают /admin, а заодно и /catalog.
- Синтаксис: лишний пробел или слеш могут сломать логику.
- Наличие директив для основных поисковых роботов (Googlebot, YandexBot).
- Ссылку на sitemap.xml — её отсутствие не критично, но замедляет обнаружение новых страниц.
- Не закрыты ли CSS, JS и другие ресурсы, необходимые для рендеринга. Если робот не видит стили и скрипты, он может неправильно оценить страницу.
sitemap.xml проверяют на:
- Только актуальные, работающие URL с кодом 200. Никаких 404, редиректов и страниц с noindex — это прямой путь к дезинформации поисковика.
- Соответствие реальной структуре сайта: если в карте есть страницы, которых нет в навигации, или наоборот, это повод разобраться.
- Актуальность дат lastmod, если они используются — устаревшие даты могут вводить в заблуждение.
- Для крупных проектов — разделение карты по типам страниц (товары, категории, статьи), чтобы роботу было проще.
Практический нюанс
Карта сайта — не свалка всех URL. В неё должны попадать только те страницы, которые вы хотите видеть в поиске. Если туда залетают фильтры, дубли, служебные страницы и редиректы, поисковик начинает путаться в приоритетах и может проигнорировать действительно важные разделы. В alfa8.ru мы всегда чистим sitemap перед подачей в Search Console — это экономит краулинговый бюджет и ускоряет индексацию новинок.
Коды ответа сервера и редиректы
Серверные коды — это язык, на котором сайт общается с роботом. Если страница отдаёт 404 вместо 200, или редирект зациклен, робот просто не дойдёт до контента. Поэтому в аудите мы обязательно прогоняем все ключевые URL и смотрим, что они возвращают.
Основные коды
- 200 — страница жива и доступна;
- 301 — постоянный редирект, сигнал «переезд навсегда»;
- 302 — временный редирект, который часто используют по ошибке вместо 301;
- 404 — страница не найдена, нормально, если это действительно удалённый URL;
- 500 — внутренняя ошибка сервера, требует немедленного вмешательства;
- 503 — сервер временно недоступен, например, при перегрузке.
Что здесь важно
- Все целевые страницы (категории, товары, статьи) должны отдавать 200.
- После переезда или смены URL старые адреса обязаны вести на новые через 301 — иначе теряется ссылочный вес.
- Цепочки редиректов (когда с одного URL перекидывает на другой, потом на третий) лучше убирать — они замедляют обход и размывают вес.
- Массовые 404 на внутренних ссылках — признак бардака в структуре.
- Ошибка 500 — стоп-сигнал: если она появляется часто, сайт могут посчитать нестабильным.
Типовые ошибки
- Несколько редиректов подряд вместо одного прямого — например, со страницы на /category, потом на /category/, потом на /catalog/category.
- Редирект на нерелевантную страницу, когда старая карточка товара ведёт на главную.
- Битые ссылки в меню и хлебных крошках, которые генерируют 404.
- Разные версии одного URL из-за слеша, регистра или параметров, которые не склеены canonical.
Дубли страниц и канонизация
Дубли — это бич любых проектов, где есть фильтры, сортировки, параметры URL или несколько путей к одной странице. Если не управлять этим, поисковик сам решит, какую версию считать основной, и может ошибиться. В итоге в выдаче окажется не та страница, которую вы хотели, а её клон с мусорным адресом.
Откуда берутся дубли
- Страницы со слешем и без (site.ru/catalog и site.ru/catalog/);
- http и https версии;
- с www и без;
- параметры в URL (utm, sort, filter);
- сортировки и фильтры, которые генерируют новые адреса;
- одинаковые товары в разных категориях;
- печатные версии, теги, страницы пагинации, которые не закрыты от индексации.
Что делает SEO-специалист
- Ищет повторяющиеся URL с одинаковым или очень похожим контентом.
- Сравнивает title, description и H1 — если они совпадают, это почти гарантированный дубль.
- Проверяет, указан ли canonical и на ту ли страницу он ведёт.
- Определяет, какая версия должна быть основной, и настраивает канонизацию или редиректы.
- Смотрит, не склеиваются ли ошибочно разные страницы из-за кривого canonical — например, когда все товары ссылаются на одну категорию.
Почему это важно
Когда у поисковика есть несколько почти одинаковых страниц, он выбирает одну «каноническую» по своим алгоритмам. Если выбор падёт на дубль с кривым URL или без внутренних ссылок, вы теряете позиции и трафик. Кроме того, дубли размывают ссылочный вес: внешние ссылки могут идти на разные версии, и ни одна не получает полной силы.
Скорость загрузки и Core Web Vitals
Скорость давно перестала быть просто «приятным бонусом». Это прямой сигнал для поисковиков и критичный фактор конверсии. Причём важны не абстрактные секунды загрузки, а метрики Core Web Vitals, которые отражают реальный пользовательский опыт: как быстро появляется основной контент (LCP), насколько быстро сайт реагирует на клики и ввод (INP), и не прыгает ли вёрстка при загрузке (CLS).
Что обычно смотрят
- LCP — время загрузки самого крупного видимого элемента;
- INP — задержка реакции на взаимодействие;
- CLS — визуальная стабильность;
- общий вес страницы;
- количество и размер скриптов;
- оптимизацию изображений;
- время ответа сервера (TTFB).
Что чаще всего замедляет сайт
- Тяжёлые баннеры и слайдеры на главной;
- несжатые изображения в карточках товаров;
- десятки сторонних скриптов (чаты, аналитика, виджеты);
- блокирующие CSS и JS, которые мешают рендерингу;
- слабый хостинг или отсутствие кеширования.
В одном проекте мы ускорили загрузку в два раза, просто убрав неиспользуемый слайдер и сжав картинки.
Простой ориентир
Если страница долго «оживает» и при скролле дёргается, не спешите винить дизайнера. Чаще всего проблема в перегруженном фронтенде, неоптимизированных медиафайлах или медленном серверном ответе. Начинайте с аудита скорости в PageSpeed Insights и смотрите на конкретные рекомендации, а не на общий балл.
Мобильная версия и адаптивность
Мобильный трафик в Рунете давно перевалил за половину, так что мобильная версия — это не опция, а must have. Поисковики индексируют сайты с приоритетом mobile-first, поэтому если на смартфоне всё плохо, десктопные позиции тоже пострадают.
Проверяют:
- Корректность отображения на основных разрешениях (320, 375, 414, 768, 1024).
- Читаемость текста без зума.
- Удобство меню и кнопок — чтобы пальцем можно было попасть.
- Отсутствие горизонтальной прокрутки.
- Работу форм, фильтров и корзины.
- Скорость загрузки на мобильных сетях (3G, 4G).
- Совпадение контента с десктопной версией — если на мобильной что-то скрыто, это может считаться скрытым текстом.
Типовая ошибка
На десктопе всё красиво, а на телефоне кнопка «Купить» уезжает за экран, фильтр не открывается, а текст налезает на изображение. Это не только бесит пользователей, но и ухудшает поведенческие факторы. Поисковик видит, что с мобильной версией проблемы, и понижает сайт в выдаче. В alfa8.ru мы всегда тестируем мобильную версию на реальных устройствах, а не только в эмуляторе.
Внутренняя перелинковка и структура сайта
Структура сайта — это скелет, по которому робот перемещается и распределяет вес. Если важные страницы закопаны глубоко и на них нет ссылок, они будут индексироваться медленно и ранжироваться хуже. Поэтому в аудите мы обязательно смотрим на перелинковку.
Что проверяют
- Глубину вложенности: сколько кликов от главной до целевой страницы.
- Наличие орфанных страниц — тех, на которые вообще нет ссылок с других страниц сайта.
- Корректность хлебных крошек — они должны отражать реальный путь.
- Распределение ссылочного веса: не перегружены ли одни разделы в ущерб другим.
- Анкоры внутренних ссылок — они должны быть релевантными, а не «здесь» или «подробнее».
- Ищем «провалы» в структуре, когда целые разделы не связаны с остальным сайтом.
Почему это важно
Если страница находится в пяти кликах от главной и на неё ведёт одна ссылка из глубокого подвала, робот будет заходить на неё редко. А значит, она может выпасть из индекса или не получить достаточно веса для конкуренции по частотным запросам. Мы часто перестраиваем перелинковку в интернет-магазинах, добавляя блоки «Похожие товары» или «С этим товаром покупают», чтобы улучшить обход.
Микроразметка и служебные данные
Микроразметка — это способ объяснить поисковику, что именно находится на странице: товар, статья, контакты или хлебные крошки. Сама по себе она не поднимет сайт в топ, но помогает получать расширенные сниппеты и улучшает понимание контента. В аудите мы проверяем, не сломана ли разметка и соответствует ли она реальности.
Что чаще всего проверяют
- Organization и LocalBusiness — для компаний;
- Product — для карточек товаров (цена, наличие, отзывы);
- BreadcrumbList — хлебные крошки;
- Article — для статей;
- FAQPage — для вопросов-ответов;
- ContactPoint — контакты.
Частые ошибки
- Разметка есть, но данные неверные: например, цена в разметке не совпадает с ценой на странице.
- Разметка не соответствует видимому контенту — поисковик может счесть это манипуляцией.
- Одинаковые сущности размечены по-разному на разных страницах.
- Разметка сломалась после редизайна — разработчики обновили вёрстку, а микроразметку не поправили.
Безопасность, HTTPS и серверная часть
Безопасность и стабильность — это гигиена. Если сайт работает через раз, сертификат просрочен, а часть ресурсов грузится по HTTP, доверие поисковиков и пользователей падает. Поэтому в аудит всегда включаем проверку серверной части.
Проверяют
- Корректность SSL-сертификата: не просрочен ли, покрывает ли все поддомены.
- Переход всех версий сайта на HTTPS — не должно быть дублей с http.
- Отсутствие mixed content: когда на HTTPS-странице подгружаются скрипты или картинки по HTTP.
- Корректные редиректы с http на https — обычно через 301.
- Наличие ошибок сервера в логах.
- Стабильность ответа под нагрузкой — если сайт ложится при наплыве посетителей, это проблема.
Почему это важно
Поисковик может понизить сайт, если находит mixed content или частые ошибки. Пользователи, увидев предупреждение о небезопасном соединении, просто уйдут. А если сервер периодически отдаёт 500, робот может сократить частоту обходов. В агентской практике был случай, когда после переезда на HTTPS забыли поправить внутренние ссылки — половина страниц отдавала редирект, и трафик просел на 30%.
Как проходит технический аудит: пошагово
В alfa8.ru мы придерживаемся чёткой последовательности, чтобы не утонуть в деталях и не упустить критичное. Вот как выглядит наш типовой процесс.
Шаг 1. Сбор данных
Выгружаем все URL сайта (через краулер или CMS). Смотрим, сколько страниц в индексе через Search Console и Яндекс.Вебмастер. Проверяем карты сайта — все ли они актуальны. Собираем данные из панелей вебмастеров: ошибки сканирования, проблемы с безопасностью, статус индексации. Делаем первичный краулинг, чтобы увидеть реальную картину.
Шаг 2. Поиск критических ошибок
Ищем всё, что бросается в глаза: 404 и 500 ошибки, закрытые важные разделы, проблемы с canonical, массовые дубли, длинные цепочки редиректов, явные косяки мобильной версии. Это то, что требует немедленного вмешательства.
Шаг 3. Проверка качества обхода
Анализируем, как робот ходит по сайту: какие страницы получают внутренний вес, а какие висят орфанными. Смотрим, нет ли мусорных URL, которые отъедают краулинговый бюджет. Проверяем, что попадает в индекс случайно — часто это страницы пагинации или фильтров.
Шаг 4. Анализ скорости и интерфейса
Замеряем Core Web Vitals, смотрим на стабильность вёрстки, тестируем на реальных мобильных устройствах. Выявляем тяжёлые элементы и скрипты, которые тормозят загрузку.
Шаг 5. Приоритизация
Не пытаемся исправить всё и сразу. Сначала закрываем критические проблемы, которые влияют на индексацию и доступность. Потом переходим к дублям, структуре и перелинковке. И только после этого занимаемся оптимизацией скорости и микроразметкой. Такой порядок даёт максимальный эффект в кратчайшие сроки.
Как SEO-специалист расставляет приоритеты
Главное правило: аудит должен заканчиваться не устрашающим списком из сотни пунктов, а чётким планом с приоритетами. Иначе команда утонет в задачах, а клиент — в смете. Мы в alfa8.ru используем простую матрицу приоритетов.
| Приоритет | Что относится | Что делать |
|---|---|---|
| Высокий | Закрытые важные страницы, массовые 404, ошибки индексации, сломанный robots.txt | Исправлять немедленно — без этого SEO не работает. |
| Средний | Дубли, проблемы canonical, редиректные цепочки, слабая перелинковка | Включать в ближайший спринт — размывают вес и мешают ранжированию. |
| Низкий | Мелкие визуальные дефекты, второстепенные оптимизации (например, неидеальная микроразметка на непосещаемых страницах) | Планировать после решения критических задач. |
Чек-лист: что должен проверить SEO-специалист
- Индексация важных страниц — сравнить фактическое количество с индексом;
- robots.txt и sitemap.xml — проверить на ошибки и актуальность;
- коды ответа страниц — пройти краулером и выявить не 200;
- редиректы и цепочки — убедиться, что нет лишних переадресаций;
- дубли и canonical — найти и устранить;
- ошибки 404 и 500 — исправить битые ссылки и нестабильность;
- скорость загрузки — замерить LCP, INP, CLS;
- мобильная версия — протестировать на реальных устройствах;
- внутренняя перелинковка — проверить глубину и орфанные страницы;
- микроразметка — валидировать через инструменты;
- HTTPS и mixed content — убедиться в безопасности;
- орфанные страницы — найти и связать;
- структура URL — убрать мусорные параметры;
- служебные и мусорные страницы — закрыть от индексации;
- корректность отображения контента для робота — проверить через Fetch as Google.
Типовые ошибки владельцев сайта
- Запускают SEO до устранения технических проблем — это как красить стены в доме без фундамента.
- Смотрят только на дизайн, игнорируя индексацию — красивая обёртка не спасёт, если сайт не виден.
- Считают, что карта сайта сама по себе решает все проблемы — нет, она лишь помогает, но не заменяет нормальную структуру.
- Не проверяют сайт после редизайна — а зря, потому что часто ломаются редиректы и canonical.
- Не тестируют мобильную версию на реальных страницах — проверяют только главную, а в карточках товаров всё плохо.
- Не отделяют критические ошибки от второстепенных — в итоге тратят бюджет на мелочи, а индексация стоит.
Вывод
Технический аудит — это не разовая акция, а фундамент, на котором строится всё SEO. Он отвечает на главный вопрос: «Поисковик вообще видит сайт и правильно ли его понимает?» Если фундамент кривой, никакие тексты и ссылки не дадут стабильного роста. Поэтому в своей практике я всегда придерживаюсь правила: сначала индексация и доступность, потом дубли и структура, затем скорость и удобство. Именно в такой последовательности мы работаем над проектами в alfa8.ru — и именно она приносит реальные результаты, а не просто красивые отчёты.
FAQ
Что входит в технический аудит сайта?
Полный цикл: от проверки индексации и robots.txt до анализа скорости, микроразметки и безопасности. Всё, что влияет на то, как робот видит и обрабатывает сайт.
Как часто делать технический аудит?
Минимум перед стартом продвижения и после любых глобальных изменений: редизайн, смена CMS, переезд. Для крупных проектов с динамическим контентом мы рекомендуем мониторить ключевые параметры ежемесячно.
Можно ли продвигать сайт без технического аудита?
Технически можно, но это игра в рулетку. Если есть скрытые проблемы с индексацией или дублями, бюджет на SEO будет сливаться впустую. Лучше один раз проверить, чем потом гадать, почему нет трафика.
Чем технический аудит отличается от SEO-аудита?
Технический аудит — это часть SEO-аудита, которая фокусируется на «железе»: индексация, коды ответа, скорость, дубли. Полный SEO-аудит включает ещё анализ контента, семантики, конкурентов и коммерческих факторов.
Кто должен исправлять ошибки после аудита?
Это командная работа: SEO-специалист ставит задачи и контролирует, разработчик правит код и серверные настройки, верстальщик — мобильную версию, контент-менеджер — дубли и мета-теги. Главное — чтобы все задачи были приоритизированы и понятны исполнителям.
