Технический SEO-аудит: что проверять и в каком порядке

Технический SEO-аудит отвечает на один вопрос: могут ли поисковики найти, отрисовать и проиндексировать страницы, которые должны приводить трафик, и понимают ли они, какая версия каждой страницы настоящая. Контент и ссылки определяют, насколько высоко страница ранжируется, а технические проблемы - участвует ли она в гонке вообще. Мы проводим такие проверки на integrono.com (18 языков), на наших продуктах и на сайтах клиентов, и одни и те же десяток проблем встречаются снова и снова.

Чек-лист написан для разработчиков и основателей, которые могут сами менять сайт. Для старта платные инструменты не нужны: хватит Google Search Console, браузера, curl и краулера вроде Screaming Frog (бесплатно до 500 URL).

Перед началом: объём и данные

• Составьте список типов страниц, которые должны ранжироваться (главная, услуги, товары, статьи, категории), и тех, которым это не нужно (корзина, внутренний поиск, фильтры, админка).
• Подтвердите домен в Google Search Console (DNS-подтверждение охватывает http, https и все поддомены) и откройте отчёты «Страницы», «Файлы Sitemap» и Core Web Vitals.
• Просканируйте сайт десктопным краулером с настройкой Googlebot smartphone и выгрузите все URL с кодом ответа, индексируемостью, canonical, title, H1 и числом слов.

1. Доступ для сканирования: добираются ли боты до страниц?

Начните с robots.txt. Он должен отдавать 200, быть обычным текстом и не блокировать CSS, JavaScript и разделы, которые нужно индексировать. Одна строка Disallow: /, оставшаяся от staging-окружения, - классическая катастрофа в день запуска.

curl -sI https://example.com/robots.txt | head -n 5
curl -s  https://example.com/robots.txt

# Good minimal example
User-agent: *
Disallow: /admin/
Disallow: /cart
Sitemap: https://example.com/sitemap.xml

Проверьте, что XML-sitemap содержит только канонические индексируемые URL с кодом 200: без редиректов, без страниц с noindex и без 404. Для многоязычных сайтов каждому URL нужны языковые альтернативы (см. наш гайд по многоязычному SEO). Отправьте sitemap в Search Console и сравните «отправлено» с «проиндексировано».

2. Коды ответа и редиректы

Каждый важный URL должен отдавать прямой 200. Проверьте варианты адресов, которые реально запрашивают люди и боты:

for u in http://example.com https://example.com https://www.example.com https://example.com/page/ https://example.com/page; do
  printf "%s -> " "$u"; curl -s -o /dev/null -w "%{http_code} %{redirect_url}\n" "$u"
done

• Один канонический хост. Контент отдаёт ровно один вариант из http/https и www/без www, остальные редиректят на него 301 за один шаг.
• Без цепочек и циклов редиректов. A на B на C тратит краулинговый бюджет и размывает сигналы, отправляйте старые URL сразу на финальный.
• Настоящие 404. Отсутствующая страница должна отдавать 404 или 410, а не страницу с кодом 200 и текстом «не найдено» (soft 404).
• Ошибки 5xx в логах или Search Console требуют немедленной реакции: частые серверные ошибки заставляют Google замедлить сканирование.

3. Индексируемость: разрешена ли страница и уникальна ли она?

Индексацию определяют три сигнала: meta-тег robots или заголовок X-Robots-Tag, canonical URL и то, не дублирует ли страница другую. Проверяйте по шаблонам, а не по отдельным страницам.

• Утечки noindex. noindex, скопированный со staging в продакшен или отправляемый в HTTP-заголовке веб-сервером, молча убирает страницы из поиска.
• Canonical. У каждой индексируемой страницы один абсолютный canonical на саму себя. Страницы пагинации и фильтры должны либо ссылаться на разумного родителя, либо быть исключены. Никогда не указывайте canonical на URL с редиректом, noindex или 404.
• Дубли. Варианты со слэшем и без, заглавные буквы в пути, UTM-параметры и версии для печати создают одну страницу по нескольким адресам. Выберите один и сделайте редирект или canonical для остальных.
• «Просканировано, но пока не проиндексировано» в Search Console обычно означает слабый или почти дублирующий контент, а не технический запрет. Улучшите страницу или объедините с другой.

curl -s https://example.com/page | grep -i -E '<link rel="canonical"|<meta name="robots"'
curl -sI https://example.com/page | grep -i -E 'x-robots-tag|^HTTP|^location'

4. Структура сайта и внутренние ссылки

Поисковики находят страницы по ссылкам и по структуре ссылок судят об их важности.

• Глубина клика. Важные страницы должны открываться не дальше чем за три клика с главной.
• Страницы-сироты. Страницы из sitemap без внутренних ссылок получают мало внимания. Сравните список краулера со списком sitemap.
• Анкоры. Используйте описательный текст («технический SEO-аудит»), а не «нажмите здесь». Ссылайтесь с сильных страниц на те, которые хотите продвинуть.
• Битые внутренние ссылки. Исправляйте ссылки, ведущие на 404 или на редиректы.
• Настоящие ссылки. Навигация на JavaScript-обработчиках клика вместо <a href> может не сканироваться.

5. Технические сигналы на странице

• Title и meta description: уникальные на каждой странице, title примерно до 60 символов, чтобы его не обрезали. Дубли и пустые поля найдите в выгрузке краулера.
• Один H1, соответствующий интенту страницы, с логичными H2/H3 ниже.
• Язык и кодировка: корректный <html lang>, везде UTF-8, валидный и взаимный hreflang.
• Изображения: понятные имена файлов, alt, современные форматы (WebP или AVIF) и явные width и height против сдвигов макета.
• Пагинация и фильтры: убедитесь, что фасетные URL не порождают миллионы сканируемых комбинаций.

6. Рендеринг и JavaScript

Google умеет выполнять JavaScript, но рендеринг стоит в очереди и иногда не удаётся. Если основной контент или ссылки появляются только после клиентского рендеринга, проверьте их в инструменте «Проверка URL» («Просмотреть просканированную страницу» и скриншот). Для контентных сайтов самый надёжный вариант - серверный рендеринг или статическая выдача. Сравните вывод curl с тем, что видно в браузере: если нужного текста нет в исходном HTML, вы зависите от рендеринга.

7. Скорость и Core Web Vitals

Пользовательский опыт страницы - фактор ранжирования умеренного веса и очень важный фактор конверсии. Смотрите отчёт Core Web Vitals в Search Console (полевые данные реальных пользователей) и запускайте PageSpeed Insights или Lighthouse на ваших шаблонах. Обычные цели: Largest Contentful Paint меньше 2,5 с, Interaction to Next Paint меньше 200 мс и Cumulative Layout Shift меньше 0,1. Типичные быстрые победы: сжать и правильно подобрать размер изображений, включить Brotli или gzip, надолго кэшировать статику, отдавать через CDN и убрать блокирующие рендеринг CSS и скрипты. PHP-часть мы разбираем в статье про Core Web Vitals для PHP-сайтов.

8. Структурированные данные

Структурированные данные сами по себе не повышают позиции, но делают страницы пригодными для расширенных результатов и помогают машинам понимать сущности. Проверяйте каждый шаблон в Rich Results Test и Schema Markup Validator. Типичные типы: Organization, BreadcrumbList, Article, FAQPage, Product с Offer, LocalBusiness. Разметка должна соответствовать тому, что пользователь видит на странице. Готовые примеры - в нашем гайде по JSON-LD.

9. Безопасность и мобильная версия

• HTTPS везде с действующим сертификатом, редирект с HTTP на HTTPS и отсутствие смешанного контента.
• Адаптивная вёрстка с правильным meta-тегом viewport: Google индексирует сначала мобильную версию.
• Никаких навязчивых оверлеев, закрывающих контент на телефоне.
• Заголовки безопасности и здоровый сервер: на ранжирование напрямую не влияют, но взломанный или медленный сайт быстро теряет позиции.

10. Расставьте приоритеты и напишите задачи

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

1. Критично: страницы закрыты, под noindex или отдают ошибки; неверный canonical на страницах, приносящих деньги; сломанные редиректы.
2. Высокий приоритет: дубли, цепочки редиректов, важные страницы-сироты, отсутствие hreflang, плохой LCP на ключевых шаблонах.
3. Средний: повторяющиеся title, отсутствие структурированных данных, вес изображений.
4. Низкий: косметические проблемы разметки.

К каждому пункту добавьте шаблон URL, доказательство (вывод команды или скриншот), ожидаемый результат и ответственного. «Исправить canonical» - не задача, а «страницы товаров с параметром ?sort= должны ссылаться canonical на чистый URL; шаблон product.php, строка X» - задача.

Как часто проводить аудит

Делайте лёгкую проверку раз в месяц (отчёты Search Console, быстрый краулинг, статус ключевых URL) и полный аудит после миграций, редизайнов, обновления фреймворка или когда трафик падает без очевидной причины. Добавьте автоматические проверки в конвейер деплоя: тест, что главная отдаёт 200, не содержит noindex и имеет ожидаемый canonical, ловит самые дорогие ошибки раньше пользователей.

Чем мы можем помочь

Если нужен экспертный взгляд на ваш сайт, наша услуга технического SEO включает аудит, исправления в коде и мониторинг, причём изменения мы можем внести сами, а не просто отдать PDF. Начните с платной консультации, если нужен приоритизированный список того, что исправлять в первую очередь. Взгляд основателя на всю SEO-стратегию - в статье SEO для основателей SaaS.