Проверка сайта: что смотреть в первую очередь

Быстрая проверка сайта

Быстрая проверка сайта должна сразу показать, открыт ли URL, безопасна ли ссылка, нет ли базовых ошибок DNS, SSL, скорости и индексации. Рабочий результат - не общий балл, а понятная карта действий.

Проверка сайта онлайн должна дать карту состояния: доступность, безопасность, DNS, скорость и SEO. По этой карте вы решаете, что чинить сейчас, а что можно оставить на плановую доработку.

Карта статусов показывает приоритет

Получить проверку сайта проще всего через публичный URL: вставьте адрес, дождитесь отчёта и смотрите не на красивую оценку, а на статусы по группам. Красная зона означает риск для посетителя или поисковой системы: сайт не открывается, сервер отдаёт 5xx, SSL-сертификат сломан, URL помечен как опасный. Жёлтая зона говорит о проблемах, которые мешают качеству работы: медленная загрузка, скачки макета, предупреждения DNS. Синяя зона чаще относится к улучшениям: метатеги, sitemap, индексация, внутренние ссылки.

Доступность проверяют по странице, а не только по сети

Проверить доступность и работоспособность сайта значит убедиться, что важная страница отвечает по HTTP/HTTPS и не уходит в таймаут. Ping помогает как быстрый сетевой сигнал, но рабочий вывод делайте по странице: код 200, корректный редирект или ошибка 5xx дают разные задачи для администратора.

Домен и DNS задают базовые сведения

Проверить домен, DNS и базовые сведения о сайте значит посмотреть, куда указывает домен, совпадает ли он с ожидаемым ресурсом, есть ли рабочий SSL и что видно по регистрации или истории домена. DNS-записи объясняют технический маршрут, SSL показывает защищённость соединения, а WHOIS и веб-архив дают контекст без права выносить окончательный verdict.

Скорость смотрят отдельными метриками

Проверить скорость сайта нужно отдельно от факта доступности. Страница может открываться, но долго показывать первый контент, прыгать при загрузке или тормозить после клика; поэтому в отчёте ищите FCP, CLS и INP, а не только общий балл.

SEO-сигналы показывают, видит ли страницу поиск

Проверить SEO-показатели сайта можно по публичным признакам: robots.txt, sitemap.xml, canonical, title, description, H1, ответы 4xx и 5xx, редиректы и индексируемость URL. Для точной видимости в поиске понадобятся Google Search Console, Яндекс.Вебмастер и Яндекс.Метрика.

Безопасность ссылки требует нескольких проверок

Проверить сайт или ссылку на вирусы, фишинг и мошенничество значит совместить HTTPS, репутацию URL и ручный осмотр домена. Зелёный замок не доказывает подлинность страницы: фишинговый сайт тоже может получить сертификат.

Инструмент выбирают по задаче

Выбрать подходящий инструмент проще по задаче: для доступности нужны HTTP, Ping и DNS; для угроз - VirusTotal и Safe Browsing; для скорости - PageSpeed Insights или Lighthouse; для SEO - внешний аудит плюс кабинеты поисковых систем. Универсальный отчёт удобен как старт, но один инструмент не заменяет все источники данных.

Проверьте результат по шагам:

1. Откройте главную страницу и одну важную внутреннюю страницу.
2. Сравните HTTP-ответы для HTTP и HTTPS-версий.
3. Посмотрите, совпадает ли домен в сертификате с проверяемым адресом.
4. Проверьте скорость отдельно для мобильной и десктопной версии.
5. Отметьте SEO-предупреждения, которые мешают индексации.

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

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

PageSpeed Insights показывает полевые данные реальных пользователей и лабораторные данные Lighthouse; Core Web Vitals оцениваются на уровне страницы или origin, а проходной статус требует хороших значений всех трёх ключевых метрик на 75-м перцентиле.

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

Если ручная проверка прошла удачно, но жалобы пользователей повторяются, ищите сбои между проверками. Короткий отказ на 3-5 минут может исчезнуть до того, как вы откроете сервис диагностики, но посетители уже увидят ошибку.

Состав комплексного анализа

Комплексный анализ сначала разделяет инфраструктурные слои, а уже потом SEO-симптомы. Такой порядок помогает найти точку отказа: сеть, серверный ответ, DNS, домен или публичные технические файлы.

Комплексный аудит сайта раскладывает проблему на слои: сеть, серверный ответ, DNS, домен и публичные технические файлы. Такой порядок помогает не лечить SEO-симптом, пока причина лежит в инфраструктуре.

Ping показывает сетевой отклик

Сначала проверьте доступность. Ping показывает, отвечает ли узел на сетевой запрос, и сколько времени занимает путь туда и обратно. Это полезный быстрый тест, но он не доказывает, что веб-страница работает: ICMP могут блокировать firewall или провайдерские фильтры, а сам сайт при этом отдаёт нормальный HTTP-ответ.

Разделите диагностику на три слоя:

1. Проверьте Ping: есть ли отклик, нет ли потерь пакетов, насколько стабилен RTT.
2. Проверьте HTTP или HTTPS: какой код ответа возвращает конкретная страница.
3. Проверьте DNS: куда указывает домен и какие записи управляют сайтом, почтой и подтверждениями.

Ping оценивает доступность узла через ICMP Echo и считает RTT: время туда-обратно между отправкой запроса и получением ответа. Потери пакетов рассчитываются как (отправлено - получено) / отправлено × 100%.

HTTP/HTTPS-ответ уточняет состояние страницы

HTTP-ответ показывает состояние веб-приложения точнее, чем один сетевой отклик. Класс 2xx говорит об успешном ответе, 3xx - о перенаправлении, 4xx - о проблеме запроса или доступа, 5xx - о серверной ошибке. Для владельца сайта важен не только факт «работает ли сайт», но и конкретный код: 404 на карточке товара, 301 в длинной цепочке редиректов и 500 на форме заявки требуют разных действий.

DNS-записи объясняют, куда ведёт домен

DNS проверяйте до SEO-выводов. A и AAAA связывают домен с IP-адресами, CNAME задаёт алиас, MX отвечает за почту, TXT хранит подтверждения и политики, NS указывает авторитетные DNS-серверы, TTL задаёт время кэширования записи. Ошибка в DNS может выглядеть как проблема хостинга, хотя сервер исправен.

В нашей практике инфраструктурной проверки мы отдельно смотрим TTL, потому что DNS TTL определяет, как долго DNS-запись кэшируется: длинный TTL ускоряет повторный DNS-запрос за счёт кэша, но замедляет распространение изменений записей до конечных пользователей. Это важно перед переездом сайта, сменой IP или подключением CDN: старые записи могут жить у пользователей дольше, чем ожидает команда.

Характерная ошибка в проверке сайта - начинать с общего SEO-балла, когда базовые слои ещё не разобраны. Если TTL высокий, старые DNS-записи могут держаться у пользователей после смены IP или CDN, и команда будет чинить уже исправный сервер. Проверьте домен, DNS, HTTP/HTTPS и сертификат; после этого переходите к скорости и SEO.

Доменная история даёт контекст, но не verdict

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

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

Безопасность и доверие

Проверка безопасности сайта начинается с HTTPS, репутации URL, домена и фишинговых признаков. Сертификат защищает соединение, но доверие к ссылке проверяют шире.

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

Проверяйте ссылку так:

1. Откройте сертификат и убедитесь, что домен совпадает с адресом в строке браузера.
2. Проверьте URL через репутационный сервис, например VirusTotal.
3. Сверьте домен с ожидаемым брендом: лишние дефисы, похожие буквы и странные зоны требуют внимания.
4. Посмотрите, нет ли предупреждений Google Safe Browsing.
5. Не вводите пароль и данные карты, пока не пройдены первые четыре проверки.

Google объявил HTTPS лёгким поисковым сигналом в августе 2014 года; в рекомендациях также указаны 2048-битные ключи и корректная настройка HTTPS для всего сайта.

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

Google Safe Browsing помогает понять, видит ли Google конкретный сайт как опасный. Если сайт попал в предупреждения браузеров или поиска, проблема уже влияет не только на безопасность посетителей, но и на переходы из выдачи. В русскоязычном сегменте проверка ссылок на фишинг стала регулярной задачей: в 2025 году антифишинговая система Kaspersky предотвратила 554 002 207 попыток перехода по фишинговым ссылкам, а 43,27% писем в российском веб-сегменте были спамом.

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

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

Скорость и пользовательский опыт

Скорость сайта оценивают по загрузке, стабильности и реакции интерфейса. FCP, CLS и INP показывают разные проблемы, поэтому исправления тоже будут разными.

FCP - First Contentful Paint, время до первого видимого содержимого страницы. Если пользователь долго видит пустой экран, проблема часто связана с серверным ответом, блокирующими ресурсами, тяжёлыми стилями или скриптами. Хороший ориентир для FCP - 1,8 секунды или меньше на 75-м перцентиле загрузок, отдельно для мобильных и десктопных пользователей.

Для FCP хорошим считается значение 1,8 секунды или меньше на 75-м перцентиле загрузок, отдельно для мобильных и десктопных пользователей.

CLS - Cumulative Layout Shift, показатель неожиданных смещений макета. Он растёт, когда изображения загружаются без заданных размеров, баннеры появляются поздно, рекламные блоки двигают контент или шрифты меняют высоту текста после отрисовки. Пользователь нажимает на кнопку, но страница сдвигается, и действие попадает не туда.

INP - Interaction to Next Paint, метрика отзывчивости интерфейса после действия пользователя. В марте 2024 года INP заменил FID в составе Core Web Vitals; после замены отчёты Search Console перестали показывать FID и перешли на INP как метрику отзывчивости. Если старый сервис проверки скорости всё ещё делает акцент на FID, его отчёт хуже соответствует текущей методологии Google.

Разберите проблему скорости по причине:

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

Наш аналитический разбор скорости показывает жёсткую развилку: PageSpeed Insights проходит Core Web Vitals только при хороших INP, LCP и CLS на 75-м перцентиле, а по исследованию PageSpeedMatters на данных CrUX за май 2026 года все три Core Web Vitals проходили 49,1% мобильных origin и 58,0% десктопных origin. Значит, проверка скорости нужна не только после редизайна; около половины мобильного веба не дотягивает до полного прохождения этих сигналов.

Сначала чините метрику, которая совпадает с жалобой пользователя. Пустой экран ведёт к FCP и LCP, скачки интерфейса - к CLS, задержка после клика - к INP.

SEO-показатели и аналитика

Внешняя проверка видит публичные SEO-сигналы, а кабинеты аналитики добавляют фактическое поведение пользователей. Без доступа к Метрике, Вебмастеру и Search Console отчёт остаётся первичным техническим снимком.

SEO-анализ сайта соединяет публичные технические сигналы и данные из кабинетов аналитики. Без доступа к Яндекс.Метрике, Яндекс.Вебмастеру и Google Search Console внешняя проверка видит только часть картины.

Минимальный SEO-чек начинается с индексируемости URL. Проверьте robots.txt, sitemap.xml, canonical, title, description, H1, ответы 4xx и 5xx, редиректы, внутренние ссылки, внешние ссылки, органические показы и CTR. CTR в поисковой аналитике считается как клики / показы × 100%; клики - переходы из выдачи, показы - появления страницы в результатах поиска за выбранный период, результат измеряется в процентах.

CTR в поисковой аналитике считается как клики / показы × 100%; в Google Search Console рядом с ним смотрят клики, показы и среднюю позицию.

Яндекс.Метрика помогает проверить не только посещаемость сайта, но и качество визитов. Отказ в Метрике считается по своим правилам: не больше одного просмотра страницы, длительность меньше заданного времени для расчёта отказов и отсутствие события «неотказ»; по умолчанию порог времени - 15 секунд. Поэтому сравнивать отказ из разных систем без понимания методики нельзя.

Внешняя проверка может показать, что страница открыта для индексации, title заполнен, sitemap доступен, а canonical не конфликтует с URL. Кабинеты покажут другой слой: какие запросы дают показы, где падает CTR, какие страницы Google или Яндекс уже обошли, какие цели срабатывают и на каком шаге пользователь уходит. Если вы проверяете чужой сайт или новый лендинг без трафика, внешнего аудита достаточно для первичного технического списка; если нужно понять почему просели заявки, нужен доступ к Метрике, Вебмастеру или Search Console.

Соберите SEO-картину из четырёх источников:

• внешний аудит сайта - технические ошибки, метатеги, robots, sitemap, скорость и доступность;
• Яндекс.Метрика - визиты, отказы, источники, цели и поведение пользователей;
• Яндекс.Вебмастер - индексирование, ИКС, проблемы обхода и качество сайта в контуре Яндекса;
• Google Search Console - клики, показы, средняя позиция, страницы, запросы и выборка ссылок.

ИКС в Яндекс.Вебмастере полезен как внешний контекстный сигнал качества, но его нельзя превращать в единственную оценку SEO. Высокий или низкий показатель не объяснит сам по себе, закрыта ли страница от индексации, есть ли ошибки canonical, насколько корректны метатеги и как ведёт себя органический трафик.

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

Мониторинг доступности

Мониторинг доступности сайта нужен, когда важна история сбоев, а не только состояние в момент ручной проверки. Он проверяет сайт по расписанию и отправляет уведомления, если HTTP, Ping, SSL или другой контрольный сигнал ломается.

Разовая проверка отвечает на вопрос «что происходит сейчас». Мониторинг отвечает на другой вопрос: «что происходило ночью, в выходные, во время рекламной кампании или после выката». Если сайт недоступен пять минут между двумя ручными проверками, отчёт утром будет зелёным, а пользователи уже увидят ошибку.

Выбирайте мониторинг по критичности сайта:

1. Для визитки и блога начните с HTTP/HTTPS-проверки главной страницы и уведомления на почту.
2. Для интернет-магазина добавьте проверки корзины, оплаты, SSL и ключевых категорий.
3. Для SaaS или личного кабинета контролируйте страницу входа, API-ответы, SSL и домен.
4. Для проекта с рекламным трафиком включите частые проверки перед стартом кампании и во время пиков.

UptimeRobot заявляет бесплатный лимит 50 monitors; сервис поддерживает HTTP(s), SSL, port, ping и keyword monitoring, а уведомления доступны через email, SMS, Slack и другие каналы.

На рынке есть разные модели. UptimeRobot удобен для базового массового мониторинга. Monitorus показывает оплату за количество проверок: пример расчёта для одного сайта каждые 30 минут без SMS - 14,4 рубля в месяц по формуле 2 проверки в час × 24 часа × 30 дней × 0,01 рубля. Statuser.cloud даёт Free до 5 серверов, Pro за 290 ₽/мес с частотой проверки от 1 минуты, 5 регионами, мониторингом SSL и домена; Team - 1 690 ₽/мес и до 100 серверов в базовом отображении тарифа. Monitor-Site.com заявляет комплексную проверку сайта каждую минуту и 15 дней бесплатного тестового периода.

В наших инфраструктурных разборах мы видим, что интервал проверки меняет смысл мониторинга. UptimeRobot указывает такие интервалы мониторинга: Free Plan - каждые 5 минут, Solo и Team - каждую 1 минуту, Scale - каждые 30 секунд. Для небольшого сайта пяти минут достаточно, а для платёжной страницы или сервиса входа минута простоя уже может стать заметной потерей заявок.

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

Выбор инструмента и действия после отчёта

Инструмент проверки сайта выбирают по задаче, а исправления начинают с красных ошибок. Сначала убирайте то, что мешает открыть сайт и доверять ему, затем переходите к скорости, SEO и аналитике.

Приоритет исправлений после проверки

Главная ошибка после анализа - чинить всё подряд. Приоритет должен идти от отказа к улучшению: сначала доступность, 5xx, SSL и DNS; затем угрозы и репутация URL; затем критичные Core Web Vitals на мобильных; затем индексирование и SEO-метаданные; после этого аналитика и контентные улучшения.

Дерево выбора инструмента

Выбирайте сервис по задаче:

1. Нужно понять, работает ли сайт сейчас - используйте HTTP-проверку, Ping и DNS-диагностику.
2. Нужно проверить ссылку на вирусы или фишинг - используйте VirusTotal, Google Safe Browsing и ручную проверку домена.
3. Нужно проверить скорость загрузки сайта - используйте PageSpeed Insights, Lighthouse, WebPageTest или GTmetrix.
4. Нужно оценить SEO - соедините внешний аудит, Яндекс.Вебмастер, Яндекс.Метрику и Google Search Console.
5. Нужно не пропускать сбои - подключите UptimeRobot, Monitorus, Monitor-site или Statuser.cloud.

VirusTotal не измеряет скорость, PageSpeed Insights не проверяет фишинговую репутацию, Яндекс.Метрика не видит чужой сайт без доступа к счётчику, а Ping не гарантирует работоспособность веб-приложения. Поэтому хороший рабочий набор состоит из нескольких проверок, а не из одного универсального отчёта.

Типы проверки дают разную глубину данных

Что онлайн-проверка не покажет без доступа

Если сайт новый или у вас нет доступа к аналитике, внешняя проверка оценит только публичные сигналы: HTTP, DNS, SSL, скорость, robots, sitemap, метатеги, репутацию URL и часть индексации. Поведение пользователей, конверсии и точные источники трафика появятся только после подключения счётчиков и кабинетов.

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

Готовность отчёта к работе

Проверьте готовность отчёта к работе:

• У каждой критичной ошибки есть страница, код ответа или конкретный проверяемый параметр.
• SSL, DNS и HTTP вынесены выше косметических SEO-рекомендаций.
• Метрики скорости разделены на FCP, LCP, INP и CLS, а не сведены к одному баллу.
• SEO-блок показывает индексируемость, robots, sitemap, title, description и canonical.
• Для повторяющихся сбоев указан мониторинг, а не только ручная перепроверка.

Наш практический вывод такой: чем ближе проверка к деньгам, заявкам и входу пользователей, тем выше должен быть приоритет исправления. Ошибка 5xx на форме заявки важнее длинного description; истёкший SSL важнее отсутствующего favicon; высокий INP на мобильной странице оплаты важнее мелкой рекомендации по разметке.

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