Что входит в техническое SEO: разбор глазами разработчика
Техническое SEO ставит в тупик большинство владельцев сайтов. Контент вроде есть, ссылки есть, а в поиске сайт либо не виден, либо стоит намного ниже, чем должен. В большинстве случаев причина именно в техническом слое: бот не может нормально прочитать страницу, или читает её не ту версию, или страница грузится слишком долго по меркам мобайла.
Меня зовут Евгений Волков, я fullstack-разработчик, и техническое SEO для меня это не отдельная дисциплина, а часть каждого проекта. Когда строишь сайт на Nuxt или React с нуля, все эти настройки закладываешь сразу: правильный рендер, canonical, sitemap, JSON-LD. Когда приходишь на аудит готового сайта, задача другая: найти, что именно мешает поиску работать, и починить в порядке приоритета. В этом тексте я разберу, что входит в техническое SEO блок за блоком, и объясню, что из этого делает разработчик, а что лежит в зоне SEO-специалиста.
Что такое техническое SEO и чем оно не является
Коротко: техническое SEO обеспечивает, чтобы поисковый робот мог найти страницу, прочитать её содержимое и правильно понять, о чём она. Без этого фундамента всё остальное работает вхолостую.
Хорошая метафора: контент и ссылки это груз. Техническое SEO это дорога, по которой этот груз доставляется к поиску. Если дорога разбита, груз не доедет, или доедет не туда.
Техническое, контентное, ссылочное: где граница
SEO принято делить на три ветки.
Контентное SEO отвечает на вопрос «что написано»: текст, ключевые слова, структура заголовков, внутренние ссылки, объём и польза материала. Ссылочное SEO про авторитет: сколько других сайтов ссылается на вас и насколько они сами весомы. Техническое SEO про устройство: как сайт отдаёт контент роботу, как он устроен в коде, насколько он быстр.
Граница часто размыта. Canonical это технический тег, но он решает, за каким URL закрепляется вес ссылок. Заголовок H1 контентный элемент, но его правильный рендер на стороне сервера это уже техника. На практике я не делаю жёсткого разделения: смотрю на задачу, а не на её категорию.
Почему без технической базы контент и ссылки работают вхолостую
Представьте: вы написали отличную статью, получили несколько обратных ссылок, но страница закрыта в robots.txt или отдаёт noindex. Поисковик её попросту игнорирует. Или рендер сайта сделан на чистом SPA без SSR: бот приходит, видит пустой HTML-каркас и не может прочитать ни слова контента. Или canonical страницы ведёт на другой URL. Вы сами сливаете вес в другое место.
Технические проблемы бывают двух видов. Одни полностью блокируют индексацию: это критические дефекты, исправляются первыми. Другие снижают потенциал без полного блока: медленный LCP, отсутствие structured data, неоптимальные URL. С ними тоже надо работать, просто в следующую очередь.
Что входит в технический аудит: 8 блоков
Структурирую технический SEO-аудит по восьми блокам. Ниже таблица-чеклист, потом разберу каждый.
| Блок | Что проверяем | Кто чинит |
|---|---|---|
| 1. Краулинг и индексация | robots.txt, sitemap.xml, noindex, crawl budget | Разработчик + SEO |
| 2. JavaScript-рендеринг | SSR vs SPA, отрендеренный HTML, видимость контента | Разработчик |
| 3. Дубли и canonical | canonical-теги, параметры URL, www vs apex | Разработчик + SEO |
| 4. Скорость и Core Web Vitals | LCP, INP, CLS, TTFB, PageSpeed score | Разработчик |
| 5. Структура URL | ЧПУ, 301-редиректы, цепочки, глубина вложенности | Разработчик + SEO |
| 6. Мобайл / mobile-first | viewport, mobile UX, адаптив, mobile-friendly тест | Разработчик |
| 7. HTTPS и безопасность | сертификат, mixed content, заголовки безопасности | Разработчик |
| 8. Микроразметка Schema.org | JSON-LD, типы, валидация, FAQPage, BreadcrumbList | Разработчик + SEO |
1. Краулинг и индексация: robots.txt, sitemap.xml, noindex
Первое, что проверяю на любом сайте: открыт ли он вообще для поиска. Звучит банально, но Disallow: / в robots.txt это самая разрушительная ошибка из всех. Она обнуляет всё. На стейджинге сайт часто закрывают намеренно, а потом запускают в прод, забыв убрать это правило.
# Правильный robots.txt: открываем всё, закрываем только служебное
User-agent: *
Allow: /
Disallow: /admin/
Disallow: /api/
# Скармливаем боту карту сайта явно
Sitemap: https://evolkov.tech/sitemap.xml
Sitemap.xml должен содержать только индексируемые страницы, без noindex-мусора. Динамику (посты блога, карточки товаров) добавляем через серверный источник. После публикации карту нужно явно передать в Google Search Console и Яндекс.Вебмастер.
noindex на конкретной странице ставится через мета-тег robots в <head>. Для юридических и служебных страниц это правильно. Для коммерческих посадочных или статей блога это катастрофа.
Crawl budget важен для больших сайтов: если у вас тысячи страниц, бот не будет обходить все из них на каждом визите. Помогает чистый sitemap, правильная перелинковка и закрытие от краулинга бесполезных параметров (UTM, фильтры сортировки).
2. JavaScript-рендеринг: почему SPA невидим для бота и как SSR это решает
Это самая критичная техническая проблема для современных фронтендов. Чистый SPA (Vue, React без SSR) отдаёт боту пустой HTML-каркас. Весь контент появляется позже, когда браузер выполнит JavaScript. Бот либо видит пустоту, либо ждёт. Медленно и ненадёжно.
SSR (рендер на сервере) или prerender (рендер на сборке) решают это в корне: бот получает готовый HTML с текстом, заголовками и метатегами прямо на первом запросе.
Проверить это просто:
# Смотрим сырой HTML без выполнения JS
curl -s https://example.com | grep '<h1'
Если команда возвращает ваш заголовок: рендер работает. Если пусто, сайт виден боту как пустая страница.
На сайтах на Nuxt с SSR этой проблемы нет. На кастомных React-SPA без Next.js она возникает практически всегда. Про настройку рендера конкретно под Nuxt я написал подробно в разборе SEO для Nuxt: индексация, sitemap и метатеги.
3. Дубли и canonical: откуда берутся и как не наплодить
Дубли возникают незаметно. Один и тот же контент доступен по нескольким адресам: example.com, www.example.com, example.com/, example.com/index.html. Поисковик не понимает, какой из них главный, вес размазывается между ними.
Canonical-тег говорит поиску: «эта страница: единственный правильный адрес этого контента». Проставляется в <head> каждой страницы.
<!-- В Nuxt: canonical через useSeoMeta или useHead -->
<script setup lang="ts">
const route = useRoute()
useHead({
link: [
{
rel: 'canonical',
href: `https://evolkov.tech${route.path}`
}
]
})
</script>
Три правила, которые нельзя нарушать. Canonical должен быть абсолютным URL с протоколом и доменом. Он должен совпадать с URL в sitemap и во внутренних ссылках. На нормальной уникальной странице он ссылается сам на себя.
Параметры URL (UTM, фильтры, сортировка) часто создают технические дубли. Для фильтров и пагинации проблему решают либо noindex на отфильтрованные страницы, либо canonical, указывающий на базовую страницу без параметров.
4. Скорость и Core Web Vitals: LCP, INP, CLS
С 2021 года Google официально учитывает Core Web Vitals как сигнал ранжирования. Три метрики:
- LCP (Largest Contentful Paint): за какое время появляется самый крупный элемент первого экрана. Цель: менее 2,5 секунды.
- INP (Interaction to Next Paint): отзывчивость на клики и ввод. Пришёл на замену FID в 2024. Цель: менее 200 мс.
- CLS (Cumulative Layout Shift): насколько вёрстка прыгает во время загрузки. Цель: менее 0,1.
Что убивает LCP чаще всего: неоптимизированные изображения (JPG вместо WebP, без явных размеров), тяжёлый рендер-блокирующий CSS, медленный TTFB сервера. Что убивает CLS: картинки и iframe без указанных ширины и высоты, шрифты без font-display: swap, динамически вставляемые баннеры.
На проектах на Nuxt я замечал: 3D-герой в первом экране одним своим весом обваливает LCP на мобайле. Оптимизация ассетов и отложенная загрузка Three.js дают быстрый выигрыш. Весь процесс ускорения, бандл, изображения, DevTools, я разобрал отдельно в гайде по ускорению сайта.
5. Структура URL: ЧПУ, 301-редиректы, цепочки
Человекопонятные URL (ЧПУ, slug) помогают и пользователям, и поиску. /blog/chto-vhodit-v-tehnicheskoe-seo лучше, чем /blog?id=4821&cat=7. Ключевое слово в slug: дополнительный сигнал о теме страницы.
301-редирект сообщает поиску, что страница переехала навсегда. Вес (PageRank) частично передаётся на новый адрес. 302 означает временный переезд и вес не передаёт. Это частая ошибка при смене URL.
Цепочки редиректов это медленно и плохо: A → B → C вместо прямого A → C. Каждое лишнее звено замедляет краулинг и тратит бюджет обхода. Проверяется краулером (Screaming Frog) или в ответах сервера.
Глубина вложенности желательно не более 3–4 уровней от главной. Страница, до которой надо кликнуть 8 раз, краулится реже.
6. Мобайл и mobile-first индексация
Google с 2019 года переключился на mobile-first индексацию: он ранжирует именно мобильную версию сайта, а не десктопную. Если мобильная версия отличается от десктопной (спрятан контент, другие метатеги, нет части ссылок), Google ранжирует по худшей.
Viewport мета-тег обязателен: <meta name="viewport" content="width=device-width, initial-scale=1">. Без него Google считает сайт не адаптированным.
Проверяется в Google Search Console (отчёт «Удобство для мобильных устройств») и через инструмент Mobile-Friendly Test. На практике современные фреймворки (Nuxt, Next.js) с Tailwind или аналогом делают адаптив по умолчанию, но стоит проверить отдельно для сложных компонентов: таблиц, карт, тяжёлых форм.
Отдельный момент: шрифты. Если подключаете веб-шрифты через Google Fonts, на мобайле с медленным соединением они блокируют первый рендер. Самохостинг шрифтов с font-display: swap даёт заметный прирост по LCP и убирает мигание текста при загрузке (FOUT). Мелочь, но в совокупности с другими оптимизациями это складывается в реальный прирост по Core Web Vitals.
7. HTTPS и безопасность: mixed content, заголовки
HTTPS: базовый сигнал доверия. Сайт без сертификата получает предупреждение в браузере и проигрывает в ранжировании. В 2026 году ситуация с этим простая: Let's Encrypt + Caddy или nginx настраиваются за час.
Mixed content: когда HTTPS-сайт подгружает ресурсы по HTTP (картинки, скрипты, шрифты). Браузер блокирует такие ресурсы, страница отображается некорректно, в консоли DevTools появляются предупреждения. Лечится заменой http:// на https:// в src всех ресурсов.
Заголовки безопасности (HTTP Security Headers) влияют на доверие и отчасти на поведенческие сигналы: Strict-Transport-Security (HSTS), X-Content-Type-Options, X-Frame-Options. Добавляются на уровне сервера (Caddy, nginx) без изменений в коде приложения.
8. Микроразметка Schema.org: что добавлять и зачем
Structured data объясняет поиску, что за сущность на странице: статья, товар, организация, часто задаваемые вопросы. Она не поднимает позиции напрямую, но даёт расширенные сниппеты: дату, автора, хлебные крошки, блок FAQ прямо в выдаче. Расширенный сниппет = выше кликабельность.
Подключается через JSON-LD в <head> страницы. Вот пример для блог-поста:
{
"@context": "https://schema.org",
"@type": "Article",
"headline": "Что входит в техническое SEO",
"author": {
"@type": "Person",
"name": "Евгений Волков",
"url": "https://evolkov.tech/cv"
},
"datePublished": "2026-07-26",
"dateModified": "2026-07-26"
}
Что размечать в первую очередь: Person или Organization для всего сайта (питает knowledge graph), Article на статьях с датами и автором, BreadcrumbList для крошек (часто попадают прямо в сниппет), FAQPage если на странице есть реальный FAQ, Service на коммерческих посадочных с ценой.
Главное правило: не размечай то, чего нет на странице. Фейковый aggregateRating со звёздами, которых нет в реальности, Google карает удалением расширенных сниппетов.
Что из этого чинит разработчик, а что SEO-специалист
Это самый практичный раздел. Многие SEO-задачи технически решаются только в коде. Понимание границ экономит время и деньги.
| Задача | Исполнитель | Почему |
|---|---|---|
| SSR вместо SPA, настройка рендера | Разработчик | Это архитектурное решение на уровне фреймворка |
| Canonical в шаблоне страницы | Разработчик | Нужен доступ к коду компонента |
| JSON-LD Schema.org | Разработчик | Вставляется программно в <head> |
| Исправление цепочек редиректов | Разработчик | Правится в конфиге сервера или middleware |
| Оптимизация LCP, CLS, INP | Разработчик | Код, ассеты, CSS, lazy loading |
| robots.txt и директивы noindex | Оба | Часто настраивается через CMS или конфиг |
| sitemap.xml | Оба | Генерируется автоматически модулем или плагином |
| Структура URL и слаги | Оба | SEO выбирает слаги, разработчик реализует роутинг |
| Мета-теги title и description | SEO + правки разработчика | SEO пишет тексты, разработчик подключает поле в CMS |
| Выбор ключевых слов и анализ конкурентов | SEO-специалист | Это стратегия, не код |
| Построение структуры ссылок | SEO-специалист | Анализ и стратегия, реализация через CMS |
| Контентный аудит страниц | SEO-специалист | Экспертиза в оценке качества контента |
+Плюсы
- Правильный рендер (SSR/prerender) закрывает самую критичную техническую проблему разом: бот видит готовый HTML с первого запроса.
- JSON-LD в коде не зависит от CMS и не сбивается при обновлениях платформы.
- Canonical и robots.txt настраиваются один раз и работают для всего сайта автоматически.
−Минусы
- Никакой код не заменит стратегию: выбор ключей, анализ конкурентов, построение семантического ядра. Это работа SEO-специалиста, и её нельзя «запрограммировать».
- Технически идеальный сайт без хорошего контента и внешних ссылок не попадёт в топ по конкурентным запросам.
- Некоторые CMS (особенно старые) технически ограничивают то, что можно сделать без доступа к серверу или базе данных.
Инструменты технического аудита
Инструменты можно разделить на бесплатные и платные. На бесплатных можно провести полноценный аудит небольшого сайта.
Бесплатные инструменты
Google Search Console: главный инструмент. Показывает, что Google думает о вашем сайте: какие страницы проиндексированы, какие исключены и почему, есть ли ошибки краулинга. Кнопка «Просмотреть как Google» позволяет увидеть отрендеренный HTML глазами бота. Это незаменимо для диагностики SPA-проблем.
Яндекс.Вебмастер: то же самое для Яндекса. Показывает статус индексации, ошибки, скорость загрузки, поисковые запросы. Обязателен для рунета.
PageSpeed Insights: замеряет Core Web Vitals как на полевых данных (реальные пользователи Chrome), так и в лабораторных условиях. Даёт конкретные рекомендации по каждой метрике.
Chrome DevTools: для глубокой диагностики скорости: вкладка Performance показывает, что именно тормозит. Network показывает, что и когда грузится, Lighthouse запускается прямо из браузера. Про работу с DevTools для диагностики скорости я детально разобрал в посте как проверить скорость сайта.
Платные и специализированные инструменты
Screaming Frog SEO Spider: краулер, который обходит весь сайт и собирает полный список URL, кодов ответа, заголовков, мета-тегов, дублей, редиректов. Бесплатный план до 500 URL, платный снимает ограничение. Для любого аудита крупнее визитки незаменим.
Ahrefs Site Audit: облачный краулер с подробными отчётами по техническим проблемам. Удобен тем, что не нужно запускать ничего локально и отчёты автоматизируются. Из минусов: у Ahrefs нет данных по Яндексу и российскому трафику, для рунета это ограничение.
pr-cy.ru: российский инструмент SEO-аудита. Умеет проверять мобильную версию, скорость, мета-теги, robots, sitemap, дубли. Удобен тем, что понимает специфику Яндекса и показывает рекомендации с учётом рунета.
Как это связано с разработкой на современных фреймворках
Nuxt, Next.js и другие SSR-фреймворки закрывают большую часть технического SEO по умолчанию. Это не значит, что всё настроено правильно из коробки: нужно явно прописать canonical, отдать корректный sitemap, добавить JSON-LD, настроить robots. Но архитектурная основа правильная: рендер на сервере уже правильная.
Проблемы начинаются, когда фреймворк используется как SPA-обёртка без SSR, когда canonical генерируется с www вместо apex-домена, когда в sitemap попадают noindex-страницы или служебные маршруты. Это не ошибки фреймворка, это ошибки конфигурации.
На моей практике больше всего технических SEO-проблем я нахожу именно там: sitemap c неправильным доменом, canonical, указывающий на локалхост (баг с .env в проде), цепочки редиректов после переезда, JSON-LD с пустыми полями. Ничего из этого не лечится контентом или ссылками. Только правкой кода или конфига.
Про конкретные настройки для Nuxt, включая useSeoMeta, hreflang и routeRules, я подробно написал в разборе SEO для Nuxt. Про оптимизацию производительности и Core Web Vitals на уровне бандла и ассетов: смотри пост как ускорить сайт.
Что дальше
Технический аудит это не разовая процедура, а регулярная гигиена. После запуска, после редизайна, после смены хостинга, после добавления крупного нового раздела. Каждый раз проверяешь, что роботы по-прежнему видят то, что нужно, и не видят того, что не нужно.
Начинать всегда стоит с быстрого осмотра: robots.txt открыт, GSC не показывает критических ошибок, sitemap отправлена, отрендеренный HTML содержит реальный контент. Это занимает 20 минут и закрывает самые грубые проблемы. Дальше идёт полноценный аудит по всем восьми блокам: краулинг, рендер, дубли, скорость, URL, мобайл, безопасность, разметка. Приоритет расставляется по принципу «сначала то, что вообще блокирует индексацию, потом то, что снижает потенциал».
На сайтах, которые я строю с нуля на Nuxt или React, техническая основа закладывается сразу: правильный рендер, canonical, sitemap, JSON-LD, robots. Это дешевле, чем чинить потом. На готовых сайтах прохожу аудитом и работаю по той же последовательности: сначала диагностика, потом правки с чёткими приоритетами.
Если вы хотите понять, что именно мешает вашему сайту в поиске прямо сейчас, это входит в мою услугу технического SEO. Начинаем с аудита: Google Search Console, Яндекс.Вебмастер, отрендеренный HTML, sitemap, canonical, скорость. Дальше чиним по приоритету. Стартует от 10 000 ₽, точная вилка после просмотра проекта.
