Проверка домена после запуска сайта

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

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

Зафиксируйте исходные данные

Запишите ожидаемую конфигурацию до проверки:

• основной адрес: с www или без него;
• IPv4 и IPv6 площадки;
• авторитетные NS;
• почтовый провайдер и его MX;
• наличие DNSSEC;
• дата окончания домена и сертификата;
• URL карты сайта и правила robots.txt;
• ответственный за домен и хостинг.

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

Проверьте авторитетный DNS

Начните с NS, указанных у реестра, и убедитесь, что все они отвечают одной актуальной версией зоны. Затем сравните A и AAAA для основного имени и www. Если используется CNAME, его конечная цель должна существовать.

Подробные команды и чтение секций ответа разобраны в статье о dig и nslookup. Для быстрой проверки IPv4 откройте терминал на своём компьютере и выполните следующую команду, заменив домен на свой:

dig example.com A +noall +answer

dig запрашивает A-запись и выводит только секцию ответа. В результате ожидаются имя, фактический TTL, тип A и нужный IPv4. Пустой ответ означает, что A-записи нет в выбранной точке проверки; SERVFAIL часто указывает на проблему делегирования или DNSSEC, а NXDOMAIN — на отсутствие самого имени.

Повторите запрос для AAAA, NS и у нескольких резолверов. Если IPv6 на площадке не настроен, не оставляйте старую AAAA: устройства могут предпочесть её рабочей A-записи. При DNSSEC проверьте валидирующий ответ и отсутствие разрыва между DS и ключами зоны.

Сравните варианты адреса

Откройте четыре варианта: HTTP и HTTPS, с www и без него. Один выбранный адрес должен вернуть страницу, остальные — постоянный редирект непосредственно на него. Цепочка из двух или трёх перенаправлений замедляет запрос и усложняет диагностику.

Проверьте не только главную, но и внутренний URL. Правило редиректа должно сохранять путь: /help/ на альтернативном домене ведёт на /help/ основного, а не на главную.

В HTML каждой индексируемой страницы canonical должен указывать на её основной публичный URL. Внутренние ссылки и карта сайта используют ту же схему и имя. Подробнее выбор адреса разобран в материале про www и канонический домен.

Проверьте HTTPS и сертификат

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

На рабочем компьютере заголовки можно проверить командой ниже. Она не меняет сайт: curl только отправляет запрос и показывает заголовки ответа.

curl -I https://example.com/

Ожидается успешный код 200 на основном адресе либо 301/308 на альтернативном с корректным Location. Ошибка проверки сертификата, цикл редиректов или ответ 5xx требуют исправления до объявления запуска завершённым. Не отключайте проверку TLS параметром -k в итоговом тесте: так можно скрыть именно ту ошибку, которую увидит пользователь.

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

Пройдите пользовательские сценарии

Проверьте на компьютере и телефоне:

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

Откройте инструменты разработчика и найдите запросы 404, смешанный контент HTTP внутри HTTPS и ошибки JavaScript. Изображение, которое видно из кеша автора, может отсутствовать у нового посетителя.

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

Убедитесь, что почта домена не пострадала

Смена A-записи сайта не должна автоматически менять MX. Сравните MX, SPF, DKIM и DMARC с инструкцией почтового провайдера. Отправьте тест в обе стороны на независимый внешний ящик и проверьте заголовки полученного сообщения.

Если письма не приходят, не добавляйте несколько случайных SPF-записей. У имени должна быть одна итоговая политика SPF, а DKIM-селектор обязан совпадать с настройкой отправляющей системы. Основы этих записей собраны в статье о почте домена.

Проверьте адреса для уведомлений регистратора и восстановления доступа. Они должны быть доступны даже при проблеме с основным сайтом.

Проверьте доступ поисковых систем

Откройте robots.txt и убедитесь, что после тестового окружения не осталось общего Disallow: /. На индексируемых страницах не должно быть случайного noindex. Карта сайта содержит только канонические URL, возвращающие успешный ответ.

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

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

Включите наблюдение после запуска

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

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

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

Закройте запуск контрольной записью

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

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

Для поисковой части используйте первичные рекомендации: руководство Google по файлам Sitemap и переездам сайта.