Технический SEO — это работы, благодаря которым Google без препятствий сканирует, рендерит и индексирует ваш сайт. Международный термин — technical SEO. Правило простое: если Google не может прочитать страницу, качество контента не имеет значения — этой страницы в поиске просто нет.
- Всё строится на трёх вопросах: может ли Google просканировать сайт, отрендерить его и проиндексировать?
- Охват: индексация, скорость и Core Web Vitals, мобильная версия, коды состояния и редиректы, канонические URL, рендеринг JavaScript, структурированные данные.
- Результат часто виден быстро — эффект технических правок обычно проявляется в Search Console за дни или недели.
- Сам по себе технический SEO не даёт позиций; он условие того, чтобы заработало всё остальное.
Что такое технический SEO
Поиск Google работает в три этапа: сканирование, индексирование и выдача результатов. Технический SEO отвечает за первые два. Контент и авторитет играют роль на третьем — но страница, не прошедшая первые два этапа, до него не доходит.
На сайтах с JavaScript между ними появляется ещё один этап. Документация Google перечисляет их так: «1. Crawling 2. Rendering 3. Indexing» — бот скачивает файл, исполняет его как браузер и только потом индексирует. Если рендеринг падает, контент есть, но Google его не видит.
Проверить все три пункта на своём сайте можно бесплатно — через Search Console. Как её читать, объясняем отдельно: что такое Google Search Console. Общая картина: что такое SEO и как оно работает.
Когда это приоритет
Технический SEO не всегда стоит первым в очереди. Но если есть один из симптомов ниже — должен.
| Симптом | Вероятная техническая причина |
|---|---|
| Страницы вообще не появляются в Google | Блокировка в robots.txt, тег noindex, ошибка canonical, проблема с sitemap |
| Много «Discovered — currently not indexed» в Search Console | Краулинговый бюджет, объём малоценных страниц, слабая перелинковка |
| Мобильный трафик сильно отстаёт от десктопного | Нехватка контента в мобильной версии, проблемы рендеринга |
| Сайт переехал или сменил дизайн — трафик упал | Сломанные цепочки редиректов, изменённые URL, потерянные canonical |
| Страницы открываются заметно медленно | Core Web Vitals — проблемы LCP, INP и CLS |
| Товары и услуги не попадают в расширенные результаты | Структурированных данных нет или они с ошибками |
Верно и обратное: для небольшого быстрого сайта, который индексируется без проблем, технических работ мало — бюджет разумнее направить в контент.
Что входит в технический SEO
1. Сканирование и индексация
robots.txt, sitemap.xml, директивы индексации, структура внутренних ссылок и краулинговый бюджет. Самая частая ловушка здесь — сочетание noindex с блокировкой в robots.txt. Документация Google говорит прямо: «For the noindex rule to be effective, the page or resource must not be blocked by a robots.txt file, and it has to be otherwise accessible to the crawler.» Закроете страницу в robots.txt — бот никогда не увидит noindex, и страница может остаться в индексе.
При этом краулинговый бюджет — проблема не для всех. Google задаёт порог в цифрах: крупные сайты от миллиона уникальных страниц и сайты от 10 000 страниц с ежедневно меняющимся контентом. Ниже этого тратить на него время не нужно. Что означают статусы индексации: отчёт «Индексирование страниц».
2. Скорость и Core Web Vitals
Метрики пользовательского опыта Google состоят из трёх показателей, «хорошие» пороги (для 75% пользователей) такие:
| Метрика | Что измеряет | «Хороший» порог |
|---|---|---|
| LCP — Largest Contentful Paint | Скорость появления основного контента | 2,5 секунды или меньше |
| INP — Interaction to Next Paint | Скорость отклика на нажатия и клики | 200 миллисекунд или меньше |
| CLS — Cumulative Layout Shift | Визуальная стабильность — скачки вёрстки | 0,1 или меньше |
Важно: прежняя метрика FID в 2024 году выведена из состава Core Web Vitals, её место занял INP — если видите аудит с отчётом по FID, он устарел. О влиянии на ранжирование Google высказывается точно: «Core Web Vitals are used by our ranking systems», но «There is no single signal» — скорость сама по себе не волшебная кнопка, релевантность всегда важнее.
3. Мобильная версия (mobile-first индексация)
Определение Google: «Google uses the mobile version of a site's content, crawled with the smartphone agent, for indexing and ranking.» Практический вывод: контента, которого нет в мобильной версии, для Google не существует. Дизайн может отличаться — аккордеоны, вкладки и свёрнутые блоки допустимы — но сам текст должен присутствовать.
4. Коды состояния, редиректы и canonical
Ответ сервера — это прямая инструкция для Google. Цепочки редиректов, битые ссылки, корректная обработка удалённых страниц и канонические сигналы для дублей — всё здесь. Подробности: HTTP-коды состояния и SEO, 301 и 302, 404, 410 и soft 404.
5. Рендеринг JavaScript
На SPA и сайтах с тяжёлым JS проверяем, как контент реально доходит до бота. Google предупреждает: «Google Search won't render JavaScript from blocked files or on blocked pages» — один JS- или CSS-файл, закрытый в robots.txt, способен сделать целую страницу пустой. Рекомендуется server-side рендеринг или пререндер, потому что «not all bots can run JavaScript».
6. Структурированные данные (schema markup)
Разметка товаров, услуг, статей, FAQ и данных организации в формате, который понимает Google. При корректном внедрении открывает доступ к расширенным результатам и закрепляет бренд как сущность: schema markup и связывание сущностей.
Инструменты технического SEO, которые мы используем
В аудите технического SEO каждое утверждение подтверждается измерением. Вот набор:
| Инструмент | Для чего используем |
|---|---|
| Google Search Console | URL Inspection — как страницу видит Google, статусы индексации, отчёт Core Web Vitals, управление sitemap. |
| Screaming Frog SEO Spider | Полное сканирование: цепочки редиректов, битые ссылки, дубли заголовков и canonical, анализ глубины. |
| PageSpeed Insights | LCP, INP и CLS — лабораторные и реальные пользовательские данные (CrUX). |
| Lighthouse | Аудит производительности, доступности и лучших практик на уровне страницы; повторный замер после правок. |
| Chrome DevTools | Блокирующие ресурсы, сетевой водопад, ошибки JS — здесь находим настоящую причину медленной загрузки. |
| Chrome UX Report (CrUX) | Полевые данные реальных пользователей и сравнение с конкурентами. |
| Rich Results Test | Проверка того, что структурированные данные действительно считываются Google. |
| Schema Markup Validator | Общая корректность синтаксиса Schema.org, включая ошибки, которые не ловит тест Google. |
| Ahrefs Site Audit | Регулярные автоматические сканирования и динамика проблем во времени. |
| Semrush Site Audit | Оценка технического здоровья и второй источник для приоритизации. |
| web.dev — Core Web Vitals | Официальный источник порогов и методики; передаём разработчикам как справочник. |
Для быстрых первичных проверок можно воспользоваться и бесплатными SEO-инструментами на нашем сайте.
Как идёт аудит: пять этапов
- Полное сканирование (1–3 дня). Сайт сканируется так, как его видит бот: все URL, коды состояния, canonical, заголовки и глубина перелинковки.
- Сверка с тем, что видит Google. Результат сопоставляется с данными Search Console — какие страницы в индексе, какие нет и почему. Расхождение всегда самая ценная информация.
- Замер производительности. LCP, INP и CLS измеряются по типам шаблонов (главная, категория, товар, блог), выделяется корневая причина.
- Приоритизированный отчёт. По каждой проблеме три колонки: влияние, сложность внедрения и конкретное решение — на языке, понятном разработчику.
- Внедрение и повторная проверка. Правки вносим сами или передаём вашей команде, затем повторяем те же замеры, чтобы изменение подтвердилось цифрами.
Самые частые ошибки
С этим мы сталкиваемся примерно на каждом втором аудите технического SEO — список можно использовать как первичную самопроверку.
- noindex, оставшийся с тестового окружения. Сайт вышел в продакшн, а в шаблоне забыт
noindex— страницы месяцами не попадают в индекс. - CSS/JS, закрытые в robots.txt. Google видит пустую или сломанную страницу, потому что не рендерит из заблокированных файлов.
- Страницы пагинации с canonical на самих себя.
?page=2и?page=3начинают конкурировать с основным листингом. - Цепочки редиректов. A → B → C → D. Каждое звено теряет сигнал и расходует краулинговый бюджет.
- Дубли http/https и www/без-www. Один и тот же контент доступен по четырём адресам.
- Нехватка контента в мобильной версии. Текст есть на десктопе, но отсутствует в мобильном шаблоне — при mobile-first индексации этого контента нет.
- 404 и редиректы внутри sitemap. Google получает недостоверный список, доверие к нему падает.
- Неоптимизированные изображения. Самая частая причина проблем с LCP: огромные файлы без заданных размеров.
Когда появится результат
Преимущество технической работы в том, что результат обычно виден быстрее, чем от контента. После снятия блокировки индексации страницы могут попасть в индекс за дни; правки по скорости, опираясь на данные реальных пользователей, проявляются в отчёте Core Web Vitals по мере заполнения 28-дневного окна измерения.
Гарантий при этом нет. В документации Google сказано: «No one can guarantee a #1 ranking on Google.» Техническая работа открывает возможность видимости — наполняют её контент и авторитет.
Отличие от ежемесячной услуги
| Формат | Что даёт | Кому подходит |
|---|---|---|
| Технический SEO (эта страница) | Глубокий технический аудит и внедрение правок, проектный формат | Бизнесу с техническими проблемами или при запуске нового сайта |
| SEO-аудит | Только анализ и приоритизированный список задач, внедрение на вас | Бизнесу со своими разработчиками |
| SEO-услуга | Техника + контент + авторитет + ежемесячные замеры, непрерывный цикл | Тем, кто делает органику основным каналом продаж |
На практике порядок такой: сначала техническая база, потом ежемесячная работа. В обратном порядке деньги, вложенные в контент, утекают через технические дефекты.
От чего зависит цена
Стоимость проекта по техническому SEO не фиксирована — объём работ зависит от пяти факторов:
- Количество URL — сканирование сайта на 50 страниц и каталога на 50 000 товаров это разная работа.
- Платформа — готовая CMS, самописная система или JS-фреймворк (React, Vue, Next.js) требуют разного подхода.
- Кто внедряет — правки вносим мы или ваш разработчик.
- Языки и регионы — hreflang и многоязычные canonical это отдельный объём работ.
- Глубина проблемы — несколько правок или структурная переработка.
Состав пакетов: цены на SEO. Расчёт по вашему сайту: получить предложение.
Частые вопросы
Технический SEO делается один раз?
Основной объём работ проектный и заканчивается. Но сайт живой: новые страницы, новые функции и обновления плагинов создают технический долг. Контрольное сканирование раз-два в год оправдано.
Если сайт быстрый, позиции вырастут?
Сами по себе — не гарантированно. Google пишет, что Core Web Vitals используются системами ранжирования, но также что «There is no single signal», и релевантность всегда весомее. Скорость решает, когда два результата в остальном равны.
У нас есть разработчик — нужны ли вы?
Часто это лучшая модель: мы определяем, что менять, зачем и в каком порядке, а ваш разработчик внедряет. Так быстрее и дешевле.
Нужно ли переделывать сайт?
Чаще всего нет. Переделку предлагаем только когда препятствием является сама платформа, и этот вывод следует из аудита, подкреплённого цифрами.
Вижу отчёт по FID — это нормально?
Нет. FID выведен из Core Web Vitals в 2024 году, его заменил INP. Инструмент или подрядчик, отчитывающийся по FID, работает по устаревшей методике.
После переезда упал трафик — это восстановимо?
Обычно да. Большая часть потерь при переезде — сломанные редиректы, изменённая структура URL и потерянные canonical, и всё это исправимо. Чем раньше вмешаться, тем меньше потери.