Как проверить сайт после запуска: DNS, HTTPS и ошибки

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

Ниже — последовательность проверки после первого запуска или переноса. Большую часть действий можно выполнить в браузере. Для проверки ответов сервера пригодится curl: в Windows запускайте curl.exe из PowerShell, а в Linux и macOS — curl из терминала.

1. Откройте сайт без входа администратора

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

Не проверяйте запуск только по адресу из файла hosts или через предпросмотр панели. Такое открытие может обходить обычный DNS и правила доступа. После предварительной проверки до смены DNS обязательно нужен отдельный проход по публичному адресу.

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

2. Убедитесь, что домен ведёт на нужный сервер

В PowerShell можно посмотреть адреса домена:

Resolve-DnsName example.com -Type A
Resolve-DnsName example.com -Type AAAA

Замените example.com своим доменом. A относится к IPv4, AAAA — к IPv6. Отсутствие AAAA само по себе не является ошибкой. Но если IPv6-запись есть, она должна вести на обслуживающий сайт сервер. Иначе часть посетителей может попадать на другую площадку.

Сравните ответ с адресами в панели провайдера. Если недавно меняли записи, проверьте также действующие NS и ответ другого DNS-резолвера. Не меняйте NS или почтовые MX только ради устранения ошибки веб-сайта: сначала выясните, какая запись неверна. Порядок настройки разобран в инструкции по привязке домена.

3. Проверьте основной адрес и перенаправления

Выберите, какой адрес будет основным: например, https://example.com/. Затем откройте HTTP-версию и вариант с www. Ожидаемый результат — понятный переход к одному основному адресу с сохранением пути нужной страницы.

Проверка заголовков в Windows:

curl.exe -I http://example.com/
curl.exe -I https://www.example.com/
curl.exe -I https://example.com/

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

Запрос с -I использует метод HEAD. Некоторые приложения обрабатывают его иначе, чем обычное открытие страницы. Если результат непонятен, сделайте GET с выводом заголовков, но без сохранения тела:

curl.exe -sS -D - -o NUL https://example.com/

В Linux и macOS вместо NUL укажите /dev/null. Не считайте, что единственный ответ 200 доказывает исправность: сервер может вернуть 200 вместе с текстом ошибки или заглушкой. Сопоставляйте статус с содержимым страницы.

4. Проверьте HTTPS и ресурсы страницы

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

В инструментах разработчика браузера откройте Network и перезагрузите страницу. Проверьте загрузку CSS, JavaScript, шрифтов, изображений и видео. Красная строка может означать отсутствующий файл, отказ доступа или проблему с другим доменом. Во вкладке Console посмотрите ошибки сценариев и предупреждения о смешанном содержимом.

При смешанном содержимом часть ресурсов продолжает загружаться по HTTP. Исправлять нужно адреса ресурсов или настройки приложения; отключение защиты браузера не решает проблему для посетителей. Есть отдельное руководство по исправлению смешанного контента.

Для сертификата используйте проверку SSL, а для ответа сервера — HTTP-заголовки. Эти инструменты используют общий сохранённый отчёт анализа домена; его можно обновить раз в сутки.

Так выглядела проверка Hostfera после открытия 28 октября 2026 года: главная ответила 200 по HTTPS, HTTP-версия — перенаправлением 301. Это результат проверки доступности; работу форм и внутренних страниц проверяем отдельными шагами.

5. Проверьте внутренние страницы и настоящий 404

Откройте несколько материалов из разных разделов, страницу контактов и результаты поиска. Перейдите по ссылкам внутри текста. Проверьте не только страницу с новым адресом, но и старый URL, если он изменился при переносе.

Затем запросите заведомо несуществующий адрес, например /page-that-does-not-exist-2026/. Ожидаемый результат для обычного сайта — ответ 404 с понятной страницей ошибки. Если вместо него приходит главная с кодом 200, поисковик и посетитель получают неверный сигнал о существовании страницы.

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

6. Пройдите главное действие целиком

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

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

Если приложение размещено в Docker, проверьте публичный HTTPS-адрес, а не только ответ localhost. В уроке установки Docker показано, как связаны контейнер, локальный порт и Nginx.

7. Проверьте готовность к индексации

У открытой статьи не должно оставаться случайного noindex в HTML или заголовке X-Robots-Tag. Проверьте canonical, доступность robots.txt и карту сайта. На закрытых служебных страницах ограничение индексации, наоборот, может быть правильным.

Не удаляйте все запреты автоматически. Панель управления, результаты частного анализа и внутренний поиск отличаются от публичной статьи. Подробная последовательность есть в проверке robots.txt и sitemap.xml.

8. Зафиксируйте результат и проверьте восстановление

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

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

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

Если запускаете WordPress

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