Технический SEO-аудит: диагностика инфраструктуры сайта для роботов Google и Яндекса

Почему техническая инфраструктура важнее, чем кажется

Когда компании инвестируют в SEO, они часто фокусируются на контенте. Написали идеальную статью, провели keyword research, подготовили уникальные примеры – и ждут трафика. Но результаты разочаровывают.

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

Представьте: вы подготовили статью, которая отвечает на все вопросы пользователей, имеет идеальную структуру и полезные примеры. Но если:

robots.txt блокирует эту страницу,
сайт загружается 5+ секунд на мобильных,
половина текста рендерится через JavaScript, который Google еще не обработал,

– то эта страница никогда не займет место в топе, независимо от качества контента.

Это различие между “контентом для людей” и “инфраструктурой для роботов.”

Google обрабатывает оба уровня одновременно:

Робот видит вашу страницу (crawlability) – может ли Googlebot вообще получить доступ к контенту?
Робот понимает, о чем страница (indexability) – можно ли её индексировать и ранжировать?
Робот оценивает удобство пользователя (Core Web Vitals) – быстро ли загружается страница, стабилен ли макет, отзывчивая ли интеракция?

Если на одном из этих уровней есть проблемы – трафик потеряется.

Core Web Vitals как ключевой фактор ранжирования 2024-2025

С 2021 года Google официально использует Core Web Vitals как фактор ранжирования. Но в 2024-2025 это не просто “фактор” – это tie-breaker между конкурентами. Если ваш контент и контент конкурента одинаковой качественности, Google выберет более быстрый и стабильный сайт.

Это означает, что для нишевых и конкурентных запросов техническая оптимизация часто решает всё.

Основные блоки технического аудита

1. Анализ индексации и краулинга (Crawlability & Indexability)

Проблематика: Поисковые роботы не видят важные страницы или тратят бюджет на индексацию мусора – тонких страниц, дублей, стараниц сессии. Это называется index bloat (вздутие индекса). Последствие: ваши ценные страницы с трафиком-генератором контентом остаются недоиндексированными, потому что Google потратил бюджет на мусор.

Влияние основных технических ошибок на потери органического трафика

Проверки:

robots.txt – управление доступом робота

Робот начинает с robots.txt. Это текстовый файл в корне сайта, где вы говорите Google, что нельзя трогать.

Типичные ошибки:

Блокировка CSS/JS: Если вы напишите Disallow: /assets/, Google не сможет рендерить JavaScript. Результат: сайт выглядит пустым для поисковика.
Слишком широкие блокировки: Disallow: / блокирует весь сайт (но это редко нужно)
Блокировка параметров: Disallow: /*?* блокирует все URL с параметрами, но это может пересечь каноничные страницы.

Правильный robots.txt:

textUser-agent: *
Disallow: /wp-admin/
Disallow: /search/
Disallow: /cart/
Disallow: /checkout/
Disallow: /*?utm_*

Sitemap: https://example.com/sitemap.xml
Sitemap: https://example.com/sitemap-blog.xml

Правило: блокируйте только низкоценные пути – внутренний поиск, фильтры (которые создают дубли), чекауты. Не блокируйте никогда основной контент.

XML-sitemap.xml – карта сайта для роботов

Sitemap – это заявление Google: “Вот самые важные страницы, которые надо индексировать.” Но часто в sitemap попадает мусор, что сбивает Google с толку.

Лучшие практики:

Включайте только каноничные, индексируемые URL – не включайте редиректы, 404-и, параметрические дубли
Сегментируйте по типам контента – отдельная sitemap для блога, отдельная для товаров, отдельная для услуг. Это помогает Google быстрее найти изменения
lastmod = реальное изменение контента – не серверное время, не текущее время. Google учится паттернам: если lastmod всегда текущее время, Google перестаёт доверять этому полю
Не нужна priority в sitemap – Google её игнорирует

Пример хорошей sitemap:

xml<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://example.com/</loc>
    <lastmod>2025-01-15</lastmod>
  </url>
  <url>
    <loc>https://example.com/blog/article-1</loc>
    <lastmod>2025-01-10</lastmod>
  </url>
</urlset>

После создания – сразу отправьте в Google Search Console и добавьте ссылку в robots.txt.

Статус-коды ответа сервера (HTTP Status Codes)

Каждый URL возвращает статус-код, который говорит Google, что произошло. Неправильный код = неправильное решение.

Код	Значение	Воздействие на SEO	Когда использовать
200	OK – страница существует и загрузилась полностью	Индексируется, ранжируется нормально	Для всех живых страниц с контентом
301	Перманентный редирект	Передает 90-95% link equity на новый URL	Для постоянных переезжаний (домен, URL structure)
302	Временный редирект	Передает мало/ноль link equity, Google не обновляет индекс	Только для временных (тестирование, ограниченные предложения)
404	Страница не найдена	Может остаться в индексе (Google ждет возвращения)	Для окончательно удаленных страниц, опечаток
410	Gone – удалено навсегда	Google быстрее удаляет из индекса, экономит crawl budget	Для окончательно скончавшихся товаров/услуг
503	Сервис временно недоступен	Рейтинги сохраняются, краулинг паузируется	Для планового обслуживания, апдейтов серверов
500	Server Error	Может привести к деиндексации	Никогда – исправьте немедленно

Типичная ошибка: разработчик использует 302 вместо 301 при переносе старой страницы на новую. Результат: новая страница не получает ссылающийся трафик, рейтинги остаются на старой URL. Ждёте месяц, потом месяц, потом удаляете старую – и только потом видите, что ошибка была в типе редиректа. Потеря трафика на месяцы.

Soft 404s – опасная ошибка. Это когда сервер возвращает 200 OK, но страница пустая, показывает сообщение об ошибке или полностью не загружается. Google индексирует такую страницу как живую, но потом замечает, что она не полезна – и её рейтинг падает, а для вас это выглядит как непонятное снижение видимости.

Найти soft 404s:

Google Search Console → Coverage → “Soft 404”
Screaming Frog: фильтр по пустым страницам или низкому word count

Дублирование контента и каноничные теги

Дубли возникают везде:

Сессионные параметры: example.com/page?SESSIONID=123 и example.com/page?SESSIONID=456 – одна и та же страница
UTM параметры: ?utm_source=google vs ?utm_source=email – опять же, один контент
Сортировка товаров: products?sort=price vs products?sort=date
WWW-версии: www.example.com/page и example.com/page

Без управления дублями Google расходует crawl budget на одну и ту же страницу раз 5-10, вместо того, чтобы индексировать новые страницы.

Решение – canonical теги:

На странице-дубле добавляете в <head>:

xml<link rel="canonical" href="https://example.com/products?sort=price" />

Это говорит: “Эта страница – дубль. Вот оригинал (canonical). Индексируй оригинал и передай ему все сигналы.”

Лучшие практики canonical:

Self-referencing canonical – даже на оригинальной странице добавляйте <link rel="canonical" href="самой себя" />
Всегда указывайте на 200 OK URL – не на редирект, не на 404
Избегайте цепочек canonicals – если A → B → C, это путаница
Мониторьте в Search Console – раздел “Canonicals” покажет, если Google выбрал другой canonical, чем вы указали

Crawl budget – почему он важен

Google не крадет весь сайт за раз. У каждого сайта есть crawl budget – количество URL, которое Google обойдет за день (или неделю для больших сайтов).

Большой сайт (100k+ страниц) может получить budget 1000 URLs/день. Если вы:

Не удаляли 404-и,
Не заблокировали параметры сессии,
Оставили 50 версий каждого товара (разные сортировки),

– то 700 из 1000 URLs будут потрачены на мусор. Ваши ценные новые статьи, которые вы опубликовали, останутся недоиндексированными.

Кейс: E-commerce магазин с 10k товаров потратил 500 URLs/день на параметрические дубли (разные сортировки, фильтры). После блокировки параметров в robots.txt и добавления canonical тегов:

Google начал индексировать новые товары в 2x быстрее
Новые товары появлялись в поиске за 2-3 дня вместо недели

2. Скорость загрузки и Core Web Vitals (Performance)

Метрики:

Метрика	Хорошо	Нужно улучшить	Ужасно
LCP (Largest Contentful Paint)	< 2.5 сек	2.5-4 сек	> 4 сек
INP (Interaction to Next Paint)	< 200 мс	200-500 мс	> 500 мс
CLS (Cumulative Layout Shift)	< 0.1	0.1-0.25	> 0.25
TTFB (Time to First Byte)	< 800 мс	800-1800 мс	> 1800 мс

LCP – это метрика, которую видит пользователь. Она измеряет, когда загружается основное содержимое страницы (чаще всего большое изображение выше сгиба или блок текста). Если LCP > 2.5 сек, уже 25% пользователей уходят.

INP заменил старый First Input Delay (FID). Это отзывчивость: когда пользователь кликает кнопку, появляется ли реакция сайта за 200 мс? Если нет – users считают сайт “зависшим”.

CLS – это визуальная стабильность. Когда вы читаете текст, и вдруг реклама загружается сверху, текст прыгает вниз, и вы кликаете не на то? Это плохой CLS.

TTFB – первый байт данных от сервера. Хороший TTFB зависит от:

Версии PHP (чем новее, тем быстрее)
Database queries оптимизации
Кеширования
Хостинга качества

Оптимизация для WordPress

Reduce TTFB (Time to First Byte):

Обновите PHP на актуальную версию (PHP 8.2+). Каждая новая версия = 10-20% ускорение
Включите кеширование:
- На уровне хостинга (попросите у провайдера включить Nginx cache или Object caching)
- Плагины: WP Super Cache, Jetpack Boost (бесплатно), WP Rocket (платно)
- Кеширование создает статические HTML копии страниц, экономя PHP/MySQL обработку
Оптимизируйте БД:
- Удалите трэш посты, ревизии постов, спам комментарии
- Плагин: WP Sweep или WP-Optimize
Используйте CDN (Cloudflare, KeyCDN, AWS CloudFront)
- Раздает статические ассеты (CSS, JS, images) с серверов ближе к пользователям
- Cloudflare бесплатный план уже неплохо помогает
Ограничьте плагины – каждый плагин = дополнительные queries. Оставляйте только нужные

Optimize LCP (Largest Contentful Paint):

LCP элемент часто – изображение выше сгиба. Для оптимизации:

Конвертируйте изображения в AVIF/WebP:
- AVIF: 50% меньше чем WebP, 65% меньше чем JPEG (при том же качестве)
- Поддержка AVIF еще не 100%, поэтому используйте fallback:

xml<picture>
  <source srcset="image.avif" type="image/avif">
  <source srcset="image.webp" type="image/webp">
  <img src="image.jpg" alt="Description">
</picture>

НЕ ленивозагружайте LCP элемент:

xml<!-- НЕПРАВИЛЬНО: LCP изображение будет загружаться медленнее -->
<img src="hero.jpg" loading="lazy" />

<!-- ПРАВИЛЬНО: укажите fetchpriority -->
<img src="hero.jpg" fetchpriority="high" loading="eager" />

Минифицируйте CSS/JS:
- Инструменты: UglifyJS (JS), CSSNano (CSS)
- Плагины WordPress: Autoptimize (бесплатный), WP Super Minify
- Удалите unused CSS (например, если используете Gutenberg, не нужен весь CSS от Elementor)
Defer non-critical JavaScript:

xml<!-- Критичный скрипт -->
<script src="critical.js" defer></script>

<!-- Некритичный - загружается после main content -->
<script src="analytics.js" async></script>
<script src="ads.js" async></script>

Inline critical CSS:

xml<style>
/* Только стили для above-the-fold контента */
body { font-family: Arial; }
.hero { background: blue; }
</style>
<link rel="stylesheet" href="main.css" media="print" onload="this.media='all'">

Blocksy theme кейс: Бесплатная тема Blocksy достигает 0.8 сек LCP благодаря:

Code splitting (webpack)
Bundling и minification CSS/JS
Smart conditional loading
Встроенная оптимизация шрифтов

Просто выбор правильной theme может дать 50% улучшение LCP без особых затрат.

INP и CLS оптимизация

INP (Interaction to Next Paint) < 200 мс:

Минимизируйте JavaScript на main thread
Избегайте длинных скриптов без точек прерывания
Используйте Web Workers для тяжелых вычислений
Оптимизируйте события (debounce, throttle для частых вызовов)

CLS < 0.1:

Зарезервируйте место для объявлений и встроек (определите фиксированный height)
Загружайте шрифты правильно (используйте font-display: swap)
Избегайте top-вставок (реклама вверху таблицы вызывает прыжок контента)

Тестирование скорости

Google PageSpeed Insights:

Заходите на https://pagespeed.web.dev/
Вводите URL
Видите LCP, INP, CLS с рекомендациями
Значения берутся из реальных данных пользователей (Chrome UX Report) + synthetic test

GTmetrix: более детальный анализ, видны filmstrips, opportunities по изображениям

WebPageTest: для глубокого анализа, можно симулировать 3G, разные браузеры

Lighthouse (Chrome DevTools):

Откройте DevTools → Lighthouse
Выберите “Performance”
Запустите тест
Увидите LCP, FCP, CLS, неиспользуемый JavaScript

3. Мобильная адаптация (Mobile-First Indexing)

Факт 2024-2025: Google полностью перешел на mobile-first indexing к июлю 2024. Это не значит, что desktop не индексируется – это значит, что мобильная версия вашего сайта = основная версия для ранжирования.

Если мобильная версия медленная, имеет плохой UX или не имеет контента – ваш рейтинг упадет, даже если desktop идеален.

Проверки:

Google Mobile-Friendly Test:
- Откройте https://search.google.com/test/mobile-friendly
- Введите URL
- Видите стандартные ошибки: viewport не настроен, текст слишком маленький, touch-элементы слишком близко
Viewport метатег (обязателен):

xml<meta name="viewport" content="width=device-width, initial-scale=1.0">

Без этого Google считает сайт “не для мобилок”.

Touch-элементы:
- Минимальный размер кнопки: 48×48 px (не 24×24 px)
- Минимальное расстояние между ссылками: 8 px
- Если пользователь часто тыкает не на то – это плохо для UX и для CLS
Медиа (изображения, видео):
- Используйте responsive images с srcset
- На мобилках не загружайте полноразмерные изображения (1920×1080)
- Смотрите пункт “Оптимизация изображений” выше
Адаптивный дизайн (не AMP):
- Одна HTML структура, которая адаптируется через CSS media queries
- Это лучше, чем AMP (Accelerated Mobile Pages), которая усложняет архитектуру
Мобильный контент:
- Контент должен быть идентичным между desktop и mobile версией
- Не скрывайте важный контент за display:none на мобилках (Google видит HTML, но может не оценить это)
- То же количество заголовков, ссылок, изображений, структурированные данные

Миграция на mobile-first: 60%+ трафика интернета с мобилок. Если ваш сайт работает хорошо только на desktop, вы теряете половину потенциального трафика.

4. Код, разметка и структура (On-Page Technical)

HTML-разметка

Иерархия заголовков H1-H6:

Один H1 на странице (не 5-10)
H1 = основной заголовок страницы
H2, H3 = подразделы в логическом порядке
Не прыгайте с H1 прямо на H3 (нарушает структуру)

xml<h1>Лучшие способы оптимизации LCP</h1>
  <h2>1. Оптимизация изображений</h2>
    <h3>1.1. Конвертация в WebP</h3>
    <h3>1.2. Compression</h3>
  <h2>2. Минификация CSS</h2>

Мета-теги:

Title (55-60 символов): основной ключ + бренд. Видно в поиске и браузере
Meta Description (155-160 символов): кратко о странице. Это то, что видят в выдаче Google
Meta robots: index, follow (по умолчанию), noindex (не индексировать), nofollow (не переходить по ссылкам)
Charset: <meta charset="utf-8">
Canonical: уже обсуждали выше

Пример:

xml<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>Технический SEO-аудит: полный чек-лист 2025</title>
<meta name="description" content="Пошаговое руководство по диагностике инфраструктуры сайта. Проверка robots.txt, Core Web Vitals, мобильной адаптации с готовым ТЗ.">
<meta name="robots" content="index, follow">
<link rel="canonical" href="https://example.com/technical-seo-audit">

Структурированные данные (Schema.org)

Google использует структурированные данные, чтобы понять, о чём ваша страница, и показать в поиске rich snippets (звёзды рейтинга, цена, наличие товара).

JSON-LD format (рекомендованный Google):

json<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "Технический SEO-аудит",
  "description": "Пошаговое руководство",
  "image": "https://example.com/image.jpg",
  "author": {
    "@type": "Person",
    "name": "Иван Петров"
  },
  "datePublished": "2025-01-20",
  "dateModified": "2025-01-25"
}
</script>

Частые типы:

Article – для блога, новостей
Product – для товаров (цена, наличие, рейтинг)
LocalBusiness – для локальных компаний (адрес, телефон, часы)
Organization – для компании в целом

Валидация:

Используйте Google’s Rich Results Test: https://search.google.com/test/rich-results
Проверьте структурированные данные, нет ошибок
Дождитесь rich snippet в поиске (может занять дни)

JavaScript SEO

Если ваш сайт на React, Vue, Angular – контент загружается через JavaScript. Google может это обработать, но медленнее и сложнее.

Server-Side Rendering (SSR) vs Client-Side Rendering (CSR):

Метрика	SSR	CSR
Начальная загрузка	Быстро (полный HTML)	Медленно (нужен JS)
Индексация	Быстро, надежно	Медленно, требует рендеринга
SEO	Лучше	Хуже
Серверная нагрузка	Выше	Ниже

SSR: сервер генерирует полный HTML, отправляет браузеру готовую страницу. Google получает полный HTML сразу, индексирует быстро.

CSR: сервер отправляет пустой HTML (только <div id="app"></div>), браузер загружает JS, JS рендерит контент. Google может это обработать, но:

Медленнее (нужен extra crawl для рендеринга)
Рискует (если JS не загрузится – контента нет)

Для максимальной надежности SEO используйте SSR или гибридный подход (Next.js, Nuxt).

Тестирование:

Google Search Console → URL Inspection → посмотрите, видит ли Google контент
Lighthouse → сравните “фото” страницы (как видит Google) с реальной версией

Внутренние ссылки

Структура URL (ЧПУ – человекочитаемые URL):

❌ Плохо: example.com/page.php?id=123&lang=ru&utm=email
✅ Хорошо: example.com/ru/blog/technical-seo-audit/

Хорошие URL:

Описательные (содержат ключ)
Короткие (< 75 символов)
На латинице (кириллица вызывает проблемы с кодированием)
Иерархичные (категория/подкатегория/страница)

Орфанные страницы – нет входящих ссылок:

Такие страницы Google находит медленнее
Не получают link equity от других страниц
Решение: добавьте ссылки с related страниц

Глубина вложенности (кликов от главной):

Идеально: ≤ 3 клика от главной до любой страницы
Глубже 4 кликов → риск, что Google не найдет

Проверить в Screaming Frog: Menu → Visualization → Crawl Depth.

5. Безопасность и протоколы (Security)

SSL/HTTPS

Обязательно:

Каждый сайт должен быть на HTTPS (даже личные блоги)
Google усилил рейтинг-влияние HTTPS с 2015 года
Браузеры показывают “Not Secure” для HTTP

Проверки:

SSL-сертификат валиден:
- Не просрочен
- Цепочка доверия не нарушена (все промежуточные сертификаты на месте)
- Используйте инструмент Qualys SSL Test: https://www.ssllabs.com/ssltest/
HTTP → HTTPS редиректы (301):

text# .htaccess
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Проверьте: http://example.com → должен редиректить на https://example.com с кодом 301.

Нет mixed content (смешанного контента):

Если страница на HTTPS, все ресурсы (images, scripts, styles) должны быть на HTTPS
Если изображение на http:// в HTTPS странице → браузер не загружает, консоль выдает ошибку

Проверить в Chrome DevTools → Console → ищите “Mixed Content” ошибки.

HSTS (HTTP Strict Transport Security):

textStrict-Transport-Security: max-age=31536000; includeSubDomains

Это говорит браузеру: “Всегда используй HTTPS для этого сайта в течение года.”

Защита от взлома

Проверьте на вирусы: Google Search Console → Security Issues
Избегайте iframe вставок (часто используются хакеры для инъекций)
Регулярно обновляйте CMS, плагины, WordPress версию
Используйте .htaccess/nginx конфиг для базовой защиты:

text# .htaccess - блокировка доступа к чувствительным файлам
<Files wp-config.php>
  Order allow,deny
  Deny from all
</Files>

<Files .htaccess>
  Order allow,deny
  Deny from all
</Files>

Сравнение основных инструментов для технического SEO-аудита

Типичные ошибки и чек-лист приоритизации

Вот критичные и частые ошибки, которые блокируют индексацию или вызывают потерю трафика:

Критичные (блокируют индексацию, потеря > 30% трафика)

❌ Неправильный robots.txt – блокирует главную страницу или основной контент
❌ 5xx ошибки на главной – Google не может получить доступ к сайту
❌ Отсутствие HTTPS – браузеры показывают “Not Secure”
❌ Soft 404s – 200 код, но пустые страницы (index bloat)
❌ Циклические редиректы – A → B → A → B (Google прекращает следование)

Время на исправление: 1-3 дня (срочно)

Высокий приоритет (потеря 15-30% трафика)

⚠️ Медленная мобильная загрузка (LCP > 3 сек)
⚠️ Дубли главной страницы – www vs non-www, http vs https, параметры сессии
⚠️ Битые canonical теги – указывают на 404 или редирект
⚠️ 302 вместо 301 для постоянных редиректов – Google не обновляет индекс
⚠️ Недостаточное кеширование – TTFB > 1.5 сек

Время на исправление: 1-2 недели

Средний приоритет (потеря 5-15% трафика)

🟡 Отсутствие микроразметки (Schema.org) – не видны rich snippets
🟡 Неоптимизированные изображения – не используется WebP/AVIF, нет lazy loading
🟡 Глубокая вложенность страниц – > 4 кликов от главной
🟡 Отсутствие внутренних ссылок на важные страницы
🟡 Плохая разметка заголовков – не один H1, неправильная иерархия

Время на исправление: 2-4 недели

Готовое ТЗ для разработчиков

После аудита нужно передать ошибки разработчику. Вот шаблон ТЗ:

Приоритет	Проблема	URL	Решение	Трудозатраты	Статус
Критично	Robots.txt блокирует /products/*	/robots.txt	Удалить `Disallow: /products/`, добавить только параметры в `Disallow: /?`	15 мин	⏳
Критично	500 ошибка на главной при > 100 concurrent users	https://example.com/	Увеличить server resources (PHP-FPM workers), оптимизировать database queries	4 часа	⏳
Высокий	Soft 404: страница товара возвращает 200, но “Out of Stock” без 404 код	/products/sku-12345	Возвращать 410 Gone для недоступных товаров (или 404 если товар удален)	1 час	⏳
Высокий	302 редирект для www → non-www переезда	https://www.example.com/*	Изменить на 301 редирект; проверить .htaccess или nginx config	30 мин	⏳
Высокий	LCP > 3 сек на мобилке (LCP image = hero.jpg 2MB)	/blog/post-title	Оптимизировать hero.jpg: конвертировать в WebP/AVIF, сжать до 200KB, добавить fetchpriority=”high”	2 часа	⏳
Высокий	TTFB 2.5 сек (server response)	* (все страницы)	Включить Nginx page caching, обновить PHP на 8.2+, оптимизировать slow DB queries	4 часа	⏳
Высокий	Дубли главной: example.com, www.example.com, example.com?utm_source=email	/	Настроить 301 редирект: все варианты → https://example.com/ (без www, без параметров)	1 час	⏳
Высокий	Canonical теги указывают на 404 страницы	/products/*	Проверить логику canonical в коде (CMS), убедиться, что canonical = live URL	3 часа	⏳
Средний	Schema.org Article разметка отсутствует на блоге	/blog/*	Добавить JSON-LD в template блога: `@type: Article`, headline, datePublished, author	2 часа	⏳
Средний	Изображения не конвертированы в WebP	* (все изображения)	Установить плагин Smush, включить “Convert to WebP”, добавить lazy loading	30 мин	⏳

Формат для экспорта:

Выгрузите из Screaming Frog: Menu → Export → Issues + URLs
Создайте таблицу в Google Sheets или Excel
Отправьте разработчику с сроками

Процесс проведения аудита (Workflow)

День 1-2: Сканирование

Инструмент: Screaming Frog SEO Spider

Скачайте и установите Screaming Frog (бесплатная версия до 500 URLs)
Откройте: Configuration → Include/Exclude → укажите, какие пути сканировать (исключите /admin, /temp)
Запустите crawl: нажмите Start в главном окне
Ждите (для сайта 1000 URL это ~ 10 мин)
После завершения экспортируйте:
- Вкладка “Issues” → список всех ошибок
- Вкладка “Responses” → фильтруйте по статус-кодам (5xx, 4xx, 302)
- Вкладка “Titles” → дубли, отсутствие titles

Также:

Проверьте Google Search Console → Coverage → “Excluded” и “Errors”
Проверьте логи сервера (посмотрите, что Google краулит)

День 3: Ручная проверка

Главная страница:
- Откройте в браузере, затем Ctrl+U (вид исходного кода)
- Проверьте: meta tags (title, description, viewport, canonical)
- Проверьте robots meta tag (не должно быть noindex)
- Проверьте Schema.org разметку (JSON-LD)
Google PageSpeed Insights для 3-5 ключевых страниц (главная, топ 2 товара/статьи)
- Посмотрите LCP, INP, CLS scores
- Запишите Opportunities (рекомендации)
Google Mobile-Friendly Test – проверьте мобильность
Rich Results Test (https://search.google.com/test/rich-results) – проверьте структурированные данные

День 4: Анализ метрик

Сравнение с конкурентами (ТОП-10):

Возьмите 3-5 конкурентов из ТОП-10 по целевому ключевому слову
Для каждого проверьте PageSpeed Insights → запишите LCP, INP, CLS
Сравните вашу метрику с конкурентами
Если вы отстаете на > 0.5 сек по LCP – это критичная проблема

Трендов в Search Console:

Organic Search → посмотрите, падали ли impressions/clicks в последний месяц
Если падали → коррелируйте с датой деплоя или обновления

День 5: Отчет и ТЗ

Подготовьте документ с:

Резюме: сколько критичных ошибок, сколько потеря трафика
Детали по каждой ошибке (как в ТЗ выше)
Скриншоты (из Screaming Frog, PageSpeed, Search Console)
Сроки исправления (когда вы ожидаете восстановление трафика)

Реальные кейсы внедрения

Кейс 1: WooCommerce – исправление дублей категорий

Ситуация:

E-commerce магазин одежды, 500 товаров
В Screaming Frog найдено 800+ URLs (вместо 500)
Google Search Console → Excluded: 300 URLs (параметры сортировки)

Ошибка:

/products/women/shirts?sort=price, /products/women/shirts?sort=date, /products/women/shirts?sort=newest
Каждая комбинация фильтра = отдельный URL в индексе

Решение:

Добавить canonical на все параметрические версии → главный товар
Заблокировать параметры в robots.txt: Disallow: /*?sort=*
В WooCommerce settings отключить параметры сортировки (или перейти на JavaScript сортировку без URL change)

Результат:

Google перестал краулить мусор, начал индексировать новые товары
Органический трафик +40% за 2 месяца (новые товары быстрее попали в поиск)
Index bloat снизился на 70%

Кейс 2: LCP оптимизация на Blocksy

Ситуация:

Блог на Blocksy theme, LCP 2.8 сек
Главное изображение = 3MB JPG файл

Решение:

Установить Smush плагин, конвертировать все изображения в WebP
Обновить PHP до 8.1
Включить Nginx page caching на хостинге
Добавить fetchpriority=”high” к hero image
Использовать CDN (Cloudflare)

Результат:

LCP улучшился до 1.2 сек
Сайт вышел в ТОП-3 по конкурентному запросу (был на 6-7)
Конверсия +15% (быстрее сайт = больше conversions)

Кейс 3: Миграция сайта – восстановление после 500+ 404 ошибок

Ситуация:

Сайт переехал с old.example.com на example.com
500+ URLs получили 404 ошибку
Трафик упал на 60% за неделю

Ошибка:

Забыли настроить 301 редиректы
Новые URLs имели другую структуру (old: /post-123 → new: /blog/post-title)
Google перестал индексировать старые страницы, новые еще не заиндексировал

Решение:

Срочно добавить 301 редиректы: /post-123 → /blog/post-title (для каждого URL)
Создать новую sitemap.xml с новыми URLs
Отправить в Google Search Console с пометкой “migration”
Использовать URL Inspection Tool: запросить переиндексацию топ-50 URLs вручную
Мониторить Coverage отчет каждый день

Результат:

За 2 недели большинство старых страниц перенаправились
За 3-4 недели трафик восстановился на 90%
За 2 месяца трафик достиг нового максимума (благодаря улучшениям на новом сайте)

Часто задаваемые вопросы (FAQ)

Чем отличается технический аудит от SEO-аудита контента?

Технический аудит проверяет инфраструктуру:

Может ли Google увидеть страницу? (robots.txt, indexability)
Быстро ли она загружается? (Core Web Vitals)
Мобильная версия работает? (mobile-friendliness)
Код правильный? (meta tags, structured data, redirects)

SEO-аудит контента проверяет, подходит ли контент запросу:

Охватывает ли страница intent пользователя? (search intent)
Есть ли нужные слова и фразы? (keyword density, semantic coverage)
Конкурентна ли страница? (сравнение с ТОП-10)
Есть ли CTA и внутренние ссылки? (engagement signals)

Оба нужны. Отличный контент на медленном сайте с 500 ошибками = потерянные деньги.

Как часто нужно проводить технический аудит?

Малые сайты (< 100 страниц): раз в 3 месяца или после обновления theme/plugins
Средние сайты (100-1000 страниц): раз в месяц
Крупные сайты (1000+ страниц): раз в неделю (автоматизировано через API)
После миграции: каждый день в течение месяца

Также проводите аудит, если:

Трафик резко упал (может быть техническая ошибка)
Обновили CMS или плагины
Нанимали нового разработчика

Можно ли сделать технический аудит самостоятельно?

Для малых сайтов – да:

Скачайте Screaming Frog (бесплатная версия)
Проверьте Google Search Console
Используйте PageSpeed Insights для скорости
Вручную проверьте robots.txt, sitemap, главные страницы

Для больших сайтов – лучше нанять спеца:

Нужна глубокая диагностика (server logs analysis, JavaScript rendering issues)
Нужно сравнить с конкурентами
Нужно стратегическое руководство, не просто список ошибок

Сколько стоит технический аудит?

Малый сайт (10 страниц): 30 000 тг / 10 000 руб
Средний сайт (100-1000 страниц): 100 000-200 000 тг / 30 000-60 000 руб
Крупный e-commerce (10k+ товаров): 150 000+ тг / 50 000+ руб

Что входит:

Полный crawl (Screaming Frog)
Анализ performance (PageSpeed)
Проверка mobile-friendliness
Анализ структурированных данных
Report с ТЗ для разработчика
1-2 консультации по реализации

ROI обычно в 3-5x за 3-6 месяцев (увеличение трафика после исправления ошибок).

Итого: чек-лист для немедленного действия

Если вы уходите и вам нужно срочно проверить свой сайт:

Откройте Google Search Console → Coverage → посмотрите, есть ли ошибки
Проверьте robots.txt: не блокирует ли он основной контент (заходите на https://example.com/robots.txt)
Откройте PageSpeed Insights → посмотрите LCP (должно быть < 2.5 сек)
Проверьте Google Mobile-Friendly Test
В исходном коде (Ctrl+U) найдите один H1, meta description, canonical tag
Проверьте, есть ли Schema.org разметка (поиск по <script type="application/ld+json">)
Убедитесь, что сайт на HTTPS (в адресной строке замок, не предупреждение)
Скачайте Screaming Frog, проползите сайт, посмотрите Issues

Если найдёте критичные ошибки – немедленно передайте разработчику.

Успехов в оптимизации! 🚀