Аудит сайта клиники по 152-ФЗ: 9 ошибок

Для клиники сайт — это формы записи, обратного звонка и вызова врача на дом. В них человек оставляет имя, телефон и дату рождения, а в свободном поле сообщения может написать что угодно, в том числе о здоровье. Цена ошибки здесь выше, чем на обычном сайте. За утечку сведений о здоровье юридическому лицу грозит штраф от 10 до 15 млн ₽ (ч. 16 ст. 13.11 КоАП), а при повторе — от 1 до 3% годовой выручки, но не менее 25 млн ₽ (ч. 18).

Коротко: 12 замечаний (9 существенных и 3 рекомендации), 7 пунктов в порядке, 6 вопросов, которые мы задали клинике. Хотите сразу проверить свой сайт? Перейти к чек-листу или скачать PDF.

Короткие разборы отдельных ошибок мы публикуем в нашем VK.

Что оказалось в порядке

Аудит ищет не только ошибки, поэтому начнём с хорошего:

политика опубликована и доступна со всех страниц, где собираются данные (ст. 18.1 ч. 2; штраф за её отсутствие для юрлица — 30–60 тыс. ₽, ч. 3 ст. 13.11 КоАП);
оператор указан и внесён в реестр Роскомнадзора (ст. 22 ч. 1; без уведомления — 100–300 тыс. ₽, ч. 10 ст. 13.11 КоАП);
чекбоксы согласия не отмечены заранее;
по данным клиники, данные за границу не передаются, базы и серверы находятся в России;
форма отзыва не публикует телефон и e-mail, биометрия не собирается.

Девять ошибок, которые нашёл аудит

1. Cookie-баннер, который ничего не решает

Баннер предлагает одну кнопку согласия, выбора нет. Мы проверили, что происходит в браузере: запросы к сервису аналитики уходят независимо от баннера. Дополнительно согласие на cookie «зашито» в отправку формы заявки, а отдельного документа о cookie на сайте нет.

Схема cookie-баннера на сайте клиники: запросы аналитики до выбора и после выбора пользователя — Cookie-баннер и запросы аналитики на сайте клиники

Отдельной нормы о cookie в 152-ФЗ нет. Но если cookie и сопутствующие данные позволяют определить человека, они персональные (ст. 3 п. 1), и согласие на них должно быть конкретным, информированным и однозначным (ст. 9 ч. 1). Поэтому мы говорим о расхождении с принципом осознанного согласия, а не об установленном нарушении.

КАК ИСПРАВИТЬ. Опубликовать документ о cookie (какие файлы, зачем, чьи сервисы, сколько хранятся). В баннере сделать кнопки «Принять» и «Отклонить», убрать согласие на cookie из чекбоксов форм. Необязательные скрипты запускать только после выбора.

КАК ПРОВЕРИТЬ. Откройте сайт в режиме разработчика (вкладка Network) и не нажимайте на баннер. Запросов к аналитике быть не должно.

В VK мы разбирали эту проверку по шагам.

2. Один чекбокс на два действия

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

Закон требует согласия конкретного, информированного, однозначного и оформленного отдельно от иных документов (ст. 9 ч. 1). Когда нужна письменная форма, например для сведений о здоровье, в согласии должны быть цель, перечень данных, оператор, действия, срок и способ отзыва (ст. 9 ч. 4, ст. 10 ч. 2 п. 1). Для юрлица штраф за обработку без письменного согласия, когда оно требуется, или за неполный состав сведений в нём — 300–700 тыс. ₽, при повторе 1–1,5 млн ₽ (ч. 2 и 2.1 ст. 13.11 КоАП). Оговорка: согласие не единственное основание, для договора и медицинской деятельности закон предусматривает другие (ст. 6 ч. 1 п. 5, ст. 10 ч. 2 п. 4).

КАК ИСПРАВИТЬ. Подготовить отдельный документ согласия. На каждой форме поставить отдельный чекбокс со ссылкой на него, а политику вынести отдельной строкой без слов «ознакомлен».

КАК ПРОВЕРИТЬ. Чекбокс ведёт на отдельный документ, и в нём есть все пункты из ст. 9 ч. 4.

3. Политика разрешает прятать согласие в чужих документах

В политике сказано, что согласие может быть «встроено» в другой документ, который подписывает человек. Рядом стоит неточная ссылка на закон: случаи обработки без согласия указаны не в «п. 2 ст. 6», а в ст. 6 ч. 1 п. 2–11.

Закон прямо требует обратного: согласие оформляется отдельно от других документов (ст. 9 ч. 1). Политика, которая допускает иное, закрепляет практику, на которую в законе нет опоры.

КАК ИСПРАВИТЬ. Убрать фразу о «внедрении» согласия, написать, что оно оформляется отдельно, и исправить ссылку на «пункты 2–11 части 1 статьи 6».

КАК ПРОВЕРИТЬ. В политике нет ни одной формулировки, допускающей согласие внутри иного документа.

4. Политика написана для магазина, а не для клиники

В политике нет пациентов и медицинских услуг. Субъекты названы как подрядчики, заказчики и контрагенты, цель — «основная деятельность по Уставу». Зато в перечне данных есть СНИЛС, платёжные реквизиты, данные для учётной записи и точная геолокация. Таких полей на формах сайта нет, а регистрации и личного кабинета, судя по проверенным страницам, тоже нет.

Обработка ограничивается заранее определёнными целями, а объём данных не должен быть избыточным (ст. 5 ч. 2, 5). Сведения о здоровье — специальная категория со своими основаниями (ст. 10 ч. 1–2). Для юрлица штраф за обработку вне предусмотренных законом случаев или несовместимую с целями сбора — 150–300 тыс. ₽ (ч. 1 ст. 13.11 КоАП).

КАК ИСПРАВИТЬ. Описать каждую цель отдельным блоком: цель, субъекты, перечень данных, основание, способы, срок. Выделить цели: запись и обратный звонок, медицинские услуги, отзывы, аналитика, кадры. Убрать данные и цели, которых нет в реальных процессах.

КАК ПРОВЕРИТЬ. Перечни данных в политике совпадают с полями реальных форм.

5. Бессрочное хранение

В политике срок обработки прямо назван неограниченным.

Данные хранятся не дольше, чем требуют цели, если срок не задан законом или договором (ст. 5 ч. 7). После достижения цели их уничтожают, как правило, в течение 30 дней (ст. 21 ч. 4). Бессрочное хранение заявок увеличивает и последствия возможной утечки: за утечку данных 1–10 тыс. человек штраф для юрлица — 3–5 млн ₽ (ч. 12 ст. 13.11 КоАП).

КАК ИСПРАВИТЬ. Для каждой цели указать срок и документ, на который он опирается: закон, приказ или решение оператора. Для медицинской документации срок берётся из профильного документа Минздрава.

КАК ПРОВЕРИТЬ. У каждой цели в политике есть срок и основание.

В VK мы показали, как выглядит правильная формулировка срока.

6. Отзывы с именем без отдельного согласия

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

Публикация имени и текста для всех посетителей — распространение (ст. 3 п. 5). Согласие на него оформляется отдельно (ст. 10.1 ч. 1), молчание согласием не считается (ч. 8), а по требованию автора распространение прекращают в течение трёх рабочих дней (ч. 12–14). Если в тексте сведения о здоровье, это уже специальная категория.

КАК ИСПРАВИТЬ. Добавить отдельный необязательный чекбокс на публикацию отзыва и имени и описать в политике, как удалить отзыв по просьбе автора.

КАК ПРОВЕРИТЬ. На форме есть отдельная галочка, в политике описан порядок удаления.

7. Сервисы на сайте есть, в политике их нет

На всех страницах подключён счётчик аналитики, на странице контактов встроена карта. В политике о них ни слова, а общая оговорка гласит, что данные третьим лицам без письменного согласия не передаются.

Политика должна описывать цели, данные и способы обработки (ст. 18.1 ч. 1 п. 2). Если сервис получает IP-адрес и сведения об устройстве, об этом надо сказать.

КАК ИСПРАВИТЬ. Назвать каждый сервис, цель, категории данных и получателя.

КАК ПРОВЕРИТЬ. Список сервисов в политике совпадает с реальными запросами сайта.

8. Раздел о передаче данных за границу, которой нет

Политика даёт оператору право передавать данные в другие страны и хранить их там, причём «по письменному согласию». По словам клиники, ничего за границу не уходит.

Описана деятельность, которой не ведётся. К тому же механизма «согласие вместо уведомления» в ст. 12 нет: до передачи оператор уведомляет Роскомнадзор (ч. 3), а базы данных граждан РФ должны находиться в России (ст. 18 ч. 5). Если бы данные действительно хранились за рубежом, штраф для юрлица составил бы 1–6 млн ₽ (ч. 8 ст. 13.11 КоАП).

КАК ИСПРАВИТЬ. Заменить раздел одной фразой: трансграничная передача не осуществляется, базы находятся в России.

КАК ПРОВЕРИТЬ. Текст политики совпадает с фактами.

9. Нет порядка обращений и порядка уничтожения данных

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

Сроки здесь жёсткие: ответ на запрос — 10 рабочих дней с возможным продлением на 5 (ст. 14 ч. 3, ст. 20 ч. 1), исправление неточных данных — 7 рабочих дней (ст. 20 ч. 3), прекращение неправомерной обработки — 3 рабочих дня (ст. 21 ч. 3), уничтожение — 30 дней (ст. 21 ч. 4–5). Штрафы для юрлиц: за непредоставление информации субъекту — 40–80 тыс. ₽ (ч. 4 ст. 13.11), за неисполнение требования об уничтожении в срок — 50–90 тыс. ₽ (ч. 5).

КАК ИСПРАВИТЬ. Добавить в политику разделы «Порядок обращений» и «Уничтожение данных» и подготовить внутренний документ: кто уничтожает, как, в какие сроки и как это фиксируется.

КАК ПРОВЕРИТЬ. В политике есть порядок и сроки, а внутренний документ можно предъявить.

В VK мы разобрали, что такое внутренний документ об уничтожении данных и как он выглядит.

Три рекомендации

Это не нарушения, но тексту они помогают:

добавить дату и версию политики, определить термины и исправить сквозную нумерацию;
указать на странице «Контакты» и в подвале оператора, реквизиты и контакт ответственного за организацию обработки (ст. 22.1);
дополнить перечень прав: подтверждение факта обработки, сведения о лицах с доступом, возражение против автоматизированного решения, отказ от рекламы (ст. 14 ч. 7, ст. 16 ч. 3, ст. 15 ч. 2).

Вопросы к клинике: что не видно на сайте

Сайт показывает только внешнюю сторону. Как данные живут внутри — в медицинской информационной системе, на почте, в мессенджерах — известно только самому оператору, поэтому мы задали ему шесть вопросов:

Попадают ли сведения о здоровье в свободные поля форм или по телефону, и на каком основании они обрабатываются?
Какие сроки хранения установлены для заявок, медицинской документации, кадровых документов и отзывов?
Как на практике уничтожаются данные заявок и составляется ли акт?
Есть ли договор с разработчиком медицинской информационной системы, в котором определены данные, действия, цели и безопасность (ст. 6 ч. 3)?
Назначен ли ответственный за обработку и есть ли внутренние документы по ст. 18.1? Совпадают ли сведения в уведомлении Роскомнадзора с новыми целями (ст. 22 ч. 7)?
Используются ли телефоны и e-mail из заявок для рекламных звонков и сообщений? Для этого нужно отдельное предварительное согласие (ст. 15 ч. 1).

Чек-лист 152-ФЗ для сайта клиники: 27 пунктов в PDF — Чек-лист 152-ФЗ: 27 пунктов для проверки сайта клиники

Чек-лист: проверьте свой сайт самостоятельно

Каждую из девяти ошибок можно найти у себя за один заход. Идите по строкам таблицы:

Что проверить	Где смотреть	Что должно быть
Политика	Подвал сайта и формы	Открывается, ссылка есть на каждой форме со сбором данных
Цели и данные	Раздел о целях в политике	Для клиники: пациенты, медицинские услуги, данные о здоровье; данные как на формах
Срок хранения	Раздел о сроках	Срок для каждой цели и документ-основание
Согласие	Форма записи	Отдельный документ, пустой чекбокс, без слов «ознакомлен»
Cookie	Вкладка Network, до клика по баннеру	Нет запросов к аналитике, есть «Отклонить»
Сервисы	Код страницы, Network	Каждый подключённый сервис назван в политике
Отзывы	Форма отзыва	Отдельная галочка на публикацию имени и текста
Обращения и уничтожение	Политика	Порядок, сроки ответа и способ уничтожения данных

Хотите проверить всё по полному списку? Скачайте PDF-чек-лист: 27 пунктов с основаниями из закона. Его можно распечатать и отмечать пункты.

Что входит в аудит сайта

Мы проверяем сайт по тексту 152-ФЗ и по связанным нормам: политику, формы, согласия, cookie, сторонние сервисы, отзывы и то, как всё это согласуется между собой. Внутренняя часть — приказы, договоры с подрядчиками, процедура уничтожения данных — проверяется по документам оператора, поэтому аудит заканчивается вопросами, на которые клиника отвечает сама.

Мы проводим такие аудиты и готовим документы: политику обработки персональных данных, тексты согласий и политику cookie, под реальные формы и сервисы сайта.

Итоги аудита в цифрах


Замечаний всего	12
из них существенных	9
рекомендаций	3
Пунктов в порядке	7
Вопросов клинике	6

Если вы хотите знать, сколько таких пунктов нашлось бы на вашем сайте, напишите нам.

Источники: Федеральный закон от 27.07.2006 № 152-ФЗ «О персональных данных»; КоАП РФ, ст. 13.11.

FORKEL — разработка интернет-магазина: технологии и запуск

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

С чего начинается FORKEL

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

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

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

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

Почему мы начали с технической основы

На старте важно разделить несколько задач:

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

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

Технологическая основа

В качестве платформы управления сайтом выбрана 1С-Битрикс: Управление сайтом, редакция «Малый бизнес». Это основа будущего интернет-магазина, на которой предстоит выстраивать работу с каталогом и коммерческими сценариями.

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

В ходе подготовки окружения мы работали с конфигурацией Docker Compose, PHP-контейнером, настройками PHP и конфигурацией Nginx. Также подготовили пример переменных окружения и документацию по запуску.

Отдельное внимание уделили конфигурации проекта и работе с Git: параметры локального окружения и секретные значения не должны случайно попадать в репозиторий. Для этого необходимо правильно настроить .gitignore, хранить пример конфигурации отдельно и проверять, какие файлы уже отслеживаются Git.

Важно понимать границы текущего результата: локальное окружение подготовлено и, по результатам проверки, работает. Это ещё не означает, что весь сайт или функциональность интернет-магазина уже развёрнуты и готовы к использованию.

«FORKEL — от проектирования интерфейса к технической реализации интернет-магазина»

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

Дальнейшую работу можно условно разделить на несколько направлений.

1. Интерфейс и пользовательские сценарии

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

2. Backend и платформа

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

3. Каталог и данные о товарах

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

4. Интеграции и обработка заказов

В перспективе необходимо будет рассмотреть обмен данными с 1С, подключение платёжных решений и служб доставки. Для платежей рассматриваются ЮKassa и Альфа-Банк. Конкретная схема интеграции, состав модулей и настройки будут определяться на соответствующем этапе.

Все эти направления пока относятся к планам развития. Мы не будем описывать их как реализованные функции до тех пор, пока они не будут действительно внедрены и проверены.

Почему будем рассказывать о разработке поэтапно

Вместо одного большого рассказа о проекте мы планируем разбирать отдельные решения по мере их появления.

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

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

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

Что дальше

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

В следующем материале разберём Docker-окружение FORKEL подробнее — от структуры конфигурационных файлов до запуска и проверки работоспособности. Это будет разбор конкретной реализации, а не универсальная инструкция, оторванная от проекта.

FORKEL только начинает путь от проектирования к работающему интернет-магазину. В этой серии мы будем фиксировать этот путь последовательно — от технического фундамента до реализации пользовательских и коммерческих сценариев.

Как проверить, что заявки с WordPress доходят до адресата

Почему успешная отправка формы ещё ничего не гарантирует

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

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

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

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

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

Как проходит заявка с сайта WordPress

Типовая цепочка отправки заявки с почтовым уведомлением выглядит так:

Форма сайта → обработчик WordPress → сохранение заявки (если настроено) → WP Mail SMTP → Brevo → почтовый сервер получателя → почтовый ящик.

Каждый компонент отвечает за отдельную часть процесса.

Форма сайта собирает введённые пользователем данные и отправляет запрос.
Обработчик WordPress принимает запрос, проверяет данные и выполняет предусмотренные действия.
Хранилище заявок сохраняет обращение, если на сайте реализован такой механизм.
WP Mail SMTP передаёт почтовое сообщение настроенному почтовому сервису.
Brevo обрабатывает отправку письма и предоставляет сведения о статусе доставки.
Почтовая инфраструктура получателя принимает письмо и помещает его в почтовый ящик либо обрабатывает по своим правилам.

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

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

Шаг 1. Отправить контрольную заявку

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

Зафиксируйте результат:

появилась ли индикация успешной отправки;
исчезла ли форма или очистились ли поля;
отобразилось ли сообщение об ошибке;
возникли ли ошибки в браузере или сетевом запросе.

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

Что проверить в браузере

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

Обратите внимание на:

адрес и тип запроса;
HTTP-статус;
тело ответа сервера;
сообщения об ошибках;
время выполнения запроса.

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

Что подтверждает этот этап: форма инициирует запрос, а сайт возвращает определённый результат обработки.

Чего он не подтверждает: сохранение заявки и получение уведомления адресатом.

Шаг 2. Проверить, сохранилась ли заявка

Следующий этап — выяснить, что произошло с данными после отправки формы.

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

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

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

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

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

Что подтверждает этот этап: наличие записи подтверждает сохранение конкретной тестовой заявки в проверенном хранилище.

Чего он не подтверждает: успешную отправку письма или доставку уведомления.

Шаг 3. Проверить журнал WP Mail SMTP

Если форма должна отправлять уведомление по электронной почте, изучите журнал WP Mail SMTP.

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

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

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

Не следует сразу менять все настройки. Сначала определите, на каком этапе возникла ошибка и что именно сообщает журнал.

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

Что подтверждает этот этап: результат обработки попытки отправки на стороне WordPress и почтового механизма в пределах доступного журнала.

Чего он не подтверждает: фактическое появление письма во входящих у получателя.

Шаг 4. Проверить статус письма в Brevo

Если WordPress отправляет почту через Brevo, следующий источник данных — журнал событий этого сервиса.

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

В зависимости от результата могут встречаться следующие ситуации:

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

Точные названия статусов и доступность событий зависят от интерфейса и конфигурации сервиса.

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

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

Что подтверждает этот этап: статус, зарегистрированный почтовым сервисом, и доступные сведения о передаче сообщения принимающей стороне.

Чего он не подтверждает: прочтение письма человеком.

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

Последняя проверка — открыть почтовый ящик, на который настроена отправка уведомлений.

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

Если письмо не найдено, сопоставьте результаты предыдущих этапов:

Есть запись о заявке, но нет попытки отправки — проверяйте логику уведомления и обработчик формы.
WP Mail SMTP сообщает об ошибке — изучайте текст ошибки и настройки отправки.
Brevo зарегистрировал отказ или возврат — анализируйте причину на стороне почтовой доставки.
Brevo сообщает о доставке, но письма нет во входящих — проверьте спам, фильтры, правила обработки и журналы почтовой системы получателя.
Письмо пришло, но данные в нём неверны — проверяйте шаблон уведомления, сопоставление полей формы и обработку данных.

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

Что подтверждает этот этап: письмо действительно доступно в проверенном почтовом ящике.

Чего он не подтверждает: стабильную доставку всех будущих писем при любой нагрузке и любых условиях.

Практическая проверка K·ART·MAKE

Мы провели контрольную проверку двух форм на инфраструктуре K·ART·MAKE: формы обратной связи и калькулятора.

В обоих сценариях получили следующие результаты:

контрольные заявки успешно отправлены через формы;
тестовые записи найдены в предусмотренном хранилище;
WP Mail SMTP зафиксировал успешную отправку;
письма поступили в почтовый ящик;
проверенная цепочка с использованием Brevo работала корректно.

В проверенных сценариях ошибок не обнаружили.

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

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

Как поддерживать надёжность приёма заявок

Разовая проверка подтверждает работу конкретного сценария в конкретный момент. Для контроля в дальнейшем полезно организовать регулярные проверки.

Рекомендуется:

Периодически отправлять контрольные заявки. Проверяйте ключевые формы, особенно после обновлений WordPress, плагинов и настроек почты.
Контролировать сохранение обращений. Если заявки должны храниться на сайте, убедитесь, что их можно найти и восстановить.
Изучать журналы отправки. Обращайте внимание не только на успешные события, но и на ошибки, отказы и повторные попытки.
Проверять фактическое получение писем. Статус отправки полезен, но не заменяет контроль конечного результата.
Продумать резервный канал. Для критичных обращений можно предусмотреть дополнительное уведомление, интеграцию с CRM или очередь повторной отправки — с учётом архитектуры проекта.
Разделять хранение заявки и уведомление. По возможности данные обращения должны сохраняться независимо от успешности почтовой доставки. Тогда сбой уведомления не обязательно означает потерю самой заявки.
Документировать проверку. Фиксируйте дату, проверенную форму, результат сохранения, статус отправки и факт получения письма.

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

Когда нужна техническая диагностика сайта

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

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

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

K·ART·MAKE помогает разбираться в технических проблемах сайтов: от диагностики форм и интеграций до аудита, оптимизации и модернизации инфраструктуры.

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

Brevo для WordPress: SMTP, плюсы и минусы

Почему отправка почты с WordPress — это тоже часть инфраструктуры

Форма обратной связи на сайте кажется простой вещью: пользователь заполняет поля, нажимает кнопку, а заявка приходит на почту.

Но технически между этими двумя действиями происходит несколько операций.

Данные формы принимает WordPress, затем формируется письмо, оно передаётся почтовому серверу, проходит SMTP-аутентификацию и отправляется на почтовый сервер получателя.

Если один из этапов настроен неправильно, пользователь увидит сообщение «Заявка отправлена», а бизнес может так и не получить письмо.

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

На K·ART·MAKE для этой задачи мы используем связку:

WordPress → WP Mail SMTP → Brevo SMTP → рабочая почта.

В этой статье разберём, как она работает, почему мы выбрали такой подход, какие у Brevo есть плюсы и минусы и нужен ли VPN при использовании SMTP из России.

Как работает связка WordPress и Brevo

В нашей конфигурации каждый компонент выполняет свою задачу.

WordPress принимает данные из формы и формирует сообщение.

WP Mail SMTP отвечает за передачу письма через настроенный SMTP-сервис вместо стандартного механизма отправки WordPress.

Brevo выступает в роли SMTP relay — принимает письмо от сайта и передаёт его дальше в почтовую инфраструктуру.

Рабочая почта получает готовое сообщение с заявкой.

Упрощённо цепочка выглядит так:

Форма на сайте

↓

WordPress

↓

WP Mail SMTP

↓

Brevo SMTP

↓

Почтовый сервер получателя

Для пользователя вся эта система скрыта: он просто заполняет форму и нажимает кнопку.

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

Brevo SMTP для WordPress

Зачем использовать отдельный SMTP-сервис

Можно попытаться отправлять письма непосредственно средствами сервера.

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

Но у коммерческого сайта другая задача.

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

Использование отдельного SMTP-сервиса позволяет вынести часть почтовой инфраструктуры за пределы самого WordPress.

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

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

Что нам нравится в Brevo

SMTP и API

Brevo предоставляет несколько способов интеграции, включая SMTP и API.

Для нашего сценария нужен именно SMTP: сайт должен передать транзакционное письмо сервису, после чего оно отправляется получателю.

Это позволяет не усложнять архитектуру там, где достаточно простой и понятной SMTP-связки.

Транзакционные письма

Заявка из формы — типичный пример транзакционного сообщения.

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

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

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

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

Для технического специалиста это важнее, чем просто наличие кнопки «отправить письмо».

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

Работа с собственным доменом

Для коммерческого сайта важно не просто отправлять письма, но и корректно настроить отправителя и домен.

DNS-записи и механизмы аутентификации домена являются частью нормальной почтовой инфраструктуры.

Это отдельный этап настройки, который не стоит пропускать.

Бесплатный тариф для небольших объёмов

Для небольших проектов у Brevo есть бесплатный тариф.

На момент подготовки статьи он предусматривает ограничение до 300 отправлений в сутки.

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

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

Какие у Brevo есть минусы

У любого внешнего сервиса есть компромиссы, и Brevo здесь не исключение.

Зависимость от внешнего сервиса

После подключения Brevo становится частью инфраструктуры сайта.

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

Поэтому внешний SMTP — это не «магическое решение», а ещё один компонент системы, зависимость от которого необходимо учитывать.

Требуется правильная настройка

Само подключение SMTP не гарантирует идеальную доставку.

Нужно корректно настроить:

SMTP-аутентификацию;
адрес отправителя;
домен;
DNS-записи;
механизмы аутентификации домена;
WP Mail SMTP;
ограничения самого сервера.

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

Необходимость контролировать отправителя

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

Это влияет на прозрачность почтовой инфраструктуры и дальнейшую диагностику проблем с доставкой.

Не всем сайтам нужен Brevo

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

Поэтому мы не рассматриваем Brevo как универсальный выбор для любого WordPress-сайта.

Вопрос должен звучать иначе:

соответствует ли такая схема требованиям конкретного проекта?

Работает ли Brevo в России

Для российского бизнеса это один из первых вопросов при выборе зарубежного сервиса.

Наш практический опыт здесь довольно конкретный.

На момент подготовки этой статьи связка WordPress + WP Mail SMTP + Brevo SMTP на сайте K·ART·MAKE работает из России без VPN.

Мы используем её именно для отправки сообщений из форм сайта на рабочую почту.

Отдельный VPN для этой SMTP-связки нам не требуется.

Но здесь важно не делать слишком широких выводов.

Brevo — это не только SMTP. В платформе есть email-маркетинг, SMS и другие функции, и условия их использования могут различаться в зависимости от конкретного сервиса, страны и текущих правил.

Поэтому утверждение «Brevo полностью доступен из России» было бы слишком широким.

Корректнее говорить о конкретном сценарии:

мы используем Brevo SMTP для транзакционной отправки писем с WordPress-сайта и в нашей конфигурации это работает без VPN.

Нужен ли VPN для WordPress

В нашей архитектуре — нет.

WordPress и WP Mail SMTP устанавливают соединение с SMTP-инфраструктурой Brevo напрямую.

VPN не является частью этой схемы.

Если отправка перестанет работать, это также не означает автоматически, что требуется VPN.

Причина может находиться в самой конфигурации SMTP, DNS, сервере, сетевых ограничениях или почтовой системе получателя.

Поэтому сначала необходимо определить место сбоя.

Что проверять, если заявки перестали приходить

Когда пользователь говорит «я отправил форму, но письмо не пришло», недостаточно проверить только WordPress.

Диагностировать нужно всю цепочку.

1. Работает ли сама форма

Сначала проверяем, действительно ли данные формы были приняты сайтом.

Если форма не сформировала запрос или произошла ошибка JavaScript, до почтовой инфраструктуры дело вообще не дойдёт.

2. Формирует ли WordPress письмо

Следующий этап — проверить, создаётся ли сообщение и передаётся ли оно почтовому механизму.

3. Работает ли WP Mail SMTP

Здесь проверяется конфигурация mailer, SMTP credentials и результат тестовой отправки.

4. Устанавливается ли соединение с Brevo

Если SMTP-аутентификация не проходит, письмо не будет передано сервису.

5. Корректно ли настроен домен

Нужно проверить DNS и настройки аутентификации домена.

6. Что происходит после отправки

Даже если Brevo принял сообщение, это ещё не означает, что оно обязательно окажется во входящих получателя.

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

Именно поэтому правильная диагностика начинается не с предположения «Brevo не работает», а с проверки всей цепочки.

Как эта инфраструктура используется на K·ART·MAKE

На нашем сайте формы являются частью реального пользовательского сценария.

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

Калькулятор стоимости →

Для более общего обращения предусмотрена отдельная страница контактов.

Связаться с K·ART·MAKE →

После отправки формы заявка проходит через нашу почтовую инфраструктуру:

форма → WordPress → WP Mail SMTP → Brevo SMTP → рабочая почта.

Для посетителя это обычная веб-форма.

Для нас — ещё один компонент digital-инфраструктуры, который должен работать предсказуемо.

Когда такая схема имеет смысл

Связка WordPress + WP Mail SMTP + Brevo может быть оправдана, если сайту необходимо регулярно отправлять транзакционные письма и при этом хочется отделить почтовую инфраструктуру от самого веб-сервера.

Например:

сайт получает заявки через формы;
отправляет уведомления пользователям;
отправляет технические сообщения;
требует контролируемой SMTP-интеграции;
должен иметь понятную схему диагностики почтовых проблем.

Но если проект маленький и отправляет несколько сообщений в месяц, отдельный сервис может быть необязателен.

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

Наш вывод

Brevo не является универсальным решением для любой почтовой инфраструктуры.

Но для нашего сценария — WordPress, формы обратной связи, WP Mail SMTP и транзакционная отправка заявок на рабочую почту — эта связка подходит.

Главное преимущество для нас не в количестве функций, а в том, что архитектура остаётся понятной:

сайт отвечает за сайт, SMTP-сервис — за отправку почты.

И на момент подготовки материала наша конфигурация Brevo SMTP работает из России без VPN.

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

Именно поэтому при работе с digital-проектами мы смотрим не только на то, «работает ли форма», а на всю техническую цепочку, которая стоит за ней.

K·ART·MAKE — технический партнёр для бизнеса.

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