Сайт доступен не всем: как найти причину

Если сайт доступен не всем пользователям, обычная проверка «открылось у меня» почти бесполезна. Частичный сбой проявляется только при определённой сети, регионе, IP-адресе, браузере, устройстве, учётной записи или варианте страницы.

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

Короткий ответ. Зафиксируйте адрес страницы (URL), время, сообщение об ошибке и условия пользователя. Повторите сценарий из другой сети, на другом устройстве и без авторизации. Затем сравните ответы системы доменных имён (DNS), защитного слоя, серверные журналы и пользовательское состояние.

Что означает «доступен не всем»

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

Проверка ответа сервера в Яндекс Вебмастере полезна как независимая точка наблюдения. Но Яндекс отдельно предупреждает: инструмент использует другой IP-адрес, поэтому его ответ может отличаться от ответа реальному роботу или посетителю. Нужны несколько точек, а не один зелёный статус.

Симптом	Вероятный слой	Первое сравнение
Не открывается у одного провайдера или региона	DNS, маршрут, сеть доставки, правило защиты	Другая сеть и внешний резолвер
Не работает только на мобильном	Шаблон, ресурс, сценарий, браузер	Тот же URL на мобильной и настольной версиях
Не входит часть пользователей	Файлы cookie, сессия, права, эксперимент	Гость, новая сессия и известная учётная запись
Главная открывается, форма или оплата — нет	Отдельный программный интерфейс (API), скрипт, интеграция	Полный бизнес-сценарий, а не только страница

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

Какие данные запросить у пользователя

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

Адрес: полный URL страницы или шага, где возникла ошибка.
Время: дата и точное время с часовым поясом.
Симптом: текст ошибки, код ответа или снимок экрана.
Среда: город, провайдер или мобильная сеть, устройство и браузер.
Состояние: был ли пользователь авторизован, новый ли это визит.
Шаги: что он сделал до сбоя и повторяется ли ошибка.

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

Как воспроизвести проблему за 15 минут

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

Повторите тот же URL и шаг в исходной среде, если она доступна.
Смените Wi-Fi на мобильный интернет, сохранив устройство и браузер.
Откройте URL на другом устройстве в той же сети.
Повторите сценарий как гость и после входа.
Зафиксируйте код ответа, время загрузки и идентификатор запроса, если он показан.

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

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

Где искать причину после воспроизведения

Сеть, DNS и регион

Если проблема следует за сетью или регионом, сравните DNS-ответы, IPv4 и IPv6, срок действия сертификата, маршрут до узла и ответ сети доставки. После недавней смены DNS проверьте, не получают ли разные резолверы старые и новые записи.

Правила защиты и ограничения по IP

Межсетевой экран приложения может принимать решения по стране, автономной системе, IP-адресу, частоте запросов и другим признакам. Например, официальная документация Cloudflare показывает правила блокировки по номеру автономной системы (ASN), континенту и стране. Поэтому ищите совпадение проблемных запросов с журналом правил, а не отключайте защиту целиком.

Браузер, устройство и ресурсы

Если сеть не влияет, сравните консоль и сетевые запросы в браузере. Часто код страницы (HTML) загружается, но один скрипт, стиль, шрифт или API блокируется. Проверьте ошибки JavaScript, статус ресурса, заголовки безопасности и работу без расширений.

Вход, файлы cookie и варианты страницы

Если сбой зависит от входа, проверьте новую сессию, срок действия файлов cookie, права и вариант эксперимента. Не удаляйте данные пользователя до фиксации. Разработке нужны условия, в которых сервер выбрал проблемную ветку.

Что покажут Метрика и Вебмастер

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

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

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

Как подтвердить исправление

Исправление считается подтверждённым только в исходном проблемном сегменте. Если ошибка была у мобильного провайдера в конкретном регионе, успешное открытие по офисному Wi-Fi ничего не доказывает.

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

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

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

Чек-лист для передачи разработке

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

Почему сайт открывается у меня, но не у клиента?

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

Достаточно ли проверить сайт с телефона?

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

Когда считать проблему исправленной?

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