Подготовка к анализу URL
Сбор и верификация исходных данных (URL, заголовки HTTP)
Первый шаг — зафиксировать полный URL: протокол (http/https), хост, путь, параметры запроса и фрагмент. URL указывает местоположение ресурса и способ доступа, поэтому важно сохранить точную строку запроса и варианты с/без завершающего слэша. Для получения заголовков HTTP используются инструменты командной строки: например, curl -I или curl -L для следования по редиректам; в ответе фиксируются статус-код (200, 301, 404, 500), заголовки Content-Type и charset (обычно text/html; charset=UTF-8), Cache-Control, X-Robots-Tag и заголовки безопасности (X-Frame-Options, Content-Security-Policy). Эти данные служат отправной точкой для проверки доступности и поведения сервера. Дополнительные примеры можно посмотреть на OnlyTats.
Формулировка целей и критериев проверки
Перед началом анализа задаются цели: проверить полноту текстового контента, корректность метаданных, индексируемость, доступность и риски сторонних скриптов. Критерии оценки включают: длину title (рекомендовано 50–60 знаков), длину meta description (примерно 150–160 знаков), наличие H1, наличие robots.txt по пути /robots.txt и sitemap по пути /sitemap.xml, а также целевые пороги производительности: Time to First Byte (TTFB) менее 200 мс, First Contentful Paint (FCP) около 1 с, Largest Contentful Paint (LCP) менее 2.5 с.
Аудит содержимого страницы
Оценка текстовой части: структура, уникальность, соответствие заголовкам
Текстовый контент должен соответствовать теме и ключевым запросам. Оцениваются объем (количество слов и символов), структура абзацев, наличие вводного блока и заключения, плотность ключевых слов без переспама. По признакам уникальности проводится проверка фрагментов текста через поисковые запросы по цитатам и через алгоритмическое сравнение шинглов с установкой порога совпадения, например, 30–40% совпадающих n‑gram при оценке дублирования. Наличие H1 проверяется на соответствие основному заголовку; последовательность заголовков (H1, H2, H3…) формирует иерархию и ожидания читателя: пропуски уровней и несколько H1 затрудняют семантическую интерпретацию.
Мультимедиа и метаданные: форматы, alt, open graph
Изображения должны иметь атрибуты alt и оптимальный размер; предпочтительные форматы для веба — WebP и AVIF с fallback в JPEG/PNG. Для ленивой загрузки используется атрибут loading=»lazy» у тегов img. Метаданные включают title, meta description, meta charset (UTF-8), meta viewport (width=device-width, initial-scale=1) и Open Graph теги для корректного превью при шаринге. Проверяется соответствие og:title и title, а также отсутствие дублирующих или конфликтующих метатегов.
Семантика и структурированные данные
Проверка микроразметки и JSON‑LD
Страница анализируется на наличие структурированных данных в формате JSON-LD или микроразметки (Microdata, RDFa). В JSON-LD должен присутствовать @context равный «https://schema.org» и корректный @type (например, Article, Product), а поля name, description и datePublished при их использовании должны иметь валидные значения. Ошибки парсинга (невалидный JSON, дублирование полей) препятствуют корректной интерпретации сниппетов.
Соответствие заголовков и семантической иерархии
Заголовки формируют иерархию: H1 задаёт основную тему, H2 — основные разделы, далее H3 и ниже — подразделы. Проверяется отсутствие нескольких H1, логичность вложения (не понижение уровня без причины) и наличие ключевых фраз в заголовках для релевантности. Заголовки должны отражать структуру HTML-кода, так как HTML‑код задаёт структуру и семантику страницы.
Техническая проверка и индексируемость
Анализ robots.txt, sitemap и HTTP‑заголовков
Проверяется доступность /robots.txt и его содержание: директивы User-agent, Disallow, Allow и наличие строки Sitemap: https://…/sitemap.xml. robots.txt регулирует доступ роботов к частям сайта и должен не блокировать важный контент. Sitemap.xml проверяется на валидность XML и соответствие указанным URL. HTTP‑заголовки анализируются на предмет редиректов (301/302), X-Robots-Tag и правил кеширования, влияющих на индексирование и обновление контента.
Выявление динамически подгружаемого контента и проблем с индексацией
Динамически загружаемый контент определяется по наличию крупных XHR/fetch запросов, генерации DOM через JavaScript и отсутствию контента в первоначем HTML. Для проверки используется сравнение ответа curl (серверный HTML) и рендеренного DOM в браузерных инструментах или headless‑браузерах; если основное содержимое приходит только после выполнения скриптов, это приводит к риску неполного индексирования поисковыми роботами, если рендеринг не поддерживается на стороне индексации.
Производительность, доступность и безопасность
Метрики скорости загрузки и критические ресурсы
Ключевые метрики: TTFB, FCP, LCP и количество сетевых запросов. Критические ресурсы — CSS и JS, блокирующие рендеринг, должны минимизироваться и выноситься в критический путь. Рекомендуется измерять размер начальной загрузки и количество запросов; снижение их числа влияет на время до первого отображения контента. Также проверяется использование кэширования, gzip/ Brotli компрессии и правильные заголовки кеша.
Проверка доступности и рисков, связанных со сторонними скриптами
Доступность оценивается по соответствию WCAG AA: контраст текста минимум 4.5:1 для обычного текста, наличие фокусной навигации и альтернативных текстов для медиа. Внешние скрипты могут создавать риск утечек данных и замедлений: анализируются запросы к сторонним доменам, используемые CDN и библиотеки, наличие политики CSP и инъекции скриптов. Отсутствие CSP или динамическая подгрузка скриптов без проверки источника повышают риск.
Рекомендации по исправлению и приоритизации
Список приоритетных правок и короткий план действий
Приоритетные правки: исправить критические HTTP-редиректы и ошибки 4xx/5xx; убедиться в доступности /robots.txt и sitemap.xml; добавить или привести в порядок title и meta description (50–60 и 150–160 знаков); обеспечить H1 и корректную иерархию заголовков; оптимизировать изображения (WebP/AVIF, loading=»lazy»); уменьшить блокирующие CSS/JS и сократить TTFB до ~200 мс. Для структурированных данных — валидировать JSON-LD и устранить ошибки парсинга.
Как контролировать результаты после внесения изменений
Контроль осуществляется регулярными сканированиями и лог-анализом: сравнение метрик TTFB/FCP/LCP до и после изменений, периодическая проверка статусов HTTP и файла /robots.txt, отслеживание сканируемости через периодические рендер-тесты и проверку файлов sitemap.xml. Ведётся журнал правок и наблюдаются изменения в частоте появления ошибок 4xx/5xx и в показателях доступности и скорости для подтверждения эффективности выполненных работ.