Может ли кэширование CDN приводить к тому, что поисковые роботы получают старые страницы?

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

Чтобы разобраться с проблемой cdn caching for search crawlers, сначала нужно выяснить, какой ответ фактически получает робот, а затем проверить, почему кэш не обновился. Одного лишь факта, что в браузере отображается новая версия или в результатах поиска всё ещё видна старая, недостаточно для определения причины.

На каком уровне продолжает использоваться старая страница

Запрос может проходить через граничный узел, кэш вышестоящего уровня и кэш приложения на исходном сервере. Если очистить только кэш на самом внешнем уровне, а на вышестоящем уровне останется старая копия, граничный узел снова получит устаревшее содержимое. Поэтому при оценке успешности очистки кэша нужно учитывать её охват: указанный URL, весь каталог, тег кэширования и разные имена хостов относятся к разным объектам.

Результат также зависит от ключа кэширования. Адрес одной и той же статьи с параметрами и без них, пути для разных языков и разные имена хостов могут соответствовать разным копиям. Если правила кэширования включают в ключ устройство, регион или заголовки запроса, браузер и робот могут получить разные версии. И наоборот, если многоязычное содержимое переключается по заголовкам запроса, но кэш не разделяет его должным образом, могут отображаться страницы на другом языке.

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

Какие заголовки ответа действительно важны для диагностики

Сначала проверьте запрос HTML-документа, а не только изображений, скриптов или таблиц стилей. Длительное кэширование статических ресурсов не означает, что для основного текста статьи установлен такой же срок. Следующие поля нужно рассматривать с учётом фактических правил CDN:

• Cache-Control: max-age задаёт период свежести ответа; для общего кэша при наличии s-maxage следует в первую очередь проверить его. В панели управления CDN также могут быть настроены правила граничного кэширования, переопределяющие заголовки ответа исходного сервера.
• no-cache разрешает сохранять ответ, но требует проверять его перед повторным использованием; no-store указывает, что ответ не следует сохранять. Если считать эти директивы одинаковыми, настройки могут не соответствовать ожиданиям.
• Age помогает оценить возраст ответа из кэша, но сам по себе не подтверждает, что содержимое устарело или актуально. Маркер попадания в кэш также показывает только статус кэширования — его нужно сопоставлять с информацией о версии в содержимом.
• ETag и Last-Modified используются в условных запросах. Если содержимое изменилось, а валидаторы не обновились должным образом, сервер может ошибочно вернуть 304, и запрашивающая сторона продолжит использовать имеющуюся копию.

stale-while-revalidate позволяет в течение заданного окна сначала возвращать устаревшее содержимое, а затем проверять его в фоновом режиме; stale-if-error разрешает использовать старую копию при определённых ошибках. Если для страницы важно строго соблюдать сроки обновления, нужно определить, допустимы ли такие окна, а не просто изменить длительность кэширования.

Как получить проверяемые доказательства того, что робот загрузил старую страницу

Выберите полный URL, для которого возникла проблема, и зафиксируйте ожидаемый новый заголовок, фрагмент текста или маркер версии. Сохраните заголовки ответа и текст страницы обычным GET-запросом, например командой curl -sS -D headers.txt -o page.html 'https://example.com/article'. Один лишь запрос HEAD не позволяет проверить содержимое; кроме того, некоторые сервисы обрабатывают HEAD и GET по-разному.

Затем сравните ответы исходного сервера и CDN, сохранив одинаковыми имя хоста, путь, параметры и языковые условия. Прямое обращение к IP-адресу исходного сервера может привести на сайт по умолчанию и дать неверный результат. Для сравнения с исходным сервером используйте способ доступа, который сохраняет правильные имя хоста и настройки TLS. Если на самом исходном сервере по-прежнему старая версия, сначала проверьте статус публикации, кэш приложения или синхронизацию узлов бэкенда.

Не используйте произвольный случайный параметр как единственный способ проверки. Он может обходить кэш или игнорироваться ключом кэширования, а тестовый адрес может отличаться от адреса, по которому обращается робот. Добавление в запрос Cache-Control: no-cache также не заменяет проверку обновления на стороне сервера: фактическая обработка зависит от настроек CDN.

Подмена User-Agent на имя робота позволяет проверить, разделяют ли правила запросы по этому полю, но не доказывает, что реальный робот получает такой же ответ. Более весомые доказательства дают журналы доступа граничных узлов, где зафиксированы время, полный URL, узел, статус кэша и версия содержимого; источник запроса следует проверять по опубликованным поисковой системой рекомендациям. Отсутствие записи в журнале исходного сервера может означать, что запрос был обработан на граничном узле из кэша.

Какую версию нужно проверить после очистки кэша

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

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

Если сохранять в журнале публикаций версию содержимого, объекты очистки кэша и результаты проверки, при возникновении проблемы будет проще отличить сбой публикации от задержки обновления кэша. Этот процесс также может служить конкретным техническим аспектом темы Анализ влияния цифровой трансформации на устойчивость бизнеса: в ходе восстановления необходимо проверять содержимое, возвращаемое на каждом уровне.

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