Технический аудит сайта: TLS, редиректы, заголовки, DNS

Технический аудит сайта — проверка фундамента: сертификат, редиректы, robots.txt и sitemap, заголовки безопасности, кеш, DNS, почта и забытые файлы.

Инфраструктура · Опубликовано: 11 октября 2026 г. · 5 мин чтения · Анна Ковалёва

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

Чем он отличается от SEO- и UX-аудита

SEO-аудит спрашивает, понятна ли страница поисковику; UX — удобна ли она человеку. Технический аудит сайта спрашивает, доходит ли до них вообще правильный ответ: по HTTPS, с нужным кодом, без лишних прыжков, с заголовками, закрывающими типовые атаки, и с доменом, который не истечёт через неделю. Большинство пунктов бинарны и проверяются снаружи, без доступа к серверу, — поэтому их легко автоматизировать. Общая методика — от скана до задач и повторной проверки — описана в статье про аудит сайта онлайн, а здесь разберём только технический слой, блок за блоком.

1. HTTPS и сертификат

• Срок действия. Тревога за 30, 14 и 7 дней. Автопродление ломается чаще, чем кажется: сменили DNS, закрыли 80-й порт, забыли перезагрузить nginx. Подробно — в разборе сроков сертификата и домена, а что показывает отчёт — на странице срок TLS-сертификата.
• Версии протокола. TLS 1.0 и 1.1 отозваны; сервер должен принимать TLS 1.2 и 1.3.
• Полная цепочка. Без промежуточного сертификата десктопный Chrome часто справится сам, а Android, curl и вебхуки платёжных систем — нет.

Проверка из консоли:

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -enddate -issuer

2. Адреса и редиректы

У сайта должен быть ровно один основной адрес. http:// отдаёт 301 на https:// (см. редирект на HTTPS), вариант с www или без него — 301 на основной. Каждый лишний шаг — ещё один сетевой круг до первого байта, поэтому считайте редиректы до входной страницы: ноль или один — норма, три — задача в трекер. Проверьте и обратный случай: несуществующий адрес обязан отвечать 404, а не 200 с текстом «страница не найдена».

curl -sI http://example.com/ | head -3
curl -s -o /dev/null -w "%{http_code}" https://example.com/no-such-page-123

3. robots.txt и sitemap.xml

Это технические файлы, хотя от них зависит SEO. Классическая авария — Disallow: /, переехавший со стейджинга на прод вместе с релизом. Убедитесь, что robots.txt не закрывает главную, CSS и JavaScript и указывает путь к карте сайта. Сам sitemap.xml должен быть валидным XML, содержать только канонические адреса с ответом 200 и не тащить за собой URL стейджинга или чужого домена.

4. Заголовки безопасности и утечки

Базовый набор — Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options: nosniff, защита от встраивания во фрейм и Referrer-Policy; зачем нужен каждый и как внедрить CSP, ничего не сломав, мы разбирали в статье про заголовки безопасности. Не менее важно то, чего на сервере быть не должно:

• файлы, оставленные деплоем, — .env, .git/, дампы базы; боты ищут их в первые же часы (открытые файлы);
• листинг каталогов и опубликованные source maps;
• баннеры версий вроде Server: nginx/1.18.0 или X-Powered-By: PHP/7.4;
• метод TRACE, который сервер отражает обратно.

5. Отдача: сжатие, кеш, протокол

HTML и статика должны уходить сжатыми (gzip, а лучше Brotli) по HTTP/2 или HTTP/3. Файлам с хешем в имени — Cache-Control: public, max-age=31536000, immutable, самому HTML — короткий срок или no-cache плюс ETag, чтобы повторный визит стоил ответа 304. Разумный ориентир для сервера — первый байт быстрее 800 мс.

6. DNS, домен и почта

Минимум два NS-сервера, включённая блокировка трансфера, автопродление домена. Для почты — одна SPF-запись в пределах десяти DNS-запросов, DKIM и DMARC: сначала p=none с адресом для отчётов, затем quarantine. CAA, DNSSEC и MTA-STS — необязательно, но полезно.

dig +short TXT example.com
dig +short TXT _dmarc.example.com

Как провести технический аудит с SiteScan

1. Запустите бесплатную проверку с главной: введите домен — через минуту-другую будет отчёт.
2. Откройте блоки «TLS-сертификат», «Регистрация домена», «Адреса и редиректы», «Индексация», «Заголовки безопасности», «DNS и почта». У каждой строки есть кнопка с пояснением, которая ведёт в справочник.
3. Нажмите «Копировать ТЗ»: критичные, высокие и средние находки уйдут в буфер обмена списком задач для разработчика — с адресами и критерием приёмки.
4. После исправлений запустите проверку снова. Блок «Что изменилось с прошлого сканирования» покажет, что исправлено, что появилось и что осталось.
5. Сроки не стоит держать в голове: кнопка «На постоянную проверку» ставит домен на регулярные проверки, а уведомления приходят на почту, в Telegram или по SMS.