hackseo

Как проверить работу сайта после подключения сети доставки контента

Пошаговая проверка сайта после подключения CDN: как проверить адреса и перенаправления, ответы сервера, загрузку файлов, обновление кеша и работу форм. Что зафиксировать и передать разработчику при обнаружении ошибок.

Как проверить работу сайта после подключения сети доставки контента

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

Что меняется после подключения CDN

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

После подключения появляется дополнительный участок передачи данных. Например, основной сервер уже отдаёт новое изображение, а CDN ещё хранит старое. Или сайт неправильно определяет, что посетитель использует защищённое соединение, и отправляет его по кругу между адресами.

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

Подготовьте страницы и условия проверки

Составьте список адресов, которые представляют разные части сайта. Выбирайте страницы с разным устройством и поведением, а не только самые посещаемые.

  • Главная страница и раздел каталога.
  • Карточка товара или страница услуги.
  • Статья с изображениями и документами.
  • Страница с фильтрами или поиском.
  • Форма заявки, корзина и вход в аккаунт, если они есть.
  • Старый адрес с настроенным перенаправлением.
  • Заведомо несуществующий адрес.

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

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

Шаг 1. Убедитесь, что запросы проходят через CDN

Открывающийся сайт ещё не доказывает, что сеть доставки контента работает. Браузер может показать локальную копию, а часть адресов — по-прежнему обращаться напрямую к основному серверу.

Откройте инструменты разработчика через меню браузера и найдите вкладку Network, или «Сеть». Она показывает запросы, которые браузер отправляет для загрузки страницы. Включите сохранение журнала — Preserve log, если такая настройка есть, — и перезагрузите страницу.

Выберите запрос самой страницы. Обычно он обозначен типом Document. В разделе заголовков ответа найдите признаки обработки запроса CDN. Названия заголовков различаются у поставщиков, поэтому сверяйте их с описанием в панели вашего сервиса. Универсального заголовка, который обязан присутствовать у любой CDN, нет.

Затем проверьте запрос изображения или файла стилей. Если CDN подключена только для файлов, запрос страницы может идти напрямую — это нормально для такой схемы. Сопоставьте наблюдения с тем, что планировали подключить.

Если подтверждения нет, попросите администратора проверить DNS — систему, которая связывает доменное имя с сервером, — и режим обработки нужного домена в панели CDN. Не меняйте записи наугад: сначала выясните, какие адреса должны обслуживаться через сеть.

Шаг 2. Проверьте адреса и перенаправления

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

Введите проверяемый адрес вручную и проследите его путь во вкладке «Сеть». Смотрите не только на итоговую адресную строку: промежуточные переходы могут скрывать ошибку.

Проверьте следующие ситуации:

  • Адрес с HTTP открывает предусмотренную версию с HTTPS.
  • Варианты домена с www и без него ведут на выбранный основной вариант.
  • Старый адрес попадает на соответствующую новую страницу.
  • Путь страницы сохраняется при смене протокола или домена.
  • Параметры адреса сохраняются там, где нужны фильтрам, поиску или рекламным меткам.

Например, при открытии /catalog/item?color=blue переход на HTTPS не должен самовольно превращать адрес в / или убирать выбранный цвет, если сайт использует этот параметр.

В ответе перенаправления поле Location содержит следующий адрес. Проверьте, нет ли там внутреннего имени сервера, неправильного домена или возврата на HTTP. Повторение одних и тех же адресов в журнале указывает на возможный цикл.

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

Шаг 3. Сопоставьте код ответа с содержимым

Код ответа — это служебное обозначение результата запроса. Его видно в столбце Status на вкладке «Сеть». Проверяйте код вместе с тем, что действительно получил браузер.

Ответ Что означает Что проверить
200 Запрос обработан успешно Пришла нужная страница или файл, а не сообщение об ошибке
301, 302, 307, 308 Перенаправление Следующий адрес соответствует ожидаемому переходу
304 Можно использовать ранее сохранённую копию Браузер располагает правильной версией ресурса
403 Доступ запрещён Защита не блокирует обычного посетителя
404 Ресурс не найден Адрес действительно отсутствует
5xx Ошибка обработки на стороне серверов Где возник сбой: в CDN или на основном сервере

Для существующей страницы ожидается её нормальное содержимое. Для несуществующей — ответ 404, даже если оформленная страница ошибки визуально похожа на остальные разделы сайта. Если сервер сообщает 200, но показывает «Страница не найдена», код и содержимое не соответствуют друг другу.

Отдельно проверьте файлы. Бывает, что запрос изображения или сценария получает 200, но внутри ответа находится страница блокировки. Формально запрос завершился успешно, однако браузер не получил нужный ресурс.

Не определяйте причину ошибки только по её коду. Например, сбой связи CDN с основным сервером и ошибка самого приложения могут выглядеть похоже для посетителя. Для точной диагностики понадобятся журналы запросов.

Шаг 4. Проверьте изображения, стили и сценарии

Файлы стилей отвечают за оформление, а сценарии — за интерактивные действия: раскрытие меню, фильтры, отправку формы. Страница может открываться, но оставаться непригодной для использования из-за ошибки одного такого файла.

На вкладке «Сеть» последовательно просмотрите изображения, CSS, JavaScript и шрифты. Для проблемного запроса проверьте адрес, код ответа и содержимое. Поле Content-Type сообщает браузеру тип полученных данных. Если вместо файла стилей приходит HTML-страница, исправлять нужно передачу ресурса, а не внешний вид сайта.

Откройте вкладку Console, или «Консоль». Там браузер показывает ошибки выполнения сценариев и ограничения загрузки. Обращайте внимание на сообщения о незагруженных файлах, небезопасных запросах и запрете обращения к другому домену.

Если ресурс перенесли на отдельный домен CDN, могут потребоваться настройки CORS — правил доступа между разными источниками. Это особенно заметно при загрузке шрифтов или данных. Передайте разработчику точный текст сообщения; разрешать любые обращения без разбора не следует.

Проверьте HTTPS не только у страницы, но и у её ресурсов. Запросы по HTTP внутри защищённой страницы могут блокироваться браузером. Также просмотрите ленивую загрузку: изображения ниже первого экрана появляются только после прокрутки и легко остаются вне первоначальной проверки.

Шаг 5. Убедитесь, что кеш обновляется правильно

Кеширование нужно проверять отдельно от доступности страницы. Работающая CDN может исправно отдавать устаревшую копию.

Выберите безопасное изменение, которое не затрагивает цены, заказы и другие важные данные. Например, обновите тестовый текст на доступной посетителям служебной странице или замените тестовое изображение. Если такие изменения выполняет разработчик, согласуйте проверяемый элемент с ним.

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

Заголовки Cache-Control, Age и служебные заголовки поставщика могут помочь разобраться в поведении копии. Их наличие и трактовка зависят от конфигурации. Показатель попадания в кеш сам по себе не доказывает, что содержимое актуально.

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

Отдельно сравните страницы с разными параметрами. Если фильтры color=blue и color=red должны давать разные результаты, CDN не должна отдавать им одну общую копию. Правило кеширования должно учитывать параметры, которые меняют содержимое.

Шаг 6. Пройдите действия посетителя

Проверка загрузки не заменяет проверку покупки или заявки. Пройдите основные сценарии целиком: откройте меню, примените фильтр, добавьте товар в корзину, отправьте тестовую форму и проверьте результат на стороне сайта.

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

Во вкладке «Сеть» найдите запрос действия. Посмотрите, не получил ли он страницу проверки посетителя, запрет доступа или неожиданный переход вместо ответа приложения. Защитные правила CDN могут мешать отдельным запросам, хотя сама страница открывается нормально.

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

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

Шаг 7. Проверьте служебные данные страниц

После подключения CDN сравните технические сведения важных страниц с ожидаемыми. Владельцу бизнеса не нужно редактировать код: можно открыть исходный текст страницы через меню браузера и передать найденные отличия разработчику.

Проверьте canonical — указание предпочтительного адреса страницы. Он должен содержать предусмотренный публичный адрес, а не внутренний домен сервера. Также убедитесь, что у доступных для поиска страниц не появилось указание noindex, которое запрещает индексирование. Оно может находиться в тексте страницы или заголовке ответа X-Robots-Tag.

Откройте файл robots.txt и используемую карту сайта. Убедитесь, что вместо них CDN не отдаёт страницу блокировки, а адреса в карте соответствуют рабочему домену. Эти проверки помогают выявить ошибки передачи и содержимого, но не позволяют обещать изменение поисковых позиций.

Как зафиксировать ошибку для разработчика

Записывайте проблему так, чтобы другой человек мог её воспроизвести. Формулировка «после CDN всё сломалось» не показывает, какой запрос нужно исследовать.

Включите в описание:

  • Точный адрес и действие перед ошибкой.
  • Ожидаемый и фактический результат.
  • Браузер, устройство, сеть и наличие входа в аккаунт.
  • Время проверки с часовым поясом.
  • Код ответа и последовательность перенаправлений.
  • Текст ошибки и идентификатор запроса, если он доступен.

Например: «В приватном окне карточка открывается, но после выбора размера изображение не меняется. Запрос нового изображения получает 403». Такое описание позволяет искать конкретную блокировку.

Если специалист просит выгрузить журнал Network в формате HAR, учтите: он может содержать данные форм, cookies и сведения сессии. Перед передачей удалите чувствительные данные или запишите новый журнал в тестовой сессии.

Когда проверку можно считать завершённой

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

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

Проверить сайт бесплатно

← Все статьи