Как подключить домен к Тильде и другим конструкторам: A-записи, SSL и типичные ошибки

Коротко. Подключение домена к конструктору — это две отдельные операции: у регистратора вы направляете домен A-записью на адрес платформы, а в панели проекта указываете этот домен, чтобы платформа знала, какой сайт по нему отдавать. Пока не сделаны оба шага, будет либо «сайт не найден», либо чужая заглушка. Сертификат платформа выпускает сама, но только после того, как записи разъехались по резолверам.

Что происходит, когда вы «подключаете домен»

Домен сам по себе никуда не ведёт. Он лишь имя, у которого есть набор DNS-записей, и одна из них — A — говорит браузеру, на какой IP-адрес идти за содержимым. Конструктор сайтов держит ваш сайт на своих серверах, поэтому подключение сводится к тому, чтобы имя указывало на эти серверы.

Второй шаг не менее важен и его чаще всего забывают. На одном IP-адресе платформы живут десятки тысяч сайтов. Сервер различает их по имени, которое браузер присылает в запросе. Если вы направили домен на платформу, но не привязали его к своему проекту в панели, сервер получит незнакомое имя и ответит заглушкой или ошибкой — технически всё верно, просто он не знает, чей это домен.

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

Два сценария: домен у регистратора или внутри конструктора

От того, где куплен домен, зависит, где вы будете править записи.

• Домен куплен у регистратора (обычный случай). DNS-записями управляете вы — в панели регистратора или у того DNS-хостинга, чьи NS-серверы прописаны у домена. Это даёт полный контроль: можно оставить почту на прежнем сервере, добавить проверочные TXT-записи, поднять поддомены.
• Домен куплен внутри конструктора. Тогда платформа обычно и регистратор, и DNS-хостинг: подключение делается в один клик, но управление записями ограничено интерфейсом платформы. Если позже понадобится нестандартная запись — почта, верификация, поддомен на стороннем сервере — упрётесь в возможности этого интерфейса.

Прежде чем что-то менять, полезно посмотреть, куда домен смотрит сейчас и чьи у него NS-серверы: это сразу показывает, в какой панели вы будете работать. Быстрее всего — через проверку WHOIS и просмотр DNS-записей. Разница между «сменить NS» и «поменять A-запись» разобрана в материале про привязку домена к хостингу.

Пошагово: какие записи нужны

Минимальный набор для сайта на конструкторе — две записи: корень домена и www.

1. Снизьте TTL заранее. За несколько часов до переезда поставьте у изменяемых записей TTL 300–600 секунд. Тогда резолверы обновят их быстро, а не через сутки. После успешного переезда TTL можно вернуть обратно; зачем это нужно, разобрано в материале про TTL DNS-записей.
2. Корень домена (@) — A-запись на IP-адрес платформы, взятый из панели проекта. Некоторые DNS-хостинги умеют ALIAS или ANAME и позволяют вместо IP указать имя платформы — так надёжнее, потому что при смене адреса ничего править не придётся.
3. Поддомен www — обычно CNAME на имя, которое даёт платформа. Разницу между CNAME и A разбирает материал про CNAME и A-записи: в корне домена CNAME по стандарту невозможен, поэтому там либо A, либо фирменные ALIAS/ANAME.
4. Удалите конфликтующие записи. Старая A-запись прежнего хостинга, вторая A-запись «на всякий случай», забытая AAAA-запись на IPv6-адрес старого сервера — всё это заставит часть посетителей уходить на старый сайт. Особенно коварна AAAA: у пользователя с IPv6 браузер предпочтёт её, и человек увидит старую версию сайта, пока вы будете уверять, что переезд состоялся.
5. Укажите домен в панели проекта и дождитесь, пока платформа подтвердит, что видит правильные записи.

# Что смотреть до и после правки записей
dig example.com A +short
dig www.example.com CNAME +short
dig example.com AAAA +short        # должно быть пусто, если IPv6 у платформы нет
dig example.com NS +short          # чей DNS-хостинг — там и правим записи

# Проверить, что сервер платформы отвечает именно за ваш домен
curl -sI https://example.com | head -n 5

Почему не выпускается SSL-сертификат

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

Частые причины, по которым выпуск не происходит вообще:

• Записи ещё не распространились или разъехались частично. Проверять надо не своим браузером, а из нескольких точек — проверкой распространения DNS; почему это занимает часы, объясняет материал про распространение DNS.
• Осталась CAA-запись прежнего провайдера. Она перечисляет удостоверяющие центры, которым разрешено выпускать сертификаты для домена. Если центр платформы в этот список не входит, выпуск блокируется молча и намертво. Разбор — в материале про CAA-записи.
• Домен проксируется через промежуточный сервис с включённым проксированием. Тогда до платформы запрос доходит не напрямую, проверка владения не проходит, а посетитель видит ошибку сертификата, даже если сайт открывается.
• Подключён только корень, а www забыт (или наоборот). Сертификат выпустится на одно имя, а на втором браузер покажет «подключение не защищено».

Что именно отдаёт сервер — какой сертификат, на какие имена и от какого центра — показывает проверка SSL; как читать её вывод, разобрано в материале про проверку сертификата.

Что будет с почтой на этом домене

Смена A-записи почту не трогает, смена NS-серверов — уносит её целиком. Исходящие письма при этом продолжают отправляться, поэтому пропажу входящих замечают через день-два, когда клиент спрашивает, почему ему не отвечают. Выписывайте всю зону до переезда, а не по памяти.

Это тот случай, когда цена ошибки высокая, а ошибка неочевидна.

• Вы меняете только A-запись и CNAME — почта не пострадает. MX-записи остаются на месте, письма ходят как раньше.
• Вы меняете NS-серверы (переводите домен на DNS-хостинг платформы) — вся зона переезжает целиком. Если в новой зоне не создать MX, SPF, DKIM и DMARC заново, почта перестанет приходить, и заметите вы это не сразу, потому что исходящие письма продолжат отправляться.

# Выписать текущую зону ДО смены NS
for t in A AAAA CNAME MX TXT NS CAA SRV; do
  echo "== $t"; dig example.com $t +short
done

# Почтовые записи лежат на служебных именах — их забывают чаще всего
dig _dmarc.example.com TXT +short
dig selector._domainkey.example.com TXT +short   # селектор смотрите в почтовой панели

Поэтому перед сменой NS выпишите все текущие записи домена, а не только те, о которых помните. Как правильно переносить почтовые записи, разобрано в материалах про настройку MX и почту на своём домене, а порядок смены NS — в материале про смену DNS-сервера. Убедиться, что почтовые записи на месте, можно проверкой MX и проверкой почтовых настроек домена.

Типичные ошибки и что они означают

Что видит посетитель	Причина	Что делать
Страница платформы «сайт не найден»	Записи ведут на платформу, но домен не привязан к проекту в панели	Добавить домен в настройках проекта и дождаться подтверждения
Открывается старый сайт	Осталась прежняя A- или AAAA-запись, либо кэш резолвера	Удалить лишние записи, проверить dig … AAAA, дождаться TTL
ERR_NAME_NOT_RESOLVED	Записи нет вовсе или домен не делегирован на тот DNS, где вы правите	Сверить NS-серверы домена с панелью, где вносите записи; разбор — в материале про эту ошибку
«Подключение не защищено»	Сертификат ещё не выпущен, выпущен не на все имена или мешает CAA	Проверить имена в сертификате и CAA-запись
www открывается, корень — нет (или наоборот)	Настроено только одно из двух имён	Добавить недостающую запись и убедиться, что сертификат покрывает оба имени
Бесконечный редирект	Редирект настроен и на стороне платформы, и на стороне промежуточного сервиса	Оставить перенаправление только в одном месте; цепочку покажет проверка редиректов
Сайт открывается у вас, но не у клиента	У вас записи уже обновились, у него — ещё нет	Проверить из нескольких точек, дождаться истечения прежнего TTL

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

Сколько ждать и что считать готовым

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

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

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

Как проверить результат

• Проверка DNS-записей — что реально отдаёт зона: A, AAAA, CNAME, MX, CAA.
• Проверка распространения — обновились ли записи в разных резолверах, а не только у вас.
• Проверка SSL — на какие имена выпущен сертификат и когда истекает.
• Проверка редиректов — сколько переходов между www и корнем, нет ли цикла.
• Проверка заголовков — какой сервер отвечает и не осталась ли отдача со старого хостинга.
• Мониторинг доступности — чтобы падение домена или истёкший сертификат не обнаружились со слов клиента.

Частые вопросы

Обязательно ли переводить домен на NS-серверы конструктора?

Нет, и часто не нужно. Достаточно A-записи и CNAME в текущей зоне. Перевод NS оправдан, только если вам удобнее управлять всеми записями в одной панели, и вы готовы перенести туда почтовые и проверочные записи.

Можно ли подключить к конструктору поддомен вместо основного домена?

Да, и это самый безопасный способ попробовать: поддомен подключается CNAME-записью, а основной сайт и почта не затрагиваются вообще. Что выбрать под лендинг — поддомен или каталог — разобрано в материале про поддомены и подкаталоги.

Домен подключён, но сайт открывается без замка. Что делать?

Подождать: автоматический выпуск сертификата занимает от минут до нескольких часов после того, как записи разъехались. Если за сутки ничего не изменилось — проверять CAA-запись, наличие проксирования и то, что оба имени (корень и www) подключены.

Почему сайт открывается со старым содержимым?

Почти всегда это кэш: либо резолвер ещё отдаёт прежний IP, либо браузер держит страницу. Проверьте фактический адрес через dig и откройте сайт в приватном окне. Если адрес уже новый, а содержимое старое — дело в кэше платформы или CDN, а не в DNS.

Что будет с прежним хостингом после переезда?

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

Нужно ли что-то делать с поисковыми системами после переезда?

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

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

• TTL изменяемых записей снижен заранее.
• Актуальные значения A и CNAME взяты из панели проекта, а не из чужой инструкции.
• Настроены оба имени: корень домена и www.
• Старые A- и AAAA-записи прежнего хостинга удалены.
• Домен добавлен в настройках проекта, платформа подтвердила подключение.
• Проверено распространение записей из нескольких точек, а не только в своём браузере.
• Сертификат выпущен и покрывает и корень, и www.
• Между www и корнем один переход, без цикла.
• Почтовые записи проверены, если на домене есть почта — особенно после смены NS.
• Настроен мониторинг доступности и срока действия сертификата.