Страницы выпадают из индекса
Нужно проверить HTTP, robots, canonical, sitemap, внутренние ссылки и реальные сигналы indexability.
Crawl • Render • Index • SEO с апреля 2009 года
Технический SEO-аудит сайта
Обновлено:
Обнаружение URL → HTTP → robots → рендеринг → canonical → internal links → index
Технический SEO-аудит проверяет путь страницы до поискового индекса: может ли робот обнаружить URL, получить корректный HTTP-ответ, отрендерить содержимое, понять директивы robots и canonical и принять нужную версию страницы к индексированию. На выходе — технический backlog и ТЗ с критериями приёмки.
- Ошибки связываются с конкретными URL, шаблонами и реальным охватом.
- Отдельно проверяются JavaScript/rendering, фильтры, пагинация и массовые URL.
- После исправлений технический сигнал можно принять повторным crawl, а не «на глаз».
Стоимость после оценки
Яндекс и Google
ТЗ разработчику
repeat crawl / QA
Когда нужен технический SEO-аудит
Он полезен, когда проблема находится в техническом слое или нужно проверить сайт перед/после существенного релиза.
После миграции или смены URL
Редиректы, старые адреса, canonical, sitemap и внутренние ссылки должны согласованно вести к новой структуре.
После редизайна или нового шаблона
Один дефект шаблона способен затронуть тысячи URL: метаданные, robots, canonical, links или rendered content.
Большой каталог и фильтры
Нужно оценить URL-space, параметры, фасеты, пагинацию, crawl traps и расход обхода на технические комбинации.
Сайт зависит от JavaScript
Важно сравнить source HTML и rendered DOM и убедиться, что SEO-элементы доступны после рендеринга.
Перед масштабным SEO-внедрением
Техническая база проверяется до массовых изменений, чтобы новые страницы не наследовали системную ошибку.
Технический аудит или комплексный SEO-аудит
Разделяю эти услуги по задаче, чтобы #418 не каннибализировал #389.
Технический SEO-аудит — эта страница
Crawlability, indexability, HTTP, robots, sitemap, canonical, redirects, duplicates, JavaScript/rendering, performance, filters/pagination и технические internal links.
Комплексный SEO-аудит
Техника плюс поисковый спрос, семантика, структура, контент, коммерческие факторы, ссылки, конкуренты и аналитика бизнеса.
Не входит автоматически: аудит PHP-кода, поиск уязвимостей сервера и полноценный security-аудит. HTTPS/mixed content может быть техническим SEO-сигналом, но безопасность инфраструктуры — отдельная дисциплина.
Путь URL: crawl → render → index
Технический аудит удобнее воспринимать как последовательность этапов. Ошибка на любом из них может сделать нужную страницу недоступной или некорректно понятой поисковой системой.
Discoverробот находит URL
HTTPсервер отвечает
Robotsдирективы разрешают нужное действие
RenderHTML / JS формируют документ
Canonicalопределяется предпочтительная версия
Linksструктура подтверждает URL
Indexстраница допускается к индексу
HTTP-коды, редиректы и доступность URL
Первый вопрос — что фактически получает crawler при запросе адреса.
200 OK
Проверяю, действительно ли целевая страница отдаёт полезный документ, а не soft-404 или заглушку под статусом 200.
301 / 302 / 307 / 308
Цепочки, циклы, временные редиректы вместо постоянных и внутренние ссылки через промежуточные адреса.
404 / 410 / soft-404
Разделяю реально удалённые URL, ошибочные ссылки и страницы, которые формально отвечают 200, но не содержат полезного документа.
5xx и нестабильные ответы
Серверная ошибка блокирует получение страницы и при массовом характере может мешать нормальному обходу сайта.
Robots.txt, meta robots и X-Robots-Tag
Разные директивы решают разные задачи. Блокировка обхода и запрет индексирования — не одно и то же.
robots.txtуправляет → доступом crawler к URL/разделу
meta robotsуправляет → index/follow для HTML-документа
X-Robots-Tagпередаёт → robots-директивы через HTTP-заголовок, в том числе для не-HTML ресурсов
Отдельно проверяю противоречия: например, когда важный URL одновременно присутствует в sitemap, получает внутренние ссылки, но закрыт robots/noindex или канонизирован на другую страницу.
Sitemap.xml и согласованность технических сигналов
Sitemap — не просто файл с URL. Его состав должен подтверждать реальную индексируемую структуру сайта.
Что должно попадать
Целевые canonical URL с корректным ответом, которые действительно планируются к индексированию.
Что не должно смешиваться
404, redirect, noindex, закрытые или неканонические версии страниц не должны системно присутствовать в sitemap как целевые URL.
lastmod
Если используется, дата должна отражать реальное существенное обновление страницы, а не формально меняться при каждом экспорте.
Сигналы должны соглашаться: sitemap декларирует важный URL → canonical подтверждает его версию → internal links поддерживают структуру → robots не противоречит задаче.
Canonical, параметры и дубли страниц
Поисковая система сама выбирает каноническую версию, если сайт отправляет противоречивые сигналы. Задача аудита — найти такие противоречия.
Self-canonical
Целевая индексируемая страница обычно должна подтверждать собственный URL, если нет осознанной причины канонизировать её иначе.
Параметры URL
UTM, сортировки, фильтры, session IDs и другие параметры могут создавать дополнительные версии одного документа.
Технические зеркала
HTTP/HTTPS, www/non-www, slash/no slash, регистр и альтернативные пути должны иметь согласованную политику.
Противоречия
Canonical на URL A, redirect на URL B и внутренние ссылки на URL C — типичный сигнал, который нужно свести к одной логике.
Фильтры, фасеты, параметры и пагинация
На больших сайтах именно техническое пространство URL часто становится главным источником crawl waste и дублей.
URL-space
Считаю, сколько вариантов создают фильтры, параметры и сортировки и может ли crawler уйти в практически бесконечные комбинации.
Crawl traps
Календарные параметры, комбинации фильтров, повторные параметры и циклическая навигация могут генерировать новые URL без нового содержания.
Index policy
Технический аудит проверяет корректность правил. Какие фасеты должны стать коммерческими landing, решается уже в e-commerce SEO по спросу и ассортименту.
JavaScript SEO и рендеринг
Если важный SEO-элемент появляется только после JavaScript, проверяю не предположение, а фактическую разницу между source HTML и rendered DOM.
| Элемент | Source HTML | Rendered DOM | Что ищем |
|---|---|---|---|
| Title / Description | исходное значение | итоговое значение | не остаётся ли «Загрузка…» или другой placeholder |
| Canonical / robots | исходные директивы | после JS | не меняются ли критичные SEO-сигналы |
| H1 / контент | доступный HTML | отрендеренный документ | получает ли crawler основной смысл страницы |
| Internal links | обычные href | JS-навигация | можно ли обнаружить целевые URL |
| Structured data | JSON-LD/source | итоговый DOM | валидна ли разметка и соответствует ли содержимому |
Внутренние ссылки, глубина и orphan pages
В техническом аудите рассматриваю не семантический анкор-план, а доступность URL для обхода и отсутствие технических разрывов.
Битые внутренние ссылки
Ссылки на 404/410 и неверные адреса мешают навигации и создают ненужные запросы crawler.
Ссылки через редирект
Если сайт уже знает конечный URL, внутреннюю ссылку рациональнее вести сразу на него, а не через промежуточную цепочку.
Orphan и crawl depth
Страница может существовать в sitemap или базе, но не иметь нормального внутреннего пути; отдельно смотрю глубину важных типов URL.
Скорость и Core Web Vitals
Performance — часть технической картины, но не отдельная гарантия позиций. Приоритет зависит от масштаба и реального влияния проблемы.
TTFB
Время до первого байта помогает отделить серверную задержку от дальнейшей загрузки фронтенда.
LCP
Проверяю, какой крупный элемент определяет визуальную загрузку и почему он появляется поздно.
INP
Оценивает отзывчивость страницы на взаимодействие; проблемы часто связаны с тяжёлым JavaScript.
CLS
Ищу элементы, которые неожиданно сдвигают layout после начала загрузки страницы.
Structured data и техническая валидность
Проверяю разметку как технический сигнал: синтаксис, соответствие типу страницы и видимому содержимому.
JSON-LD
Синтаксис должен корректно парситься и не содержать сломанных динамических значений после рендера.
Соответствие странице
Product, Service, Article, BreadcrumbList, FAQ и другие сущности используются только там, где соответствуют реальному содержимому.
Дубли и противоречия
Несколько конкурирующих schema-блоков или разные значения цены, URL и canonical могут создавать неоднозначную картину.
Ошибки группируются по шаблонам, а не только по URL
Для большого сайта важно найти root cause. Сто одинаковых ошибок на страницах — часто одна ошибка шаблона.
URLпринадлежит → типу страницы / шаблону
Templateгенерирует → canonical, meta, links и другие технические свойства
Ошибка шаблонамасштабируется → на группу URL
Это особенно важно для каталогов, фильтров, карточек, региональных страниц и других типов URL, которые создаются массово.
Как выглядит результат технического аудита
Не экспорт ошибок crawler, а рабочий backlog для разработчика и SEO с критерием приёмки.
| Проблема | Пример | Охват | Root cause | Приоритет | Expected behavior | Acceptance |
|---|---|---|---|---|---|---|
| Canonical указывает на категорию | /product/example | 318 карточек | product template | P0 | self-canonical | контрольная выборка отдаёт self-canonical |
| Внутренние ссылки через 301 | меню / карточки | 146 ссылок | старые href в шаблоне | P1 | прямая ссылка на 200 URL | redirected internal links = 0 в целевой группе |
| Soft-404 отвечает 200 | /catalog/empty | 42 URL | empty-state template | P1 | корректный status / полезная страница | повторный crawl подтверждает новую логику |
| Title появляется только после JS | SPA template | 1 тип страниц | client-side render | P2 | нужный Title доступен в целевом HTML/рендере | source/render test пройден |
Как проходит технический SEO-аудит
Процесс строится от фактического состояния URL к воспроизводимой задаче и повторной проверке.
01
Определяю scope
Размер сайта, типы шаблонов, CMS, JavaScript, фильтры, регионы и текущая проблема.
02
Собираю crawl и поисковые данные
URL, HTTP, meta, canonical, links, sitemap плюс данные Search Console / Вебмастера, если они доступны.
03
Проверяю спорные сигналы вручную
HTML, headers, rendered DOM, конкретные URL и правила шаблонов — crawler не должен быть единственным источником диагноза.
04
Группирую root causes
Определяю, какие замечания локальные, а какие создаются одним шаблоном или системным правилом.
05
Формирую backlog и ТЗ
Проблема → охват → доказательство → приоритет → ожидаемое поведение → критерий приёмки.
06
При необходимости проверяю внедрение
После релиза выполняется повторный crawl или контрольная проверка URL и фиксируется отсутствие регрессии.
Какие данные и инструменты использую
Инструменты дают наблюдение, но вывод формируется после проверки конкретного технического сигнала.
Crawler / Screaming Frog
URL, HTTP, redirects, canonical, meta, links, depth, sitemap и массовые технические признаки.
Google Search Console
Фактическая видимость Google, страницы и сигналы индексации со стороны поисковой системы.
Яндекс Вебмастер
Диагностика, поисковые данные и состояние страниц в Яндексе.
PageSpeed / Lighthouse
Performance, CWV и фронтенд-сигналы как один из технических слоёв.
SEO Control Lab
Диагностика, URL dynamics, indexability и контроль изменений на поддерживаемых проектах.
MODX Control Lab
Для MODX — source-level проверка Resources/Templates/TV и безопасное пакетное внедрение.
Rendered HTML
Сравнение исходного ответа и итогового DOM при JavaScript-зависимых страницах.
Server logs — по задаче
Использую, когда нужен фактический bot crawl на крупном сайте; не навязываю log analysis каждому проекту.
Повторная проверка после исправлений
Принятая задача должна иметь технически проверяемый результат.
Before / after crawl
Сравнивается класс ошибок и контрольные группы URL до и после релиза.
Acceptance criteria
Например: self-canonical, один redirect, код 200, отсутствие класса дублей или доступность SEO-элемента в rendered DOM.
Regression check
Проверяю, не сломало ли исправление соседний шаблон, другой тип URL или противоречащий технический сигнал.
Стоимость и формат технического аудита
Трудоёмкость различается в разы между небольшим сайтом услуг и каталогом с фильтрами, JavaScript и сотнями тысяч URL.
До старта
Оценка после просмотра сайта
Согласовываю scope, ожидаемый результат, стоимость и ориентир по сроку до начала работ.
Что влияет на объём
Количество типов страниц, URL-space, CMS, JavaScript, фильтры, мультирегиональность, доступность данных и необходимость ручной проверки.
Внедрение — отдельно по задаче
Безопасные SEO-правки могу выполнить сам; разработка, инфраструктура и сложный frontend передаются профильному специалисту с ТЗ.
Связанные услуги
Технический аудит решает узкий crawl/render/index scope; смежные задачи остаются у своих страниц.
Комплексный SEO-аудит
Если нужно искать ограничения не только в техническом слое, но и в спросе, структуре, контенте и коммерческих факторах.
SEO интернет-магазина
Для категорий, фильтров, карточек и принятия бизнес-решений о том, какие e-commerce фасеты должны участвовать в поиске.
SEO-сопровождение
Для регулярного цикла backlog → внедрение → QA → поисковые данные после разовой диагностики.
Частые вопросы о техническом SEO-аудите
Crawl, robots, canonical, JavaScript, Core Web Vitals, логи, внедрение и повторная проверка.
Что проверяет технический SEO-аудит?
Путь URL до поискового индекса: обнаружение страницы, HTTP-ответ, robots-директивы, HTML и JavaScript-рендеринг, canonical, sitemap, внутренние ссылки, indexability, массовые дубли и другие технические сигналы.
Чем технический SEO-аудит отличается от комплексного SEO-аудита?
Технический аудит концентрируется на crawl, render и index layer. Комплексный аудит дополнительно оценивает семантику, структуру спроса, контент, коммерческие факторы, ссылки, конкурентов и аналитику бизнеса.
Проверяете ли вы robots.txt и sitemap.xml?
Да. Проверяю не только наличие файлов, но и согласованность сигналов: не блокирует ли robots.txt нужные URL, не попадают ли в sitemap редиректы, noindex, 404 или неканонические страницы, и соответствует ли lastmod реальным обновлениям там, где он используется.
Что проверяется по canonical?
Self-canonical, canonical на другие URL, противоречия с редиректами и sitemap, параметры, HTTP/HTTPS, www/non-www, слеши и другие ситуации, где поисковая система может выбрать не ту версию страницы.
Входит ли JavaScript SEO и рендеринг?
Да, когда сайт зависит от JavaScript. Сравниваю исходный HTML и отрендеренный DOM по критичным элементам: Title, robots, canonical, H1, основной контент, внутренние ссылки и structured data.
Проверяете ли Core Web Vitals?
Да, как отдельный технический слой. Смотрю TTFB, LCP, INP и CLS по доступным данным, но не обещаю рост позиций только из-за улучшения одного показателя производительности.
Что делать с фильтрами и фасетами?
В техническом аудите проверяю, сколько URL они создают, нет ли crawl traps, дублей и противоречий canonical/noindex/robots. Коммерческое решение о том, какие фасеты должны стать поисковыми посадочными, относится к архитектуре e-commerce SEO.
Проверяются ли серверные логи?
По задаче. Для большинства сайтов сначала достаточно crawler-данных, Search Console, Яндекс Вебмастера и проверки рендера. Логи особенно полезны на крупных проектах, когда нужно понять фактический обход ботами и расход crawl budget.
Что я получу по итогам?
Технический backlog: проблема, пример URL, охват, доказательство, предполагаемая причина на уровне шаблона или правила, приоритет, ожидаемое поведение и критерий приёмки.
Можете ли вы внедрить исправления?
Часть безопасных SEO-правок могу внедрить сам на знакомом стеке и через собственные Control Lab-инструменты. Изменения ядра CMS, сложного JavaScript, инфраструктуры или серверной конфигурации обычно передаются профильному разработчику с ТЗ.
Как проверить, что техническая ошибка исправлена?
После релиза выполняется повторный crawl или контрольная проверка набора URL. Критерий приёмки задаётся заранее: например, self-canonical, отсутствие цепочки редиректов, корректный HTTP-код или исчезновение класса дублей.
Сколько стоит и сколько длится технический аудит?
Стоимость и срок зависят от количества URL, типов шаблонов, CMS, JavaScript, региональности и глубины проверки. До старта оцениваю scope и называю условия; универсальный срок и цену для любого сайта не обещаю.