В корзине пусто!
Большинство сайтов, которые годами не растут в поиске, страдают не от слабого контента и не от нехватки ссылок — у них технические блокеры, которые мешают поисковому роботу нормально работать с ресурсом. Технический SEO-аудит — это диагностика, которая выявляет эти блокеры до того, как вы вкладываете бюджет во внешнее продвижение.
В этом гайде — структурированная методология: что проверять, какими инструментами и как расставлять приоритеты, чтобы исправления давали результат. Подходит и для самостоятельной работы, и для постановки ТЗ разработчику. Если нужна помощь — команда SEO-Factory занимается SEO-продвижением сайтов под ключ.
Содержание
- Что входит в технический аудит
- Подготовка к аудиту: необходимые инструменты
- Краулинг и бюджет сканирования
- Краулинг и индексация: robots.txt, sitemap, GSC
- Дублирование контента и канонизация
- Core Web Vitals и скорость загрузки
- Мобильная оптимизация
- HTTPS, редиректы и структура URL
- Структурированные данные и Schema.org
- Отчёт по результатам аудита
- Как приоритизировать исправления
Что входит в технический аудит
Технический SEO охватывает всё, что влияет на способность поискового робота находить, обходить и индексировать страницы. В отличие от контентного или ссылочного анализа, здесь нет субъективности: либо ошибка есть, либо её нет.
Основные блоки проверки:
- Краулинг — может ли Googlebot обойти все нужные страницы без ограничений
- Индексация — какие страницы попадают в поисковый индекс, а какие заблокированы
- Скорость и Core Web Vitals — соответствие требованиям Page Experience
- Мобильная версия — корректность Mobile-First индексации
- HTTPS и безопасность — наличие SSL и правильная реализация редиректов
- Структура URL — читаемость, канонизация, цепочки редиректов
- Дублирование контента — технические дубли, canonical теги
- Schema.org и разметка — структурированные данные, hreflang, Open Graph
Подготовка к аудиту: необходимые инструменты
Прежде чем запускать аудит, важно собрать правильный стек инструментов. Каждый закрывает свою зону — ни один не заменяет остальные.
Google Search Console
Бесплатный и незаменимый. Перед аудитом убедитесь, что сайт подтверждён: добавьте HTML-тег в <head>, загрузите файл верификации или подтвердите через DNS-запись. Если есть обе версии — www и non-www — подтвердите обе и установите основное свойство. Подключите GSC к Google Analytics 4 через раздел «Связи» в GA4: это позволяет анализировать органические ключевые слова прямо в GA4 и отслеживать конверсии в разрезе поисковых запросов.
Google Analytics 4
Для аудита важны отчёты: «Вовлечённость» → «Страницы и экраны» (какие страницы получают трафик и конвертируют), «Acquisition» → «Organic Search» (трафик из поиска). После соединения с GSC в GA4 появится отчёт «Search Console» с органическими запросами и позициями — это даёт полную картину до и после исправлений.
Screaming Frog SEO Spider
Бесплатная версия обходит до 500 URL — достаточно для небольшого сайта. Для крупнее — лицензия около £149/год. Ключевые настройки перед краулингом:
- JavaScript рендеринг: Configuration → Spider → Rendering → выбрать «JavaScript». Это позволяет Screaming Frog рендерить страницы как браузер и находить контент, загружаемый через JS. Критично для SPA и сайтов на React/Vue.
- Custom Extraction: Configuration → Custom → Extraction — можно извлекать произвольные данные через CSS-селектор или XPath. Например, проверить наличие canonical на каждой странице или вытащить конкретный мета-тег.
- Crawl limits: для крупных сайтов установите лимит глубины (Configuration → Spider → Limits → Max Crawl Depth), чтобы не тратить время на страницы с большой вложенностью.
Ahrefs Site Audit или Semrush Site Audit
Облачные краулеры — запускаются без установки ПО и выдают готовые отчёты с категоризацией ошибок. Ahrefs хорошо выявляет проблемы с внутренними ссылками и orphan-страницами. Semrush даёт подробный отчёт по Core Web Vitals и HTTPS. Оба подходят для регулярного мониторинга: настраиваете автоматический краулинг раз в неделю и получаете уведомления о новых ошибках.
Доступ к серверу
Для полноценного аудита крупного сайта нужны лог-файлы сервера — они показывают, какие страницы реально обходил Googlebot и как часто. Доступ через cPanel (раздел «Логи» / Raw Access Logs) или SSH (cat /var/log/nginx/access.log | grep Googlebot). Инструменты для анализа логов: Screaming Frog Log File Analyser или Botify. Если Googlebot не посещает важные страницы — это сигнал проблем с краулинговым бюджетом.
Минимальный стек для старта: Google Search Console + Screaming Frog (бесплатная версия) + PageSpeed Insights. Этого достаточно для аудита сайта до 500 страниц и выявления 80% критических проблем.
Краулинг и бюджет сканирования
Первый шаг аудита — понять, как поисковый робот видит ваш сайт. Запускаете Screaming Frog и делаете полный краулинг. На выходе — список всех URL со статусами, заголовками, кодами ответа, глубиной вложенности.
Что искать:
- Страницы с кодом 4xx — битые ссылки, несуществующие страницы. В GSC собирают crawl errors и убивают краулинговый бюджет.
- Цепочки редиректов — 301 → 301 → 301. Google рекомендует не более одного редиректа в цепочке. Каждый лишний — потеря PageRank и замедление краулинга.
- Большая глубина вложенности — страницы, до которых нужно 5+ кликов от главной. Критические страницы должны быть доступны за 3 клика.
- Orphan-страницы — страницы без внутренних ссылок. Робот может их просто не найти.
Совет: В GSC отчёт «Покрытие» (Coverage) показывает, какие страницы проиндексированы, а какие заблокированы. Разрыв между Screaming Frog и GSC-индексом больше 15–20% требует расследования.
Краулинговый бюджет важен для крупных сайтов (от 10 000+ страниц). Если сайт генерирует тысячи параметрических URL (фильтры в интернет-магазине), значительная часть бюджета тратится на ненужные страницы вместо важных. Именно такие проблемы выявляет технический аудит в составе SEO-продвижения.
Краулинг и индексация: robots.txt, sitemap, GSC
Robots.txt — первое, что читает поисковый робот. Ошибка здесь может заблокировать от индексации целые разделы или весь сайт. Это случается после переезда между CMS или после «временного» закрытия в тестовый режим, которое забыли отменить.
Как читать robots.txt и типичные ошибки
Файл находится по адресу https://example.com/robots.txt. Директива Disallow: / запрещает обход всего сайта — одна из самых разрушительных ошибок. Другие типичные проблемы:
- Заблокирован CSS/JS:
Disallow: /wp-content/themes/илиDisallow: *.js— Google не может рендерить страницы, видит их «голыми». Проверьте в GSC → Инструмент проверки URL → «Позволяет ли Google просматривать эту страницу?» - Заблокирован WordPress admin: правильно блокировать
/wp-admin/, но не/wp-admin/admin-ajax.php— он нужен для AJAX-запросов. - Disallow: / для всего Googlebot — чаще всего остаток от разработки. Проверяйте после каждого переезда.
XML sitemap: валидный формат и обновление
Sitemap.xml должен содержать только канонические URL со статусом 200 и без noindex. Для крупных сайтов используйте sitemap index — файл, ссылающийся на отдельные sitemap-файлы по разделам (товары, статьи, категории). Каждый подфайл — не более 50 000 URL или 50 МБ.
Поле lastmod — только для страниц, которые реально изменились. Одинаковая дата для всех страниц — Google игнорирует этот сигнал. После каждой публикации новый материал должен появляться в sitemap автоматически (если CMS настроен правильно) или добавляться вручную.
Google Index Coverage Report
В GSC → «Покрытие» четыре статуса:
- Valid — проиндексировано, всё хорошо.
- Valid with warning — проиндексировано, но есть вопросы (например, страница в sitemap, но закрыта через noindex).
- Excluded — не проиндексировано, Google считает это нормальным (noindex, canonical на другую страницу, дубль).
- Error — ошибка: 404, server error (5xx), заблокировано robots.txt, редирект.
Ошибки и предупреждения требуют немедленного внимания. Для каждой страницы со статусом «Error» используйте «Инструмент проверки URL» — он показывает, что именно видит Google при краулинге.
Запрос на индексацию через GSC
После исправления ошибки или публикации новой страницы: GSC → Инструмент проверки URL → введите URL → «Запросить индексацию». Google проверяет страницу в течение нескольких часов–дней. Массово добавить новые URL в индекс можно через обновлённый sitemap — GSC проверяет его регулярно автоматически.
Soft 404 vs 404: разница и решение
Жёсткий 404 — сервер возвращает код 404, страница не существует. Правильно: если страница больше не нужна — пусть возвращает 404 или 410 (Gone). Если переехала — 301 на новый адрес.
Soft 404 — сервер возвращает код 200, но контент говорит «товар не найден» или «ничего не найдено». Google видит пустую страницу с кодом 200 и тратит на неё краулинговый бюджет. Решение: настройте страницы «товар не найден» и «нет результатов поиска» возвращать реальный 404.
На одном e-commerce проекте с 12 000 товаров обнаружили 3 400 soft-404 — страницы распроданных товаров с кодом 200 и надписью «нет в наличии». После перевода их на 410 краулинговый бюджет освободился для важных категорий, и за 6 недель количество проиндексированных страниц выросло на 18%.
Дублирование контента и канонизация
Google не штрафует за дубли напрямую, но тратит на них краулинговый бюджет и размывает PageRank. В результате ни одна из версий не ранжируется так хорошо, как могла бы.
Типы дублей и причины их возникновения
| Тип дублирования | Причина | Решение |
|---|---|---|
| HTTP vs HTTPS версия | Нет 301-редиректа | Добавить редирект 301 |
| www vs non-www | Не выбран основной домен | 301 + настройки GSC |
| URL с параметрами фильтров | ?sort=price, ?color=red и т.д. | Canonical или noindex |
| Страницы пагинации | /page/2, /page/3... | Self-canonical на каждой |
| Trailing slash vs без | /blog и /blog/ как разные URL | Выбрать один вариант + 301 |
| Printer-friendly версии | /print/ или ?format=print | Canonical на основную страницу |
| Сессионные параметры | ?sessionid=abc123 | Canonical или параметры в GSC |
Canonical тег: правильная реализация
Тег canonical в <head>: <link rel="canonical" href="https://example.com/canonical-url/">. Если страница уникальна — self-canonical (указывает на себя). Если дубль — canonical на оригинал.
Типичные ошибки:
- Canonical указывает на страницу с noindex — противоречивый сигнал.
- Canonical chain: страница A canonical → B, B canonical → C. Google может не принять C как каноническую. Всегда указывайте на конечный URL.
- Canonical конфликтует с hreflang: если для языковых версий canonical указывает на главный язык — Google проигнорирует hreflang.
hreflang для многоязычных сайтов
Если сайт имеет языковые версии, hreflang сообщает Google: какую версию показывать какой аудитории. Базовый формат:
<link rel="alternate" hreflang="uk" href="https://example.com/uk/page/">
<link rel="alternate" hreflang="ru" href="https://example.com/ru/page/">
<link rel="alternate" hreflang="x-default" href="https://example.com/page/">
Теги должны быть взаимными: если UK-версия ссылается на RU-версию, RU-версия обязана ссылаться обратно на UK. Проверяйте через Screaming Frog (Hreflang → Hreflang All) или в GSC → «Международное таргетирование».
Совет: Используйте инструмент hreflang Tags Testing Tool от TechnicalSEO.com — он проверяет взаимность тегов и выявляет конфликтные canonical.
Core Web Vitals и скорость загрузки
С 2021 года Core Web Vitals — официальный сигнал ранжирования. В конкурентных нишах, где остальные сигналы равны, плохие CWV дают преимущество конкуренту.
Как проверять: PageSpeed Insights — лабораторные и полевые данные (реальные пользователи из Chrome UX Report). Ориентируйтесь на полевые — они влияют на ранжирование. GSC → «Основные показатели» — агрегированный отчёт по всем страницам.
Частые причины плохого LCP: медленный сервер (TTFB > 800 мс), изображение баннера без fetchpriority="high", рендерблокирующие ресурсы в <head>, отсутствие CDN.
Частые причины CLS: изображения без width/height, рекламные блоки вставляются после загрузки, шрифты без font-display: swap.
Мобильная оптимизация и Mobile-First индексация
С 2023 года Google анализирует мобильную версию страницы, а не десктопную. Если на мобильной меньше контента или есть проблемы с рендерингом — это отражается в ранжировании.
Что проверять:
- Мобильная версия содержит тот же контент, что и десктопная
- Viewport meta-тег:
<meta name="viewport" content="width=device-width, initial-scale=1"> - Кнопки и ссылки — минимум 48×48 px для тапа
- Элементы не накладываются, горизонтальный скролл отсутствует
Инструмент: GSC → «Удобство для мобильных» показывает конкретные страницы с проблемами. Дополнительно — Mobile-Friendly Test от Google для проверки отдельных URL.
HTTPS, редиректы и структура URL
HTTPS
SSL установлен — не значит реализован правильно. Типичные ошибки: не все страницы редиректят с HTTP на HTTPS, есть mixed content, внутренние ссылки используют HTTP, SSL-сертификат просрочен.
Структура URL и редиректы
URL должна читаться человеком и содержать ключевое слово: /uslugi/seo-prodvizhenie/ — хорошо, /p=1423 — плохо.
- URL с параметрами без canonical или noindex — закрыть
- Дублирование с / и без / в конце — выбрать один вариант + 301
- Цепочки 301→301 — заменить на прямой редирект к финальному URL
- 302 там где должны быть 301 — исправить
Структурированные данные и Schema.org
Структурированная разметка не является прямым сигналом ранжирования, но даёт rich snippets в поисковой выдаче — звёзды, цены, FAQ, хлебные крошки. Это увеличивает CTR на 20–30% даже без изменения позиции.
Какие типы разметки дают rich snippets
| Тип Schema | Rich snippet | Где использовать |
|---|---|---|
| FAQ | Разворачиваемые вопросы под сниппетом | Страницы услуг, лендинги |
| HowTo | Пошаговые инструкции с иконками | Гайды, статьи-инструкции |
| Product + Review | Звёзды, цена, наличие | Карточки товаров e-commerce |
| BreadcrumbList | Хлебные крошки вместо URL | Все страницы сайта |
| Organization | Панель знаний компании | Главная страница |
| LocalBusiness | Адрес, телефон, часы работы | Контактная страница, лендинг |
JSON-LD против Microdata
Google рекомендует JSON-LD — разметку размещают в блоке <script type="application/ld+json"> в <head> или перед </body>. Преимущество: не требует изменения HTML-структуры, легко поддерживать, можно добавлять через GTM. Microdata встраивается в HTML-атрибуты — более трудоёмко и подвержено ошибкам при обновлении шаблона.
Практический пример BreadcrumbList JSON-LD
BreadcrumbList — наиболее простая и эффективная разметка для любого сайта. Заменяет URL в поисковой выдаче на читаемые хлебные крошки и повышает CTR. Пример для страницы услуги:
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "BreadcrumbList",
"itemListElement": [
{"@type": "ListItem", "position": 1, "name": "Главная", "item": "https://example.com/"},
{"@type": "ListItem", "position": 2, "name": "Услуги", "item": "https://example.com/uslugi/"},
{"@type": "ListItem", "position": 3, "name": "SEO-продвижение", "item": "https://example.com/uslugi/seo/"}
]
}
</script>
Для статей блога добавьте также тип Article с полями headline, datePublished, dateModified и author — это сигнал E-E-A-T и основание для отображения даты публикации в сниппете.
Проверка и ошибки
Проверяйте через Rich Results Test от Google — показывает, какие rich snippets доступны для страницы и где ошибки. В GSC → «Улучшения» отображаются ошибки структурированных данных по всему сайту: неправильное поле, отсутствующий обязательный элемент, несоответствие типа.
Важно: разметка Review (звёзды) на собственных страницах компании без агрегатора — Google всё чаще её игнорирует или помечает как манипулятивную. Для звёзд в сниппете нужен агрегатор отзывов (Trustpilot, Google Reviews) или Product/Recipe с реальными отзывами третьих лиц.
Отчёт по результатам аудита
Проведённый аудит без качественного отчёта — потраченное время. Отчёт — это не список ошибок со скриншотами, а документ, по которому команда разработчиков может действовать.
Как приоритизировать находки
Все находки делятся на три уровня:
- Критичные (Critical): блокируют индексацию или краулинг. Исправлять немедленно. Примеры: Disallow: / в robots.txt, массовый noindex на важных страницах, сломанный SSL, цепочки редиректов на главных страницах.
- Важные (Important): снижают эффективность, но не блокируют. Исправлять в течение 2–4 недель. Примеры: плохие CWV-показатели, отсутствующие canonical на дублях, ошибки hreflang, sitemap со страницами 404.
- Низкий приоритет (Low): незначительное влияние, исправлять в рамках следующего спринта. Примеры: отсутствующие alt-теги на декоративных изображениях, неоптимальные meta description, лишние HTML-атрибуты.
Формат технического отчёта для клиента
Оптимальная структура: исполнительное резюме (3–5 предложений о состоянии сайта и ключевых рисках) → сводная таблица по блокам (краулинг, индексация, CWV, mobile, дубли, Schema) → детальный раздел по каждому блоку с конкретными URL и скриншотами → трекер исправлений с ответственными и дедлайнами.
Трекер исправлений
Google Sheets — самый простой вариант. Столбцы: описание проблемы | URL / шаблон | приоритет | ответственный | дедлайн | статус | дата проверки. После исправления — помечаете «Исправлено», после реиндексации — «Подтверждено в GSC». Это позволяет отслеживать прогресс и не возвращаться к одним и тем же вопросам дважды.
Повторный аудит через 30–60 дней
Первый аудит фиксирует состояние «до». Повторный через 30–60 дней — оценивает эффект от исправлений: сколько ошибок GSC исчезло, как изменились CWV-показатели, вырос ли процент проиндексированных страниц. Это также выявляет новые проблемы, появившиеся после обновлений сайта.
Рекомендуемая частота аудитов: полный технический аудит — раз в 6 месяцев или после крупных изменений (переезд домена, смена CMS, редизайн). Мини-проверка — ежемесячно: GSC Coverage на ошибки, PageSpeed Insights для 3–5 ключевых страниц, проверка sitemap. Два-три часа внимания раз в месяц предотвращают накопление критических проблем, которые потом требуют недель исправлений.
Что должен содержать финальный отчёт
Качественный отчёт о техническом аудите — это документ, понятный и разработчику, и маркетологу, и владельцу бизнеса. Оптимальная структура:
- Исполнительное резюме — 3–5 предложений: общее состояние сайта, наиболее критичные находки, ожидаемый эффект от исправлений. Без технического жаргона — для принятия решений.
- Сводная таблица по блокам — краулинг, индексация, CWV, мобильная, дубли, Schema — статус каждого (хорошо / требует внимания / критично) и количество находок.
- Детальные секции по каждому блоку — конкретные URL, скриншоты, описание проблемы, рекомендованное решение.
- План действий (Action Plan) — задачи сгруппированы по приоритету: что исправить на этой неделе, что в течение месяца, что запланировать на квартал.
- Трекер исправлений — таблица (Google Sheets) с колонками: проблема, URL/шаблон, приоритет, ответственный, дедлайн, статус.
KPI аудита
Результат аудита измеряется конкретными метриками до/после:
- % проиндексированных страниц от общего количества (цель: >90% для важных разделов)
- Количество ошибок в GSC Coverage (цель: 0 или минимум)
- PageSpeed Score (цель: >70 mobile, >85 desktop)
- LCP, INP, CLS в полевых данных GSC (цель: «Хорошо» для 75%+ страниц)
- Количество страниц в sitemap vs. количество проиндексированных (разрыв <10%)
Как приоритизировать исправления после аудита
Типичный аудит среднего сайта даёт 50–200 проблем. Правильный подход — матрица «влияние на SEO × сложность исправления».
| Квадрант | Влияние | Сложность | Действие | Примеры |
|---|---|---|---|---|
| Сделать первыми | Высокое | Легко | На этой неделе | Robots.txt, canonical, 301 редиректы |
| Запланировать | Высокое | Сложно | Следующий спринт | Оптимизация CWV, рефакторинг URL |
| После главного | Низкое | Легко | По возможности | Meta description, alt-теги |
| Отложить | Низкое | Сложно | Переоценить позже | Редизайн ради минимального эффекта |
На практике 20% технических ошибок дают 80% негативного влияния на ранжирование. Найдите эти 20% и исправьте — результат ощутится через 2–4 недели после переиндексации.
Часто задаваемые вопросы
Что входит в технический SEO-аудит сайта?
Технический аудит охватывает 6 блоков: индексация (robots.txt, sitemap, GSC Coverage), скорость загрузки и Core Web Vitals, структура URL и редиректы, метатеги и дубли контента, мобильная оптимизация, микроразметка Schema.org. Дополнительно проверяют HTTPS, внутреннюю перелинковку и краулинговый бюджет.
Как часто нужно проводить технический SEO-аудит?
Полный аудит — раз в 6–12 месяцев. После крупных изменений на сайте (переезд, редизайн, новые разделы) — обязательно внепланово. Базовую автоматическую проверку (Screaming Frog или Ahrefs Site Audit) стоит запускать ежемесячно для раннего обнаружения проблем.
Какими инструментами проводят технический SEO-аудит?
Основной стек: Screaming Frog (краулинг), Google Search Console (индексация и ошибки), PageSpeed Insights / Lighthouse (скорость), Ahrefs или Semrush Site Audit (комплексные проверки). Для проверки структурированных данных — Google Rich Results Test. Все базовые инструменты имеют бесплатные версии или пробный доступ.
Сколько времени занимает технический аудит и когда ждать результатов?
Сам аудит занимает 1–3 дня в зависимости от размера сайта. После исправлений Google требует 2–8 недель для повторного обхода и переиндексации страниц. Критические ошибки (5xx, заблокированные robots.txt важные страницы) можно исправить и ускорить переиндексацию через запрос в GSC «Проверить URL».
Нужен технический SEO-аудит?
Команда SEO-Factory проведёт полный технический аудит с детальным отчётом и дорожной картой исправлений. Определим приоритеты, дадим чёткий план действий и проверим результат через 30–60 дней.
