
Короткий ответ: чтобы сайт продолжал открываться во время ограничений мобильного интернета в России, одной настройки WordPress, смены DNS или переноса на российский хостинг недостаточно. Ресурс должен быть включён в перечень доступных сервисов, который формирует Минцифры. При этом владелец обязан подготовить инфраструктуру: российское размещение, постоянные публичные IP-адреса, полный список доменов и отсутствие критической зависимости от недоступных внешних сервисов.
Эта инструкция объясняет весь процесс без сказок про «секретную галочку»: как устроены белые списки, кто может претендовать на включение, какие технические сведения потребуются, как проверить обычный сайт или WordPress, куда направлять обращение и почему даже разрешённая главная страница иногда загружается без изображений, формы оплаты и личного кабинета.
Материал актуализирован 18 августа 2026 года. Практика и состав перечня меняются, поэтому перед подачей обращения проверяйте свежие сообщения Минцифры и требования вашего регионального ведомства.
Содержание
- Что такое белый список сайтов
- Как работает доступ во время ограничений
- Какие сайты могут попасть в перечень
- Технические требования и подготовка
- Аудит WordPress
- Пошаговый план включения
- Что написать в обращении
- Как проверить работу сайта
- Ошибки и мифы
- Что делать, если сайт не включили
- Частые вопросы
Что такое белый список сайтов при ограничении интернета
«Белым списком» называют перечень российских сайтов, приложений и цифровых сервисов, доступ к которым операторы сохраняют в периоды ограничения передачи данных в мобильных сетях. Логика противоположна обычной блокировке: вместо запрета отдельных адресов временно разрешается доступ только к определённому набору ресурсов.
По данным Минцифры от 23 апреля 2026 года, в перечень было включено более 500 российских сервисов. В него входят государственные системы, банки, маркетплейсы, транспорт, доставка, СМИ, медицинские и другие востребованные платформы. Перечень развивается, а фактическая доступность отдельных компонентов может различаться у операторов и по регионам.
Важно не смешивать разные понятия:
- Белый список Минцифры нужен для доступа при ограничениях мобильного интернета.
- Список разрешённых сайтов в корпоративной сети настраивает администратор конкретной организации.
- Исключение в антивирусе или браузере действует только на устройстве пользователя.
- Индексация Яндексом и Google влияет на поиск, но не на сетевую доступность.
- Реестры Роскомнадзора и перечень запрещённой информации решают другую задачу.
Минцифры отдельно разъясняло, что этот механизм применяется при ограничении мобильного, а не фиксированного интернета. Поэтому сайт может не открываться через LTE или 5G, но нормально работать через домашний проводной интернет или Wi-Fi.
Как работает белый список на практике
Для пользователя всё выглядит просто: он вводит адрес, а сайт либо открывается, либо нет. Для владельца сервиса картина сложнее. Современный сайт редко живёт на одном домене и одном сервере. Основная HTML-страница может приходить с example.ru, изображения с cdn.example.ru, каталог из api.example.ru, шрифты с зарубежного CDN, карта из внешнего сервиса, форма через отдельную CRM, а оплата через домен банка.
Если разрешён только основной домен, пользователь увидит каркас страницы, но часть функций сломается. Возможны следующие симптомы:
- не загружаются CSS, шрифты, изображения или JavaScript;
- не открывается личный кабинет;
- форма отправляется бесконечно или выдаёт ошибку;
- не работает CAPTCHA;
- каталог пуст, потому что его наполняет отдельный API;
- невозможно оплатить заказ;
- встроенное видео остаётся чёрным прямоугольником;
- не приходят уведомления, письма или push-сообщения.
Поэтому заявлять и проверять нужно не «сайт вообще», а всю цепочку обслуживания пользователя: домены, поддомены, публичные точки входа, API, хранилища, авторизацию, платёжные и коммуникационные компоненты.

Что именно идентифицирует ресурс
В открытых технических рекомендациях основной акцент сделан на публичных IP-адресах, через которые пользователи получают доступ к сервису. В документации Yandex Cloud прямо указано: адреса должны быть статическими, зарезервированными за владельцем, а передавать рекомендуется отдельные адреса /32, а не широкие диапазоны. Сам факт размещения в российском облаке автоматического включения не даёт. Решение принимается отдельно для каждого сервиса.
На практике в техническое приложение разумно включать одновременно:
- основной домен и вариант с
www; - все пользовательские поддомены;
- статические IPv4 и используемые IPv6;
- назначение каждого домена и адреса;
- провайдера, автономную систему и место размещения;
- схему прохождения трафика от пользователя до приложения.
Какие сайты могут попасть в белый список Минцифры
Формализованного открытого регламента, который гарантировал бы включение после выполнения набора пунктов, нет. Это принципиальный момент. Техническая готовность необходима, но она не равна одобрению.
По сложившейся практике государство оценивает как минимум три группы факторов:
- Востребованность. Сколько людей регулярно пользуется сервисом, какова месячная и суточная аудитория, насколько широко он представлен в регионах.
- Общественная или экономическая значимость. Что произойдёт, если сервис перестанет работать: люди не смогут вызвать такси, получить медицинскую помощь, оплатить услугу, оформить доставку или узнать важную информацию.
- Техническая и правовая готовность. Где расположена инфраструктура, кому принадлежат точки входа, соблюдается ли российское законодательство, можно ли однозначно описать и контролировать сетевой контур.
Приоритет обычно получают массовые сервисы, связанные с повседневными потребностями: государственные услуги, финансы, транспорт, связь, торговля, медицина, образование, логистика, СМИ и региональная инфраструктура. Небольшой корпоративный сайт, личный блог или лендинг тоже может направить обращение, но честно: без доказанной значимости вероятность включения заметно ниже.
Кому имеет смысл подаваться в первую очередь
- региональным службам такси и доставки;
- медицинским, аптечным и социальным сервисам;
- образовательным платформам с большой аудиторией;
- сервисам ЖКХ, транспорта и городской инфраструктуры;
- банкам, платёжным и финансовым системам;
- крупным магазинам и производственным платформам;
- СМИ и информационным ресурсам с подтверждённым охватом;
- B2B-системам, остановка которых влияет на критичные процессы других компаний.
Что подтверждает востребованность
Фразы «сайт очень нужен людям» мало. Нужны проверяемые показатели:
- MAU и DAU, то есть месячная и суточная аудитория;
- данные Яндекс Метрики за 6-12 месяцев;
- количество зарегистрированных и активных пользователей;
- число заказов, обращений, платежей или других полезных операций;
- доля мобильной аудитории;
- география пользователей;
- контракты с государственными или социальными организациями;
- письма от партнёров, подтверждающие зависимость их процессов от сервиса;
- оценка ущерба от недоступности;
- описание конкретных жизненных сценариев, которые перестают работать.
Техническая подготовка сайта к белому списку
Ниже не «официальный сертификат соответствия», которого не существует, а практический базовый контур. Его задача: сделать инфраструктуру понятной, стабильной и проверяемой.
1. Разместите публичный контур в России
Входные серверы, балансировщики и другие компоненты, принимающие пользовательский трафик, должны находиться в российской инфраструктуре. Отдельно проверьте базы данных и обработку персональных данных. Если сайт визуально размещён в России, но запросы уходят в иностранный API или зарубежное хранилище, полноценной доступности не будет.
Домен в зоне .ru или .рф сам по себе ничего не доказывает. Российский домен можно направить на зарубежный сервер, а домен другой зоны можно обслуживать в российском ЦОД. Решает реальная схема размещения и маршрутизации.
2. Получите статический публичный IP
Динамический адрес может измениться после перезапуска виртуальной машины, миграции или перенастройки облака. В заявке такой адрес превращается в мину замедленного действия: сегодня он ведёт на ваш сайт, завтра уже нет.
Нужен зарезервированный публичный IP, закреплённый за ресурсом. Предпочтительный вариант: отдельный адрес /32 для каждой внешней точки входа. Сохраните подтверждение из панели хостинга или облака, договор и письмо провайдера о закреплении адреса.
Официальная документация Yandex Cloud отдельно объясняет подготовку IP-адресов для белого списка Минцифры. Если сервис не может получить собственный внешний IP, перед ним можно поставить L7-балансировщик с выделенным статическим адресом.

3. Не полагайтесь на общий IP дешёвого хостинга
На shared-хостинге один адрес часто обслуживает сотни сайтов разных владельцев. Сам сайт при этом может работать нормально, но доказать исключительное закрепление адреса сложно. Кроме того, соседние проекты меняются без вашего контроля.
Для серьёзной заявки лучше использовать VPS, выделенный сервер, облачный балансировщик или другую схему, где внешний IP закреплён именно за вашим сервисом. Это не делает включение автоматическим, зато убирает очевидную техническую проблему.
4. Соберите полный реестр доменов
Создайте таблицу всех адресов, к которым обращается браузер или мобильное приложение. Для каждого укажите владельца, назначение, IP, страну размещения и критичность.
| Компонент | Пример | Что проверить | Риск |
|---|---|---|---|
| Основной сайт | example.ru | A, AAAA, редиректы, IP | Сайт не откроется |
| Версия www | www.example.ru | Куда перенаправляет | Редирект оборвётся |
| API | api.example.ru | Авторизация и данные | Пустой каталог или кабинет |
| Статика/CDN | cdn.example.ru | CSS, JS, фото, видео | Сломанная вёрстка |
| Хранилище | files.example.ru | Документы и вложения | Не скачиваются файлы |
| Авторизация | auth.example.ru | Вход, OAuth, SMS | Невозможно войти |
| Платёж | Домен банка | Редирект и callback | Невозможно оплатить |
5. Уберите критические зарубежные зависимости
Иностранный сервис не обязательно плох и не обязательно запрещён. Проблема в другом: во время режима ограниченного доступа он может быть недоступен, а вместе с ним перестанет работать ваша функция.
Чаще всего владельцы забывают про:
- Google Fonts и другие внешние шрифты;
- Google reCAPTCHA;
- библиотеки с jsDelivr, unpkg и cdnjs;
- Cloudflare или другой иностранный reverse proxy/CDN;
- видео YouTube и Vimeo;
- виджеты иностранных соцсетей и мессенджеров;
- зарубежные карты, аналитику и коллтрекинг;
- формы, которые отправляют данные в иностранную CRM;
- SMTP, API рассылок и webhook на внешних платформах;
- объектные хранилища и серверы изображений за пределами РФ.
Критические CSS, JavaScript, шрифты и изображения лучше хранить локально. Для карт, аналитики, CAPTCHA, видео и коммуникаций нужны российские альтернативы либо собственный контролируемый компонент. Подробнее о поиске внешних подключений я писал в материале о локализации сайтов и 152-ФЗ.
6. Проверьте DNS
Проверьте A, AAAA, CNAME, NS, MX и редиректы. Типичная ошибка: A-запись ведёт на российский сервер, но www через CNAME уходит к иностранному CDN. Или браузер предпочитает IPv6, который ведёт на другой контур и не был указан в документах.
Базовые команды для администратора:
dig +short A example.ru
dig +short AAAA example.ru
dig +short NS example.ru
curl -I https://example.ru
curl -sS -o /dev/null -w '%{remote_ip}\n' https://example.ru
Эти команды показывают текущий ответ из одной точки сети. Для полной картины нужны проверки у нескольких операторов и из разных регионов.
7. Не делайте HTTP/3 единственным вариантом
Сайт должен стабильно работать по обычному HTTPS через TCP-порт 443 с корректной цепочкой сертификата. HTTP/3 можно использовать как ускорение, но должен сохраняться рабочий откат на HTTP/2 или HTTP/1.1. Не заставляйте клиента зависеть от одного транспорта.
8. Проверьте безопасность и документы
Подготовка к белому списку не отменяет базовую безопасность:
- актуальные версии CMS, плагинов и серверного ПО;
- HTTPS и корректная конфигурация сертификата;
- резервное копирование;
- журналирование изменений и инцидентов;
- защита административной панели;
- ограничение лишних открытых портов;
- защита API и форм от злоупотреблений;
- политика обработки персональных данных и необходимые согласия;
- локализация персональных данных, если сайт их собирает.
Не приписывайте несуществующие требования. Например, наличие файла политики конфиденциальности не включает сайт в перечень автоматически. Но явные проблемы с законодательством и безопасностью точно не усилят заявку.
Как подготовить WordPress к работе при ограничениях
WordPress сам по себе не мешает включению в белый список. Проблема обычно в теме, плагинах и внешних интеграциях, накопленных за годы. Сайт выглядит «локальным», но при открытии делает десятки запросов на чужие домены.
Аудит через браузер
- Откройте сайт в Chrome или другом браузере.
- Нажмите F12 и перейдите во вкладку Network.
- Включите Disable cache.
- Перезагрузите страницу.
- Проверьте столбец Domain или сохраните HAR-файл.
- Повторите проверку для главной, статьи, каталога, корзины, оплаты, формы, входа и личного кабинета.
Одной главной страницы недостаточно. Зависимость может появляться только после нажатия кнопки, входа пользователя или перехода к оплате.

Что проверить в WordPress
| Узел | Типичная проблема | Что делать |
|---|---|---|
| Тема | Шрифты и библиотеки с внешнего CDN | Скачать и подключить локально |
| Кэш | CDN меняет IP или обслуживает файлы за рубежом | Использовать контролируемый российский контур |
| Формы | reCAPTCHA, зарубежный SMTP или CRM | Заменить и проверить полный путь заявки |
| WooCommerce | Внешняя оплата, доставка, остатки | Проверить домены и callback каждого модуля |
| Изображения | Offload Media в зарубежном хранилище | Перенести файлы или поставить российскую точку входа |
| Комментарии | Аватары Gravatar не загружаются | Локальные аватары или отказ от внешней картинки |
| Аналитика | Ошибка скрипта ломает интерфейс | Загружать аналитику асинхронно и без влияния на функции |
| WP-Cron | Задачи вызывают недоступные API | Локализовать интеграции и логировать ошибки |
| REST API | Фронтенд обращается к другому домену | Включить API-домен в схему и заявку |
Особое внимание формам
Форма может визуально работать, но письмо не придёт из-за внешнего SMTP, заявка не попадёт в CRM или проверка CAPTCHA не завершится. Тестируйте не нажатие кнопки, а конечный результат: запись появилась в базе, уведомление дошло, менеджер увидел заявку, пользователь получил подтверждение.
В качестве резервного канала можно оставить контакт через доступную российскую платформу. Например, для WordPress у меня есть отдельный материал про кнопку связи через MAX. Это не заменяет включение сайта, но помогает не потерять контакт с клиентом при сбое формы.
Административная часть WordPress
Даже если публичные страницы открываются, обновления WordPress, плагины, лицензии темы, антиспам и внешние API могут быть недоступны. Для аварийного режима заранее подготовьте:
- доступ к серверу и резервной копии без зависимости от одного SaaS;
- локальный архив критичных плагинов и темы;
- документированную процедуру обновления;
- контакты хостинга и регистратора;
- мониторинг с российских точек;
- страницу с контактами, которая не зависит от JavaScript.
Как добавить сайт в белый список: пошаговый план
Шаг 1. Определите критические пользовательские сценарии
Не начинайте с IP. Сначала выпишите, что человек должен суметь сделать:
- открыть главную и контакты;
- найти товар или услугу;
- войти в аккаунт;
- отправить заявку;
- оформить и оплатить заказ;
- получить документ;
- увидеть статус операции;
- связаться с поддержкой.
У каждого сценария будет собственная цепочка доменов и сервисов.
Шаг 2. Нарисуйте схему инфраструктуры
Укажите DNS, CDN, балансировщик, веб-серверы, API, базы данных, хранилище, авторизацию, оплату, рассылки, мониторинг и внешние интеграции. Отметьте страну размещения каждого компонента и владельца.
Шаг 3. Перенесите публичный контур в российскую инфраструктуру
Уберите зарубежную точку входа из критического пути. Если миграция всей системы невозможна, начните с российского reverse proxy или L7-балансировщика с выделенным IP, но только как с прозрачной и контролируемой архитектуры. Не используйте такую схему для сокрытия реального назначения трафика.
Шаг 4. Закрепите статические IP
Защитите адреса от случайного удаления, соберите подтверждающие документы, укажите связь каждого IP с конкретным доменом и функцией.
Шаг 5. Локализуйте зависимости
Перенесите критичную статику, замените CAPTCHA, аналитику, карты, видео, SMTP и интеграции. После каждого изменения снова снимайте список сетевых запросов.
Шаг 6. Подготовьте правовую и информационную часть
Проверьте реквизиты владельца, контакты, политику обработки данных, согласия, оферту и другие документы, применимые к вашему сервису. Не вставляйте шаблоны вслепую: состав документов зависит от реально собираемых данных и процессов.
Шаг 7. Соберите доказательства значимости
Сделайте короткую аналитическую записку: кто пользуется сервисом, сколько пользователей приходит с мобильных устройств, какие операции выполняются и какой ущерб создаёт недоступность. Приложите Метрику, статистику приложения, договоры и письма партнёров.
Шаг 8. Направьте обращения
Коммуникация по перечню ведётся через Минцифры и органы, которые могут рекомендовать ресурс. Практический маршрут:
- Направить обращение через официальную форму Минцифры. Если соответствующая подкатегория доступна, выбрать «Интернет-услуги» и вопрос доступности сайтов и сервисов при ограничениях мобильного интернета.
- Обратиться в региональное министерство цифрового развития.
- Направить материалы в профильный орган: здравоохранение, транспорт, образование, торговлю или другое ведомство по тематике сервиса.
- Использовать профильную ассоциацию или отраслевое объединение, если вы в нём состоите.
Это не четыре независимые «заявки на автоматическое включение», а четыре возможных канала, через которые ресурс получает рассмотрение и поддержку. В открытой практике нет универсальной кнопки с гарантированным сроком и результатом.
Шаг 9. Отвечайте на технические запросы
Назначьте одного ответственного специалиста. Он должен быстро подтвердить IP, объяснить архитектуру, предоставить обновлённую таблицу и сообщать о плановых изменениях. Если между заявкой и проверкой вы сменили CDN или адрес, старые сведения могут стать бесполезными.
Шаг 10. Проверьте результат у разных операторов
После подтверждения нельзя ограничиться открытием главной страницы из офиса. Проверяйте реальные мобильные сети, регионы и сценарии. Фиксируйте дату, оператора, тип сети, домен, IP, результат и скриншот ошибки.
Какие сведения приложить к обращению
Пакет лучше разделить на понятное сопроводительное письмо и техническое приложение. Чиновнику не нужно искать IP внутри двадцати страниц маркетингового текста, а инженеру не нужна история компании вместо таблицы адресов.
Состав основного письма
- Полное наименование заявителя.
- ИНН, ОГРН или ОГРНИП, адрес и контакты.
- ФИО ответственного руководителя и технического специалиста.
- Название, адрес и назначение сервиса.
- Описание аудитории и географии.
- Обоснование общественной или экономической значимости.
- Последствия недоступности.
- Просьба рассмотреть ресурс и рекомендовать его включение.
- Перечень приложений.
Техническое приложение
| Поле | Что указать |
|---|---|
| Домен | Точное имя без маски и предположений |
| Назначение | Сайт, API, авторизация, файлы, оплата |
| IPv4 | Каждый статический адрес отдельно, предпочтительно /32 |
| IPv6 | Каждый реально используемый адрес или сеть |
| Провайдер | Название хостинга или облака |
| Размещение | Город и страна ЦОД |
| Подтверждение | Скриншот панели, договор или письмо провайдера |
| Протоколы | HTTPS, API и необходимые порты |
| Зависимости | Внешние сервисы, без которых сценарий не работает |
| Ответственный | ФИО, телефон, email технического специалиста |
Шаблон обращения
Тема: о рассмотрении интернет-ресурса для включения в перечень сервисов, доступных при ограничениях мобильного интернета
[Наименование организации или ИП] является владельцем интернет-сервиса [название, URL], предназначенного для [краткое описание функции].
Сервисом пользуются [количество] пользователей в месяц, из них [доля] заходят с мобильных устройств. Основная география: [регионы]. Через ресурс пользователи выполняют [перечень значимых операций].
Недоступность сервиса в периоды ограничения мобильного интернета приводит к [конкретные последствия для граждан, организаций или региона]. Значимость подтверждается [данные Метрики, количество операций, договоры, письма партнёров и другие документы].
Публичная инфраструктура сервиса размещена на территории Российской Федерации. Для пользовательского доступа используются закреплённые статические IP-адреса и домены, перечисленные в техническом приложении. Ответственным за техническое взаимодействие назначен [ФИО и контакты].
Просим рассмотреть возможность включения интернет-сервиса [название] в перечень ресурсов, доступ к которым сохраняется в периоды ограничения работы мобильного интернета, либо направить рекомендацию о его включении в Минцифры России.
Приложения: описание сервиса, статистика аудитории, обоснование значимости, перечень доменов и IP-адресов, схема инфраструктуры, подтверждение закрепления адресов, контактные данные ответственных лиц.
Шаблон нужно адаптировать под реальный сервис. Не заявляйте социальную значимость, которую невозможно подтвердить, и не прячьте внешние компоненты.
Как проверить, что сайт действительно работает
Проверка должна повторять действия обычного пользователя. Сделайте матрицу тестирования:
| Проверка | МТС | МегаФон | Билайн | T2 |
|---|---|---|---|---|
| Главная страница | Да/нет | Да/нет | Да/нет | Да/нет |
| CSS и изображения | Да/нет | Да/нет | Да/нет | Да/нет |
| Поиск и каталог | Да/нет | Да/нет | Да/нет | Да/нет |
| Вход в кабинет | Да/нет | Да/нет | Да/нет | Да/нет |
| Форма заявки | Да/нет | Да/нет | Да/нет | Да/нет |
| Оплата | Да/нет | Да/нет | Да/нет | Да/нет |
| Скачивание файла | Да/нет | Да/нет | Да/нет | Да/нет |

Для каждой ошибки сохраните:
- точное время и регион;
- название оператора;
- URL и IP;
- скриншот;
- текст ошибки;
- HAR-файл браузера;
- результат DNS-разрешения;
- серверные логи за этот интервал.
Если главная открывается, а корзина нет, не пишите просто «сайт не работает». Укажите конкретный домен API или платёжный переход. Так проблему можно диагностировать, а не обсуждать неделями.
Контроль после любых изменений
Составьте внутреннее правило: смена IP, CDN, балансировщика, домена API или платёжной интеграции требует повторной проверки и, при необходимости, актуализации сведений. Белый список не отменяет управление конфигурацией.
Что не поможет: распространённые мифы
«Достаточно купить российский домен»
Нет. Доменная зона не определяет фактическое размещение и не является пропуском.
«Перенесу сайт на российский хостинг, и он попадёт автоматически»
Нет. Российское размещение готовит инфраструктуру, но решение о включении принимается отдельно. Это прямо отмечено в документации облачных провайдеров.
«У моего хостинга открывается сайт, значит откроются все его клиенты»
Нет. Доступность сайта провайдера не означает доступность каждого клиентского домена и IP.
«Нужно сообщить только главный домен»
Недостаточно. Пользовательские функции могут зависеть от API, CDN, хранилища, авторизации и оплаты.
«Если поставить CDN, всё заработает»
CDN ускоряет доставку, но добавляет точки входа и адреса. Если вы не контролируете IP и географию, задача усложняется.
«Сертификат российского удостоверяющего центра решает вопрос»
Корректный TLS-сертификат нужен для HTTPS, но сам по себе не влияет на включение ресурса.
«Можно купить гарантированное внесение»
Подрядчик может провести аудит, перенести инфраструктуру и подготовить документы. Но обещание гарантированного решения государственного органа без прозрачного регламента стоит воспринимать крайне осторожно.
«После включения можно забыть об инфраструктуре»
Нет. Смена IP или внешней зависимости может снова сломать доступность, даже если название сервиса осталось прежним.
Что делать, если сайт не включили
Для малого бизнеса и небольших проектов отказ или отсутствие ответа вполне реальны. Это не повод оставлять клиентов без связи. Нужна резервная схема.
- Сделайте облегчённую страницу. Контакты, адреса, режим работы, основные услуги и инструкции без тяжёлого JavaScript и внешних ресурсов.
- Дублируйте критичную информацию на доступных массовых платформах. Не весь сайт, а контакты, статус работы, каталог и ответы на частые вопросы.
- Подготовьте российский канал связи. Сообщество, чат-бот или страница на платформе, которая уже сохраняет доступность.
- Не храните все заявки в одном внешнем сервисе. У формы должна быть локальная запись и повторная отправка после восстановления связи.
- Сообщите клиентам резервные контакты заранее. Во время ограничения поздно объяснять, где вас искать.
- Собирайте факты об ущербе. Они пригодятся при повторном обращении и для более сильного обоснования.
Главная цель здесь не формальный статус, а непрерывность бизнеса. Иногда простая статическая страница с телефоном полезнее тяжёлого приложения, которое красиво загружается только до первого запроса к недоступному API.
Чек-лист владельца сайта
- Определены критические пользовательские сценарии.
- Нарисована актуальная схема инфраструктуры.
- Публичные точки входа находятся в России.
- Получены и закреплены статические публичные IP.
- Собраны домены, поддомены, A, AAAA и CNAME.
- Проверены редиректы между www и основным доменом.
- Критические шрифты, CSS, JS и изображения локализованы.
- Проверены API, CAPTCHA, карты, видео, SMTP и CRM.
- Форма протестирована до фактического получения заявки.
- Оплата проверена вместе с callback и статусом заказа.
- Подготовлены документы о закреплении IP.
- Собраны Метрика, MAU, DAU, операции и география.
- Сформулированы последствия недоступности.
- Подготовлены письмо и техническое приложение.
- Обращения направлены в федеральный и профильный региональный канал.
- Назначен технический ответственный.
- Есть резервная страница и канал связи.
- Настроены тесты у нескольких мобильных операторов.
- Изменения IP и доменов проходят контроль.
Частые вопросы
Можно ли самостоятельно добавить сайт в белый список?
Самостоятельно изменить перечень нельзя. Владелец может подготовить ресурс и направить обоснованное обращение в Минцифры, региональный или профильный орган. Решение принимают уполномоченные структуры.
Есть ли официальная форма заявки?
Единого публичного регламента с гарантированным сроком и результатом нет. Обращение можно направить через контакты Минцифры и параллельно через региональное или отраслевое ведомство. Доступные категории формы могут изменяться.
Обязательно ли переносить сайт в Россию?
Для подготовки к включению публичный контур и вычислительные мощности сервиса должны находиться в российской инфраструктуре. Зарубежные компоненты в критическом пути создают риск недоступности.
Подойдёт ли обычный виртуальный хостинг?
Технически сайт может работать, но общий IP затрудняет подтверждение закрепления адреса за конкретным ресурсом. Для заявки предпочтительнее выделенный статический IP.
Нужен ли российский домен .ru или .рф?
Доменная зона сама по себе не решает вопрос. Важнее фактическое размещение, публичные IP, назначение сервиса и возможность подтвердить инфраструктуру.
Можно ли оставить Cloudflare?
Иностранный reverse proxy или CDN усложняет схему: пользователи подключаются к его адресам, а не напрямую к вашему серверу. Для предсказуемой работы нужен контролируемый российский входной контур и понятные статические IP.
Нужно ли указывать поддомены?
Да, если через них пользователи получают страницы, API, файлы, авторизацию или другие функции. Основного домена недостаточно.
Что делать с IPv6?
Если AAAA-запись опубликована и пользователи реально подключаются по IPv6, адрес нужно учитывать в схеме и документах. Иначе браузер может выбрать незаявленный маршрут.
WordPress может попасть в белый список?
Да. CMS не является критерием отбора. Важны назначение ресурса, его востребованность, инфраструктура и отсутствие незаявленных критических зависимостей.
Почему разрешённый сайт открывается без картинок?
Вероятнее всего, изображения находятся на другом домене или CDN, который не доступен в текущем режиме. Нужно проверить сетевые запросы страницы и заявленный контур.
Российский SSL-сертификат добавляет сайт в список?
Нет. Сертификат обеспечивает защищённое соединение, но не является заявкой и не даёт автоматического разрешения.
Сколько рассматривается обращение?
Отдельного общедоступного регламента со специальным сроком включения нет. Обычные обращения рассматриваются по применимым правилам, но это не означает, что за тот же срок будет принято решение о добавлении ресурса.
Можно ли гарантировать включение?
Нет. Можно гарантировать качество технической подготовки и комплекта документов, но не решение уполномоченного органа.
Работают ли белые списки на домашнем интернете?
Согласно официальному разъяснению Минцифры, механизм используется при ограничении мобильного интернета и не относится к фиксированному доступу.
Что делать после включения?
Регулярно проверять критические сценарии у разных операторов, контролировать IP и домены, фиксировать изменения инфраструктуры и своевременно актуализировать сведения.
Итог
Чтобы сайт работал при ограничениях мобильного интернета, нужны два независимых результата.
- Технический: сайт обслуживается через понятный российский контур со статическими IP и не разваливается из-за недоступных внешних компонентов.
- Организационный: уполномоченные органы признали сервис востребованным или значимым и включили необходимые сетевые параметры в перечень.
Первый результат находится в руках владельца и разработчика. Второй зависит от процедуры рассмотрения. Поэтому начинать нужно не с обещаний «внесём за три дня», а с аудита, карты зависимостей, закреплённых адресов и доказательств реальной пользы сервиса.
Я занимаюсь разработкой, SEO, автоматизацией и техническим аудитом сайтов. Если вам нужно проверить WordPress или другой проект, найти внешние зависимости, подготовить схему инфраструктуры и понятное техническое приложение, связаться со мной можно через страницу автора.
Источники и полезные документы
- Минцифры: сервисов, доступных при ограничениях мобильного интернета, стало больше.
- Минцифры: белый список используется только при ограничении мобильного интернета.
- Yandex Cloud: сведения для включения ресурса в белый список Минцифры.
- Официальная форма обращения в Минцифры.
- Право.ru: практика включения и отсутствие формализованных правил.
Добавить комментарий