Начните с желаемых страниц и воспроизводимых доказательств
Составьте список публичных страниц, которые вы хотите, чтобы нашли поисковики: ключевые товары, статьи, категории и перенесённые URL. Для каждой запишите предпочтительный URL, ожидаемый ответ, индексируемость, шаблон, владельца и приоритет. Отдельно ведите легитимные исключения.
Сохраняйте неаутентифицированный ответ, заголовки, путь редиректов, исходный код страницы, отрендеренный вид, состояние внутренних ссылок и состояние карты сайта для репрезентативных URL. Выбирайте примеры для каждого шаблона и паттерна URL. Доказательства имеют дату: настройка CDN, деплой, слой согласия или персонализация могут изменить их позже.
Успешная проверка главной страницы не доказывает, что работают листинги, варианты товаров или локализованные маршруты.
Храните датированные заголовки и отрендеренные доказательства, чтобы сравнивать исправления и последующие регрессии.
Сделайте индексируемость осознанным решением
Индексируемость означает, что страница может быть включена в поисковый индекс; это не то же самое, что краулинг или ранжирование. Проверьте директивы meta robots в HTML и заголовки ответа X-Robots-Tag. Директива noindex говорит поисковым системам не показывать страницу; X-Robots-Tag также применяется к не‑HTML файлам, например PDF.
Отдельно проверьте robots.txt. Краулер должен иметь доступ к странице, чтобы увидеть директиву noindex, поэтому блокировка URL может помешать обнаружению этой директивы. Проверяйте задеплённый публичный ответ, потому что настройки CMS и флаги окружения могут добавлять правила. Noindex — это не контроль доступа: защищайте чувствительный материал через аутентификацию и соответствующую проверку безопасности.
Помечайте noindex, ответы с требованием логина, ссылки на стейджинг и заблокированные важные ассеты на страницах, предназначенных для индексирования.
HTTP‑заголовок ответа может содержать директиву даже там, где нет HTML‑head.
Выделите один предпочтительный URL
Канонизация определяет предпочтительный URL среди дубликатов или очень похожих версий, таких как HTTP и HTTPS, разные хосты, параметры отслеживания, фильтры или версии для печати. Сравните rel=canonical, внутренние ссылки, URL в карте сайта и цель редиректа. Для индексируемой страницы они обычно должны указывать на один и тот же абсолютный предпочтительный URL.
Используйте постоянный серверный редирект при выводе дубликата из обращения. Google описывает постоянные редиректы и rel=canonical как сильные сигналы, в то время как включение в sitemap — более слабый; согласованные сигналы усиливают предпочтение. Не используйте robots.txt для канонизации и не давайте страницам конкурирующие канонические указания. Самоссылочный rel=canonical помогает заявить предпочтительную версию, но окончательный выбор остаётся за поисковой системой.
Документируйте варианты, предпочитаемую цель, требуемое управление и ответственного.
Тестируйте старые→новые соответствия перед миграцией и держите обратимый вариант изменения редиректов.
Проверьте коды состояния и поведение редиректов
Коды состояния сообщают браузерам и краулерам, что произошло. Важные живые страницы должны возвращать информативный 2xx‑ответ с ожидаемым содержимым. Страница без релевантной замены должна возвращать настоящий 404 или 410; перемещённый контент должен доходить до ближайшей релевантной замены. Страница с 200, которая показывает только ошибку, может рассматриваться как мягкий 404 (soft 404).
Записывайте каждый шаг редиректа. Google обычно следует до 10 переходов в цепочке для общего веб‑краулинга, но цепочки увеличивают задержку и нестабильность. Google указывает, что ответы 5xx и 429 могут временно замедлить краулинг, а постоянные ошибки сервера могут в конечном итоге удалить индексированные URL. Исследуйте повторяющиеся сбои совместно с инженерами-владельцами на уровнях приложения, CDN, origin, кэша, зависимостей и деплоя.
Сохраняйте исходный URL, переходы, коды, конечный URL и ожидаемое состояние.
Убирайте перекрывающиеся правила CMS, CDN, хоста, локали или завершающих слэшей вместо добавления ещё одного шага.
Проверяйте отрисовку JavaScript и маршрутизацию
Инспектируйте как начальный HTML, так и отрендеренный вид для ключевых шаблонов. Подтвердите, что основной контент, заголовки, ссылки, rel=canonical, директивы robots и состояние присутствуют после рендеринга. Google описывает отдельные фазы crawl, render и index и указывает, что содержимое, невидимое в отрендеренном HTML, не может быть индексировано.
Используйте элементы <a> с атрибутом href для навигации. Маршруты, зависящие только от фрагмента (#), которые загружают отличное содержимое, ненадёжны для обнаружения. Прямо запрашивайте несуществующие товары, статьи и отфильтрованные URL. Клиент‑сайд приложениям нужен реальный статус ошибки; Google документирует маршрутизацию к серверному 404 или добавление noindex, чтобы избежать мягких 404. Server‑side rendering (SSR) или prerendering могут помочь, но проверяйте задеплённый ответ.
Проверьте исходный HTML, отрендеренный HTML и вид в браузере человека на предмет существенных отличий.
Отдавайте приоритет каноническому в исходном HTML; если JavaScript его устанавливает, убедитесь, что существует один не конфликтующий rel=canonical.
Держите карты сайта и внутренние ссылки чистыми
Карта сайта — это карта обнаружения, а не команда к индексированию. Включайте успешные, предполагаемые, предпочитаемые канонические URL; исключайте редиректы, ошибки, страницы с noindex, дубли с параметрами и защищённые URL. Google рекомендует полностью квалифицированные абсолютные URL и рассматривает включение в sitemap как подсказку каноничности, а не гарантию.
Проверяйте карту сайта и сравнивайте её с списком intended‑index и навигацией. Google документирует кодировку UTF-8 и пределы 50 MB в несжатом виде или 50,000 URL на одну карту. Для больших сайтов разбивайте по полезным группам и используйте индекс‑карту. Обновляйте lastmod только при значимых, проверяемых изменениях страницы.
Исследуйте значимые различия между intended URL, записями в sitemap и внутренними ссылками.
Проверьте сгенерированную карту сайта и выборку указанных URL после изменений маршрутизации или CMS.
Измеряйте производительность и институционализируйте аудит
Используйте field‑данные там, где доступны, и контролируемые lab‑тесты для исследования Core Web Vitals (ключевые метрики веб‑опыта): Largest Contentful Paint для загрузки, Interaction to Next Paint для отзывчивости и Cumulative Layout Shift для визуальной стабильности. Сегментируйте по типу страницы и устройству, потому что средние значения могут скрывать сломанный высокоценный шаблон.
Трассируйте медленную или нестабильную доставку через изображения, CSS и JavaScript, сторонние теги, шрифты, встраиваемые элементы и кэширование. Сделайте одно измеримое изменение, затем повторно проверьте рендеринг и пользовательские потоки. Field‑данные отражают реальных пользователей; lab‑данные помогают воспроизвести проблему. Ни те, ни другие не предсказывают поведение каждого будущего краулера или посетителя. Повторяйте сфокусированную проверку регрессии после рискованных релизов и проводите полный аудит после миграций или изменений платформы.
Исправляйте сбои в шаблонах, критичных для дохода или часто используемых, прежде чем улучшать небольшие показатели в других местах.
Перед закрытием работы повторно проверьте ответ, rel=canonical, отрендеренное содержимое, состояние sitemap и соответствующие доказательства производительности.