HTTP-заголовки для SEO: robots, canonical и cache

HTTP-заголовки управляют ответом до разбора HTML и особенно важны для PDF, изображений, файлов и редиректов. X-Robots-Tag передаёт правила индексирования, Link может указать canonical для не-HTML ресурса, Location задаёт цель переноса, а валидаторы кеша помогают не передавать неизменившееся тело повторно. Ошибочная конфигурация CDN способна применить одно правило ко всему разделу.

Схема показывает ключевые элементы задачи и их связь.

Оглавление

• Снимать ответ на каждом слое
• Использовать X-Robots-Tag
• Передавать canonical через Link
• Проверять Location
• Использовать Retry-After
• Настроить ETag и Last-Modified
• Учитывать Cache-Control
• Не забывать Vary
• Автоматизировать контракт

Снимать ответ на каждом слое

Браузер показывает итог CDN, но источник, reverse proxy и приложение могут добавлять или перезаписывать заголовки.

Практический порядок:

• запросить edge.
• проверить origin.
• сравнить host.
• сохранить raw headers.

Для раздела «снимать ответ на каждом слое» недостаточно формальной настройки. Начальная выборка должна включать типовой, приоритетный и пограничный URL; иначе среднее скроет различия между шаблонами. Сначала выполняют «запросить edge», затем «проверить origin» и проверяют один контрастный пример. После этого переходят к «сравнить host», а пункт «сохранить raw headers» включают в критерии релиза.

Проверка раздела «Снимать ответ на каждом слое»: результат подтверждается тем же способом, которым собран baseline, минимум на типовом и пограничном URL. Для этапа «снимать ответ на каждом слое» отдельно измеряют влияние на доля URL с ожидаемым набором заголовков, конфликты HTML и HTTP директив и корректность кеша по вариантам ответа; изменение не должно создавать новые дубли, закрывать полезный контент или увеличивать число технических ошибок.

Главный риск всего решения — настроить директиву глобально на CDN и случайно закрыть от индексации весь публичный раздел. Поэтому первый релиз ограничивают одним классом страниц, сохраняют возможность отката и не распространяют правило до ручной проверки выборки.

Использовать X-Robots-Tag

Директива в HTTP полезна для файлов и может быть привязана к конкретному роботу, но конфликтующие правила складываются ограничительно.

Практический порядок:

• выбрать область.
• проверить noindex.
• не закрывать ресурсы случайно.
• сверить meta robots.

Для раздела «использовать x-robots-tag» недостаточно формальной настройки. Исходные данные сохраняют до изменения вместе с часовым поясом, диапазоном дат и версией правил нормализации. Данные после шага «выбрать область» не агрегируют, пока не завершены «проверить noindex» и ручная сверка выборки. После этого переходят к «не закрывать ресурсы случайно», а пункт «сверить meta robots» включают в критерии релиза.

Проверка раздела «Использовать X-Robots-Tag»: результат подтверждается тем же способом, которым собран baseline, минимум на типовом и пограничном URL. Для этапа «использовать x-robots-tag» отдельно измеряют влияние на доля URL с ожидаемым набором заголовков, конфликты HTML и HTTP директив и корректность кеша по вариантам ответа; изменение не должно создавать новые дубли, закрывать полезный контент или увеличивать число технических ошибок.

Передавать canonical через Link

HTTP canonical применяют там, где нет HTML head, сохраняя одну согласованную предпочтительную версию.

Практический порядок:

• выбрать абсолютный URL.
• проверить rel canonical.
• не задавать несколько целей.
• сверить sitemap.

Для раздела «передавать canonical через link» недостаточно формальной настройки. Автоматический результат подтверждают несколькими URL вручную: это выявляет неверную классификацию и особенности шаблона. Связку «выбрать абсолютный URL» → «проверить rel canonical» проверяют отдельно от последующего изменения шаблона. После этого переходят к «не задавать несколько целей», а пункт «сверить sitemap» включают в критерии релиза.

Проверка раздела «Передавать canonical через Link»: результат подтверждается тем же способом, которым собран baseline, минимум на типовом и пограничном URL. Для этапа «передавать canonical через link» отдельно измеряют влияние на доля URL с ожидаемым набором заголовков, конфликты HTML и HTTP директив и корректность кеша по вариантам ответа; изменение не должно создавать новые дубли, закрывать полезный контент или увеличивать число технических ошибок.

Работа разбита на последовательные этапы от исходных данных до проверки.

Проверять Location

Цель редиректа должна быть однозначной, доступной и не образовывать цепочку или петлю через CDN и приложение.

Практический порядок:

• проверить status.
• разрешить относительный адрес осознанно.
• пройти цепочку.
• обновить внутренние ссылки.

Для раздела «проверять location» недостаточно формальной настройки. Проверку проводят на финальном публичном host, потому что CDN, reverse proxy и приложение могут возвращать разные ответы. До массового исправления воспроизводят проблему, выполняя «проверить status» и «разрешить относительный адрес осознанно» на одном URL. После этого переходят к «пройти цепочку», а пункт «обновить внутренние ссылки» включают в критерии релиза.

Проверка раздела «Проверять Location»: результат подтверждается тем же способом, которым собран baseline, минимум на типовом и пограничном URL. Для этапа «проверять location» отдельно измеряют влияние на доля URL с ожидаемым набором заголовков, конфликты HTML и HTTP директив и корректность кеша по вариантам ответа; изменение не должно создавать новые дубли, закрывать полезный контент или увеличивать число технических ошибок.

Использовать Retry-After

Заголовок объясняет временную перегрузку или обслуживание, но не заменяет исправление долгих 429 и 503.

Практический порядок:

• выбрать код.
• задать разумный срок.
• ограничить окно.
• контролировать восстановление.

Для раздела «использовать retry-after» недостаточно формальной настройки. Список из CMS или sitemap сравнивают с фактическим HTTP-ответом; само присутствие адреса в выгрузке ещё не доказывает доступность. Правило допускают к генерации только после действий «выбрать код» и «задать разумный срок». После этого переходят к «ограничить окно», а пункт «контролировать восстановление» включают в критерии релиза.

Проверка раздела «Использовать Retry-After»: результат подтверждается тем же способом, которым собран baseline, минимум на типовом и пограничном URL. Для этапа «использовать retry-after» отдельно измеряют влияние на доля URL с ожидаемым набором заголовков, конфликты HTML и HTTP директив и корректность кеша по вариантам ответа; изменение не должно создавать новые дубли, закрывать полезный контент или увеличивать число технических ошибок.

Настроить ETag и Last-Modified

Валидаторы позволяют вернуть 304 на неизменившийся ресурс, если версия связана с реальным содержимым.

Практический порядок:

• создать стабильный валидатор.
• обработать условный запрос.
• не менять ETag без причины.
• тестировать 304.

Для раздела «настроить etag и last-modified» недостаточно формальной настройки. Для параметрических URL сохраняют исходную строку и нормализованную форму, чтобы не потерять генератор дублей при агрегации. Сначала фиксируют политику через «создать стабильный валидатор», затем реализуют «обработать условный запрос» без изменения остальных классов. После этого переходят к «не менять ETag без причины», а пункт «тестировать 304» включают в критерии релиза.

Проверка раздела «Настроить ETag и Last-Modified»: результат подтверждается тем же способом, которым собран baseline, минимум на типовом и пограничном URL. Для этапа «настроить etag и last-modified» отдельно измеряют влияние на доля URL с ожидаемым набором заголовков, конфликты HTML и HTTP директив и корректность кеша по вариантам ответа; изменение не должно создавать новые дубли, закрывать полезный контент или увеличивать число технических ошибок.

Чек-лист объединяет технические, поисковые и эксплуатационные проверки.

Учитывать Cache-Control

Кеш не является прямой SEO-директивой, но влияет на стабильность, скорость и свежесть версии, которую получают роботы.

Практический порядок:

• разделить public и private.
• задать max-age.
• использовать immutable для fingerprint.
• инвалидировать HTML.

Для раздела «учитывать cache-control» недостаточно формальной настройки. Исходный HTML сравнивают с отрисованным DOM и сетевыми ошибками, если результат зависит от JavaScript. Архитектурную гипотезу проверяют через «разделить public и private» и «задать max-age» на нескольких типах страниц. После этого переходят к «использовать immutable для fingerprint», а пункт «инвалидировать HTML» включают в критерии релиза.

Проверка раздела «Учитывать Cache-Control»: результат подтверждается тем же способом, которым собран baseline, минимум на типовом и пограничном URL. Для этапа «учитывать cache-control» отдельно измеряют влияние на доля URL с ожидаемым набором заголовков, конфликты HTML и HTTP директив и корректность кеша по вариантам ответа; изменение не должно создавать новые дубли, закрывать полезный контент или увеличивать число технических ошибок.

Не забывать Vary

Если ответ зависит от языка, кодирования или Origin, ключ кеша должен различать варианты и не смешивать закрытые и публичные версии.

Практический порядок:

• перечислить варианты.
• минимизировать Vary.
• проверить CDN key.
• тестировать разные запросы.

Для раздела «не забывать vary» недостаточно формальной настройки. Событие публикации отделяют от сигнала поисковой системе и от последующего обхода: это три разные даты и состояния. Интеграция считается событийной только после шагов «перечислить варианты» и «минимизировать Vary», выполненных в правильном порядке. После этого переходят к «проверить CDN key», а пункт «тестировать разные запросы» включают в критерии релиза.

Проверка раздела «Не забывать Vary»: результат подтверждается тем же способом, которым собран baseline, минимум на типовом и пограничном URL. Для этапа «не забывать vary» отдельно измеряют влияние на доля URL с ожидаемым набором заголовков, конфликты HTML и HTTP директив и корректность кеша по вариантам ответа; изменение не должно создавать новые дубли, закрывать полезный контент или увеличивать число технических ошибок.

Автоматизировать контракт

Интеграционный тест запрашивает репрезентативные URL и сравнивает код и заголовки с ожидаемой матрицей.

Практический порядок:

• выбрать шаблоны.
• добавить файлы.
• проверить редиректы.
• запускать после релиза.

Для раздела «автоматизировать контракт» недостаточно формальной настройки. Финальная сверка повторяет тот же запрос, которым получен baseline, и дополняется негативным сценарием. Контрольный сценарий начинается с «выбрать шаблоны» и завершается независимой проверкой после «добавить файлы». После этого переходят к «проверить редиректы», а пункт «запускать после релиза» включают в критерии релиза.

Проверка раздела «Автоматизировать контракт»: результат подтверждается тем же способом, которым собран baseline, минимум на типовом и пограничном URL. Для этапа «автоматизировать контракт» отдельно измеряют влияние на доля URL с ожидаемым набором заголовков, конфликты HTML и HTTP директив и корректность кеша по вариантам ответа; изменение не должно создавать новые дубли, закрывать полезный контент или увеличивать число технических ошибок.

Итог фиксируется как воспроизводимый рабочий артефакт: контракт заголовков для каждого шаблона, статуса, типа файла и слоя инфраструктуры. В нём указывают источник данных, дату, владельца изменения и ожидаемое поведение каждого класса URL.

Что делать дальше

Сначала сохраните исходную выгрузку и определите один класс URL, на котором можно безопасно проверить гипотезу. После релиза повторите тот же запрос или обход, сравните контрольную выборку и только затем масштабируйте изменение. Если проблема затрагивает шаблоны, генерацию URL и индексацию большого раздела, можно заказать Поддержка и доработка сайтов.

Материалы по теме:

• технический SEO-аудит
• проверка индексации сайта
• настройка robots.txt

Частые вопросы

Нужен ли для проверки платный краулер?

Нет. Начальную диагностику можно провести выгрузкой CMS, командными HTTP-запросами, access-логами и данными Яндекс Вебмастера. Платный инструмент ускоряет сбор больших графов, но не заменяет правила классификации и ручную проверку выборки.

Когда оценивать изменение?

HTTP-ответы, HTML, ссылки и sitemap проверяют сразу после релиза. Поведение поискового робота оценивают после появления новых обходов в логах и Вебмастере; сроки зависят от сайта, поэтому обещать фиксированную дату индексации нельзя.

Нужно ли менять весь сайт одновременно?

Нет. Безопаснее выбрать один шаблон или раздел, сохранить baseline и иметь план отката. Массовое изменение оправдано после того, как контрольный класс проходит автоматические и ручные проверки.

Как не создать каннибализацию?

Каждому URL назначают отдельный интент и роль. Если две страницы отвечают на один вопрос одинаково, их объединяют или разводят по задаче до публикации, а внутренние анкоры направляют пользователя к наиболее точному материалу.

Вывод

HTTP-заголовки управляют ответом до разбора HTML и особенно важны для PDF, изображений, файлов и редиректов. X-Robots-Tag передаёт правила индексирования, Link может указать canonical для не-HTML ресурса, Location задаёт цель переноса, а валидаторы кеша помогают не передавать неизменившееся тело повторно. Ошибочная конфигурация CDN способна применить одно правило ко всему разделу. Надёжное внедрение связывает источник данных, класс URL, ответственное изменение и повторяемый критерий приёмки. Так техническая оптимизация улучшает обнаружение полезного контента, а не просто меняет отчётность.