Чек лист проверки сайта в 2026 году

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

Почему проверка должна охватывать не только SEO

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

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

Проверку удобнее проводить по реальным сценариям: пользователь открыл страницу, отправил форму, оплатил заказ, подписался на рассылку или перешел по рекламному материалу. Так видно не только наличие документа, но и соответствие фактической обработки заявленному порядку.

Контур 1 Юридическая корректность

Персональные данные и формы

Имя, телефон, электронная почта и другие сведения, позволяющие связать информацию с человеком, требуют понятной цели обработки и правового основания. С 1 сентября 2025 года согласие на обработку персональных данных должно оформляться отдельно от иных документов, которые подтверждает пользователь. Поэтому фразу о согласии не следует прятать внутрь пользовательского соглашения или объединять с рекламной подпиской.

Что проверить в каждой точке сбора

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

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

Cookie и аналитические идентификаторы

Не всякий файл cookie одинаков по назначению. Составьте перечень используемых технологий, разделите необходимые функции, аналитику, персонализацию и рекламу. Для каждой категории определите правовое основание, срок хранения, получателей и способ информирования пользователя. Баннер не должен обещать выбор, которого интерфейс фактически не предоставляет.

Информация о компании и условиях продажи

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

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

Если сайт только собирает B2B-заявки и не оформляет дистанционную розничную продажу, это должно следовать из интерфейса. Кнопка «Купить», онлайн-оплата и автоматическое подтверждение заказа могут создавать иной пользовательский сценарий, чем форма запроса коммерческого предложения.

Реклама и публичные материалы

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

Зоны повышенного внимания

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

В спорной ситуации материал передают на оценку юристу до публикации. Исправление уже распространенной рекламы не отменяет необходимость хранить сведения о согласованиях и версиях.

Контур 2 Техническая надежность

Доступность сайта и ключевых функций

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

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

Резервные копии

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

Безопасность и защита данных

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

Автоматический сканер находит известные признаки, но не подтверждает безопасность всей системы. Значимые проекты требуют периодической проверки специалистом, а обработка платежных и чувствительных данных — учета дополнительных отраслевых требований.

Поисковая доступность и качество страниц

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

• проверить robots.txt, meta robots и доступность важных разделов;
• убедиться, что XML-карта содержит основные доступные URL без дублей и редиректов;
• найти страницы с ошибочными кодами ответа, цепочки и циклы;
• проверить canonical, языковые и региональные связи, если они используются;
• сопоставить исходный HTML и отрендерованную страницу для JavaScript-интерфейса;
• найти битые внутренние ссылки и изолированные страницы;
• проверить актуальность контактов, цен, наличия, дат и документов;
• не удалять прежние URL без карты перенаправлений;
• оценить мобильное отображение, читаемость и стабильность интерфейса.

Цель этого блока не «закрыть все предупреждения», а убедиться, что пользователь и поисковый робот получают одинаковую актуальную версию ключевой информации.

Контур 3 Организационная управляемость

Доступы подрядчики и владельцы активов

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

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

Регламент обновлений и работа с инцидентами

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

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

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

Финальный этап объединяет три контура. Проведите несколько сценариев от первого посещения до обработки обращения и фиксируйте фактическое поведение.

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

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

Как провести проверку за один рабочий цикл

1. Составить перечень доменов, поддоменов, форм, кабинетов и интеграций.
2. Назначить владельцев юридического, технического и организационного контуров.
3. Собрать действующие документы, договоры с сервисами и список обработчиков данных.
4. Пройти ключевые пользовательские сценарии на компьютере и телефоне.
5. Проверить технические сигналы, безопасность, резервирование и доставку заявок.
6. Разделить находки на подтвержденные нарушения, риски и улучшения.
7. Для каждой задачи указать ответственного, срок, способ проверки и план отката.
8. После исправления повторить исходный сценарий и сохранить результат.

Как определить приоритет

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

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

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

Краткие выводы

Проверка сайта в 2026 году должна соединять право, технику и управление. Отдельный документ не защищает бизнес, если форма собирает другие данные; резервная копия бесполезна без восстановления; исправный сайт теряет обращения, если уведомление не доходит до менеджера.

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