Проверка адреса доставки в Тильде нужна в тот момент, когда покупатель уже ввёл адрес в корзине, нажал «Оформить», а курьерская служба туда физически не доедет: соседняя область, дальнее СНТ или город, зону по которому закрыли ещё в прошлом квартале. Я закрывал такие задачи для интернет-магазинов на Tilda не один раз, и решение почти всегда сводится к одному принципу: сверять адрес с зоной доставки до того, как заказ уйдёт в CRM и деньги спишутся через эквайринг, а не после звонка менеджера с извинениями.
Зачем блокировать оформление заказа вне зоны доставки
На одном проекте с доставкой продуктовых наборов я считал долю таких отмен: 12% заказов оформлялись из городов, куда компания физически не возит товар. Менеджер прозванивал каждый вручную, тратил по 3-4 минуты на звонок и извинения, а часть клиентов уже успевала оплатить заказ через Т‑Банк эквайринг, деньги приходилось возвращать через личный кабинет банка. Отдельная головная боль в СДЭК: пункт выдачи в форме указан, а зона обслуживания по этому индексу у транспортной компании давно закрыта, и об этом узнают только на этапе передачи заказа.
Форма Тильды сама по себе не знает, куда компания возит товар. Поле адреса доставки принимает любую строку, а блок способов доставки в настройках карточки товара работает по регионам, но не по конкретным городам или почтовым индексам. Проверку приходится вешать отдельным скриптом поверх стандартной формы.
Как устроена проверка зоны доставки в корзине Tilda
Логика простая на бумаге и требует аккуратной реализации на практике. Скрипт слушает событие отправки формы заказа или потерю фокуса на поле адреса, забирает введённый текст, отправляет его в геокодер, получает нормализованный город, регион или координаты и сверяет результат со списком разрешённых зон. Если адрес не попадает в зону, кнопка «Оформить» блокируется, а рядом с полем появляется сообщение с причиной, не абстрактное «ошибка», а конкретное «доставка по этому адресу пока недоступна, свяжитесь с нами по телефону».
Блокировку без пояснения не использую: пользователь видит неактивную кнопку и уходит, не поняв, что случилось. Для магазина это выглядит как заказ, потерянный без причины, хотя причина есть, просто её не показали.
Что взять за основу зоны: города, полигоны или индексы
На практике использую три варианта, и выбор зависит от того, насколько плотно у заказчика распределена зона доставки.
| Метод определения зоны | Точность | Когда использовать |
|---|---|---|
| Список городов и районов | Средняя, без учёта границ внутри города | Доставка по конкретным населённым пунктам целиком |
| Полигон на карте (GeoJSON) | Высокая, до конкретной улицы | Курьерская доставка в пределах города с ограничением по районам |
| Почтовые индексы и коды ФИАС | Высокая для СДЭК и Почты России | Синхронизация с зонами обслуживания транспортной компании |
Бесплатный материал
🎁 Полезный скрипт в подарок
Подпишитесь на Telegram - пришлю готовый скрипт по этой теме.
Без спама. Отписка в 1 клик.
Сервисы геокодирования для проверки адреса: DaData, Яндекс или свой список
Сверять адрес можно тремя способами, и от выбора зависит и точность, и то, сколько запросов уйдёт в сутки при живом трафике магазина.
| Сервис | Бесплатный лимит | Что даёт |
|---|---|---|
| DaData | 10000 запросов в день | Подсказки по ФИАС, разбор адреса на город, улицу и индекс одним запросом |
| Яндекс Geocoder API | 1000 запросов в день на бесплатном тарифе | Координаты для сверки с полигоном, удобно при готовой карте зоны на Яндекс.Картах |
| Свой список городов без API | Без ограничений по запросам | Быстрое решение без внешних сервисов, но без проверки конкретной улицы или ПВЗ |
Для интернет-магазина с доставкой по нескольким крупным городам обычно хватает DaData: один запрос возвращает и нормализованный адрес, и код ФИАС, который потом сверяется со списком зон. Полигон через Яндекс беру, когда доставка курьером ограничена конкретными районами внутри одного города, а не городом целиком.
Пошаговая настройка проверки адреса при оформлении заказа
Собираю проверку в пять шагов, вне зависимости от того, что лежит в основе зоны, список городов или полигон.
- Фиксирую зоны доставки в одном месте, JSON-конфиге, а не в самом коде скрипта, чтобы менеджер мог поправить список городов сам, без правок JS.
- Вешаю обработчик на поле адреса в форме Тильды: слушаю событие blur и событие отправки формы, чтобы проверка срабатывала и при ручном вводе, и при автозаполнении.
- Отправляю введённый адрес в геокодер для нормализации, в сыром виде «мск, кутузовский 5» и «Москва, Кутузовский проспект, 5» сравнивать бессмысленно.
- Сверяю нормализованный адрес со списком зон и, если совпадения нет, блокирую кнопку отправки и показываю текст с контактами для ручного оформления.
- Логирую отказы через вебхук в n8n или в таблицу на своём сервере, чтобы через месяц видеть, из каких городов чаще всего приходят заказы вне зоны, и решать, расширять её или нет.
Вот упрощённый вариант на JS, без обращения к внешнему геокодеру, просто со сверкой по списку городов, для понимания принципа:
const allowedCities = ['москва', 'санкт-петербург', 'подольск', 'химки'];
function checkDeliveryZone(addressValue) {
const normalized = addressValue.trim().toLowerCase();
return allowedCities.some(city => normalized.includes(city));
}
document.addEventListener('submit', function (e) {
const form = e.target.closest('form');
if (!form || !form.querySelector('[name="address"]')) return;
const addressField = form.querySelector('[name="address"]');
if (!checkDeliveryZone(addressField.value)) {
e.preventDefault();
e.stopPropagation();
alert('Доставка по этому адресу пока недоступна. Свяжитесь с нами для уточнения.');
}
});Для реального проекта список городов и логика сверки сложнее: нужны опечатки, склонения, сокращения вроде «спб» и «мск», плюс кэш ответов геокодера, чтобы не платить за повторные запросы одного и того же адреса. Если делать это с нуля под конкретные зоны и способы доставки заказчика, разумнее заказать разработку кастомного скрипта для Тильды под свои условия доставки, чем дорабатывать код из статьи руками при каждом изменении зоны.
Как протестировать сценарий перед запуском
- Проверить адрес внутри зоны и убедиться, что кнопка «Оформить» остаётся активной.
- Проверить адрес заведомо вне зоны и убедиться, что появляется понятное сообщение, а не просто заблокированная кнопка.
- Проверить адрес с опечаткой в названии города, который входит в зону, и посмотреть, срабатывает ли нормализация.
- Проверить сценарий при отключённом интернете или недоступном геокодере: форма не должна пропускать заказ молча в обход проверки.
Совмещаем проверку адреса с оплатой через Т‑Банк и доставкой СДЭК
Порядок действий в корзине важен не меньше самой проверки. Виджет оплаты Т‑Банк показываю только после того, как адрес прошёл проверку зоны, иначе деньги списываются за заказ, который потом всё равно придётся отменять и возвращать. На одном проекте после переноса проверки адреса перед виджетом оплаты количество возвратов по недоступным адресам упало почти до нуля за первый же месяц.
С СДЭК ситуация отдельная: зона обслуживания у них привязана не к городу целиком, а к конкретным пунктам выдачи и к возможности курьерской доставки по индексу. Проверять её через свой список городов бессмысленно, он быстро устареет. Здесь надёжнее обращаться к API СДЭК напрямую и спрашивать доступность доставки по индексу или по выбранному ПВЗ, а собственную проверку зоны использовать как первый быстрый фильтр до того, как пользователь дойдёт до выбора способа доставки.
Частые ошибки при проверке зоны доставки в Тильде
За несколько проектов накопился список того, что ломает такую проверку чаще всего.
- Жёсткое сравнение строк без нормализации: «Москва» и «г. Москва» считаются разными городами, и часть реальных заказов блокируется по ошибке.
- Блокировка кнопки без объяснения причины: пользователь не понимает, что не так с адресом, и просто закрывает вкладку.
- Отсутствие ручного оверрайда для менеджера: даже при жёсткой зоне бывают частные случаи, когда доставку можно согласовать индивидуально, а скрипт такой возможности не оставляет.
- Забытое обновление зоны после расширения географии: список городов остаётся в коде таким же, каким был полгода назад, хотя компания уже возит в новые районы.
- Проверка на каждое нажатие клавиши без задержки: геокодер получает запрос на каждую букву и быстро упирается в лимит бесплатных обращений.
Отдельно завожу уведомление менеджеру в Telegram через простого бота на aiogram или через сценарий в n8n: как только клиент пытается оформить заказ вне зоны и явно готов платить, менеджер получает сообщение с адресом и телефоном и может связаться сам, а не полагаться только на автоматический отказ.
Ограничение доставки по зонам на карте в корзине Tilda
Стандартная Tilda не умеет работать с зонами доставки на карте. Клиент из пригорода или соседнего города оформляет заказ, оплачивает - а потом менеджер тратит…
от 9 000 ₽
Готовый скрипт →Частые вопросы
Можно ли настроить проверку адреса доставки в Тильде без программиста?
Базовый вариант с выбором города из выпадающего списка можно собрать в самом конструкторе форм Тильды. Но проверка произвольно введённого адреса с обращением к геокодеру и сверкой по полигону или списку зон требует JS и настройки API, здесь без готового или кастомного скрипта не обойтись.
Что делать, если компания расширила зону доставки?
Если зоны вынесены в отдельный конфиг, а не зашиты в код, достаточно добавить город или район в список без переписывания скрипта. В готовом решении зоны редактируются через JSON-файл, поэтому расширение географии занимает пару минут.
Как проверить адрес без внешнего геокодера, только по своему списку городов?
Сравнение по названию города работает, но нужно закладывать варианты написания: сокращения вроде «спб», склонения, опечатки. Для устойчивой проверки нормализую строку, нижний регистр, без лишних пробелов и точек, и сравниваю с массивом синонимов на каждый город, а не с одним точным названием.
Проверка адреса замедляет оформление заказа?
Запрос к геокодеру занимает 200-400 миллисекунд, пользователь такую задержку не замечает. Проблема возникает, если проверку запускать на каждое нажатие клавиши без задержки, тогда запросы летят пачками и легко упереться в лимит бесплатных обращений к API за день. Задержка в 500-800 миллисекунд перед отправкой запроса снимает эту проблему полностью.