Коммерческое предложение: полный аудит сайта и работы бизнеса

Полный аудит сайта и работы бизнеса

Сценарий проверки: сайт, обмены данными, касса, почта, кэш, роли сотрудников, мониторинг, восстановление из копии и то, где бизнес теряет деньги, а где их сохраняет. Для B2B отдельно: работа с дилерами, окупаемость рекламы (ROMI), переезд каталога и рутина продаж.

Документ: Состав работ и результат. Этот сценарий можно приложить к договору как описание аудита.
Стоимость: Считается отдельно Заказать как услугу: полный аудит сайта и работы бизнеса (ориентир от 149 000 ₽ за стандарт)., когда согласованы границы аудита, известны размер сайта и список доступов. В этот документ не включена.
Срок: Называется после того, как известны число страниц сайта и открытые доступы.

Написать письмо +7 499 938 8452

Как с нами связаться

Сайтhttps://www.acrit-studio.ru
Телефон+7 499 938 8452, пн–пт 10:00–17:00
Почтаdesign@acrit.ru
Telegram@AcritSupport
WhatsApp+7 927 05 25 930
Viber+7 927 05 25 930
YouTube@acrit-studio
ВКонтактеacrit_studio
ЮрлицоООО «Агентство Креативных Разработок Инновационных Технологий»

Что это за документ

Веб-студия АКРИТ предлагает полный аудит сайта и того, как вокруг него работает бизнес: продажи, обмены данными, учёт, реклама и рабочий день менеджера.

Документ тестирует публичную часть сайта, поиск, скорость, ошибки в коде и в консоли браузера (панели разработчика, где видны ошибки скриптов), безопасность, Битрикс, продажи и аналитику. Отдельно проверяем повседневные операции вокруг сайта: обмен с маркетплейсами и 1С, путь оплаты от кассы до поступления денег, доставку писем до почтового ящика получателя, обновление кэша после правок, роли сотрудников, нагрузку, мониторинг, тестовое восстановление, повторную проверку сайта после выкладки обновлений, читаемость текстов, спрос в B2B и окупаемость рекламы.

Что будет результатом работы

Короткий вывод для руководителя: жизнеспособна ли модель бизнеса, насколько хорошо она реализована и что исправлять в первую очередь.
Полный реестр находок. Для каждой находки указаны место, что обнаружено, какой должна быть норма, уровень важности и как её перепроверить.
Приложения: результаты обхода сайта, замеры скорости, SSL (шифрование сайта) и заголовки ответа сервера, журнал консоли браузера, журнал ошибок кода, паспорт сервера (система, версии программ, где лежат сайт и база), заключение по вирусам, реестр мусора с размерами.
Разбор по видеосвязи в рабочие часы студии, пн–пт 10:00–17:00.

Уровни находок

Блокер Поломка, из-за которой уже страдают сайт, заказы или поиск: сайт или оформление заказа недоступны, есть следы взлома, сайт целиком закрыт от индексации, оплата считает другую сумму, из интернета можно открыть дамп (файл с копией базы или файлов сайта, то есть утечка) или админку, через которую сотрудники управляют сайтом.
Существенно Массовые дубли, когда одна и та же страница открывается по разным адресам; плохая скорость у реальных посетителей, когда страница долго появляется, медленно отвечает на нажатие или блоки прыгают при загрузке; заявки из форм не доходят; нет согласия на обработку персональных данных; сайт открывается по нескольким вариантам адреса как отдельные копии (разъезд зеркал); диск или резервные копии близки к отказу.
Улучшение Ошибки в отдельных заголовках, недостаточный контраст текста с фоном в отдельных местах, мелкие замечания валидатора разметки, частные предупреждения, которые не влияют на заказы и индексацию.

Как проходит работа

Согласуем границы аудита, глубину проверки и доступы. Глубина бывает трёх видов: быстрая проверка за день (smoke), стандартная за неделю и глубокая (deep). Если нужны нагрузочный тест, перезапуск служб или пробное восстановление, письменно согласуем время для этих работ.
Проверяем сайт снаружи, как его видят посетители и поисковики: домен, https, зеркала сайта, поиск, типы страниц, доступность, базовую и углублённую скорость, ошибки в консоли браузера.
Когда доступы открыты, проверяем код, журналы, сервер, отказоустойчивость, вирусы, безопасность, мусорные файлы и встроенные проверки движка сайта.
Заполняем лист оценки модели бизнеса, собираем отчёт и приложения, проводим разбор с заказчиком.

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

Что нужно от заказчика

Основной адрес сайта и, если известны, зеркала: другие варианты адреса, по которым открывается тот же сайт.
Доступы: Яндекс Вебмастер, Google Search Console, Яндекс Метрика, Google Analytics (если есть), админка сайта, SSH-доступ к серверу или панель хостинга.
Разрешение на тестовую заявку, а для магазина — и на тестовый заказ.
Согласованное время для нагрузочного теста и перезапуска служб, если их нужно проводить на рабочем сервере, которым пользуются клиенты.
Человек, который принимает отчёт.

Если доступа к серверу нет, этапы проверки кода, сервера, вирусов изнутри и мусорных файлов помечаем как невыполненные. Статус «чисто» они в отчёте не получают.

Состав сценария

Все этапы ниже устроены одинаково: зачем этап нужен, что мы делаем, какой результат получает заказчик, затем таблица проверок. Этап 1 — выбор глубины аудита: его проходим вместе с заказчиком до начала работ и фиксируем в договоре. Этапы 2–34 посвящены сайту, поиску, скорости, безопасности, продажам и модели бизнеса. Этапы 35–52 — обменам данными, оплате, почте, кэшу, ролям сотрудников, нагрузке, мониторингу, восстановлению из копии, виджетам, проверке после выкладки обновлений, внутреннему поиску, читаемости текстов, B2B и окупаемости рекламы. Этап 53 — сборка отчёта.

Этап	Результат этапа
1. Глубина аудита: быстрая, стандартная или глубокая	Выбранная глубина аудита, список доступов заказчика и отметка у каждой проверки, какой доступ для неё нужен.
2. Подготовка и границы аудита	Согласованные границы аудита: основной адрес, тип сайта, сценарии, выборка страниц, доступы и разрешённые действия.
3. Домен и DNS	Срок и владелец домена, схема DNS, список действующих поддоменов и состояние почтовых записей SPF, DKIM и DMARC.
4. Шифрование соединения (TLS) и переход на https	Оценка сертификата и шифрования, проверка перехода с http на https и заголовка HSTS, список страниц со смешанным контентом.
5. Доступность сайта и коды ответа сервера	Коды и время ответа ключевых страниц, фон серверных ошибок, история простоев и проверка ответа сайта из другой сети.
6. Зеркала сайта и перенаправления	Таблица зеркал и цепочек перенаправлений, проверка главного зеркала в Яндексе и Google, список внутренних ссылок на редиректы.
7. Заголовки ответа сервера, cookie и утечки служебных данных	Оценка защитных заголовков и cookie, проверка служебных адресов и раскрытия версий, статус сайта в чёрных списках и список сторонних скриптов.
8. Файл robots.txt и закрытие служебных разделов	Текст robots.txt, список закрытых служебных разделов и ошибочно закрытых страниц, сверка правил с Вебмастером и Search Console.
9. Карта сайта	Проверка карты сайта в кабинетах поисковиков, доля мусорных адресов в ней, типы страниц, выпавшие из карты, и состояние дат изменения.
10. Индексация по данным Вебмастера и Search Console	Объём индекса и причины исключения страниц в Яндексе и Google, ручные меры, дубли с параметрами, постраничная навигация, регион, языки и ИКС.
11. Полный обход всех страниц сайта специальной программой	Список массовых ошибок по всем страницам сайта: коды ответа, битые ссылки, дубли, canonical, пустые страницы, изображения и адреса.
12. Основные типы страниц глазами посетителя	Замечания по главной, каталогу, карточке, контактам, поиску, странице 404, меню и общим блокам глазами посетителя.
13. Тексты и коммерческие факторы: цены, контакты, доверие	Оценка уникальности и качества текстов, опечаток, актуальности цен и контактов, страниц доверия, фото и видео.
14. Микроразметка и превью ссылок	По каждому типу страницы: есть ли микроразметка, совпадает ли она с экраном, какие ошибки повторяются на каталоге и как выглядит превью ссылки.
15. Скорость загрузки и стабильность вёрстки: базовые цифры	Показатели скорости у реальных посетителей и по тестовым замерам главных типов страниц, самые тяжёлые файлы, мешающие виджеты и проблемы с кэшем.
16. Производительность сайта: подробный разбор причин	Таблица скорости по типам страниц, водопад худших страниц, причины задержек по слоям от вёрстки до базы и сервера, план повторных замеров после правок.
17. Мобильная версия	Ширины экрана, на которых проходит сценарий заявки и покупки, скриншоты поломок и список блоков, которые мешают на телефоне.
18. Доступность для людей с ограничениями	Ошибки доступности по типам страниц, результат прохода сценария заявки с клавиатуры, проверка языка страницы и субтитров к роликам.
19. Рабочие сценарии: заявка, каталог, корзина, заказ и оплата	Протокол ручной проверки формы заявки, входа в кабинет, каталога, корзины, оформления и оплаты заказа с найденными ошибками.
20. Аналитика	Номер счётчика и страницы без него, сработавшие цели, события тестового заказа и объяснённые расхождения Метрики, GA4 и CRM.
21. Персональные данные и обязательные страницы	Сверка согласий, политики, cookie, реквизитов, документов магазина и языка экранов с 152-ФЗ и 168-ФЗ, без подмены заключения юриста.
22. Письма, которые отправляет сайт	Куда и за какое время доходят письма с сайта, оценка mail-tester, проверка подписей домена и адреса для ответа клиенту.
23. Внешняя репутация и карточки компании на картах	Картина внешних ссылок, расхождения в карточках на картах, ошибки товарных фидов и то, кто первым показан по запросу бренда.
24. Журналы и настройки сервера	Самые частые ошибки и медленные запросы из журналов сервера, проверка фоновых задач, резервных копий и режима отладки.
25. Ошибки в коде сайта	Реестр ошибок кода: где ломаются страницы, фоновые задачи, почта и обмен и что перестанет работать при обновлении PHP или движка.
26. Ошибки в консоли браузера	Журнал ошибок скриптов и незагруженных файлов по типам страниц и ключевым сценариям на компьютере, телефоне и во втором браузере.
27. Состояние сервера, стабильность и отказоустойчивость	Паспорт сервера, риски отказа, проверка резервных копий, мониторинга и единых точек отказа, а при согласованном окне ещё и протокол испытаний.
28. Вирусы и полный аудит безопасности	Заключение, взломан ли сайт на дату аудита, и реестр уязвимостей по уровням опасности с порядком их закрытия.
29. Лишние файлы и базы на сервере	Реестр лишних файлов, баз и доступов на сервере с размерами и решением по каждому; удаление только после подтверждения по строкам.
30. Отдельные проверки 1С-Битрикс	Итоги встроенных проверок Битрикса: система, безопасность, обновления, пользователи, кэш, настройки магазина и провалы монитора качества.
31. Увеличение продаж	Карта продаж: приносит ли «Купить в 1 клик» заказы через YCP, каких страниц под задачи покупателя не хватает, какие площадки и реклама нужны, что не так в CRM и на экране руководителя.
32. Системы аналитики для экрана руководителя	Таблица систем аналитики: что уже выведено на экран руководителя, что работает отдельно, чего нет и какие цифры из-за этого не видны.
33. Разбор бизнеса по сквозной аналитике: где теряются заказы и деньги	Разбор бизнеса по воронке, каналам, предложениям и марже и три–семь первых правок, каждая из которых подкреплена цифрой.
34. Оценка модели бизнеса: от идеи до выводов через 14 и 30 дней	Одна страница для владельца: сходится ли модель бизнеса, выполняет ли он обещанное клиентам, три первые правки и нужна ли новая идея.
35. Обмены с маркетплейсами и модули заказов	Сверка карточек, цен, заказов и остатков по каждой площадке с отметкой, где данные расходятся с учётом и сайтом.
36. Обмен с 1С	Схема, какая система отвечает за цену, остаток и заказ, список расхождений сайта с 1С и поведение сайта при сбое обмена.
37. Оплата и доставка: путь заказа до поступления денег	Протокол тестовой оплаты, расчёта доставки, статусов и писем с отметкой мест, где путь заказа обрывается.
38. Доставка писем до ящика получателя	Проверка записей SPF, DKIM и DMARC и таблица тестовых писем по почтовым службам: во входящих, в спаме или не дошли.
39. Кэш: видна ли правка посетителю	Время появления правки на витрине, карта слоёв кэша и регламент сброса после изменений и выкладки.
40. Админка после обновления модуля или ядра	Протокол проверки админки после обновления: сохранение ключевых форм, вкладки настроек модулей и соседние профили обмена.
41. Роли сотрудников	Матрица ролей сотрудников: какие задачи каждый решает сам, где нужен администратор или подрядчик, и список лишних прав.
42. Нагрузка на реальном объёме каталога	Время ответа списка товаров, фильтра, поиска и карточки на реальном каталоге и порог нагрузки, после которого витрина замедляется.
43. Мониторинг и оповещения	Список настроенных оповещений с получателями и историей срабатываний, пробелы в мониторинге и порядок эскалации.
44. Учебное восстановление из резервной копии	Дата последней проверенной копии, протокол учебного восстановления и чек-лист первого часа после него.
45. Сторонние виджеты при отказе	Список сторонних виджетов с оценкой критичности и проверка, работают ли заявка и оплата, когда виджет недоступен.
46. Повторная проверка на следующий день после выкладки	Одностраничный протокол проверки через 12–24 часа после выкладки: путь заказа, админка, ночной обмен и способ отката.
47. Внутренний поиск и мягкие 404	Список мягких 404 и битых пунктов меню, проверка поиска по артикулам и названиям, которыми пользуются продавцы.
48. Понятны ли тексты сайта читателю	Список страниц с непонятным текстом по выборке и примеры переформулировок для первых абзацев, слоганов и призывов.
49. B2B: спрос, дилеры и отложенные сделки	Карта потерь в B2B: соответствие сайта запросам закупщиков, работа дилеров, возврат отложенных сделок и отдача рекламы.
50. ROMI и ROAS: маржа, возвраты и длина сделки	Расчёт ROMI рядом с ROAS с учётом маржи и возвратов, подходящий период когорт и тревожные признаки в отчётах маркетинга.
51. Переезд каталога и структуры без потери спроса	Карта перенаправлений со старых адресов, список потерянных посадочных страниц и цифры трафика в первые дни после переезда.
52. Рутина продаж: CRM, 1С и время менеджера	Карта ручной работы менеджеров с оценкой часов в неделю и три автоматизации, с которых стоит начать.
53. Сборка отчёта	Реестр находок с уровнями и способом перепроверки, вывод для руководителя и отдельная страница для владельца о жизнеспособности модели.

Сценарий проверки

Таблицы этапов читаются так: в левой колонке — что проверяем, в средней — что делаем, в правой — что останется у заказчика по этой проверке.

1Глубина аудита: быстрая, стандартная или глубокая

Если глубину не выбрать заранее, аудит либо не укладывается в день, либо обещает проверить всё и ничего не доводит до конца. Быстрая проверка за день (smoke) занимает день, стандартная — неделю. Глубокая (deep) дополнительно охватывает обмены данными, 1С, путь оплаты до поступления денег и окупаемость рекламы.

Что делаем. Вместе с заказчиком выбираем одну глубину аудита и составляем список доступов, которые он может дать. Каждую проверку помечаем по тому, что для неё нужно: хватит публичного сайта, нужен кабинет (Метрика, Вебмастер, реклама) или нужен вход на сервер по SSH, доступ к 1С или к админке.

Результат. В отчёте видно, на какой глубине шёл аудит, какие этапы сознательно отложены и каких доступов не хватило.

Проверка	Что делаем	Результат
1.1 Быстрая проверка за день (smoke) все	Проверяем домен, https и коды ответа главной, карточки и корзины. Проходим одну покупку или заявку, смотрим, нет ли красных ошибок в консоли браузера (панели разработчика, где видны ошибки скриптов) на пути от карточки до оформления, и работает ли счётчик посещений.	Сайт открывается, заказ или заявка проходят, грубых поломок, которые мешают покупке, нет. Глубокую проверку в этом варианте не обещаем.
1.2 Стандартная проверка за неделю все	Проходим этапы 2–34 без глубокой проверки обменов и без учебного восстановления из резервной копии, добавляем читаемость ключевых страниц.	Реестр поломок сайта, продаж и модели бизнеса. Обмены и 1С вынесены отдельной строкой с пометкой «нужна глубокая проверка».
1.3 Глубокая проверка (deep) магазин, B2B, маркетплейсы	Проходим этапы 35–51: обмены, 1С, оплату, доставку писем до ящика получателя, обновление кэша после правок, роли сотрудников, нагрузку, мониторинг, восстановление из копии и ROMI (окупаемость маркетинга с учётом маржи).	Проверена вся связка сайта с учётом, деньгами и рекламой, а не только витрина.
1.4 Доступы заказчика все	Составляем список: Вебмастер, Search Console, Метрика, Директ или Google Ads, SSH или панель хостинга, админка движка сайта, 1С или выгрузка из неё, кабинеты маркетплейсов.	По каждому доступу отмечено: выдан, не выдан или достаточно скриншота.

2Подготовка и границы аудита

Если заранее не договориться о границах, аудит расползается: проверяют не тот адрес сайта, не те типы страниц и не те сценарии.

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

Результат. Зафиксированы основной адрес, тип сайта, сценарии, выборка страниц (по одной-две страницы каждого типа) и список разрешённых действий.

Проверка	Что делаем	Результат
2.1 Основной адрес сайта все	Смотрим браузер, whois (кто владеет доменом и до какой даты он оплачен), Вебмастер и Search Console. Определяем, на каком адресе сайт оказывается после всех перенаправлений: http или https, с www или без, со слэшем на конце или без, а для домена на кириллице (IDN) — и его запись латиницей (punycode).	Рабочий адрес один. Остальные имена перенаправляют на него кодом 301 (постоянный переезд) или осознанно работают как поддомены, например shop.site.ru. В отчёт: основной адрес, список зеркал, дата проверки.
2.2 Тип сайта и обязательные сценарии все	Согласуем с заказчиком и сверяем с картой сайта. Определяем тип: визитка, каталог, магазин, портал или лендинг. Записываем сценарии: заявка, поиск, карточка, корзина, оплата, личный кабинет, смена языка.	Список сценариев записан до начала проверки. Блок проверок для магазина обязательно проходим у магазина и не проходим у визитки. В отчёт: тип сайта, языки, регион, сценарии и то, чего на сайте нет.
2.3 Доступы все	Проверяем доступ к кабинетам и админке: Вебмастер, Search Console, Метрика, GA4, рекламные кабинеты, админка движка сайта, а при разрешении — хостинг и логи сервера.	Понятно, какую часть аудита можно провести. Если кабинета поисковика нет, в отчёте так и пишем: данных поисковика по реальным посетителям нет. Догадок об индексе не делаем. В отчёт: таблица доступов с отметками «есть» или «нет» и владельцем каждого доступа.
2.4 Выборка типов страниц все	Берём страницы из карты сайта, позже дополняем их по итогам обхода сайта программой (Screaming Frog и аналоги). В выборку входят главная, раздел, карточка товара или услуги, статья, контакты, поиск, поиск без результатов, страница 404, корзина, оформление заказа, личный кабинет, фильтр и постраничная навигация (страницы 2, 3, 4 списка).	Каждый используемый тип страницы представлен хотя бы одним адресом. Служебные страницы отделены от посадочных, то есть тех, которые люди должны находить в поиске. В отчёт: таблица адресов по типам страниц.
2.5 Ограничения проверки все	Договариваемся, можно ли отправлять тестовый заказ, проверять оплату, запускать активный сканер и смотреть Вебвизор (записи действий посетителей в Метрике).	Активные проверки и тестовые заказы проводим только в разрешённых пределах. В отчёт: что было разрешено и что мы сознательно не трогали.

3Домен и DNS

Сайт может ещё открываться, когда срок регистрации домена уже истёк или почта домена никому не принадлежит.

Что делаем. Проверяем срок регистрации домена и то, кто контролирует продление. Смотрим DNS, то есть записи, которые указывают, на какой сервер ведёт имя сайта: DNS-серверы домена, адреса сервера, поддомены и сертификаты на имя бренда. Отдельно проверяем почтовые записи SPF, DKIM и DMARC, которые защищают домен от поддельных писем.

Результат. Известны срок домена, схема DNS и состояние почтовых записей SPF, DKIM и DMARC.

Проверка	Что делаем	Результат
3.1 Срок регистрации и регистратор все	По whois и кабинету регистратора (компании, у которой куплен домен) смотрим дату окончания, включено ли автопродление, нет ли статуса clientHold (приостановка домена) и не ведёт ли домен чужой регистратор, к которому у владельца нет доступа.	До окончания регистрации больше 30 дней, продление контролирует владелец сайта. В отчёт: дата окончания, регистратор.
3.2 DNS-серверы (NS) и адресные записи A/AAAA все	Через MXToolbox, intoDNS и DNSViz проверяем, правильно ли домен направлен на свои DNS-серверы, нет ли лишних A-записей и ведут ли адреса с www и без www на один сервер. Если объявлена запись AAAA (адрес сервера в формате IPv6), проверяем, отвечает ли сервер по этому адресу.	Записи домена не противоречат друг другу, сайт открывается по всем опубликованным именам. В отчёт: NS и A/AAAA рабочего адреса, ошибки в записях домена.
3.3 Поддомены и сертификаты все	По crt.sh (журнал выпущенных сертификатов) и DNS ищем старые поддомены, тестовые копии сайта и чужие сертификаты безопасности, выпущенные на имя бренда.	Тестовые адреса закрыты от индексации и не содержат открытую копию базы рабочего сайта. В отчёт: список действующих имён домена.
3.4 Почта домена: SPF, DKIM, DMARC, MX все, если с домена отправляется почта	Через MXToolbox и dmarcian проверяем, что MX ведёт на нужный почтовый сервис, SPF (список серверов, которым разрешено отправлять почту от имени домена) не шире необходимого, а DKIM (электронная подпись письма) действительно подписывает письма. DMARC (правило для писем, не прошедших эти проверки) должен стоять хотя бы в режиме p=none со сбором отчётов; если письма уже выверены, лучше quarantine (подозрительные письма уходят в спам) или reject (такие письма отклоняются).	Настоящие письма домена проходят проверки, поддельное письмо от имени домена без подписи не выглядит доставленным. В отчёт: текст записи SPF, наличие DKIM, политика DMARC.

4Шифрование соединения (TLS) и переход на https

Поисковики и браузеры считают основным защищённый адрес сайта. Если на защищённой странице остались картинки или скрипты по незащищённому адресу (смешанный контент), браузер перестаёт показывать замок, а часть скриптов не работает.

Что делаем. Проверяем сертификат и протоколы шифрования в SSL Labs, перенаправление с http на https и заголовок HSTS. Ищем на страницах картинки, скрипты и стили, которые загружаются по незащищённому адресу.

Результат. Оценка шифрования (TLS), проверенный переход на https и список страниц со смешанным контентом.

Проверка	Что делаем	Результат
4.1 Сертификат все	В SSL Labs и в браузере проверяем срок действия, цепочку сертификатов и список имён в сертификате (SAN): покрывает ли он основной адрес сайта и вариант с www.	Оценка SSL Labs — A или A+. До истечения больше 14 дней. Сертификат выписан на рабочий адрес сайта. В отчёт: оценка, дата окончания, замечания по протоколам.
4.2 Протоколы все	В SSL Labs проверяем, не включены ли устаревшие протоколы TLS 1.0 и 1.1, SSL 3 и слабые шифры.	Работают только TLS 1.2 и 1.3. В отчёт: какие устаревшие протоколы отключены или факт, что они ещё включены.
4.3 Перенаправление с HTTP на HTTPS все	Через httpstatus.io и программу обхода сайта смотрим код ответа, число перенаправлений и то, сохраняются ли путь и параметры адреса.	Один редирект 301 (постоянное перенаправление) ведёт сразу на основной https-адрес. По порту 80 (незащищённое соединение) не открывается отдельная версия сайта. В отчёт: цепочка перенаправлений для главной, для внутренней страницы и для адреса с параметром.
4.4 Заголовок HSTS все	Через SecurityHeaders и ответ сервера проверяем, отдаёт ли основной адрес по https заголовок Strict-Transport-Security. Он требует от браузера открывать сайт только по защищённому соединению.	Заголовок есть, max-age (сколько браузер помнит это правило) — от нескольких месяцев. Параметр includeSubDomains (правило действует и на поддомены) ставится, только если все поддомены действительно работают по HTTPS. В отчёт: значение заголовка.
4.5 Смешанный контент все	В браузере, Lighthouse и программой обхода ищем картинки, скрипты, стили и встроенные окна (iframe, например страницу оплаты), которые загружаются по http на https-странице.	Активного смешанного контента (скриптов, стилей, iframe) нет, пассивные картинки по http тоже убраны. В отчёт: список адресов страниц с ресурсами по http.

5Доступность сайта и коды ответа сервера

Индексация и реклама теряют смысл, если страницы какого-то типа отвечают ошибкой 500 (внутренняя ошибка сервера) или долго не открываются.

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

Результат. Коды ответа ключевых страниц, время ответа сервера и картина серверных ошибок.

Проверка	Что делаем	Результат
5.1 Ключевые страницы отвечают кодом 200 все	Программой обхода и вручную проходим выборку страниц: главную и страницы каждого типа из этапа 2.	Посадочные страницы отдают код 200 (страница открылась нормально) без промежуточной заглушки. Коды 401 (нужно войти) и 403 (доступ запрещён) бывают только у закрытых разделов. В отчёт: таблица адресов и кодов ответа.
5.2 Время ответа сервера все	Через WebPageTest, программу обхода и панель производительности Битрикса замеряем TTFB (сколько сервер думает, прежде чем начать отдавать страницу) на главной, в разделе, карточке, поиске и фильтре.	TTFB стабильно держится в пределах примерно 0,8 с на обычной странице, если это не тяжёлый личный кабинет. Поиск и фильтр не заставляют ждать по нескольку секунд. В отчёт: TTFB по типам страниц и самые медленные адреса.
5.3 Ошибки 5xx и обрывы все	По Вебмастеру, Search Console, журналам nginx или Apache и Метрике смотрим долю ошибок 5xx (сервер не смог собрать страницу), всплески по часам и скрипты, которые их вызывают.	Постоянного фона ошибок 5xx нет. У единичного всплеска найдена причина. В отчёт: период, число ошибок 5xx, примеры адресов.
5.4 История простоев если сайт уже был под мониторингом	По UptimeRobot или аналогичному сервису и данным хостинга смотрим простои за 30–90 дней, их причины и не повлиял ли простой на индексацию.	Каждый простой объяснён. Если мониторинга не было, отмечаем это как пробел в наблюдении за сайтом. В отчёт: процент доступности или пометка «мониторинга нет».
5.5 Заглушка и технические работы все	В браузере, а если застанем технические работы, то и в файле robots.txt проверяем, отдаёт ли сайт на время работ код 503 (сайт временно недоступен) с заголовком Retry-After (через сколько можно зайти снова) и не закрывают ли сайт в robots.txt насовсем.	Рабочий сайт не остаётся на странице «ведутся работы» с кодом 200. В отчёт: что увидели.
5.6 Ответ из другой сети магазин и региональный сайт	Открываем сайт через мобильный интернет или прокси нужного региона и смотрим обход в Вебмастере. Ищем блокировку по региону, доступ только по белому списку IP-адресов и разный контент для поискового робота и человека.	Поисковый робот и обычный посетитель из нужного региона видят одинаковый публичный контент. В отчёт: расхождения, если найдём.

6Зеркала сайта и перенаправления

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

Что делаем. Перебираем варианты адреса сайта и смотрим, куда и с каким кодом каждый из них перенаправляет. Ищем длинные цепочки и петли, сверяем главное зеркало в Вебмастере и свойства в Search Console, находим внутренние ссылки, которые ведут на перенаправления.

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

Проверка	Что делаем	Результат
6.1 Таблица зеркал все	Через httpstatus.io проверяем варианты адреса: http и https, с www и без, /index.php, /index.html, со слэшем на конце и без, в верхнем регистре, в punycode (запись кириллического домена латиницей), с index на конце адреса раздела.	Все варианты одним редиректом 301 (постоянное перенаправление) ведут на один основной адрес. Внутренние ссылки сразу ведут на него. В отчёт: таблица из 8–12 проверок.
6.2 Длина цепочки все	Программой обхода и wheregoes ищем цепочки из двух и больше перенаправлений, код 302 (временное перенаправление) там, где адрес сменился навсегда, и петли.	Постоянный переезд делается одним редиректом 301. Код 302 стоит только у действительно временных адресов. В отчёт: адреса, где цепочка длиннее одного перенаправления.
6.3 Главное зеркало в Вебмастере если есть доступ	В Яндекс Вебмастере проверяем, совпадает ли назначенное главное зеркало с основным адресом сайта.	Главное зеркало одно, и это рабочий адрес на https. В отчёт: скриншот настройки.
6.4 Склейка в Google если есть доступ	В Search Console смотрим свойства сайта, тег canonical (указывает поисковику, какой адрес страницы считать основным) и перенаправления. Проверяем, что свойства для http, https и www добавлены осознанно или трафик уже собран на одном из них, а старое свойство не копит собственные ошибки из-за отсутствия редиректа.	В индексе (списке страниц, которые поисковик хранит и показывает) одна версия адреса сайта. В отчёт: какие свойства заведены.
6.5 Внутренние ссылки на перенаправления все	Программой обхода ищем ссылки в меню и карточках, которые ведут на адрес с редиректом 301 вместо конечного адреса.	Внутренних ссылок на перенаправления почти нет, кроме осознанно используемых коротких адресов. В отчёт: страницы и блоки, откуда идёт больше всего таких ссылок.

7Заголовки ответа сервера, cookie и утечки служебных данных

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

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

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

Проверка	Что делаем	Результат
7.1 Заголовки безопасности все	Проверяем ответ сервера в SecurityHeaders и Mozilla Observatory. Смотрим заголовки CSP (список источников, откуда странице разрешено загружать скрипты), X-Content-Type-Options: nosniff (запрещает браузеру угадывать тип файла), Referrer-Policy (какую часть адреса страницы получает другой сайт при переходе по ссылке), X-Frame-Options или frame-ancestors (кому разрешено встраивать сайт в своё окно, чтобы страницу нельзя было подменить) и Permissions-Policy (к камере, геолокации и другим возможностям браузера страница может обращаться).	Все заголовки на месте и не мешают работе самого сайта. Если политика CSP уже есть, разбираем её отдельно: она не должна повсеместно разрешать скрипты, вписанные прямо в страницу (unsafe-inline), потому что так защиту легко обойти. В отчёт: оценка и список отсутствующих заголовков.
7.2 Cookie все	Смотрим, какие cookie сервер ставит в ответе (заголовок Set-Cookie) и что хранится в браузере. Для cookie сессии, по которой сайт помнит вошедшего посетителя или содержимое его корзины, проверяем флаги Secure (передаётся только по https), HttpOnly (скрипт страницы не может её прочитать) и SameSite (когда её можно отправлять при переходе с чужого сайта). Маркетинговые cookie, которые ставятся до согласия посетителя, проверяем в этапе 21.	Если сессия хранится на сервере, её идентификатор не передаётся по http и не читается скриптом страницы. В отчёт: имена cookie и их флаги.
7.3 Раскрытие версий все	Смотрим заголовки ответа Server и X-Powered-By и код страницы. Ищем точные версии PHP, веб-сервера nginx и Битрикса в заголовках ответа сервера и в публичной разметке страниц.	Точные версии программ, на которых работает сайт, снаружи не видны. В отчёт: какие версии удалось увидеть.
7.4 Служебные пути все	Запрашиваем служебные адреса напрямую, проходим сайт программой обхода, проверяем его в Sucuri (поиск известного вредоносного кода) и встроенным сканером Битрикса. Проверяем /.git/ (история кода, из неё можно забрать исходники), /.env (файл с паролями и ключами), /phpinfo.php (внутренние настройки PHP), /server-status (состояние веб-сервера), /bitrix/backup/, дампы базы .sql и архивы сайта в корне, открытый просмотр содержимого папок и PHP-файлы в папке загрузок /upload/.	Такие адреса отвечают кодом 403 (доступ запрещён) или 404 (страницы нет) и не отдают дамп, то есть копию базы или файлов сайта. В папке /upload/ PHP-файлы не выполняются. В отчёт: каждый проверенный путь и код ответа.
7.5 Админка в индексе поисковиков Битрикс и любой другой движок сайта	В Вебмастере, в выдаче по запросу site: и в robots.txt проверяем, не попали ли в индекс страницы входа в админку (закрытую часть, где сотрудники управляют сайтом) и страницы, которые открываются после авторизации.	Админка закрыта от индексации. Подбор пароля ко входу ограничен капчей, лимитом попыток или доступом только из определённой сети. В отчёт: есть ли адреса админки в индексе.
7.6 Чёрные списки и вредоносный код все	Проверяем сайт в Google Safe Browsing (список опасных и взломанных сайтов), в разделе «Безопасность» Вебмастера, в Sucuri, VirusTotal (проверка адреса сразу многими антивирусами) и MXToolbox Blacklist. Ищем пометку опасного сайта, вставки чужого кода, перенаправления на посторонние домены и IP-адрес сервера в списках, по которым почтовые сервисы отказываются принимать письма.	Активных предупреждений нет. Если предупреждение было раньше, оно снято и перепроверено. В отчёт: скриншот статусов на дату аудита.
7.7 Сторонние скрипты все	Через urlscan.io и вкладку Network в браузере (список всего, что загрузила страница) ищем неожиданные домены, скрипты-майнеры, подмену форм и старые виджеты, подключённые по http: чат, карту, кнопку звонка, видео.	Про каждый внешний скрипт понятно, что это: Метрика, чат, оплата, карты. Неизвестных доменов нет. В отчёт: список сторонних доменов.

8Файл robots.txt и закрытие служебных разделов

robots.txt — текстовый файл с правилами для поисковых роботов: какие разделы сайта им можно обходить. Одна ошибка в нём может убрать сайт из индекса или, наоборот, открыть поисковикам фильтры и корзину.

Что делаем. Проверяем, что robots.txt открывается на основном адресе сайта и правила в нём читаются. Смотрим, закрыты ли служебные разделы и открыты ли посадочные страницы, указана ли карта сайта и совпадают ли правила файла с тем, как их понимают Вебмастер и Search Console. Ищем страницы, где запрет в robots.txt пересекается с пометкой noindex.

Результат. Текст robots.txt и список разделов, которые закрыты по ошибке или открыты зря.

Проверка	Что делаем	Результат
8.1 Файл доступен все	Открываем файл в браузере, Вебмастере и Search Console. Проверяем, что robots.txt отдаёт код 200 (страница открылась нормально) именно на основном адресе сайта и не перенаправляет на обычную HTML-страницу.	Файл отдаётся как простой текст (text/plain), правила читаются, случайного запрета на весь сайт (Disallow: /) нет. В отчёт: полный текст файла в приложении.
8.2 Закрыты служебные разделы все	По правилам robots.txt и результатам обхода сайта проверяем, закрыты ли админка, личный кабинет, корзина, оформление заказа, внутренний поиск, адреса с параметрами сессии, бесконечные сочетания фильтров и сортировок.	Служебные разделы закрыты. Посадочные разделы и карточки, то есть страницы, которые люди должны находить в поиске, открыты. В отчёт: список закрытых разделов по началу адреса и список того, что закрыто по ошибке.
8.3 Карта сайта указана в файле все	В robots.txt и в кабинетах поисковиков проверяем директиву Sitemap. Она должна вести на рабочий XML-файл карты сайта на основном адресе.	В файле и в кабинетах указан один и тот же адрес карты. В отчёт: адрес карты сайта.
8.4 Совпадение с кабинетами если есть доступ	Проверяем правила в инструменте анализа robots.txt в Вебмастере и Search Console. Сверяем, совпадает ли написанное в файле с тем, какие адреса поисковый робот действительно пропускает.	Проверочные адреса посадочных страниц разрешены, проверочные адреса служебных страниц запрещены. В отчёт: расхождения.
8.5 Noindex и robots.txt на одной странице все	Программой обхода ищем два случая. Страница закрыта в robots.txt и одновременно отдаёт noindex (пометку «не добавлять страницу в поиск»). Или noindex стоит на важной странице.	Важные страницы доступны для обхода и индексации. У служебных страниц один понятный способ исключения из поиска. В отчёт: число страниц с noindex по типам страниц.

9Карта сайта

Карта сайта (sitemap) — список адресов, которые владелец просит поисковики добавить в индекс. Если в ней есть мусорные адреса, они быстрее попадают в поиск.

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

Результат. Карта сайта, которую принимают поисковики, без мусорных адресов и без потерянных посадочных страниц.

Проверка	Что делаем	Результат
9.1 Корректность файла карты все	В кабинетах поисковиков, программой разбора XML и в браузере проверяем ошибки синтаксиса, размер файла, индексную карту (общий файл со ссылками на несколько карт), кодировку и код ответа.	Кабинеты приняли карту без ошибок, файл отдаёт код 200. В отчёт: число адресов, число файлов карты, ошибки из кабинетов.
9.2 Состав все	Сравниваем список адресов из карты с результатами обхода сайта. Ищем в карте адреса, которые тег canonical (указание поисковику, какой адрес страницы считать основным) называет неосновными, перенаправления, страницы с кодами 404 и 5xx, страницы с noindex и закрытые в robots.txt, адреса на http вместо https и адреса с параметрами сортировки.	В карте только основные адреса с кодом 200, которые должны быть в индексе. В отчёт: доля мусорных адресов и примеры.
9.3 Полнота все	По результатам обхода ищем страницы, которых нет в карте: новые карточки и статьи, разделы, забытые после переезда сайта.	В карте представлены все типы посадочных страниц, которые должны попадать в поиск. Отдельные пропущенные адреса перечислены. В отчёт: типы страниц, выпавшие из карты.
9.4 Даты изменения (lastmod) все	В XML-файле карты смотрим поле lastmod — дату последнего изменения страницы. Ищем одинаковую дату у всех адресов, даты из будущего и дату, которая не меняется годами, хотя каталог обновляется.	lastmod показывает реальную дату изменения, или поле не заполнено. Всему файлу не проставлена одна «свежая» дата для вида. В отчёт: как проставлен lastmod.
9.5 Картинки и видео если картинки и видео важны для поиска	Проверяем расширения карты сайта для картинок и видео. Смотрим, попадают ли главные фото товаров в карту изображений (image sitemap) или в разметку страницы.	У фото товаров есть отдельный понятный способ попасть в поле зрения поисковика. В отчёт: есть ли расширение карты и работает ли оно.

10Индексация по данным Вебмастера и Search Console

Только в кабинетах поисковиков видно, какое решение по страницам приняли сами Яндекс и Google. Обход сайта программой даёт лишь предположение.

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

Результат. Если кабинеты открыты, известно, как Яндекс и Google видят индекс сайта, какие страницы исключены и есть ли санкции, то есть понижение сайта в выдаче или исключение из неё.

Проверка	Что делаем	Результат
10.1 Объём индекса если есть доступ	В Вебмастере и Search Console, а для сверки и по запросу site: сравниваем число страниц в индексе с числом посадочных страниц. Ищем резкое падение или раздувание индекса.	Порядок цифр совпадает с числом посадочных страниц. У резкого скачка найдена причина. В отчёт: цифры по Яндексу и Google на дату проверки.
10.2 Причины исключения если есть доступ	Смотрим диагностику и раздел индексирования в Вебмастере и отчёт о покрытии в Search Console. Разбираем причины: дубль, перенаправление, noindex, запрет в robots.txt, soft 404 (страница сообщает, что ничего не найдено, но отвечает как обычная рабочая), «обнаружена, не просканирована», «просканирована, не проиндексирована», ошибка сервера.	Для каждой крупной группы исключённых страниц понятно, так задумано или это ошибка. В отчёт: основные причины и примеры адресов.
10.3 Точечная проверка адресов если есть доступ	Инструментом проверки URL в обоих кабинетах проверяем главную, раздел, карточку, статью, фильтр, поиск и корзину.	Посадочные страницы доступны поисковику и сами являются основными адресами. Фильтр, поиск и корзина не индексируются. В отчёт: статус каждого проверенного адреса.
10.4 Ручные меры и безопасность если есть доступ	Читаем сообщения в кабинетах: санкции, признаки взлома, спам в материалах, которые публикуют посетители. Ручные меры — это санкции, которые назначил сотрудник поисковика, а не автоматическая проверка.	Активных ручных мер нет. В отчёт: текст статуса из кабинетов.
10.5 Параметры и дубли все	В кабинетах и по результатам обхода ищем в индексе адреса с utm-метками (метки в рекламных ссылках, по которым видно, откуда пришёл посетитель), идентификатором сессии, параметрами sort, view, print и бесконечными сочетаниями фильтров.	В индекс попадают только чистые адреса посадочных страниц. Метки отслеживания не превращаются в отдельные страницы. В отчёт: примеры дублей с параметрами.
10.6 Постраничная навигация каталог	Программой обхода и по выдаче проверяем первую и дальние страницы списков (2, 3, 4 и так далее). Смотрим, куда указывает тег canonical (указание поисковику, какой адрес считать основным): на саму страницу или на первую. Проверяем, что заголовки title (текст вкладки и строка в поиске) у страниц различаются и дальние страницы не вытесняют первую.	Основная посадочная страница раздела — первая. Дальние страницы доступны для обхода, если через них находятся карточки, и не конкурируют с первой за один и тот же запрос. В отчёт: как устроена постраничная навигация.
10.7 Регион сайта в Яндексе региональный сайт	В Яндекс Вебмастере проверяем назначенный регион сайта, поддомены городов и совпадение контактов на странице с регионом.	Назначенный регион совпадает с тем, где работает бизнес. Городские поддомены не являются пустыми копиями без собственных контактов. В отчёт: регион и список поддоменов.
10.8 Языковые версии и hreflang мультиязычный сайт	Программой обхода и в Search Console проверяем hreflang — пометки о том, для какого языка и страны предназначена версия страницы. Смотрим, ссылаются ли версии друг на друга, есть ли версия по умолчанию x-default, совпадает ли язык в адресе и в атрибуте html lang, не смешаны ли языки на одной странице.	Каждая языковая версия ссылается на все остальные и на себя. Язык, указанный в разметке, совпадает с языком текста. В отчёт: ошибки hreflang.
10.9 ИКС и видимость в поиске для общей картины если есть доступ	По Вебмастеру, Keys.so или MegaIndex и Topvisor смотрим ИКС (индекс качества сайта — сводная оценка Яндекса), динамику показов и кликов за 3–6 месяцев и просадки отдельных разделов.	Значение ИКС зафиксировано. Если видимость упала, падение связано с конкретной группой страниц или с внешней причиной и прокомментировано. В отчёт: ИКС, динамика кликов, пострадавшие разделы.

11Полный обход всех страниц сайта специальной программой

Вебмастер и Search Console показывают, как поисковик видит сайт, но только на части страниц. Программа обхода сайта (Screaming Frog и аналоги) проходит по всем страницам подряд и находит однотипные ошибки, которые повторяются по всему сайту.

Что делаем. Запускаем программу обхода по всем страницам с учётом правил для поисковых роботов и основного адреса сайта. По её отчёту проверяем коды ответа, битые ссылки, title, description и заголовки, тег canonical, дубли, пустые страницы, глубину вложенности, изображения и вид адресов. Если сайт собирается скриптами в браузере, делаем отдельный проход с отрисовкой.

Результат. Список массовых ошибок по всему сайту: неверные коды ответа, дубли страниц, ошибки тега canonical, битые ссылки и страницы почти без полезного текста.

Проверка	Что делаем	Результат
11.1 Настройка обхода все	Запускаем Screaming Frog, Sitebulb, Netpeak или облачный аудит. Учитываем правила robots для поисковых роботов и основной адрес сайта. Если витрина собирается скриптом в браузере, включаем отрисовку JavaScript. Ограничиваем скорость обхода, чтобы сайт не упал под нагрузкой.	Обход доходит до конца и не обрывается искусственно на паре тысяч адресов, если страниц на сайте больше. Для сайта, который собирается скриптами, есть отдельный проход с отрисовкой. В отчёт: программа, дата, число обойдённых адресов и была ли включена отрисовка JavaScript.
11.2 Коды ответа и битые ссылки все	По отчёту программы ищем внутренние ссылки на страницы с кодом 404 (страницы нет), 410 (страница удалена навсегда) и 5xx (ошибка сервера), битые внешние ссылки и ссылки, которые ведут на редирект вместо конечного адреса.	В меню, карточках и ссылках между страницами сайта нет битых ссылок. Битые внешние ссылки в важных блоках убраны. В отчёт: число и примеры, сгруппированные по типам страниц.
11.3 Title страниц все	Проверяем title — название страницы, которое видно во вкладке браузера и в строке поисковой выдачи. Ищем пустые и повторяющиеся title, слишком длинные для строки в поиске, слишком короткие, чтобы что-то сообщить, и одинаковые у карточек.	У каждой страницы, открытой для поиска, свой title, и он описывает именно её. В отчёт: число пустых и повторяющихся title, худшие примеры.
11.4 Description страниц все	Ищем пустые и повторяющиеся description — короткое описание страницы для поисковой выдачи. Пустое описание не всегда считается ошибкой. Ошибка — один и тот же текст на весь каталог.	Нет одного description на тысячи адресов. В отчёт: сколько страниц делят одинаковое описание.
11.5 Заголовки H1–H3 все	Смотрим отчёт программы и вручную проверяем пять типов страниц. Ищем страницы без H1 (главного заголовка страницы), с несколькими H1, с H1, где на всех страницах стоит один и тот же слоган из шапки, и с перескоками уровней заголовков.	На посадочной странице, то есть той, которую люди должны находить в поиске, один осмысленный H1, и он не повторяется у других страниц того же типа. В отчёт: типы страниц, где H1 сломан.
11.6 Тег canonical все	Проверяем тег canonical, которым страница сообщает поисковику свой основной адрес. Ищем страницы без этого тега и страницы, где он указывает на другой домен, на редирект или на 404, а также дубли с параметрами в адресе, которые указывают сами на себя вместо основной страницы.	Страница, открытая для поиска, указывает в canonical на саму себя. Дубль указывает на основную страницу. Цепочка canonical не уводит на чужой сайт. В отчёт: типы ошибок canonical.
11.7 Дубли текста все	Программа находит точные и близкие копии: одинаковые карточки, страницы городов с одним и тем же текстом, страницы тегов, версии для печати, а также http- и https-версии, если редирект между ними работает не везде.	Один и тот же текст не открывается по нескольким адресам, доступным для поиска. В отчёт: группы страниц-дублей.
11.8 Страницы почти без текста и «мягкие» 404 все	По отчёту программы, Вебмастеру и Search Console ищем пустые разделы, карточки без описания и без цены и «мягкие» 404 — страницы поиска с текстом «ничего не найдено», которые отдают код 200, как обычная рабочая страница, и попали в индекс поисковика.	Пустые служебные страницы закрыты от поиска или отдают настоящий код 404. Пустые коммерческие разделы не попадают в индекс массово. В отчёт: примеры.
11.9 Страницы без внутренних ссылок и глубина вложенности все	По отчёту программы и карте сайта для поисковиков ищем важные страницы, на которые не ведёт ни одна ссылка с самого сайта, карточки дальше 4–5 кликов от главной и пропуски в меню.	До посадочных страниц можно дойти с главной или с главной страницы раздела. В карте сайта нет страниц-сирот, на которые сам сайт не ссылается. В отчёт: число таких страниц среди открытых для поиска.
11.10 Изображения все	С помощью программы обхода и Lighthouse ищем битые картинки, информативные изображения без alt (текстовой подписи для поиска и для людей, которые не видят картинку), исходники весом в несколько мегабайт и картинки без размеров width и height, из-за которых вёрстка сдвигается при загрузке.	Изображения в содержимом страниц открываются и подписаны alt по смыслу. У декоративных картинок alt пустой. Большая картинка первого экрана и фото в карточке не весят мегабайты. В отчёт: число битых картинок, примеры тяжёлых, типы страниц без alt.
11.11 Исходный HTML и страница после работы скриптов если витрина собирается скриптами или отдаётся через композитный кеш (готовую копию страницы для гостей)	Обходим сайт в двух режимах и смотрим код страницы. Проверяем, что title, H1, текст, товары и ссылки есть уже в первом ответе сервера и не появляются только после выполнения скриптов.	Основное содержимое посадочной страницы есть в ответе сервера. Иначе поисковик и часть посетителей видят пустой каркас. В отчёт: что пропадает, если скрипты не выполнились.
11.12 Понятные адреса и транслит все	По отчёту программы ищем страницы, доступные сразу по адресу с номером (id) и по адресу из слов, адреса на кириллице и в транслите, которые одновременно попали в индекс, а также подчёркивания и пробелы в адресах.	У каждой страницы один адрес, который можно прочитать. В отчёт: примеры двойных адресов.

12Основные типы страниц глазами посетителя

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

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

Результат. Замечания по основным типам страниц: понятность, контакты, поиск, страница 404 и меню.

Проверка	Что делаем	Результат
12.1 Главная все	Открываем в браузере и смотрим, понятно ли, кто компания и что она предлагает, куда нажать, есть ли телефон, актуально ли предложение и не сломана ли большая картинка первого экрана.	За 5 секунд понятно, как перейти к покупке или заявке. В отчёт: замечания по смыслу.
12.2 Раздел каталога или услуг каталог	Проверяем в браузере, что список не пустой, фильтр на месте, есть хлебные крошки (строка пути вроде «главная / раздел / товар»), а текст раздела не превращён в набор ключевых слов внизу страницы.	Из раздела можно перейти в карточку и понять ассортимент. В отчёт: замечания.
12.3 Карточка каталог и магазин	Смотрим в браузере цену, наличие, фото, характеристики, кнопку действия, артикул и соответствие товара своей категории.	По карточке можно решить, оставлять заявку или покупать, не уходя наугад за информацией в другие каналы. В отчёт: чего не хватает.
12.4 Контакты и реквизиты все	Проверяем страницу контактов, подвал сайта и политику: телефон, адрес, почту, юрлицо, ИНН. Сверяем их с карточкой компании на картах и с договором.	Название, адрес и телефон компании (NAP) везде совпадают. У магазина опубликованы реквизиты. В отчёт: расхождения.
12.5 Поиск по сайту если поиск есть	Вручную вводим обычный запрос, пустой запрос, один символ, спецсимволы, запрос в неправильной раскладке и запрос, по которому ничего нет.	Поиск выдаёт результаты или понятную страницу «ничего не найдено». Пустая выдача не выглядит как сломанный каталог и закрыта от индексации. На странице нет ошибки PHP. В отчёт: результаты четырёх проб.
12.6 Страница 404 все	Открываем заведомо несуществующий адрес. Проверяем, что сервер отдаёт именно код 404 или 410, а не 200, что страница оформлена и на ней есть ссылки на главную и на поиск.	Несуществующий адрес не отдаёт код 200 и не перенаправляет молча на главную, если это скрывает ошибки на сайте. В отчёт: код ответа и скриншот.
12.7 Хлебные крошки и меню все	Проходим сайт в браузере на трёх уровнях вложенности. Проверяем, что крошки повторяют структуру разделов, текущий пункт не ссылается сам на себя там, где это мешает, а меню не обрезано на телефоне.	Посетитель всегда понимает, как вернуться назад. В отчёт: уровни, где навигация сломана.
12.8 Блоки, которые повторяются на всех страницах все	Проверяем шапку, подвал, чат и другие общие блоки: нет ли устаревшей акции, чужого города, неработающего чата или кнопки мессенджера, которая никуда не ведёт.	Общий блок либо работает, либо убран с сайта. В отчёт: список дефектов в общих блоках.

13Тексты и коммерческие факторы: цены, контакты, доверие

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

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

Результат. Оценка текстов, актуальности фактов и коммерческих страниц.

Проверка	Что делаем	Результат
13.1 Уникальность ключевых текстов посадочные страницы	Проверяем в text.ru, Content Watch или Copyscape главную, 2–3 коммерческие страницы и 2 статьи. Карточки, где характеристики обоснованно повторяются, массово не проверяем ради процента уникальности.	Тексты, которые должны выводить страницу в поиске, не скопированы один в один у производителя или с чужого сайта. В отчёт: процент уникальности и источники совпадений.
13.2 Перегрузка текста ключевыми словами посадочные страницы под Яндекс	Проверяем тексты в сервисе «Тургенев» и читаем их сами. Ищем списки ключевых слов в подвале и неестественные вставки ключей в заголовках.	Текст можно прочитать вслух. Сервис не показывает крайнего уровня риска, и при чтении это подтверждается. В отчёт: оценка сервиса и цитата проблемного абзаца.
13.3 Орфография в интерфейсе все	Прогоняем тексты страниц через «Орфограммку», кнопки читаем сами. Смотрим кнопки, сообщения об ошибках в формах, шапку сайта и юридические названия.	В интерфейсе и на коммерческих страницах нет заметных ошибок. В отчёт: список опечаток, которые видит клиент.
13.4 Актуальность фактов все	Сравниваем страницы между собой: цены, наличие, телефоны, режим работы. Ищем год «2019» в подвале и акции с истёкшим сроком.	Факты на ключевых страницах не противоречат друг другу и не устарели. В отчёт: найденные противоречия.
13.5 Доверие коммерческий сайт	Смотрим страницы «О компании», доставки, оплаты, возврата и гарантии: понятно ли, кто продаёт, как получить товар, как его оплатить и вернуть. В экспертных материалах проверяем, указан ли автор.	У магазина есть оферта (условия покупки, которые клиент принимает, оформляя заказ), страницы доставки и возврата, реквизиты. У экспертной статьи указан автор. В отчёт: каких страниц не хватает.
13.6 Фото и видео все	На странице и в исходных файлах проверяем, что фото соответствуют товару, не растянуты и не относятся к чужому бренду, а видео открывается.	Фото и видео показывают то, что предлагают на странице, и не заменены стоковыми картинками без связи с товаром. В отчёт: примеры.

14Микроразметка и превью ссылок

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

Что делаем. Проверяем микроразметку главной, раздела, карточки, статьи и контактов в валидаторах Яндекса, Google и validator.schema.org. Сверяем цену, наличие, отзывы, крошки, даты и контакты в разметке с тем, что видно на экране, смотрим ошибки в Вебмастере и Search Console и проверяем превью ссылок.

Результат. По каждому типу страницы понятно, есть ли микроразметка, совпадает ли она с тем, что видно на экране, и какие ошибки повторяются на всём каталоге. К отчёту приложены проверки в валидаторах Яндекса, Google и validator.schema.org, а также ошибки из Вебмастера и Search Console, если к ним дали доступ.

Проверка	Что делаем	Результат
14.1 Типы разметки на разных страницах все	Проверяем каждый тип страницы в Rich Results Test от Google, валидаторе Яндекса и validator.schema.org. Ищем нужные типы разметки: Organization или LocalBusiness для компании, WebSite с поиском по сайту, BreadcrumbList для хлебных крошек, Product и Offer для товара, Article для статьи. FAQ допустим, только если вопросы и ответы действительно видны на странице.	Нет ошибок, из-за которых поисковик не покажет расширенный результат, то есть строку в поиске с ценой, звёздами или крошками. Обязательные поля заполнены. В отчёт: результат валидатора по каждому типу страницы.
14.2 Цена и наличие в разметке Offer магазин	Сравниваем страницу с блоком JSON-LD — отдельным фрагментом кода, в котором записана разметка. Цена, валюта, наличие и адрес товара в разметке должны совпадать с тем, что на экране.	В разметке нет другой цены и нет статуса «в наличии», если на витрине товар закончился. В отчёт: расхождения.
14.3 Отзывы в разметке если есть звёзды рейтинга	Смотрим валидатор и страницу. Проверяем, что AggregateRating (средняя оценка и число отзывов) относится именно к этому товару, отзывы видны на странице и это не купленный блок чужих оценок.	Звёзды в поисковой выдаче опираются на видимые отзывы об этом товаре или компании. В отчёт: где звёзды не совпадают с тем, что на экране.
14.4 Превью ссылок и иконки сайта все	Проверяем отладчиками превью соцсетей и в коде страницы: теги Open Graph og:title, og:description и og:image нужного размера, favicon (значок во вкладке браузера), apple-touch-icon (значок, если сайт добавляют на экран телефона) и при необходимости manifest.	Когда ссылкой делятся в соцсети, превью собирается с нужной картинкой и заголовком, а не с первой попавшейся иконкой меню. В отчёт: скриншоты превью главной и карточки.
14.5 Как записана разметка все типы страниц	Смотрим код главной, раздела, карточки, статьи и контактов. Разметка может быть записана отдельным блоком JSON-LD, которого не видно на экране, или привязана к видимым словам на странице. Проверяем, что на странице нет двух разметок, которые противоречат друг другу.	В отчёт: какой способ используется и есть ли две разные разметки одного товара или компании.
14.6 Разметка есть в ответе сервера все типы страниц	Смотрим страницу в том виде, в каком её отдал сервер, до выполнения скриптов. Название, цена, крошки и данные компании должны быть уже в этом ответе и не дописываться скриптом позже.	В отчёт: список адресов, где поисковик может не увидеть цену и название, потому что их добавляет только скрипт.
14.7 Главная страница все	Проверяем разметку компании: название, телефон, адрес, ссылку на этот сайт. Рядом должна быть разметка самого сайта. Телефон и адрес сверяем с подвалом и страницей контактов.	В отчёт: совпадают ли название, телефон и адрес и каких данных в разметке не хватает.
14.8 Хлебные крошки в разметке каталог и статьи	Сравниваем путь «главная / раздел / товар», записанный в разметке, с полосой пути, которую посетитель видит на странице.	В отчёт: где путь в разметке короче, длиннее или ведёт не в тот раздел.
14.9 Карточка товара магазин и каталог	Проверяем, что в разметке карточки есть название, картинка, цена, валюта, наличие и ссылка именно на эту карточку. Картинка открывается по защищённому адресу (https). Артикул указан, если он есть на странице.	В отчёт: каких обязательных полей не хватает, где картинка не открывается или показывает другое фото.
14.10 Товара нет в наличии магазин	Открываем карточку товара, которого нет на складе, и проверяем, что в разметке стоит «нет в наличии», а не «в наличии».	В отчёт: карточки, которые в поиске обещают товар, которого на сайте уже нет.
14.11 Статья или новость если есть статьи	Проверяем, что в разметке есть заголовок, дата публикации и картинка, а дата совпадает с датой на странице. Если на странице указан автор, он должен быть и в разметке.	В отчёт: статьи с пустой датой, с датой из будущего или с одной и той же датой у всех материалов.
14.12 Вопросы и ответы если блок вопросов есть на странице	Разметка вопросов и ответов допустима только там, где эти вопросы действительно написаны и видны посетителю. Скрытый список вопросов ради дополнительной строки в поиске нормой не считаем.	В отчёт: страницы, где в коде есть вопросы, которых нет на экране.
14.13 Страница контактов все, у кого есть офис или магазин	Проверяем разметку местной компании: название, адрес, телефон, часы работы. Сверяем её со страницей контактов и с карточкой компании на картах.	В отчёт: расхождения в адресе, телефоне и часах работы.
14.14 Ошибки разметки в Вебмастере и Search Console если открыт доступ к кабинетам	Открываем в Яндекс Вебмастере и Google Search Console отчёты по товарам, крошкам и расширенным результатам. Там видны ошибки сразу по многим страницам, тогда как ручной тест проверяет один адрес.	В отчёт: сколько страниц с ошибкой и три-пять примеров адресов на каждый тип ошибки.
14.15 Одна ошибка на весь каталог каталог и магазин	Программой обхода собираем пустые поля разметки: нет цены, нет картинки, битая ссылка внутри разметки. Если одинаковая ошибка встречается на сотнях карточек, значит, сломан шаблон страницы, а не отдельная карточка.	В отчёт: ошибка шаблона и сколько адресов она затрагивает.
14.16 Адрес внутри разметки все типы страниц	Проверяем, что адрес в разметке ведёт на основную версию этой же страницы: с https, в выбранном варианте с www или без него и без рекламных меток.	В отчёт: разметка, которая ссылается на копию адреса или на другую страницу.

15Скорость загрузки и стабильность вёрстки: базовые цифры

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

Что делаем. Снимаем Core Web Vitals, три основные оценки скорости, которыми пользуется Google, по данным реальных посетителей и прогоняем тестовые замеры на главных типах страниц. Проверяем вес картинок и видео, кэширование и сжатие файлов, шрифты и сторонние виджеты, а затем сверяем результаты с отчётами Метрики и Вебмастера.

Результат. Базовые цифры скорости по всему сайту и по главным типам страниц. Подробный разбор причин по слоям сайта идёт в этапе 16.

Проверка	Что делаем	Результат
15.1 Core Web Vitals по замерам у реальных посетителей все	В PageSpeed Insights, Search Console и CrUX (статистика скорости у реальных пользователей Chrome) смотрим три показателя. LCP показывает, за сколько секунд появляется главный крупный блок страницы, картинка или заголовок. INP показывает, как быстро страница откликается на нажатие. CLS показывает, насколько сдвигаются блоки, пока страница ещё грузится. Цифры берём для всего сайта и для главных типов страниц, отдельно для телефонов и компьютеров.	Оценка «хорошо» по текущим порогам Chrome: LCP до 2,5 с, INP до 200 мс, CLS до 0,1. Если трафика мало и замеров у посетителей нет, так и пишем. В отчёт: статус каждого показателя для телефонов и компьютеров.
15.2 Тестовые замеры по типам страниц все	Прогоняем Lighthouse в мобильном профиле и WebPageTest, который показывает порядок загрузки файлов и кадры появления страницы. Проверяем главную, раздел, карточку товара, статью и корзину, затем повторяем заход, когда файлы уже сохранены в кэше браузера.	Нет одной очевидной причины, которая тормозит всю страницу, например огромного баннера, чата, скрипт которого стоит в начале страницы и задерживает её показ, или отсутствия кэша для картинок, стилей и скриптов. В отчёт: водопад загрузки самого медленного типа страницы (схема, какой файл за каким грузится и что задерживает остальные) и те рекомендации Lighthouse, которые дают заметный выигрыш.
15.3 Вес и формат картинок и видео все	Через Lighthouse и вкладку Network в браузере, где виден список всего, что скачала страница, ищем фотографии в JPEG по несколько мегабайт, картинки без современных форматов и без размеров под экран, видео, которое без необходимости запускается само.	Первый экран, то есть часть страницы, видимая без прокрутки, не ждёт загрузки файла в несколько мегабайт. В отчёт: список самых тяжёлых файлов.
15.4 Кэширование и сжатие файлов все	По заголовкам ответа сервера, в redbot и WebPageTest проверяем, что стили, скрипты, шрифты и картинки отдаются сжатыми и с долгим сроком хранения в кэше браузера. Отдельно смотрим, чтобы страницы с личными данными посетителя не попадали в общий кэш, откуда их могут получить другие люди.	Статичные файлы (картинки, стили, скрипты, шрифты) кэшируются, повторный заход на сайт заметно легче первого. В отчёт: пример заголовков, с которыми сервер отдаёт такие файлы.
15.5 Шрифты все	По вкладке Network и визуально проверяем, сколько начертаний шрифта грузит страница (обычный, жирный, курсив), не задерживает ли её показ файл стилей, не прыгает ли текст при подгрузке шрифта и нет ли лишних запросов шрифтов с чужих доменов.	Текст виден сразу, системным или быстро загружаемым шрифтом, а скачок при подмене шрифта небольшой. В отчёт: число файлов шрифтов.
15.6 Сторонние виджеты все	По водопаду загрузки смотрим, не стоят ли на пути к первому показу страницы чужие скрипты: чат, коллтрекинг, A/B-тесты, рекламные пиксели (короткий код, который отмечает визит для рекламы или статистики).	Виджеты не задерживают первую отрисовку страницы. На страницах, где реклама не идёт, лишних пикселей нет. В отчёт: какие скрипты задерживают отрисовку.
15.7 Скорость в отчётах Метрики и Вебмастера если есть доступ	Смотрим отчёты о скорости в кабинетах и сравниваем их с разовым замером Lighthouse. Кабинет может показывать плохую скорость, даже когда тест одной страницы дал зелёную оценку.	В отчёте приведены оба источника. Если они расходятся, объясняем это выборкой страниц: тест проверял по одной-две страницы каждого типа, а кабинет собирает данные по всем посещённым страницам. В отчёт: цифры из кабинетов.

16Производительность сайта: подробный разбор причин

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

Что делаем. Прогоняем тестовые замеры на всех ключевых типах страниц и сверяем их с Core Web Vitals у реальных посетителей (LCP, загрузка главного блока; INP, отклик на нажатие; CLS, сдвиги вёрстки). Затем проверяем кэш, сжатие и доставку файлов, запросы к базе, фоновые задачи и очередь PHP на сервере. Нагрузочное испытание проводим только в согласованное время и только до заранее названного предела нагрузки.

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

Проверка	Что делаем	Результат
16.1 Core Web Vitals у реальных посетителей	Берём LCP, INP и CLS из Chrome UX Report для всего сайта, отдельно для телефонов и компьютеров.	Статус «хорошо», «нужно улучшить» или «плохо» по каждому показателю. Если трафика мало и замеров у посетителей нет, так и пишем.
16.2 Скорость у реальных посетителей в Search Console	Смотрим отчёт Core Web Vitals по группам похожих страниц, а не только по главной.	Группы страниц с плохими показателями и примеры адресов из каждой группы.
16.3 Скорость в Метрике и Вебмастере	Берём время загрузки и отказы из тех кабинетов, где уже накоплены данные о реальных посетителях.	Цифры кабинетов стоят рядом с результатом разового теста, расхождение между ними объяснено.
16.4 Тестовые замеры по типам страниц	Прогоняем Lighthouse в мобильном и десктопном профиле на главной, разделе, карточке товара, статье, поиске, фильтре, корзине, оформлении заказа, в личном кабинете и на странице контактов.	Оценки Lighthouse и главные рекомендации по каждому типу страницы.
16.5 Водопад и кадры загрузки	В WebPageTest снимаем первый заход и повторный, когда файлы уже лежат в кэше, и записываем покадровую плёнку отрисовки. Тип соединения и регион замера выбираем близкими к тем, что у реальных посетителей.	На какой секунде на экране появляется содержательная часть страницы и какой файл её задерживает.
16.6 TTFB	Измеряем TTFB, время до первого байта, то есть сколько сервер думает, прежде чем начать отдавать ответ. Смотрим те же типы страниц, отдельно для самой страницы (HTML) и для картинок, стилей и скриптов.	Типы страниц, где сервер думает дольше примерно 0,8 с, и слой, на котором уходит время: код PHP, база данных или обращение к внешней системе.
16.7 Главный блок страницы, по которому считается LCP	Определяем, что именно на странице является самым крупным элементом: баннер, заголовок, карточка товара или текст, который ждёт свой шрифт.	Файл этого элемента и его вес, не ждёт ли он загрузки скрипта, задан ли ему приоритет загрузки.
16.8 Отклик интерфейса	Ищем длинные задачи, которые надолго занимают браузер и не дают странице реагировать, смотрим INP в тестовых замерах и у реальных посетителей, проверяем код, который срабатывает при нажатии на фильтр, меню и кнопку «В корзину».	Какие действия заметно подвисают и какой скрипт их задерживает.
16.9 Сдвиги вёрстки	Ищем, из-за чего растёт CLS: картинки без заданного размера, подмена шрифтов, баннеры, которые появляются с опозданием, липкие блоки.	Список блоков, которые сдвигаются, с указанием типов страниц.
16.10 Вес и число запросов	Считаем объём и число файлов HTML, стилей CSS, скриптов JS, картинок, шрифтов и обращений к сторонним доменам, отдельно для первого экрана и для всей страницы.	Список самых тяжёлых файлов с размерами.
16.11 Файлы, которые задерживают первую отрисовку	Находим стили и скрипты в начале страницы, без загрузки которых браузер не начинает её показывать.	Список таких файлов и предложение, что перенести в конец страницы или загружать позже.
16.12 Лишний код на странице	По отчёту Lighthouse о покрытии кода на двух-трёх типах страниц ищем скрипты и стили, которые загружаются, но не используются.	Крупные файлы, которые страница почти не использует.
16.13 Изображения	Проверяем формат картинок и их исходный вес в сравнении с размером на экране, есть ли srcset (набор размеров, чтобы телефон не скачивал огромный оригинал) и отложенная загрузка картинок ниже первого экрана (lazy), выделен ли приоритет картинке, по которой считается LCP, и уменьшаются ли картинки на лету в момент запроса.	Картинки, которые можно отдавать легче без изменения макета.
16.14 Шрифты	Считаем файлы и начертания шрифтов, проверяем настройку font-display (показывать ли текст сразу запасным шрифтом, пока грузится основной), скачок текста при подмене шрифта и загрузку шрифтов с чужого домена.	Сколько шрифтов действительно нужно для первого экрана.
16.15 Сторонние виджеты	Проверяем, не задерживают ли показ страницы чат, коллтрекинг, пиксели, A/B-тесты, карты и видео.	Сколько задержки даёт каждый виджет и откуда он подключается.
16.16 Протокол, сжатие, кэш	Проверяем, работает ли сайт по HTTP/2 или HTTP/3 (современные быстрые способы передачи данных), сжимаются ли файлы через brotli или gzip, в том числе сама страница HTML, и с какими заголовками Cache-Control и ETag отдаются статичные файлы. Эти заголовки подсказывают браузеру, можно ли не скачивать файл заново.	Заголовки, с которыми рабочий сайт отдаёт статичные файлы и HTML. Повторный заход легче первого.
16.17 Сколько времени отнимают перенаправления	Считаем, через сколько автоматических перенаправлений проходит посетитель, прежде чем получит страницу: с http, с www на адрес без www или обратно, со слэшем в конце адреса и без него, с рекламными метками.	Лишние перенаправления, которые откладывают начало ответа сервера и увеличивают TTFB.
16.18 CDN и отдельный домен для статичных файлов	Проверяем, отдаются ли статичные файлы через CDN (сеть серверов, которая отдаёт картинки и скрипты ближе к посетителю), не уходит ли вместе с запросами к ним кука сессии (метка, по которой сайт помнит, что посетитель вошёл или что лежит в корзине), не мешает ли кэшированию то, что всё идёт с одного домена.	Схема доставки: HTML идёт с основного сервера, статичные файлы из кэша, кука сессии не мешает кэшированию.
16.19 Кэш Битрикса и композитный режим	Проверяем, включён ли композитный режим (готовая копия страницы для гостей, которые не вошли в личный кабинет), работают ли кэш компонентов и управляемый кэш. Страницы с личными данными не должны попадать в общий кэш.	Где кэш работает, где каждое открытие страницы собирает её заново и где кэш опасен, потому что может показать посетителю чужие данные.
16.20 Агенты Битрикса при открытии страниц	Проверяем, где выполняются тяжёлые агенты Битрикса (фоновые задачи вроде рассылки или пересчёта): во время открытия страниц посетителями или по расписанию на сервере (cron).	Список агентов, из-за которых обычный просмотр страницы становится дольше.
16.21 OPcache	Проверяем, включён ли OPcache (память, где код PHP хранится уже разобранным, чтобы не разбирать его при каждом запросе), хватает ли ему памяти, какая доля обращений попадает в него и не переполняется ли он.	Цифры OPcache и вывод, не тормозит ли его настройка работу PHP.
16.22 Запросы к базе по типам страниц	На главной, в разделе и в карточке товара считаем число SQL-запросов к базе и их суммарное время. На рабочем сайте делаем это так, чтобы ошибки не показывались посетителям: на копии сайта или штатным монитором производительности.	Типы страниц, которые делают сотни запросов, и самые долгие запросы.
16.23 Журнал медленных запросов базы	Разбираем запросы дольше 1 секунды, временные таблицы, которые база строит на лету и которые на больших списках работают медленно, неудобную сортировку результата (filesort), отсутствующие индексы, ускоряющие поиск в базе, и блокировки.	Список самых тяжёлых запросов в обобщённом виде, без конкретных значений и без выгрузки персональных данных посетителей.
16.24 Память базы и кэш данных	Смотрим, какая доля данных читается из буфера InnoDB (памяти базы) без обращения к диску, какого размера рабочие таблицы и не выбрасывают ли Redis или Memcached (быстрые хранилища временных данных) старые записи из-за нехватки места.	Упирается ли база в скорость диска и хватает ли памяти для кэша.
16.25 Поиск, фильтр, корзина	Отдельно измеряем поиск, подбор товаров в фильтре по нескольким параметрам, пересчёт корзины и шаг выбора доставки. Эти страницы работают иначе, чем главная, и по её скорости о них судить нельзя.	Время этих действий и слой, на котором оно уходит.
16.26 Обращения к внешним системам во время открытия страницы	Ищем запросы за остатками, к 1С, платёжной системе, сервису рекомендаций и геокодеру, если они выполняются, пока посетитель ждёт страницу.	Список обращений, которые нужно вынести из процесса показа страницы.
16.27 Очередь PHP	Смотрим php-fpm, службу, которая выполняет код сайта: сколько процессов занято, есть ли очередь запросов, какой задан предел одновременных обработок (max_children), были ли перезапуски из-за нехватки памяти.	Хватает ли рабочих процессов в обычный час и в час пик.
16.28 Первое открытие без кэша	На копии сайта или в спокойное время делаем один контрольный замер после согласованного сброса кэша. Так видно, как сайт встречает первую волну посетителей, пока готовых копий страниц ещё нет.	Время загрузки страницы без кэша в сравнении с прогретой.
16.29 Нагрузочное испытание	Проводим только в письменно согласованное время и до согласованного предела. Ступенями увеличиваем число одновременных посетителей на главной, в разделе и в карточке товара. Останавливаемся, если растут ошибки, очередь php-fpm, нагрузка на диск или TTFB выходит за порог.	Предельная нагрузка, при которой сайт ещё отвечает, и то, во что он упирается первым.
16.30 Восстановление после нагрузки	После остановки нагрузки измеряем, за какое время TTFB, число ошибок и загрузка процессора сервера возвращаются к обычным значениям.	Время восстановления и остались ли незавершённые задачи в очереди и в базе.
16.31 Профилирование кода, если инструмент уже установлен	Если на сервере уже есть xhprof, Tideways или Blackfire (инструменты, которые показывают, какая часть кода отнимает время), снимаем ими один самый медленный тип страницы. Новые инструменты на сервер без согласования не ставим.	Функции, которые отнимают больше всего времени, если профилирование доступно.

17Мобильная версия

Мобильную версию проверяем вручную: открываем сайт на нескольких ширинах экрана и делаем разовый тестовый замер в Lighthouse.

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

Результат. Известно, на каких ширинах телефона сценарий ещё проходит, поломки сняты на скриншоты.

Проверка	Что делаем	Результат
17.1 Ширины экрана все	В режиме устройств браузера Chrome, а при необходимости в BrowserStack (сервис с настоящими телефонами и браузерами для проверки) открываем сайт на ширинах 320, 390, 768 и 1280 px. Ищем горизонтальную прокрутку, обрезанные кнопки, наложение блоков друг на друга и поломки меню.	На ширине телефона у страницы нет горизонтальной прокрутки, основные действия доступны большим пальцем. В отчёт: ширина, на которой вёрстка сломалась, и скриншот.
17.2 Viewport и размер текста все	По исходному коду и Lighthouse (проверка страницы в браузере: скорость, удобство, базовые требования поиска) смотрим мета-тег viewport, который задаёт, как страница вписывается в ширину экрана телефона. Ищем мелкий текст и кнопки или ссылки, расположенные ближе 8 мм друг к другу.	Viewport настроен правильно, текст читается без увеличения, соседние ссылки не сливаются. В отчёт: замечания Lighthouse по мобильной версии.
17.3 Телефон и формы все	Проверяем, что номер телефона оформлен ссылкой tel:, у полей телефона и email указан соответствующий тип, а баннер cookie (пометок, которые сайт сохраняет в браузере) не закрывает кнопку отправки формы.	Позвонить и отправить форму можно одной рукой, баннер cookie не перекрывает экран без возможности его закрыть. В отчёт: что мешает.
17.4 Блоки поверх страницы все	Проходим сценарий на телефоне и смотрим, не закрывает ли липкая шапка (она остаётся на экране при прокрутке) заголовок, не перекрывает ли окно чата корзину, не прячет ли экранная клавиатура поле ввода.	В сценарии заявки и покупки ни один закреплённый блок не закрывает то, что человек сейчас делает. В отчёт: какой блок мешает.

18Доступность для людей с ограничениями

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

Что делаем. Проверяем основные типы страниц сервисом WAVE или axe, проходим сценарий заявки клавиатурой без мыши, сверяем язык страницы и заголовки вкладок. Если на сайте есть видео или аудио, проверяем субтитры и автозапуск.

Результат. Ошибки доступности по типам страниц и результат прохода сайта с клавиатуры.

Проверка	Что делаем	Результат
18.1 Автоматическая проверка типов страниц все	Сервисом WAVE или axe проверяем выборку страниц: по одной-две страницы каждого типа. Ищем недостаточный контраст текста с фоном, пустые ссылки и кнопки, картинки без alt (текстового описания картинки), поля без подписи, ошибки в ARIA-атрибутах (подсказках для программ чтения с экрана) и неверно указанный язык страницы.	На основных типах страниц нет серьёзных ошибок, или каждая такая ошибка заведена как дефект. В отчёт: число ошибок по типам страниц.
18.2 Клавиатура все	Клавишей Tab проходим главную, меню, форму и корзину. Проверяем, что видно, где сейчас фокус, порядок перехода логичный, из открытого всплывающего окна фокус не уходит на страницу под ним, а из меню можно выйти.	Сценарий заявки проходится без мыши. В отчёт: где теряется фокус.
18.3 Язык и заголовок окна все	Проверяем атрибут html lang (язык страницы) и title (текст во вкладке браузера и в строке поисковой выдачи). Язык документа должен совпадать с языком текста. Заголовок вкладки у каждой страницы свой, чтобы программа чтения с экрана различала страницы так же, как поиск.	Атрибут lang задан верно. В отчёт: значение lang.
18.4 Видео и аудио если есть видео и аудио	Проверяем плеер: у роликов с речью есть субтитры, видео с автозапуском можно поставить на паузу, в роликах нет мигания с опасной частотой.	Ролик с речью можно понять без звука, или субтитры сознательно не делали и это записано как отложенная доработка. В отчёт: ролики без субтитров.

19Рабочие сценарии: заявка, каталог, корзина, заказ и оплата

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

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

Результат. Протокол проверки заявки, поиска, каталога, корзины и оплаты в той части, которую разрешено проверять.

Проверка	Что делаем	Результат
19.1 Форма заявки если есть форма	Вручную отправляем форму и смотрим почту и Метрику. Пробуем правильную заявку, пустую отправку, неверный email и телефон, длинный текст и двойной клик по кнопке отправки.	Правильно заполненная заявка доходит до почтового ящика, а человек видит сообщение об успехе. При ошибке заполнения сайт объясняет её рядом с полем. Двойной клик не создаёт две заявки. В отчёт: куда пришло письмо, текст сообщения об успехе и пробелы в проверке полей.
19.2 Согласие на форме форма с персональными данными (имя, телефон, почта, адрес)	Проверяем, что согласие вынесено отдельно, рядом есть ссылка на политику, галочка не проставлена заранее без ведома человека. Пробуем отправить форму без согласия.	Отправить персональные данные без согласия нельзя. Текст согласия конкретный. В отчёт: как устроено согласие.
19.3 Регистрация и вход если есть кабинет	Вручную проходим регистрацию, вход, вход с неверным паролем, восстановление пароля, выход и повторный вход.	Письмо для восстановления пароля доходит, ссылка в нём работает. После выхода следующий человек за тем же компьютером не может открыть кабинет с чужими данными кнопкой «Назад», по крайней мере в пределах той же сессии браузера. В отчёт: результат по каждому шагу.
19.4 Каталог и фильтр каталог	Вручную пробуем один фильтр, сочетание фильтров, сброс, сортировку, сочетание без товаров и кнопку «Назад». Следим, как при этом меняется адрес страницы.	По списку понятно, какие фильтры применены. Сочетания фильтров без необходимости не создают адреса, открытые для индексации. Если товаров не нашлось, сайт так и пишет. В отчёт: пример адреса страницы с фильтром и попадает ли он в поиск.
19.5 Корзина магазин	Вручную добавляем товар, меняем количество, удаляем товар и проверяем пересчёт. Вводим верный и неверный промокод, пробуем товар, которого нет в наличии, и корзину из двух товаров.	Сумма совпадает с ценой в карточке и стоимостью доставки. Удалённый товар действительно исчезает из корзины. Неверный промокод не обнуляет цену. В отчёт: расхождения в суммах.
19.6 Оформление заказа магазин	Делаем тестовый заказ там, где это разрешено, как гость и как зарегистрированный пользователь. Проверяем обязательные поля, выбор доставки и оплаты, комментарий, согласие и страницу успешного заказа.	Заказ появляется в админке и приходит письмом. Сумма, состав и контакты указаны верно. Если оплата не прошла, человек видит объяснение, а заказ не пропадает без следа. В отчёт: номер тестового заказа и что с ним сделать после аудита.
19.7 Оплата магазин с онлайн-оплатой	Проверяем путь оплаты, по возможности на тестовом терминале: переход на страницу платёжного сервиса, возврат на сайт после успешной и после отклонённой оплаты, письмо и статус заказа.	После успешной и после отклонённой оплаты человек возвращается на сайт и видит понятный статус. Повторная оплата не создаёт лишний второй заказ. В отчёт: какие варианты оплаты реально прошли.
19.8 Заказы в личном кабинете магазин	В личном кабинете смотрим состав и статус заказа, повтор заказа и сохранённые адреса.	Человек видит свой заказ и не видит чужой. В отчёт: результат проверки, при которой мы подставляем в адрес страницы номер чужого заказа (такой заказ открываться не должен).
19.9 Несколько сайтов или языков если есть	Проверяем переключатель языка или города: остаётся ли человек на той же странице или его всегда отправляет на главную, меняются ли валюта и контакты города.	Переключатель ведёт на ту же страницу (товар, раздел) на другом языке или для другого города, если такая страница есть. В отчёт: куда ведёт переключатель.
19.10 Избранное, сравнение, отзыв если есть	Вручную добавляем товары в избранное и сравнение, обновляем страницу, отправляем отзыв и смотрим, как он проходит модерацию.	Избранное и сравнение не сбрасываются без причины. Если на сайте заявлена модерация, отзыв не публикуется в обход неё. В отчёт: что сломалось.

20Аналитика

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

Что делаем. Проверяем, что счётчик Метрики стоит на всех типах страниц ровно один раз, а цели и данные электронной коммерции срабатывают на тестовой заявке и тестовом заказе. Смотрим, не записывает ли Вебвизор секретные поля и какие теги загружаются до согласия на cookie. Сверяем цифры Метрики, GA4 и CRM за один день.

Результат. Номер счётчика, список сработавших целей и расхождения между системами аналитики.

Проверка	Что делаем	Результат
20.1 Один счётчик на всех типах страниц все	По Метрике, исходному коду выборки страниц и Tag Assistant (инструмент Google, который показывает, какие счётчики срабатывают на странице) ищем ошибки установки: счётчика нет, стоит чужой номер, стоят два счётчика, счётчик есть только на главной или его нет на странице успешного заказа.	Рабочий счётчик стоит на всех публичных типах страниц один раз. В отчёт: номер счётчика и страницы, где его нет.
20.2 Цели все	В Метрике и GA4 проверяем цели на тестовой заявке: отправку формы, клик по телефону и почте, успешный заказ, начало оформления.	Тестовое действие видно в отчёте по цели. Цель срабатывает на успешное действие, а не на каждый показ кнопки. В отчёт: какие цели сработали.
20.3 Электронная коммерция (передача в статистику состава и суммы заказа) магазин	В отладчике dataLayer (списка событий, которые сайт передаёт в статистику) или в отчёте Метрики смотрим события просмотра товара, корзины и покупки: идентификатор товара, цену, количество. Покупка должна передаваться один раз.	Покупка уходит в статистику один раз и с той же суммой, что в заказе. В отчёт: события тестового заказа.
20.4 Вебвизор и персональные данные если Вебвизор включён	В настройках Метрики и на полях форм проверяем, не записывает ли Вебвизор (запись действий посетителя в Метрике) пароли, данные банковской карты и паспорта.	Поля с секретными данными исключены из записи. В отчёт: какие поля исключены.
20.5 Согласие и теги все	В режиме инкогнито, до клика по баннеру cookie (пометок, которые сайт сохраняет в браузере), с помощью Blacklight смотрим, какие рекламные пиксели (коды рекламы и статистики, которые отмечают визит) и идентификаторы загружаются до согласия.	До согласия сайт не ставит маркетинговые cookie, технически необходимые остаются. После отказа лишние теги больше не работают. В отчёт: список запросов, которые уходят до согласия.
20.6 Расхождение систем если систем несколько	Сравниваем число заявок за один и тот же день в Метрике, GA4 и CRM (программе, где хранятся заявки и клиенты). Смотрим, совпадает ли порядок цифр.	Расхождение объяснено, например разными определениями цели, и не вызвано двойным счётом. В отчёт: цифры за один день.

21Персональные данные и обязательные страницы

Для российского сайта это обычная часть аудита, её не откладывают на потом для юриста. Мы проверяем, есть ли нужные документы и формулировки и связаны ли они между собой, но юридическую консультацию не заменяем. Отдельно сверяем сайт с 152-ФЗ (закон о персональных данных: согласие, политика, cookie) и 168-ФЗ (с 1 марта 2026 года информация для покупателя — частного лица должна быть на русском языке). Это сверка экранов и документов, а не заключение юриста.

Что делаем. Проверяем политику конфиденциальности, согласия на обработку данных и на рекламу, баннер cookie и то, какие cookie ставятся до согласия. Сверяем реквизиты продавца и документы магазина, ищем оператора в реестре Роскомнадзора, выясняем страну сервера. Смотрим язык экранов для покупателя, пометки рекламы, правила рекомендаций и отзывов, чек после оплаты.

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

Проверка	Что делаем	Результат
21.1 Политика конфиденциальности все	Проверяем ссылки на политику в подвале сайта и у форм. Страница политики открывается и описывает оператора, цели обработки, состав данных и сроки.	Ссылка на политику есть в подвале и рядом с формой. Текст не скопирован с чужого сайта с другим юрлицом. В отчёт: адрес страницы политики и совпадает ли оператор с реквизитами на сайте.
21.2 Согласие на обработку формы	Смотрим формы заявки, регистрации, подписки и заказа. Если сайт придерживается практики явного согласия, у формы есть отдельная галочка, а согласие не спрятано во фразу «отправляя форму, вы соглашаетесь» без выбора.	У каждой формы, которая собирает данные, есть явное действие для согласия и ссылка на документ. В отчёт: формы без согласия.
21.3 Cookie все	Заходим на сайт первый раз в чистом профиле браузера и смотрим баннер cookie (пометок, которые сайт сохраняет в браузере): отказаться так же легко, как согласиться, и как баннер показывается повторно.	Посетитель может сделать выбор. Отказ не закрывает доступ к сайту. Технические cookie сессии, которые помнят вход и корзину, отделены от рекламных. В отчёт: скриншот баннера и поведение сайта при отказе.
21.4 Документы магазина магазин	В подвале сайта ищем оферту (условия покупки, которые клиент принимает, оформляя заказ) или договор, условия доставки и оплаты, возврата и обмена, реквизиты.	Документы открываются и относятся к этому продавцу. В отчёт: каких документов нет.
21.5 Рекламные рассылки если есть подписка	Смотрим форму подписки и само письмо: согласие на рассылку отделено от заказа, в письме есть ссылка для отписки.	В письме есть работающая ссылка для отписки. Заказ товара сам по себе не подписывает на рассылку. В отчёт: как устроена отписка.
21.6 Cookie до нажатия «согласен» все	В чистом окне браузера, до клика по баннеру, смотрим, какие cookie сайт уже поставил. Технические cookie входа и корзины могут стоять сразу, cookie статистики и рекламы должны появляться только после согласия. Проверяем, что кнопки «согласен» и «отказаться» одинаково доступны, отказ не закрывает сайт, а текст баннера написан на русском.	Список cookie, которые стоят до согласия. Можно ли отказаться и продолжить пользоваться сайтом.
21.7 Текст согласия на форме каждая форма, где просят имя, телефон или почту	По 152-ФЗ у формы есть отдельная галочка согласия, и она не проставлена заранее. Рядом указано, кто собирает данные, зачем, какие сведения, на какой срок и как отозвать согласие. Ссылка на политику открывается. Одной фразы «отправляя форму, вы соглашаетесь» без галочки недостаточно.	Список форм без галочки, с заранее проставленной галочкой или с пустым текстом согласия.
21.8 Что написано в политике все	Проверяем, что политика называет оператора (организацию, которая собирает данные), его ИНН и адрес, цели, состав данных, срок хранения, кому передаются данные (оплата, доставка, статистика), как человек может запросить или удалить свои данные и куда для этого писать.	Каких обязательных частей в тексте не хватает. Совпадает ли название организации с реквизитами в подвале сайта.
21.9 Реестр Роскомнадзора все	По ИНН организации ищем её в открытом реестре операторов персональных данных на сайте Роскомнадзора. Это справка о том, уведомлял ли оператор ведомство. Проверкой всех документов она не является.	Запись в открытом реестре есть или её нет. Если запись есть, указываем её дату.
21.10 Где хранятся данные людей из России если есть доступ к серверу или известно, где хостинг	152-ФЗ требует хранить персональные данные граждан России в базах на территории России. Фиксируем, в какой стране находится сервер сайта и уходят ли данные в зарубежные сервисы статистики и оплаты. Юридическую оценку зарубежных сервисов формулируем как вопрос, а не как окончательный вывод.	Страна сервера и список зарубежных сервисов, которые получают данные посетителей.
21.11 Согласие на рекламу отдельно от заказа если есть рассылка или галочка «хочу акции»	Проверяем, что согласие на обработку данных для заявки или заказа и согласие получать рекламу оформлены двумя разными галочками. Заказ сам по себе не подписывает человека на рассылку.	Места, где одна галочка пытается закрыть и заказ, и рекламу.
21.12 Отзыв с именем автора если отзывы публикуются	Если на сайте публикуются имя, фото или город автора отзыва, на показ этих сведений нужно отдельное согласие. Отзывов без имени автора этот пункт не касается.	Как устроена публикация отзывов и есть ли согласие именно на показ данных автора.
21.13 Русский язык для покупателя (168-ФЗ) сайт продаёт товары или услуги людям, а не только компаниям	168-ФЗ (закон от 24 июня 2025 года, для сайтов действует с 1 марта 2026 года) требует, чтобы информация для покупателя — частного лица была на русском языке. Смотрим кнопки, меню, поля форм, сообщения об ошибках, баннер cookie, текст согласия, названия ссылок на политику, описания товаров, условия доставки, оплаты и возврата, письма о заказе. Названия брендов и адрес страницы в строке браузера можно не переводить. Если сайт работает только с компаниями и ИП, так и пишем: на него 168-ФЗ может не распространяться.	Список английских кнопок и фраз на пути покупателя. Отдельно отмечаем, для кого сайт: для частных лиц или только для компаний.
21.14 Кто продавец магазин и сайт услуг для людей	Проверяем, что в подвале сайта или на странице контактов указаны название, ИНН, ОГРН и адрес продавца и что они совпадают с политикой и офертой.	Каких реквизитов не видно на сайте.
21.15 Условия дистанционной покупки магазин и платные услуги	Проверяем, что на сайте указаны цена и из чего она складывается, срок и стоимость доставки, порядок возврата товара или отказа от услуги. Документ относится к этому продавцу и не скопирован у другой компании вместе с её названием.	Каких страниц не хватает и где указано чужое юрлицо.
21.16 Реклама на самом сайте если на сайте есть рекламные блоки или собственные акции, оформленные как реклама	Проверяем, что рекламный блок помечен как реклама, а согласие на рекламные письма берётся отдельно. Смотрим только наличие пометки, рекламные кампании в кабинете не разбираем.	Блоки без пометки «реклама» и рассылка, которая включается вместе с заказом.
21.17 Блок «вам подойдёт» если сайт сам подбирает товары или статьи	Если сайт подбирает товары или статьи по поведению посетителя, проверяем, что на сайте есть понятная ссылка на правила таких рекомендаций.	Есть ли такой блок и есть ли ссылка на правила.
21.18 Комментарии и отзывы посетителей если их можно оставить	Проверяем, что есть правила публикации и что чужой текст не появляется на сайте сразу, если заявлена проверка перед публикацией. Персональные данные в отзывах проверяем в пункте 21.12.	Как публикуется комментарий и где размещены правила.
21.19 Чек после оплаты если на сайте принимают оплату	Если тестовая оплата разрешена, проверяем, пришёл ли человеку чек после неё. Если тестовую оплату не делали, пишем в отчёте, что кассовый чек не проверялся.	Чек пришёл, или этот вариант не проверялся.

22Письма, которые отправляет сайт

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

Что делаем. Отправляем с сайта заявку, регистрацию, заказ и восстановление пароля и смотрим, куда и за какое время приходят письма. Одно тестовое письмо проверяем в mail-tester.com: подписи домена, ссылки, кодировку. В заголовках писем смотрим адрес отправителя и адрес для ответа.

Результат. Известно, куда доходят письма, за какое время и проходят ли они проверку подписей домена.

Проверка	Что делаем	Результат
22.1 Доставка писем формы и магазин	Отправляем заявку, регистрацию, заказ и восстановление пароля. Проверяем ящик заказчика и внешний ящик, включая папку «Спам».	Письмо приходит на указанный ящик за несколько минут и не оседает в спаме. В отчёт: куда пришло письмо и за какое время.
22.2 Качество письма все	Отправляем одно тестовое письмо в mail-tester.com (сервис оценивает, не попадёт ли письмо в спам). Проверяем записи SPF, DKIM и DMARC, тему письма, ссылки на основной адрес сайта по https и нет ли в тексте сбоя кодировки, из-за которого буквы превращаются в непонятные значки.	Проверки подписи проходят. Ссылки ведут на основной адрес рабочего сайта. Текст читается без сбоев кодировки. В отчёт: оценка mail-tester и проваленные пункты.
22.3 От кого и кому все	Смотрим заголовки письма. Адрес отправителя должен быть на домене сайта, а ответ уходить в ящик, который читают сотрудники. Там, где ждут ответа клиента, не должно быть только адреса noreply без другого варианта.	Человек может ответить на письмо, и ответ попадёт к сотрудникам. В отчёт: поля From и Reply-To.

23Внешняя репутация и карточки компании на картах

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

Что делаем. Смотрим ссылки на сайт в Ahrefs, MegaIndex или Вебмастере, сверяем название, адрес и телефон в карточках на картах с сайтом, проверяем ошибки товарных фидов и то, кто стоит первым в выдаче по названию бренда.

Результат. Картина внешних ссылок, данные карточек на картах и ошибки товарных фидов (файлов со списком товаров для рекламы и каталогов площадок).

Проверка	Что делаем	Результат
23.1 Ссылочный профиль если есть доступ к Ahrefs, MegaIndex или Вебмастеру	В отчёте по ссылкам ищем резкий всплеск мусорных анкоров (видимого текста ссылки), ссылки со взломанных сайтов и важные страницы, на которые не ведут ни внутренние, ни внешние ссылки.	Резкого всплеска ссылок или массы спамных анкоров, забитых ключевыми словами, нет, либо такой всплеск описан. В отчёт: объём ссылок и найденные аномалии.
23.2 Название, адрес и телефон (NAP) в карточках локальный бизнес, который ищут в конкретном городе	Сверяем карточки компании в Яндекс Бизнесе и Google Business Profile со страницей контактов: название, адрес, телефон, режим работы, ссылку на сайт. Эти данные должны совпадать везде.	Карточка ведёт на основной адрес сайта по https, и данные в ней совпадают с сайтом. В отчёт: расхождения.
23.3 Товарные фиды магазин с рекламой товаров	В Merchant Center (кабинет Google для товарной рекламы) и в разделе товаров Вебмастера смотрим отклонённые товары, расхождение цены в фиде и на карточке, битые ссылки и отсутствие фида.	Рабочий фид загружается без массовых отклонений. На выборке товаров цена и наличие в фиде совпадают с сайтом. В отчёт: число ошибок фида и примеры.
23.4 Упоминание бренда по возможности	Смотрим выдачу по названию бренда и данные Вебмастера. Проверяем, что по запросу бренда показывается сайт компании, а не агрегатор, дорвей (сайт-приманка для поисковиков) или старый домен.	Первым результатом по точному названию бренда идёт этот сайт или его карточка. В отчёт: кто занимает верх выдачи по запросу бренда.

24Журналы и настройки сервера

Этап выполняем, только если заказчик дал доступ к серверу. Журналы сервера напрямую показывают, какие страницы отдают ошибку 500 (страница не собралась на сервере) и какие запросы к базе работают медленно.

Что делаем. Читаем журналы веб-сервера, PHP (язык, на котором написаны сайт и админка) и Битрикса за неделю и находим медленные запросы к базе. Проверяем, как запускаются фоновые задачи, где лежат резервные копии и не показывает ли сайт ошибки посетителям.

Результат. Список самых частых ошибок из журналов веб-сервера, PHP и базы данных за неделю.

Проверка	Что делаем	Результат
24.1 Журнал веб-сервера если есть доступ	Читаем access log (все обращения к сайту) и error log (ошибки веб-сервера) за 7 дней. Выбираем самые частые 404 (страница не найдена) и 5xx (сбой на сервере), всплески активности ботов и подозрительные POST-запросы к админке.	По каждой частой ошибке понятна причина: ошибка вёрстки, бот или атака. В отчёт: адреса страниц, которые чаще всего отдают 404 и 5xx.
24.2 Журнал PHP и Битрикса Битрикс / PHP	Читаем exception.log (файл, куда Битрикс записывает сбои) и error log PHP. Ищем сбои, которые повторяются на рабочих страницах.	На страницах из выборки (по одной-две страницы каждого типа) нет ошибки, которая повторяется бесконечно. В отчёт: текст повторяющейся ошибки без лишних персональных данных.
24.3 Медленные запросы если есть мониторинг базы данных	Смотрим панель производительности и журнал медленных запросов (slow query log). Ищем запросы к базе, которые тормозят каталог и поиск.	Самые медленные запросы названы. Исправление не входит в аудит, если заказчик заказал только список находок. В отчёт: текст худшего запроса или его отпечаток (запрос без конкретных значений).
24.4 Крон и агенты Битрикс	Смотрим раздел «Проверка системы» и crontab, расписание задач сервера. Агенты в Битриксе — это фоновые задачи сайта, например рассылка или пересчёт. Проверяем, не запускаются ли они при открытии страниц посетителями вместо крона, нет ли просроченных агентов, уходит ли почта и обновляется ли поиск.	Тяжёлые агенты выполняются по расписанию, а не при заходе каждого посетителя. В отчёт: как запускаются агенты.
24.5 Резервные копии если есть доступ	Смотрим админку и папку для копий вне корня сайта. Проверяем дату последней копии и не лежит ли архив в открытой папке /bitrix/backup или в корне сайта.	Свежая копия есть, и скачать её снаружи по прямой ссылке нельзя. В отчёт: дата копии и место хранения.
24.6 Режим отладки Битрикс / PHP	Проверяем настройки и то, что видит посетитель при ошибке: display_errors (показ ошибок PHP прямо на странице), exception_handling (как Битрикс выводит сбои), режим debug и вывод SQL-запросов посетителю.	Посетитель не видит пути к файлам на сервере и запросы к базе. В отчёт: включён ли показ ошибок посетителям.

25Ошибки в коде сайта

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

Что делаем. Читаем журналы PHP и Битрикса, открываем по одной-две страницы каждого типа, проверяем синтаксис своих файлов (ошибка синтаксиса не даёт файлу выполниться) и отдельно смотрим агенты, почту и обмен. Режим отладки для посетителей при этом не включаем.

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

Проверка	Что делаем	Результат
25.1 Журнал PHP	Группируем записи error_log (файл, куда PHP пишет ошибки) за 14 дней по уровням: fatal (код остановился), warning (страница открылась, но код работает неправильно), notice (мелкая оплошность в коде), deprecated (устаревший приём, который сломается в новой версии PHP).	Повторяющиеся ошибки с файлом, строкой и частотой.
25.2 Журнал исключений Битрикса	Смотрим exception.log (файл, куда Битрикс записывает сбои) и журналы модулей за те же 14 дней.	Сбои, которые ломают публичные страницы и агенты.
25.3 Ответ основных типов страниц	Открываем главную, раздел, карточку, поиск, фильтр, корзину, оформление заказа, личный кабинет и формы. Проверяем, что нет белого экрана и кода 500.	Список адресов, где посетитель видит сбой.
25.4 Сообщения посетителю	Проверяем, что display_errors (показ ошибок PHP на странице) выключен, а режим отладки Битрикса не выводит посетителю SQL-запросы и пути к файлам на сервере.	Подтверждение, что ошибка записывается в журнал и не выводится на экран.
25.5 Версия PHP и код	Сверяем версию PHP с приёмами в своих файлах: ищем удалённые функции, устаревшие модификаторы и несовместимые модули.	Риск обновления PHP: что сломается сразу после перехода.
25.6 Синтаксис своих файлов	Запускаем проверку php -l для папки php_interface (свои доработки Битрикса, обновление их не затирает), файла init.php (свои правила, которые сайт читает при каждом открытии страницы), своих компонентов, шаблонов, cron-скриптов (программ, которые сервер запускает по расписанию) и обработчиков событий.	Файлы, которые PHP не может разобрать и выполнить.
25.7 Агенты и cron	Ищем задания, которые завершаются сбоем, и агенты, которые зависли с просроченным временем запуска.	Какие фоновые задачи на деле не выполняются.
25.8 Почтовые события	Ищем ошибки отправки по шаблонам писем и пустые обязательные поля в почтовом событии.	Письма, которые код не может собрать.
25.9 Запросы к базе из кода	Ищем ошибки SQL, обрывы соединения с базой и запросы, которые PHP повторяет сотнями на одной странице.	Тяжёлые и ошибочные запросы с привязкой к типу страницы.
25.10 Подключения файлов	Ищем битые include (подключения файлов), отсутствующие шаблоны компонентов и ссылки на файлы, удалённые при обновлении.	Страницы с сообщением «шаблон не найден» и пустым местом в вёрстке.
25.11 Правки ядра движка	Ищем изменения, внесённые прямо в ядро и модули Битрикса, а не в папки local и php_interface, которые обновление не затирает.	Список правок ядра, которые сотрёт ближайшее обновление.
25.12 Обработчики событий	Смотрим свои обработчики событий, то есть код, который срабатывает при открытии страницы, заказе или отправке письма: OnProlog и OnEpilog (выполняются в начале и в конце каждой страницы), обработчики корзины и заказа. Проверяем, не дают ли они сбой при каждом открытии страницы.	Обработчики, которые ломают обычный просмотр страниц или оформление заказа.
25.13 Обмен и импорт	Если есть обмен с 1С, выгрузки или импорт, читаем их журналы: ищем аварийные остановки и зацикливание.	На каком шаге обмен останавливается.
25.14 Кодировка	Ищем BOM (невидимый символ в начале файла, который ломает вывод), смесь кодировок и нечитаемые символы вместо букв в шаблонах страниц, письмах и выгрузках.	Места, где текст превращается в нечитаемые символы из-за неверной кодировки.
25.15 Вёрстка ключевых страниц	На ключевых типах страниц ищем повторяющиеся id элементов, кнопки внутри кнопок, незакрытые теги и скрипты, которые обращаются к несуществующей функции.	Ошибки разметки, из-за которых съезжает блок или не запускается скрипт.
25.16 Свой код в репозитории	Если заказчик даёт доступ к git, проверяем свои каталоги PHPStan (анализ кода на ошибки без запуска сайта) или аналогичным инструментом и сверяем код рабочего сайта с репозиторием.	Расхождения между рабочим сайтом и репозиторием и ошибки, найденные анализатором.
25.17 Журнал после типового сценария	Отправляем тестовую заявку и, если заказчик разрешил, тестовый заказ, после чего перечитываем журнал: не появилась ли новая ошибка именно на этом пути.	Ошибки, которые не видны при обычном просмотре сайта и появляются только при заказе.

26Ошибки в консоли браузера

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

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

Результат. Журнал ошибок по типам страниц: текст ошибки, файл, строка, повторяется ли она у каждого посетителя и ломает ли кнопку. Рядом список файлов, которые вернули коды 4xx (адрес не найден или доступ закрыт) и 5xx (сбой на сервере).

Проверка	Что делаем	Результат
26.1 Главная	Смотрим консоль и сетевые запросы при первой загрузке и после прокрутки до подвала страницы.	Ошибки и незагруженные файлы на главной.
26.2 Раздел каталога	Открываем раздел и проверяем подгрузку списка товаров, если она есть.	Ошибки в списке товаров и при его подгрузке.
26.3 Карточка	Проверяем галерею, вкладки, наличие и кнопку добавления в корзину или отправки заявки.	Какие ошибки появляются до клика, а какие после.
26.4 Фильтр и сортировка	Применяем один фильтр, комбинацию фильтров и сброс.	Ошибки, после которых фильтр молча не срабатывает.
26.5 Поиск	Проверяем обычный запрос и запрос, по которому ничего не находится.	Ошибки страницы поиска.
26.6 Корзина и оформление	Добавляем товар, меняем количество и проходим шаги доставки и оплаты до того места, где заканчивается тестовый режим.	Ошибки, которые мешают дойти до отправки заказа.
26.7 Форма заявки	Отправляем форму пустой и заполненной.	Ошибки скрипта при проверке полей и ошибки после успешной отправки.
26.8 Личный кабинет	Если кабинет есть, проверяем вход и страницу заказов.	Ошибки кабинета и чужие данные в ответах скриптов, если они видны в сетевых запросах.
26.9 Страница 404	Открываем заведомо несуществующий адрес.	Ошибки посторонних скриптов, которые появляются даже на странице 404.
26.10 Ширина телефона	Открываем главную, карточку и форму в режиме телефона.	Ошибки, которых нет на широком экране.
26.11 До и после согласия на cookie	В чистом профиле браузера смотрим, что скрипты пишут в консоль до клика по баннеру cookie и после него.	Скрипты, которые ломаются, потому что баннер их блокирует, и скрипты, которые запускаются раньше согласия посетителя.
26.12 Сеть	Проверяем загрузку самой страницы, статических файлов (картинок, стилей, скриптов), шрифтов, карт и рекламных пикселей. Ищем коды 4xx и 5xx, превышение времени ожидания, блокировки CORS (правило, которое разрешает или запрещает запросы с чужого сайта) и файлы, которые грузятся по http на странице с https.	Таблица адресов, которые не загрузились.
26.13 Политика безопасности страницы	Если на сайте включена политика CSP (список разрешённых источников скриптов), смотрим её сообщения: что она блокирует.	Блокировки, из-за которых не запускается свой или сторонний скрипт.
26.14 Порядок скриптов	Ищем две копии библиотеки jQuery на одной странице, скрипты, которые загружаются раньше ядра Битрикса, и обращения к объекту до того, как он появился на странице.	Конфликты библиотек, из-за которых перестаёт работать остальной код.
26.15 Виджеты	Проверяем чат, карты, видео и обратный звонок: ошибки в их встроенных окнах и скриптах.	Виджеты, которые засоряют консоль ошибками или не запускаются.
26.16 Метрика и реклама	Ищем ошибки счётчиков, двойную отправку данных и запросы, которые блокирует баннер cookie.	Какие данные аналитики на деле не собираются из-за ошибки скрипта.
26.17 Оплата	Если тестовый режим позволяет, проверяем окно платёжной страницы и возврат на сайт после оплаты.	Ошибки при возврате с оплаты, из-за которых покупатель не видит статус заказа.
26.18 Необработанные сбои промисов	Вместе с обычными ошибками смотрим события unhandledrejection: отложенное действие скрипта (промис) сорвалось, а страница этот сбой не обработала.	Скрытые сбои логики, которые не всегда видны как красная строка обычной ошибки.
26.19 Повтор в другом браузере	Открываем одну ключевую страницу в Firefox.	Ошибки, которые возникают только в одном браузере.

27Состояние сервера, стабильность и отказоустойчивость

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

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

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

Проверка	Что делаем	Результат
27.1 Паспорт	Записываем ОС, веб-сервер, версию PHP, базу данных, кэш, диски, панель управления, где лежит сайт и где база.	Одна страница с описанием того, из чего собран сервер сайта.
27.2 Процессор	За доступный период смотрим нагрузку (load), iowait (процессор простаивает в ожидании диска) и steal (виртуальному серверу недодают процессорное время из-за соседей). Проверяем, не загружают ли процессор впустую cron-задания или обмен.	Часы, когда сервер уже занят ещё до того, как посетители открывают страницы.
27.3 Память	Смотрим оперативную память, swap (запас памяти на диске, при его использовании сайт сильно тормозит), следы OOM в системном журнале (система принудительно закрыла программу из-за нехватки памяти) и рост памяти php-fpm (служба, которая выполняет код сайта).	Закрывала ли система процессы из-за нехватки памяти и растёт ли потребление.
27.4 Диски	По каждому тому смотрим свободное место и inode (лимит числа файлов, он может закончиться при свободных гигабайтах), темп заполнения, ошибки диска, а также RAID (связку дисков на случай поломки одного) и SMART (самодиагностику диска), если они доступны.	Через сколько дней диск заполнится при текущем росте и исправен ли он.
27.5 Время	Проверяем синхронизацию времени и часовые пояса PHP, базы и ОС.	Расхождение во времени, из-за которого сертификаты, задания по расписанию и заказы получают разные даты.
27.6 Лимиты PHP	Проверяем memory_limit (сколько памяти разрешено одной странице), max_execution_time (сколько секунд страница может выполняться, прежде чем её оборвут), лимиты upload и post (размер загружаемого файла и отправляемых данных), realpath cache и display_errors.	Лимиты, которые обрывают обмен, импорт или тяжёлую страницу.
27.7 OPcache на сервере	Смотрим OPcache (память, где хранится уже разобранный код PHP): объём, долю попаданий, перезапуски и хватает ли памяти под весь код.	Цифры по кэшу разобранного кода.
27.8 Пул процессов PHP	Смотрим пул php-fpm (рабочие процессы, которые одновременно собирают страницы): число процессов, очередь, аварийные перезапуски и соответствие настройки pm.max_children (сколько страниц можно обрабатывать одновременно) объёму памяти сервера.	Хватает ли процессов и не настроен ли пул так, что займёт всю память.
27.9 Веб-сервер	Смотрим ошибки nginx или Apache (программ, которые принимают запросы и отдают страницы) за 14 дней, лимиты соединений и таймауты.	Самые частые ошибки 5xx (сбой на сервере) и таймауты.
27.10 База	Смотрим соединения, журнал медленных запросов, взаимные блокировки, размер и рост базы. Если есть реплика (вторая копия базы на другом сервере), проверяем её отставание.	Состояние базы и есть ли её второй экземпляр.
27.11 Кэш данных	Проверяем Redis или Memcached (быстрое хранилище временных данных, которое снижает нагрузку на базу): память, вытеснение старых данных из-за нехватки места, перезапуски и не доступно ли хранилище снаружи.	Кэш работает и закрыт от доступа снаружи.
27.12 Планировщик задач	Проверяем cron и агенты Битрикса (фоновые задачи сайта): когда был последний успешный запуск и какие задания давно не отрабатывали.	Что из запланированного на деле не выполняется.
27.13 Почта сервера	Смотрим очередь исходящей почты, застрявшие письма и место под почту.	Не копится ли очередь писем, из-за которой заявки не доходят.
27.14 Журналы ОС	Проверяем ротацию (автоматическую обрезку и архивацию старых записей) журналов в /var/log и журнала PHP, ищем журналы размером в десятки гигабайт.	Какие журналы раздувают диск.
27.15 Сертификат	Проверяем срок действия сертификата (благодаря ему браузер показывает замок), автопродление и совпадение имён в сертификате с адресами сайта.	Дата окончания и кто отвечает за продление.
27.16 Резервные копии	Проверяем дату последней успешной копии, её состав, место хранения, лежит ли она на том же диске, что и сайт, шифруется ли и у кого есть к ней доступ.	Насколько свежая копия и уцелеет ли она, если этот диск выйдет из строя.
27.17 Пробное восстановление	Если есть отдельная копия или отдельная тестовая копия сайта и согласовано окно, поднимаем сайт из последней резервной копии и проверяем главную и вход в админку. Поверх рабочей базы восстановление не делаем.	Поднимается ли сайт из копии и сколько времени это заняло. Если проверку не проводили, в отчёте пишем, что восстановление не доказано.
27.18 Мониторинг	Проверяем, отслеживаются ли доступность сайта, место на диске, сертификат и очередь PHP и кому приходит оповещение ночью.	Кто узнает о падении сайта и узнает ли вообще.
27.19 Единые точки отказа	Ищем то, что существует в единственном экземпляре: один сервер, один диск, один NS-сервер (он сообщает, куда ведёт имя сайта), резервная копия на том же диске, один человек, у которого есть пароль.	Список узлов, при отказе которых сайт останавливается.
27.20 DNS	Проверяем DNS (систему, которая связывает имя сайта с адресом сервера): два независимых NS-сервера, согласованные записи A и AAAA (адрес сервера в старом и новом формате) и TTL (сколько времени сеть помнит старый адрес) на случай смены адреса.	Можно ли переключить сайт на другой адрес, если площадка недоступна.
27.21 Открытые порты	Проверяем, что снаружи открыты только нужные порты (входы на сервер для сайта, почты, базы и других служб). База, Redis и панель управления не должны быть доступны из интернета без ограничений.	Список лишних открытых портов.
27.22 Пики ошибок	Сопоставляем всплески ошибок 5xx с расписанием обмена, резервного копирования и рекламы.	Совпадают ли сбои с заданием, которое можно перенести на другое время.
27.23 Утечки за несколько дней	Смотрим, растут ли число процессов, соединения с базой и занятое место, пока службы не перезапускают.	Есть ли утечка, которая проходит только после перезапуска.
27.24 Перезапуск служб	Если окно согласовано и перезапуск разрешён, перезапускаем php-fpm и веб-сервер и проверяем, что сайт поднялся. Перезапуск рабочей базы согласуем отдельно и без окна не выполняем.	Сколько секунд сайт не отвечал и поднялся ли он сам.
27.25 Запас до отказа записи	Разбираем, что произойдёт при заполнении диска на 95% с сессиями посетителей (сайт помнит вход и содержимое корзины), заказами, журналами и загрузками.	Какая служба остановится первой и настроено ли оповещение о заполнении.
27.26 Нагрузка и отказ	В том же письменно согласованном окне, что и испытание скорости, доводим нагрузку до согласованного предела и смотрим, замедляется сайт постепенно или падает сразу. Условие остановки испытания записываем до начала.	Как сайт ведёт себя на пределе: показывает ли заглушку «идут работы» с кодом 503 (сайт временно недоступен) или пустой белый экран.
27.27 Возврат в норму	После испытания проверяем главную, карточку, корзину, ошибки в журнале и нагрузку на сервер.	Сайт вернулся к обычной работе, тестовые заказы помечены.
27.28 Дежурство	Выясняем, у кого есть доступ, чтобы поднять сайт вечером и в выходные, и где лежит инструкция.	Может ли заказчик восстановить сайт без разработчика, который его делал.

28Вирусы и полный аудит безопасности

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

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

Результат. Заключение на дату аудита: признаков взлома не найдено или найдены конкретные следы. К нему прилагается реестр уязвимостей по уровням опасности и порядок, в котором их закрывать. Лечение сайта и удаление вредоносного кода оцениваются отдельно.

Проверка	Что делаем	Результат
28.1 Репутация в поиске	Проверяем адрес сайта в Google Safe Browsing (список Google, куда попадают опасные и взломанные сайты), в разделе безопасности Яндекс Вебмастера, в Sucuri SiteCheck и VirusTotal.	Статус сайта на дату проверки со скриншотом.
28.2 Чёрные списки	Проверяем домен и IP-адрес сервера в чёрных списках почтовых сервисов и антивирусов через MXToolbox и аналоги. Из-за попадания в такой список письма уходят в спам, а браузер может предупреждать об опасности.	Попал ли домен или сервер в чёрный список.
28.3 Чужие скрипты	Собираем все внешние домены, с которых загружаются скрипты, на выборке страниц: по одной-две страницы каждого типа. Каждый домен должен быть узнаваем: счётчик, чат, карта, платёжный сервис.	Неизвестные домены и страницы, куда они встроены.
28.4 Снимок страницы	Через urlscan или аналог смотрим, какие переадресации и скрытые запросы выполняет страница и не подменяется ли её содержимое.	Совпадает ли то, что видит сервис проверки, с тем, что видит посетитель.
28.5 Признаки вредоносного кода	Ищем PHP-файлы там, где их быть не должно: в папке загрузок upload, среди картинок, в кэше, в php_interface (папка своих доработок Битрикса) и в шаблонах. Проверяем чужие вставки в index и .htaccess (файл правил веб-сервера) и типичные загрузчики вредоносного кода. Сначала файлы проверяет программа, подозрительные места потом смотрим вручную.	Путь, дата изменения и хэш каждого подозрительного файла. Содержимое в отчёт не вставляем.
28.6 Свежие правки кода	Ищем PHP-файлы, которые недавно менялись вне каталогов своих доработок и не во время обновления движка.	Файлы, которые менялись без понятной причины.
28.7 Целостность ядра	Сверяем ядро (основной код движка, его не правят вручную) и модули с оригинальной поставкой той же версии, насколько это позволяет редакция Битрикса.	Файлы ядра, которые отличаются от поставки.
28.8 Переадресации в настройках	Проверяем .htaccess, правила веб-сервера и шаблон сайта: нет ли внезапной переадресации на чужой адрес, в том числе только для посетителей с телефона или только для поисковых роботов.	Правила переадресации, которых не должно быть на обычном сайте.
28.9 Задания, которые обращаются наружу	Проверяем cron (расписание фоновых задач сервера) и агенты Битрикса (фоновые задачи сайта, например рассылка или пересчёт): не скачивают ли они что-то с чужих адресов и не обращаются ли к ним.	Задания, которые обращаются куда-то, кроме платёжной системы, почты, 1С и известных API (интерфейсов обмена данными между программами).
28.10 Новые администраторы	Проверяем учётные записи с правами администратора и даты их создания, лишних активных сотрудников и демонстрационные логины.	Список администраторов без паролей.
28.11 Штатный сканер	Если сайт на Битриксе, запускаем его сканер безопасности: внутреннюю и внешнюю проверку. Для другого движка используем его собственную проверку и те же внешние сервисы.	Находки сканера по уровням опасности.
28.12 Антивирус на сервере	Если на сервере уже установлен ClamAV, ImunifyAV, AI-Bolit или антивирус хостинга, забираем его последний отчёт. При необходимости обновляем антивирусные базы и запускаем проверку файлов сайта.	Дата последней проверки и число срабатываний. Лечение оценивается отдельно.
28.13 Обновления безопасности	Проверяем ядро движка, модули, PHP и пакеты операционной системы: какие обновления безопасности уже вышли, но не установлены.	Текущие версии и список ожидающих обновлений безопасности.
28.14 Вход в админку	Проверяем адрес входа в админку (закрытую часть, где сотрудники управляют сайтом), капчу или лимит попыток, второй фактор (подтверждение входа не только паролем), ограничение входа по сети и не попала ли страница входа в поиск.	Как защищён вход и видят ли его поисковые роботы.
28.15 SSH и панель управления	Проверяем, как специалисты входят на сервер по SSH и в панель управления: по ключу или по паролю, разрешён ли вход под root (главной учётной записью сервера без ограничений) и у кого ещё есть доступ к командной строке.	Лишние способы войти на сервер.
28.16 База и кэш снаружи	Проверяем, что MySQL, Redis и аналогичные службы не принимают подключения из интернета.	На каком адресе принимает подключения каждая служба.
28.17 Забытые панели	Ищем открытый phpMyAdmin (веб-программа прямого доступа к базе), старые установщики и тестовые скрипты, которые показывают настройки PHP.	Адреса, которые нужно закрыть.
28.18 Права на файлы	Ищем каталоги и файлы, которые может перезаписать любой процесс на сервере, и проверяем, выполняется ли PHP в папке загрузок upload.	Каталоги, где загруженный файл может запуститься как программа.
28.19 Секретные файлы в открытом доступе	Проверяем, не открываются ли по прямому адресу дампы базы, файл .env (в нём хранятся пароли и ключи), копии файлов настроек, ключи и архивы.	Адрес и код ответа. Содержимое секретных файлов в отчёт не кладём.
28.20 Заголовки защиты и cookie	Проверяем заголовки, которыми сервер сообщает браузеру правила безопасности: CSP, HSTS, nosniff, Referrer-Policy, frame-ancestors. У cookie сессии (пометки в браузере, по которой сайт помнит вход и корзину) проверяем флаги Secure, HttpOnly и SameSite.	Каких заголовков и флагов не хватает на рабочем сайте.
28.21 Проактивная защита	Проверяем встроенную защиту Битрикса от типичных атак: фильтр, контроль активности, защиту сессий и журнал вторжений. Смотрим, включены ли они и не отключены ли по сути исключениями.	Что из защиты действительно работает.
28.22 Внешняя защита	Проверяем, стоит ли перед сайтом WAF (фильтр, который отсекает типичные атаки до сервера), защита от DDoS-атак или ограничение числа запросов. Если ничего нет, атаку принимает на себя весь сервер.	Какая защита стоит перед сайтом.
28.23 Журнал атак	Смотрим за последние 14 дней попытки подобрать пароль, срабатывания фильтра и подозрительные отправки данных (POST-запросы) в админку.	Идёт ли подбор пароля прямо сейчас.
28.24 Загрузка файлов	Проверяем формы, через которые посетитель или менеджер загружает файлы: какие типы и размеры разрешены, куда файл сохраняется и может ли он выполниться на сервере.	Можно ли загрузить скрипт в папку, откуда его удастся запустить.
28.25 Чужой заказ и чужой кабинет	Если это позволяет отдельная тестовая копия сайта, входим под своей учётной записью и пробуем открыть чужой заказ или чужой документ, подставив другой номер в адрес.	Подтверждение, что чужие данные открыть нельзя, или конкретный адрес, по которому они открываются.
28.26 Письмо с формы	Проверяем, что текст из полей формы не попадает в служебные заголовки письма и не позволяет добавить скрытых получателей.	Письма с формы уходят только тем адресатам, которые указаны в настройках.
28.27 Пароли и демодоступы	Проверяем требования к паролю администратора, общие учётные записи на нескольких сотрудников, учётные записи вроде admin с известным паролем и тестовые доступы, опубликованные в открытых инструкциях.	Какие доступы нужно сменить. Сами пароли в отчёт не пишем.
28.28 Открытые служебные пути	Проверяем, не открываются ли снаружи папка .git (из неё можно скачать исходный код сайта), резервные копии, списки файлов в каталогах и журналы.	Путь и код ответа.
28.29 Итог по взлому	Сводим результаты проверки репутации, файлов, учётных записей, заданий по расписанию и сканеров в одно заключение.	На дату аудита следов взлома нет или они есть. Если есть, прилагаем перечень следов и список действий на первые сутки.

29Лишние файлы и базы на сервере

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

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

Результат. Реестр лишних файлов и баз с путями и размерами, общий объём в гигабайтах и оценка, что уборка даст диску, скорости и безопасности. Удалять что-либо будем только после отдельного подтверждения по строкам реестра.

Проверка	Что делаем	Результат
29.1 Архивы и дампы в папке сайта	Ищем файлы zip, tar, sql и bak в корне сайта, в папке загрузок upload и в папке резервных копий, если она доступна из интернета.	Путь, размер и можно ли скачать файл по прямому адресу.
29.2 Старые копии сайта	Ищем на том же сервере каталоги old, backup, test, dev и копии сайта с датой в названии.	Какие копии открываются в браузере, а какие только занимают место на диске.
29.3 Демо и черновики	Ищем демонстрационные каталоги, тестовые разделы, текст-заглушку «lorem ipsum» вместо настоящего и чужие стоковые фото, которые попали в поиск.	Адреса, которые видят посетители и поисковики.
29.4 Служебные каталоги в открытом доступе	Проверяем, открываются ли снаружи .git и .svn (служебные папки с историей кода), phpinfo (страница с внутренними настройками PHP), test.php, установщики и старые панели управления.	Код ответа и чем это опасно.
29.5 Кэш картинок и страниц	Смотрим размер и дату resize_cache (папки уменьшенных копий картинок, которая часто сильно разрастается), кэша готовых страниц (композита), управляемого и стекового кэша Битрикса.	Сколько гигабайт кэша можно не хранить постоянно, а при необходимости собрать заново.
29.6 Журналы сайта	Ищем журналы Битрикса, PHP и обмена, которые выросли, потому что старые записи не обрезаются и не архивируются автоматически.	Какие журналы занимают место и за какой период в них накопились записи.
29.7 Папка загрузок	Ищем в upload повторяющиеся файлы, исходники в формате psd и zip, которые посетителю не нужны, временные файлы загрузки, пустые каталоги и чужие резервные копии.	Самые крупные каталоги upload с пояснением, к чему они относятся.
29.8 Файлы сессий	Если сессии посетителей (данные, по которым сайт помнит вход и корзину) хранятся на диске, ищем файлы старше разумного срока.	Сколько места занимают сессии, которые уже не нужны.
29.9 Очередь почты	Ищем письма, которые копятся в очереди и уже не будут доставлены.	Объём застрявшей почты.
29.10 Временные каталоги системы	Проверяем /tmp и /var/tmp: старые архивы, аварийные снимки памяти программ и остатки чужих установок.	Крупные файлы с датой создания.
29.11 Системные журналы и пакеты	Ищем системные журналы, которые не обрезаются, старые версии ядра операционной системы и кэш менеджера пакетов.	Какой объём занимает сама система, а не сайт.
29.12 Журналы базы данных	Ищем бинарные журналы (подробную историю изменений базы, которая быстро занимает диск) без ограничения срока хранения и старые дампы рядом с файлами базы.	Сколько места занимает история изменений базы.
29.13 Дампы в домашних каталогах	Ищем архивы и дампы в домашних каталогах пользователей и в домашней папке root.	Путь и размер. Содержимое дампов не раскрываем.
29.14 Лишние сайты на сервере	Ищем настройки сайтов (виртуальные хосты) и каталоги, которые больше не относятся к рабочему домену.	Сайт, домен и размер. Удаление только по отдельному решению.
29.15 Лишние базы и пользователи баз	Ищем базы с названиями вроде copy, old, test и учётные записи базы, которыми никто не пользуется.	Название базы, размер и работает ли с ней какой-нибудь сайт.
29.16 Старые доступы	Ищем учётные записи FTP (устаревший способ загрузки файлов на сервер), SSH и панели управления, которые остались после прежних подрядчиков.	Учётные записи, которые нужно отключить. Пароли не записываем.
29.17 Снимки памяти и отладочные журналы	Ищем файлы core dump (снимки памяти упавших программ), журналы xdebug (режим подробной отладки PHP, который замедляет рабочий сайт) и отладочный вывод, который пишется в файл при каждом открытии страницы.	Файлы, которые занимают место и могут содержать данные запросов.
29.18 Контейнеры и образы	Если на сервере используется Docker или аналог, ищем остановленные контейнеры, неиспользуемые тома и старые образы.	Что из этого не используется рабочим сайтом.
29.19 Резервная копия на том же диске	Проверяем, не лежит ли резервная копия на том же диске, что и сайт. При поломке диска пропадут и сайт, и копия, поэтому такая копия одновременно занимает место и не защищает от сбоя.	Где лежит копия и единственная ли она.
29.20 Забытые скрипты	Ищем в корне сайта и в публичных папках одноразовые скрипты переноса данных, файлы вроде compare.php и import_old.php.	Скрипт, дата изменения и открывается ли он по прямому адресу.
29.21 Неиспользуемые шаблоны	Ищем старые шаблоны оформления сайта и лендинги, которые не используются на рабочем сайте.	Каталоги, которые можно удалить после подтверждения, что это оформление больше не нужно.
29.22 Почта и вложения на диске	Ищем почтовые ящики и каталоги вложений, которые выросли больше, чем нужно для работы сайта.	Объём и кому принадлежит ящик.
29.23 Итог уборки	Складываем размеры по трём группам: можно удалить, можно удалить после резервной копии, трогать нельзя.	Общий объём в гигабайтах и что уборка даст свободному месту и безопасности.

30Отдельные проверки 1С-Битрикс

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

Что делаем. Запускаем встроенные в Битрикс проверки системы и безопасности, смотрим настройки проактивной защиты, обновлений и пользователей. Проверяем, не попали ли в поиск служебные и демонстрационные разделы, как работает кэш готовых страниц, а для магазина — цены, НДС, оплату и доставку.

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

Проверка	Что делаем	Результат
30.1 Проверка системы Битрикс	Запускаем site_checker.php и смотрим обязательные тесты: права на файлы, базу данных, почту, расширения PHP и сессии.	Все обязательные пункты зелёные. Жёлтые рекомендуемые пункты перечислены в отчёте, а не скрыты. В отчёт: скриншот итога проверки.
30.2 Сканер безопасности Битрикс	Запускаем внутреннее и внешнее сканирование, смотрим критичные и средние находки и дату прошлой проверки.	Критичных угроз, которые никто не разобрал, нет. Внешнее сканирование действительно проверило публичный адрес сайта и не было пропущено из-за неверного адреса сервера в настройках главного модуля. В отчёт: список находок по уровням.
30.3 Проактивная защита Битрикс	Проверяем модуль проактивной защиты (встроенной защиты Битрикса от типичных атак): включён ли фильтр и на каком уровне, защищён ли административный раздел, работают ли контроль активности и журнал событий.	Базовая защита включена, и исключения фильтра не отключают её по сути. В отчёт: что включено.
30.4 Обновления Битрикс	В системе обновлений смотрим версию ядра и есть ли обновления безопасности, которые ждут установки.	Версия записана, доступные обновления безопасности названы. В отчёт: версия главного модуля (main) и список ожидающих обновлений, если они есть.
30.5 Пользователи Битрикс	Просматриваем список пользователей: нет ли учётной записи admin с простым паролем, активных бывших сотрудников, лишних администраторов и демонстрационных логинов.	Администраторов немного, ненужных тестовых учётных записей нет, один общий логин на всех не используется. В отчёт: число администраторов без публикации паролей.
30.6 Публичная структура Битрикс	Проверяем каталог, поиск и инфоблоки (хранилища однотипных записей в Битриксе: товаров, новостей, баннеров). Ищем служебные инфоблоки в поиске и в карте сайта, тестовые разделы «aspro» и демо-контент в индексе поисковиков, а также фасетный индекс (данные для быстрого фильтра каталога по свойствам товара): если он не построен, фильтр не работает.	В индексе поисковиков нет демонстрационных разделов и служебных инфоблоков, поиск по названию товара находит этот товар. В отчёт: примеры адресов демо-страниц, которые попали в индекс.
30.7 Композит и кэш Битрикс	Проверяем настройки композита (готовой копии страницы, которую сайт отдаёт гостям, не собирая её заново) и выборочно открываем страницы. Композит должен работать на страницах для гостей, которые не вошли в кабинет, и не сохранять корзину и личный кабинет как общую страницу.	Личные страницы одного посетителя не показываются другому из общего кэша. В отчёт: на каких страницах включён композит.
30.8 Магазин интернет-магазин на Битриксе	Проверяем типы цен, НДС, склады, единицы измерения, платёжные системы и службы доставки. Ищем типичные ошибки: цена равна нулю из-за неверного типа цены, НДС добавляется сверх цены на витрине, оплата отключена, доставка считается с ошибкой.	Рабочий тип цены совпадает с ценой на витрине. Хотя бы один способ оплаты и одна служба доставки проходят расчёт до конца. В отчёт: какие службы проверены.
30.9 Монитор качества если модуль используется	Смотрим чек-лист монитора качества Битрикса и находим проваленные обязательные тесты.	Список красных тестов приложен к отчёту. Зелёная отметка монитора не заменяет этот аудит. В отчёт: проваленные тесты монитора.

31Увеличение продаж

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

Что делаем. Для магазина и сайта с заявками разбираем, как покупатель доходит до заказа и оплаты: Яндекс Товары и YCP, страницы под задачи покупателя, маркетплейсы, рекламу, CRM и экран руководителя. Выводы делаем по ассортименту и марже конкретного магазина.

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

Проверка	Что делаем	Результат
31.1 Яндекс Товары и кнопка «Купить в 1 клик» магазин	Смотрим кабинет Яндекс Товаров и товарный фид, то есть файл со списком товаров, который магазин передаёт Яндексу. Пометка is_checkout_enabled=true в фиде означает, что товар можно купить кнопкой «Купить в 1 клик». Заказ по этой кнопке приходит только тогда, когда в Товарах подключён YCP (Yandex Commerce Protocol): так Яндекс передаёт заказ в систему магазина. Если пометка стоит, а YCP не подключён, кнопка заказов не приносит.	В отчёт: подключён ли YCP, стоит ли в фиде is_checkout_enabled=true и согласованы ли эти две настройки между собой. Отдельно указываем, появляется ли заказ, в том числе заказ лицензии, в системе магазина (на сайте, в CRM или 1С) сам или его до сих пор переносят вручную.
31.2 Куда попадает заказ из Яндекса если YCP подключён	Проходим путь одного заказа от кнопки до карточки в системе магазина: создался ли заказ, верно ли переданы товар, цена, телефон и статус, ушло ли письмо. Если заказ вручную копируют из кабинета Яндекса в таблицу, отмечаем это как слабое место.	Заказ доходит до системы магазина сам или теряется по дороге. Если теряется, указываем где: в фиде, в YCP, на сайте или в CRM.
31.3 Какие маркетплейсы уже подключены магазин	Составляем список действующих подключений этого магазина: Яндекс Маркет, Ozon, Wildberries, Мегамаркет, Avito, Kaspi и другие. По каждому проверяем, обновляется ли фид или обмен по API, заполнены ли цены и остатки, приходят ли заказы в одну систему и не копятся ли месяцами ошибки в кабинете площадки.	Таблица: площадка, подключена ли, доходят ли заказы, что сломано.
31.4 Какие площадки подходят этому магазину магазин	По ассортименту, средней цене, марже, городу и доставке оцениваем, какая площадка может принести заказы, где расходы на логистику и комиссию оставят магазин без маржи и какую площадку подключать не стоит. Вывод делаем для этого магазина, общий совет «подключите все» не даём.	Площадки разделены на три группы: уже работают, стоит подключить, не подходят (с причиной).
31.5 Какие рекламные каналы запущены магазин и услуги	Смотрим, какая реклама действительно работает: Яндекс Директ и товарные кампании, реклама внутри Маркета, Ozon, Wildberries и Avito, VK, рассылки писем и сообщений, органический поиск. Проверяем, что счётчик и цель настроены на заявку или заказ, а не на любой клик.	Список запущенных каналов и тех, которых нет, хотя для них есть подходящий товар и покупатель.
31.6 Где реклама работает впустую магазин и услуги	Сверяем рекламные каналы с тем, откуда уже приходят деньги. Ищем рекламу товаров с нулевым остатком, кампании без цели «заказ», площадки, подключённые без бюджета, и бюджет, который тратится без фида.	Что работает вхолостую и чего не хватает в первую очередь.
31.7 Есть ли CRM все, где есть заявки или заказы	Выясняем, есть ли CRM, то есть программа, где хранятся заявки и клиенты, а не только почта менеджера. Если есть, называем какая: Битрикс24, RetailCRM, amoCRM, 1С или другая. Проверяем, попадают ли в одну воронку заявки с сайта, звонки, заказы с маркетплейсов и заказы через «Купить в 1 клик».	CRM нет, она заброшена или ею пользуются. Какие источники заявок в неё не попадают.
31.8 Как настроена CRM если CRM есть	Проверяем, понятны ли менеджеру статусы, назначен ли у каждой заявки ответственный, заполнены ли обязательные поля, не создаёт ли один телефон пять карточек-дублей и совпадает ли заказ с сайта с заказом в CRM по сумме и составу.	Список настроек, из-за которых заявки теряются или задваиваются.
31.9 Что уже делается автоматически все, где есть заявки или заказы	Отмечаем, что происходит без участия людей: создание сделки, смена статуса в обе стороны, обновление остатков и цен на площадках, письмо клиенту, трек-номер, задача менеджеру, если заявку не взяли в работу за час.	Короткий список того, что уже автоматизировано.
31.10 Где ошибаются сотрудники все, где есть заявки или заказы	Ищем шаги, которые делают вручную: менеджер переписывает заказ из кабинета площадки, сам меняет остаток, сам помнит, кому перезвонить, сам сверяет цену. Рядом записываем ошибки, которые из-за этого случаются: продали товар, которого нет, забыли сменить статус, два человека взяли один заказ.	Какие ручные шаги убрать первыми, чтобы ошибки сотрудников не стоили магазину заказов.
31.11 Есть ли экран руководителя все	Выясняем, есть ли экран руководителя (дашборд), где собственник сам видит состояние дел и не запрашивает выгрузку у менеджера. Если экран есть, проверяем, видны ли на нём заказы, выручка, отказы, каналы, площадки, реклама и товары с нулевым остатком на складе.	Экрана нет, либо он есть, но цифры на нём не обновляются и по ним нельзя понять, что исправлять.
31.12 Что исправить на экране руководителя если дашборд есть	Ищем цифры, которые искажают картину или не подсказывают, что делать: реклама без заказов, площадка с заказами, но с отрицательной маржой, товары в рекламе при нулевом остатке, заявки без ответа дольше обещанного срока.	Три-пять показателей, которые руководителю стоит смотреть каждую неделю, и что с ними не так сейчас.
31.13 Какие задачи покупателя закрывают товары магазина магазин и услуги	Смотрим, что магазин продаёт на самом деле: товары, работы, монтаж, лицензии. Группируем это по задачам покупателя, а не по разделам каталога. Например, в каталоге есть кондиционеры, а покупатель ищет расчёт нескольких кондиционеров с установкой.	Список задач покупателя, которые магазин уже может решить своими товарами, но для которых может не быть отдельной страницы.
31.14 Какие комплексные предложения из этого следуют магазин и услуги	Из ассортимента собираем комплексные предложения, где покупатель заказывает решение задачи целиком, а не один товар. Для магазина кондиционеров это два разных предложения: расчёт и установка нескольких кондиционеров в частном коттедже и кондиционирование целого здания под ключ, от бюджетного варианта до полного комплекта. У другого магазина список свой: его выводим из его товаров, пример с кондиционерами не переносим.	Перечень комплексных предложений, которые этому магазину логично иметь.
31.15 Есть ли страница под каждое предложение магазин и услуги	Ищем посадочную страницу под каждое предложение, то есть страницу под одну задачу покупателя, на которую приходят из поиска или с рекламы. Это может быть и лендинг, отдельная страница одного предложения. Ищем по задаче, а не по названию модели. Засчитываем страницу, на которой есть расчёт, состав работ и заявка. Карточка одной модели или общий раздел каталога такой страницей не считаются.	По каждому комплексному предложению: страница есть; страница есть, но это каталог моделей; страницы нет.
31.16 Страница рассчитана на объект, а не на один товар если страница нашлась	Проверяем, что на странице виден масштаб задачи: несколько приборов с установкой в частном доме и отдельно целое здание под ключ. На странице указано, что входит в работу, цена или диапазон цен, срок, и есть заявка на расчёт. С карточек товаров есть переход на это предложение, а с предложения — на товары, из которых оно состоит.	Предложение можно рассчитать и заказать, либо страница обещает расчёт, а ведёт в общий каталог.
31.17 Спрос есть, а страницы нет если есть доступы к статистике	Сверяем задачи покупателя с запросами в Вебмастере, Директе и Метрике. Если люди ищут «установка кондиционеров в доме» и «кондиционирование здания под ключ», каталог моделей есть, а своей страницы под эти запросы нет, магазин теряет заказы, которые уже умеет выполнять, но не предлагает на сайте.	Запросы, под которые нет страницы, и три страницы, которые стоит сделать первыми.

32Системы аналитики для экрана руководителя

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

Что делаем. Составляем набор систем под то, откуда к этому бизнесу приходят клиенты, и проверяем, передаёт ли каждая данные на общий экран. Отдельно проверяем, связываются ли клик, звонок, заявка и оплата в одного клиента и возвращаются ли оплаты в рекламные кабинеты.

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

Проверка	Что делаем	Результат
32.1 Какие системы нужны этому бизнесу все, где есть заявки, звонки или заказы	Смотрим, откуда приходят клиенты: сайт, звонок, мессенджер, маркетплейс, офис. Для каждого такого входа нужна система, которая передаёт данные на экран руководителя. Обычный набор: Метрика, рекламные кабинеты, коллтрекинг (подменные номера, по которым видно, с какой рекламы позвонили), CRM, заказы сайта, учёт оплат и себестоимости (часто это 1С), кабинеты маркетплейсов.	Список систем именно этого бизнеса. У каждой отметка: есть и выведена на экран; есть, но работает отдельно; нет.
32.2 Метрика на экране если сайт есть	Проверяем, что номер счётчика на экране совпадает с рабочим счётчиком сайта, а цели и электронная коммерция (передача в статистику состава и суммы заказа) дают те же цифры, что стоят на экране. Установку счётчика на страницах проверяет этап 20, здесь смотрим, что экран берёт визиты именно из этого счётчика.	Экран и сайт используют один счётчик, либо визиты на экране взяты из другого источника.
32.3 Рекламные кабинеты если есть реклама или она нужна	Проверяем, выведены ли расходы и клики Яндекс Директа, VK и рекламы внутри маркетплейсов на экран рядом с заказами. Файл, который выгружают раз в месяц, источником данных для экрана не считаем.	По каждому кабинету: данные на экране, есть только в файле или кабинета нет.
32.4 Звонки если клиенты звонят	Проверяем, есть ли коллтрекинг и попадает ли звонок в ту же воронку, что заявка с формы: с источником, номером и статусом в CRM. Смотрим, хранится ли запись разговора и привязана ли она к заявке.	Звонки видны на экране вместе с источником. Если коллтрекинга нет, на экране видны только заявки с форм.
32.5 CRM и статусы если заявки ведут люди	Проверяем, что экран берёт заявки, заказы, отказы и дубли из CRM. Успешная отправка формы в Метрике оплаченным заказом не считается. Статусы на экране называются так же, как их называет менеджер в работе.	Какие статусы показывает экран и какие есть в CRM, но до экрана не доходят.
32.6 Оплаты и маржа магазин и услуги с оплатой	Проверяем учёт оплат: 1С, эквайринг (приём оплаты картой) или другую систему. Выручка на экране должна сходиться с оплатами. К экрану подключена себестоимость, поэтому на нём видна маржа, то есть сколько остаётся после закупки, работ и комиссии, а не только оборот.	Экран показывает оплаты и маржу, либо только число заказов без денег.
32.7 Маркетплейсы на том же экране если площадки подключены или их пора подключать	Проверяем, стоят ли заказы, комиссии и доставка Яндекс Маркета, Ozon, Wildberries и других площадок этого магазина на экране рядом с заказами сайта. Кабинет площадки, в который заходят раз в неделю, источником данных для экрана не считаем.	Какие площадки уже выведены на экран и какие видны только в своём кабинете.
32.8 Один клиент на всём пути все, где есть реклама или несколько входов	Проверяем, связываются ли клик, звонок, заявка и оплата в одного клиента через UTM-метки (метки в адресе страницы с источником и кампанией), номер визита Метрики и телефон. С этой связки начинается сквозная аналитика: один путь клиента от первого касания до оплаты.	Где связка работает и где путь обрывается: клик есть, а источник в CRM пустой, или оплата не привязана к рекламе.
32.9 Оплаты возвращаются в рекламу если крутится реклама	Проверяем, настроены ли офлайн-конверсии, то есть передача оплат из CRM обратно в Метрику и Директ. Тогда рекламный кабинет видит оплаченные заказы. Если обратно передаётся только факт заявки, реклама обучается на заявках, а не на оплатах.	В Метрику и Директ возвращаются оплаты, только заявки или ничего.
32.10 Сверка одного дня все	Берём вчерашний или другой согласованный день и сравниваем визиты, заявки, заказы и оплаты в Метрике, CRM, учёте и на экране. Для каждого расхождения называем причину: заявку в системах считают по-разному, данные учтены дважды, выгрузка отстаёт.	Цифры одного дня по всем системам и вывод, можно ли верить экрану.
32.11 Чего не хватает именно этому бизнесу все	Список пробелов составляем под модель этого клиента. Пример, который нельзя переносить на другой бизнес без проверки: магазин кондиционеров, который продаёт по звонку и с монтажом. Без коллтрекинга экран не видит звонков. Без учёта работ экран не отличает продажу одной модели от установки нескольких кондиционеров в коттедже и от кондиционирования здания под ключ.	Каких систем нет и какие строки экрана из-за этого нельзя использовать.

33Разбор бизнеса по сквозной аналитике: где теряются заказы и деньги

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

Что делаем. Раскладываем бизнес на воронку, каналы, предложения, деньги и маржу, отдельно смотрим скорость ответа менеджеров. На выходе получается список мест, где теряются заказы и деньги, а не выгрузка визитов.

Результат. Карта бизнеса: какие шаги, каналы и предложения приносят деньги, какие тянут результат вниз и какие три–семь правок сделать первыми.

Проверка	Что делаем	Результат
33.1 Путь до оплаты все, где есть заявки или заказы	Собираем цепочку: источник, визит или звонок, заявка, заказ, оплата, повторная покупка. На каждом переходе проверяем, что событие из предыдущей системы есть в следующей. Считаем только по системам, которые в этапе 32 признаны подключёнными.	Схема пути и места, где он обрывается: заявка есть, а в CRM её нет; заказ есть, а оплаты нет.
33.2 Воронка по шагам все, где есть заявки или заказы	Считаем конверсию, то есть долю людей, которые перешли на следующий шаг: из визита в заявку, из заявки в заказ, из заказа в оплату. Отдельно считаем отказы и дубли.	На каком шаге теряется больше всего людей и денег.
33.3 Каналы все, где есть заявки или заказы	По каждому каналу считаем заявки, оплаты и выручку: Директ, поиск, прямые заходы, рассылки, звонки, каждая площадка. Где есть расходы на рекламу, считаем стоимость заявки и ДРР (долю рекламных расходов): сколько рублей рекламы приходится на рубль выручки.	Какие каналы приносят оплаты, а в каких деньги на рекламу тратятся, но оплат нет.
33.4 Предложения, а не только модели товара магазин и услуги	Считаем по предложениям, которые крупнее карточки товара. Для магазина кондиционеров это продажа одной модели, расчёт установки нескольких кондиционеров в коттедже и здание под ключ. Для другого бизнеса список предложений берём из этапа 31. Каналы сопоставляем с предложениями: откуда приходят за коттеджем, а откуда за одной моделью.	Какие предложения приносят деньги, а какие есть в каталоге, но в оплатах не видны.
33.5 Деньги и маржа если учёт оплат подключён	Считаем выручку, средний чек, себестоимость, маржу и повторные покупки. Канал с большим оборотом и низкой маржой отмечаем отдельно. Если данных о себестоимости нет, маржу не додумываем и ссылаемся на пробел, найденный в этапе 32.	Где у бизнеса большой оборот, а где он действительно зарабатывает.
33.6 Люди, города, скорость ответа если в CRM есть эти поля	Смотрим ответственного, город и время до первого ответа клиенту. Ищем, где заявки зависают и какой менеджер или регион отстаёт. Если таких полей в CRM нет, эту часть разбора не делаем.	Где по цифрам видно, что результат зависит от работы конкретных людей.
33.7 Что исправлять все	Из разбора выбираем три–семь правок: шаг воронки, канал, предложение или недостающая система. Каждую правку подкрепляем цифрой. Общие советы без привязки к шагу и каналу в список не попадают.	Короткий список правок для руководителя и то, что нельзя посчитать, пока не подключена система из этапа 32.

34Оценка модели бизнеса: от идеи до выводов через 14 и 30 дней

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

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

Результат. Одна страница для владельца: сходится ли модель бизнеса, помогает ли ей реализация или мешает, три правки и нужна ли новая идея. Это оценка бизнеса целиком, сайт в ней лишь одна из частей.

Проверка	Что делаем	Результат
34.1 Что это за дело и для кого все	Записываем нишу, то есть конкретных покупателей, которым можно продать десять раз подряд, а не отрасль «для всех». Записываем работу, за которую клиент уже платит, и зачем в этом деле нужен сайт. Если в шапке сайта сразу две разные ниши или обещание «для всех», считаем это слабым местом идеи, даже при большом каталоге.	Одна фраза о деле: кому продаём, какую работу делаем, зачем нужен сайт. Если такую фразу сформулировать не получается, дальше оцениваем витрину без модели бизнеса.
34.2 Предложение на первом экране все	Проверяем, понятно ли за десять секунд на телефоне, что предлагает бизнес: кому, что, почём и когда клиент это получит. В предложении должны быть цена, срок, доставка и способ оплаты. Слова вроде «качественно» и «для всех, кто ценит» за предложение не считаем.	Предложение есть и совпадает с тем, что клиент реально получает. Либо на экране перечислены свойства, а самого предложения нет.
34.3 Что проверяем в этом цикле все	Записываем гипотезу, то есть предположение, которое проверяем цифрами: «если сделаем так, за столько дней увидим такой результат». Записываем и дату, когда цикл проверки заканчивается. Без цифры и даты окончания число визитов не доказывает, что модель работает.	Предположение записано. Если его нет, в отчёте прямо пишем, что модель по цифрам ещё не проверяли.
34.4 Хватит ли у бизнеса ресурсов на идею все	Записываем четыре показателя: средний чек, будут ли повторные покупки, сколько недель бизнес продержится, работая в минус, и кто из людей выполняет обещанное клиенту. Рядом отмечаем склад или свободные слоты записи, доставку за счёт магазина, нужные разрешения, зависимость от одной площадки или одного поставщика.	Цифры сходятся, уже на бумаге получается минус, или чисел нет и модель оценить не по чему.
34.5 Выдерживает ли сайт сравнение с конкурентами магазин и услуги	Открываем 3–5 действующих конкурентов как покупатель. Сравниваем цену, срок, доставку до того же адреса, наличие, гарантию, ответ в рабочее время и комплексное предложение, то есть решение задачи целиком: несколько кондиционеров в коттедже или здание под ключ. Слоганы и оформление главной страницы не сравниваем.	Где этот бизнес выигрывает, где проигрывает, когда покупатель открывает конкурента в соседней вкладке, и видно ли это покупателю на сайте.
34.6 Экономика одной продажи магазин и услуги	Считаем, что остаётся с одной продажи конкретной позиции, а не в среднем по сайту: закупка или время мастера, доставка, которую доплачивает магазин, возвраты этой позиции, комиссия площадки, реклама в пересчёте на оплаты именно этой позиции, работа людей. Отдельно считаем продажу по карточке и комплексное предложение. Опт и розницу в одну маржу не смешиваем.	Позиция в плюсе, в минусе или посчитать нельзя. Если посчитать нельзя, рост визитов может означать рост убытков.
34.7 Бизнес выполняет то, что обещает все	Сверяем предложение с тем, как оно выполняется: остаток, срок, цена в корзине, письмо после заказа, ответ сотрудника, статус заказа. Поломки, найденные в этапах 2–30, здесь сводим в одну оценку того, насколько хорошо реализована модель.	Модель рабочая, но сайт, склад или сотрудники её подводят. Либо обещание выполняется.
34.8 Сайт продаёт решение задачи, а не только товар магазин и услуги	Сверяем с этапом 31. Если из ассортимента следует комплексное предложение (расчёт нескольких кондиционеров в доме, объект под ключ), у этой задачи должна быть своя страница с составом работ и заявкой на расчёт. Карточка одной модели такую страницу не заменяет.	То, что предлагает сайт, совпадает с задачей клиента. Либо в каталоге только отдельные товары, и за решением задачи покупатель уходит к конкуренту.
34.9 Выводы по фактам через 14 и 30 дней если сайт уже принимает заявки или заказы	Через 14 и 30 дней собираем факты: заявки, оплаты, повторные покупки, отказы с причинами. Визиты, лайки и время на сайте в оценку не включаем. За один раз меняем что-то одно: предложение, цену или канал. Новая идея возвращается в начало цепочки, к выбору ниши и предположения для проверки, а не сразу к новому макету.	Что оставить, что усилить за семь дней и какую новую идею проверять, если предположение не подтвердилось.
34.10 Итоговая оценка модели все	Собираем для владельца одну страницу из выводов по идее, ресурсам, конкурентам, экономике одной продажи, реализации и итогам 14 и 30 дней. Технически исправный сайт сам по себе модель бизнеса не спасает.	Один из трёх итогов: модель сходится и реализация её поддерживает; модель сходится, но реализация не выполняет обещание; модель не сходится из-за экономики одной продажи, конкурентов или нехватки ресурсов. К итогу прилагаем три правки.

35Обмены с маркетплейсами и модули заказов

Файл с товарами для площадки (фид) может нормально скачиваться, а заказы и остатки при этом уже расходятся с реальностью. У интернет-магазина часть денег часто приходит через Ozon, Wildberries, Яндекс Маркет и похожие площадки.

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

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

Проверка	Что делаем	Результат
35.1 Карточка и цена на площадке магазин	Берём 5–10 товаров по артикулам (SKU) и сверяем название, цену, НДС и наличие на сайте и на витрине площадки.	Расхождения перечислены по каждому товару. Ответ 200 на ссылку фида без сверки самих товаров подтверждением не считаем.
35.2 Заказ с площадки на сайт магазин с заказами	Берём тестовый или свежий реальный заказ и смотрим, появился ли он в админке или в CRM (системе учёта клиентов и сделок), совпали ли состав, склад и статус.	Путь заказа можно повторить и проверить. Дубли и пустые заказы зафиксированы.
35.3 Остаток после выкупа и отмены магазин	Проверяем остатки, которые после выкупа или отмены должны обнулиться или вернуться (в модулях обмена их называют leftover), на складе с номером 0 и на втором складе. Сравниваем обмен по расписанию и ручной запуск.	Нет нулей, которые висят бесконечно, и нет ложного наличия. Если обмен по расписанию и ручной запуск дают разный результат, это отмечено отдельно.
35.4 Обмен включён и выключен магазин	Проверяем профиль с включённым и с выключенным обменом остатков и заказов. Галочке в настройках не верим, пока не посмотрим журнал этого шага обмена.	Выключенный обмен действительно останавливает шаг. Включённый оставляет понятную запись в журнале.

36Обмен с 1С

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

Что делаем. Выясняем, какая система главная для цены, остатка и заказа. Смотрим журнал обмена, зависшие агенты (фоновые задания Битрикса) и то, что остаётся на сайте, если выгрузка сорвалась.

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

Проверка	Что делаем	Результат
36.1 Главная система для данных все с 1С	По опросу сотрудников и журналу обмена выясняем, где задаются цена, остаток и статус заказа: на сайте, в 1С или вручную в обоих местах.	Есть одна записанная схема. Если данные ведут в двух местах без правил, это находка уровня «существенно».
36.2 Свежесть обмена все с 1С	Смотрим время последней успешной выгрузки и загрузки, ищем просроченные и зависшие агенты.	Определён нормальный для этого бизнеса интервал обмена. Зависшие задания перечислены.
36.3 Поведение после сбоя все с 1С	Проверяем, что видит покупатель, если обмен не прошёл за ночь: старую цену, нулевой остаток или запрет на покупку.	Описано безопасное поведение, при котором сайт не продаёт товар без актуальных данных, либо зафиксирован риск.
36.4 Заказ обратно в 1С магазин	Проверяем, что тестовый заказ доходит до 1С со всеми нужными полями: контрагентом, складом, оплатами.	Заказ попадает в 1С автоматически. Ручной перенос заказа менеджером не остаётся единственным рабочим способом.

37Оплата и доставка: путь заказа до поступления денег

То, что кнопки корзины нажимаются, ещё не значит, что заказ оформлен. Деньги появляются только после оплаты, расчёта доставки и письма или статуса заказа, которым можно доверять.

Что делаем. Проводим тестовую оплату или оплату в песочнице банка (тестовом режиме платёжной системы), проверяем расчёт доставки и выбор пункта выдачи, статусы заказа и письмо «заказ создан».

Результат. Протокол пути от кнопки «оплатить» до записи в списке заказов и письма. Каждое место, где путь обрывается, оформлено отдельной находкой.

Проверка	Что делаем	Результат
37.1 Тестовая оплата магазин	Платим тестовой картой или в песочнице банка. Проверяем успешную оплату, отмену и возврат, если он доступен.	Статус заказа совпадает с платежом. Если платёжная система сообщает об успехе, а заказа в списке нет, это блокер.
37.2 Доставка и пункты выдачи магазин с доставкой	Проверяем расчёт доставки до города, выбор пункта выдачи и самовывоз. Сверяем сумму с правилами доставки магазина.	На последнем шаге покупатель не видит неожиданно нулевую или завышенную стоимость доставки.
37.3 Письмо и статус магазин / заявки	Проверяем письма клиенту и менеджеру и статус заказа в админке после оплаты или заявки.	Клиент получает подтверждение. Менеджер видит заказ в админке, и ему не нужно звонить с вопросом, что произошло на сайте.

38Доставка писем до ящика получателя

Почтовый сервер может принять письмо к отправке, а получатель найдёт его в спаме или не получит вовсе. Этап 22 проверяет отправку писем с сайта, а этот этап — дошло ли письмо до ящика.

Что делаем. Проверяем записи домена SPF, DKIM и DMARC, по которым почтовые службы решают, доверять ли письмам с этого имени. Отправляем тестовые письма и смотрим, куда они попали.

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

Проверка	Что делаем	Результат
38.1 SPF / DKIM / DMARC все	Проверяем DNS-записи и их соответствие серверу, который на самом деле отправляет почту: Битриксу, SMTP-реле или сервису рассылок.	Записи согласованы с реальной отправкой. Если сторонний сервер отправляет письма от имени домена без разрешения в записях, это находка.
38.2 Тест во «Входящие» все	Отправляем письма о регистрации, о заказе и с формы на Gmail, Mail.ru и корпоративную почту заказчика.	Таблица по каждой почтовой службе: письмо во входящих, в спаме или не пришло.
38.3 Служебные письма магазин	Проверяем, что письма менеджеру о заказе и клиенту о статусе не складываются без разбора в один общий ящик вроде info@.	Понятно, кто какие письма получает. Важные письма не оказываются только в спаме у клиента.

39Кэш: видна ли правка посетителю

На сервере уже лежит новая версия, а посетитель и даже проверяющий видят старую. Её может отдавать композит (готовая HTML-копия страницы в Битриксе), CDN (сеть серверов, которая отдаёт файлы ближе к посетителю) или opcache (кэш PHP-кода).

Что делаем. Меняем заметную мелочь: цену, текст или остаток. Сбрасываем кэш или оставляем его, как предписывает регламент заказчика, и сравниваем витрину с админкой и с окном инкогнито.

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

Проверка	Что делаем	Результат
39.1 Правка видна снаружи все	Меняем цену или заголовок. Открываем страницу с параметром сброса кэша и без него, а также с другого устройства.	Зафиксировано, через сколько времени правка стала видна. Если старая страница не обновляется совсем, это блокер.
39.2 Композит и CDN Битрикс / CDN	Выясняем, включён ли композит, кто очищает CDN и есть ли кэш HTML-страниц на nginx.	Карта слоёв кэша и список тех, кто имеет право сбросить его после выкладки.
39.3 Opcache после обновления модуля Битрикс	Проверяем, сбрасывается ли кэш PHP после загрузки новых файлов. Если нет, на запросы продолжает отвечать старый код.	В чек-листе выкладки есть шаг сброса. Без него остаётся риск, что на сервере лежит новый код, а отвечает старый.

40Админка после обновления модуля или ядра

Публичная часть сайта может работать, а в админке кнопка «Сохранить» и вкладки уже не срабатывают. Частая причина: скрипт вкладки падает раньше, чем успевает отрисоваться форма.

Что делаем. После обновления открываем ключевые формы: товар, заказ, профиль обмена, настройки модуля. Нажимаем «Сохранить», переключаем вкладки, смотрим консоль браузера (панель разработчика, где видны ошибки скриптов) и AJAX-запросы, которые страница отправляет без перезагрузки.

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

Проверка	Что делаем	Результат
40.1 Сохранение ключевой формы Битрикс	На форме товара, заказа, профиля экспорта или заказов меняем поле, сохраняем и открываем форму заново.	Значение сохранилось. На экране нет текста ошибки вместо вкладок.
40.2 Вкладки и кнопка «Применить» Битрикс	Переключаем вкладки настроек модуля. Проверяем, что после загрузки скриптов кнопки «Применить» и «Сохранить» остаются на месте.	Все рабочие вкладки открываются. Если JavaScript падает раньше, чем появляются кнопки, это блокер.
40.3 Соседние профили модули обменов	После правки одного профиля проверяем второй профиль того же модуля, профили с включённым и выключенным обменом, запуск по расписанию и вручную.	Правка одного профиля обмена не ломает соседние.

41Роли сотрудников

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

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

Результат. Матрица ролей: задача, роль и отметка, может ли сотрудник сделать её сам, нужен ли администратор или приходится писать подрядчику.

Проверка	Что делаем	Результат
41.1 Цена и наличие магазин	Контент-менеджер под своей учётной записью меняет цену и наличие двух товаров через админку, не трогая файлы шаблона.	Сотрудник справляется без верстальщика. Если нет, в отчёт идёт находка: компания зависит от автора шаблона.
41.2 Заказы и реклама магазин	Проверяем, что менеджер видит заказы, а маркетолог может остановить рекламу по регламенту.	Названы ответственный и его заместитель. Пароль передаётся не только через личный мессенджер.
41.3 Опасные права все	Проверяем, что у контент-менеджера нет лишних прав: правки PHP, загрузки произвольных файлов, полного доступа к базе через SQL.	У каждого сотрудника только те права, которые нужны для работы, либо риск перечислен в отчёте.

42Нагрузка на реальном объёме каталога

Замер PageSpeed одной карточки не показывает, как фильтр, поиск и список товаров работают на реальном количестве товаров в час пик.

Что делаем. Замеряем список товаров, умный фильтр, поиск и карточку на объёме, близком к рабочему каталогу. Если заказчик согласен, проводим короткий нагрузочный тест без сценария атаки (DDoS).

Результат. Время ответа и узкие места на каталоге заказчика, а не на демонстрационном каталоге из 20 товаров.

Проверка	Что делаем	Результат
42.1 Список товаров и фильтр каталог	Берём раздел с большим числом товаров, проверяем 3–5 сочетаний фильтра и сортировку.	Замерено время до первого байта ответа и до отрисовки страницы. Тайм-ауты и ошибки 500 зафиксированы.
42.2 Поиск по каталогу каталог	Проверяем частые и редкие запросы, запросы с опечатками и поиск по артикулу.	Оценка того, насколько выдача подходит под запрос, глазами менеджера и время ответа.
42.3 Пиковая нагрузка по согласию	В согласованное время аккуратно нагружаем витрину запросами на просмотр страниц.	Найден порог, после которого витрина начинает работать хуже. Если время не согласовано, ставим пометку «не проводилось».

43Мониторинг и оповещения

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

Что делаем. Смотрим Zabbix, панель хостинга и сервисы проверки доступности: что отслеживается, кому приходят оповещения, были ли ложные и пропущенные срабатывания.

Результат. Список сигналов, по которым людей действительно поднимают, и пробелы в наблюдении. Типичный пробел: диск заполнен на 100%, а письма об этом никто не получил.

Проверка	Что делаем	Результат
43.1 Доступность и ошибки 5xx все	Проверяем, настроена ли внешняя проверка доступности важных страниц (ping или HTTP-запрос) и оповещение при ошибках 5xx.	Проверка настроена, и оповещение доходит до человека. Если есть только график без оповещения, это слабое место.
43.2 Диск, почта, агенты сервер	Смотрим место на диске, очередь почты, зависшие агенты Битрикса и задания по расписанию (cron).	Пороги и получатели оповещений записаны. Есть история срабатываний за месяц.
43.3 Эскалация все	Выясняем, кто реагирует первым, кто вторым и что делать, если первый в отпуске.	Названы люди и каналы связи. Если оповещения уходят только письмом на info@ и дежурного нет, это находка.

44Учебное восстановление из резервной копии

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

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

Результат. Дата последней проверенной копии и два показателя простыми словами: за сколько времени сайт можно восстановить (RTO) и за какой период данные могут потеряться (RPO).

Проверка	Что делаем	Результат
44.1 Копия свежая и полная все	Проверяем, что в копию попадают и файлы, и база, а не только файлы. Смотрим срок хранения копий и, если нужно, шифрование.	Есть свежая полная копия. Если копия делается только по FTP раз в месяц, для магазина это блокер.
44.2 Учебное восстановление по согласию	Восстанавливаем сайт на тестовой копии или разбираем последнее учение: сколько оно заняло и что перестало работать (почта, оплата, 1С).	Есть протокол учения. Если учения не было, в отчёте риск: восстановление не проверено.
44.3 Зависимости после восстановления все	Составляем чек-лист первого часа после восстановления из резервной копии: DNS, сертификат, оплата, обмены, очереди.	Чек-лист первого часа уже есть у заказчика или составлен во время аудита.

45Сторонние виджеты при отказе

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

Что делаем. Блокируем домен виджета в панели разработчика браузера (DevTools) или иначе имитируем его недоступность и проходим путь от карточки до оплаты или заявки.

Результат. Список виджетов с отметкой, критичен ли каждый, и описание того, что видит покупатель, если виджет не загрузился.

Проверка	Что делаем	Результат
45.1 Чат и консультант все	Отключаем скрипт чата и смотрим, остались ли на странице форма и телефон.	Заявку можно оставить без чата. Если чат единственный способ связаться, это риск.
45.2 Виджет оплаты и карт магазин	Имитируем сбой виджета карты или оплаты и смотрим, есть ли запасной способ или понятное сообщение об ошибке.	Покупатель не видит кнопку, которая ничего не делает. Сообщение об ошибке объясняет, что произошло.
45.3 Трекеры и согласие на cookie все	Отказываемся от cookie и проверяем, что рекламные скрипты не ломают оформление заказа.	Покупка работает, даже если посетитель отказался от необязательных cookie.

46Повторная проверка на следующий день после выкладки

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

Что делаем. Через 12–24 часа после выкладки проходим путь от главной до заказа, проверяем сохранение в админке, обмен и задания по расписанию, письма и кэш.

Результат. Протокол на одной странице с датой выкладки и именем того, кто провёл проверку.

Проверка	Что делаем	Результат
46.1 Путь до заказа магазин / заявки	Проходим путь: главная, карточка, корзина или форма, страница благодарности. Смотрим, чтобы в консоли браузера на этом пути не было ошибок.	Протокол с адресами страниц и временем. Если путь обрывается, это блокер для выкладки.
46.2 Админка и обмен Битрикс	Сохраняем товар или профиль обмена, смотрим журнал ночного обмена по расписанию.	Ночной обмен не завершился ошибкой, которую никто не заметил. Сохранение работает.
46.3 Откат все	Выясняем, известен ли способ вернуть предыдущую версию и у кого есть право это сделать.	Порядок отката описан до выкладки, и его не придумывают в спешке после поломки.

47Внутренний поиск и мягкие 404

Страницы с текстом «такой страницы нет», пустые разделы и поиск, который не находит товар по артикулу, теряют покупателей так же, как обычная ошибка 404.

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

Результат. Список пустых страниц и страниц, которые вводят посетителя в заблуждение, и оценка поиска глазами менеджера.

Проверка	Что делаем	Результат
47.1 Мягкие 404 каталог / разделы	Проверяем пустой фильтр, отключённый раздел и старый адрес, которые отвечают кодом 200 с текстом «ничего не найдено».	Такая страница либо честно отвечает кодом 404 или 410, либо показывает нормальную витрину. Пустую страницу с кодом 200 поисковик принимает за обычную, поэтому она идёт в отчёт как находка.
47.2 Поиск по артикулу и названию каталог	Проверяем запросы, которыми пользуется отдел продаж.	Товар находится. Лишние результаты в выдаче зафиксированы.
47.3 Битые пункты меню все	Проверяем все пункты шапки и подвала на выборке страниц: по одной-две страницы каждого типа.	Ни один пункт основного меню не ведёт на 404.

48Понятны ли тексты сайта читателю

Этап 13 проверяет коммерческие сведения: цену, доставку. Здесь проверяем, понимает ли человек текст, не расшифровывая автора: нет ли обрывочных телеграфных фраз, слоганов и метафор вместо фактов.

Что делаем. Берём главную, 3 карточки, 3 посадочные страницы и 3 статьи. Читаем тексты вслух и проверяем, поймёт ли их коллега с первого раза.

Результат. Список страниц, где смысл спрятан, и примеры того, как их переформулировать. Это не заменяет полноценную контент-стратегию.

Проверка	Что делаем	Результат
48.1 Первый абзац страницы выборка	Читаем первые 2–3 предложения и проверяем, понятна ли ситуация без внутренних терминов компании.	Первый абзац понятен. Если он состоит из коротких фраз-загадок, это находка.
48.2 Слоган вместо смысла выборка	Ищем пары фраз вида «Это не X. Это Y.» и метафоры, рядом с которыми нет факта.	Рядом с метафорой есть факт, или страница попадает в реестр правок.
48.3 Призыв и следующий шаг выборка	Проверяем, понимает ли человек после прочтения, что ему сделать на этой неделе.	На странице есть один понятный следующий шаг. Если его нет, страница только украшает сайт.

49B2B: спрос, дилеры и отложенные сделки

В продажах компаниям (B2B) рост часто сдерживает не нехватка рекламы. Его ограничивают предложение, сайт, работа дилерской сети и то, возвращают ли клиентов, которые отложили решение. Поэтому смотрим весь путь от спроса до выручки, работу с дилерами и возврат разовых клиентов.

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

Результат. Карта потерь в B2B: где заявка дорожает, где дилер не отвечает, где клиентов, отложивших решение, не возвращают.

Проверка	Что делаем	Результат
49.1 Предложение и сайт под запрос B2B	Сверяем посадочные страницы с реальными запросами закупщиков и смотрим, помогает сайт принять решение или мешает.	Список запросов, на которые сайт не отвечает. В выводе отмечаем, что слабый сайт удорожает заявки из любого канала.
49.2 Дилерская сеть B2B с дилерами	Выясняем, как заявка доходит до дилера, кто за неё отвечает, какой срок ответа (SLA) и видит ли завод статусы заявок.	Названо узкое место сети. Если рост планируют только за счёт дополнительной рекламы, не наладив работу сети, это отмечено как риск.
49.3 Отложенный спрос B2B / долгий цикл	По CRM смотрим, кто возвращает клиентов, ответивших «подумаю», через какой канал и есть ли для этого регламент.	Регламент возврата есть, или отмечено, что его нет. Разовых клиентов не списывают как потерянных навсегда, не попытавшись вернуть.
49.4 Контекстная реклама и GEO в B2B B2B с рекламой	Оцениваем, приводит ли кампания подходящих клиентов с учётом длины сделки. Одного того, что кампания запущена и работает, для вывода недостаточно.	Вывод: канал пополняет воронку продаж или только расходует бюджет. Если доступа к кабинету нет, оцениваем по скриншотам или выгрузке.

50ROMI и ROAS: маржа, возвраты и длина сделки

ROAS (выручка, делённая на расход на рекламу) без учёта маржи, логистики и возвратов может показывать успех, когда реклама на деле приносит убыток. ROMI (окупаемость маркетинга с учётом прибыли) в B2B часто считают по когортам за 6–12 месяцев: заявки группируют по месяцу поступления и следят, как окупается каждая группа.

Что делаем. На цифрах заказчика или на модели считаем, сколько денег осталось после себестоимости, логистики, возвратов и отложенных оплат, а не только сколько выручки принесла реклама (например, «привели на 12 млн»). Отделяем продажи, которые реклама себе приписывает (атрибуция), от продаж, которые появились благодаря ей (инкрементальность): часть покупок случилась бы и без этой рекламы.

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

Проверка	Что делаем	Результат
50.1 ROAS без маржи реклама	Берём кампанию с высоким ROAS и вычитаем себестоимость, доставку, возвраты и комиссию площадки.	ROMI посчитан рядом с ROAS. Если при высоком ROAS кампания убыточна, это тревожный признак.
50.2 Когорты 6–12 месяцев B2B	Для сделок с длинным циклом считаем окупаемость по месяцу заявки, а не по оплатам текущего дня.	Период когорт соответствует циклу сделки. Оценку по вчерашним данным помечаем как опасную.
50.3 Атрибуция и реальный прирост реклама	Оцениваем, какая доля приписанных рекламе продаж похожа на покупки, которые случились бы и так: по запросам с названием бренда, повторные, через дилера.	В отчёте есть оговорка. Если все продажи без оговорок приписаны последнему клику, это тревожный признак.
50.4 Тревожные признаки в отчёте маркетинга реклама	Проверяем, учтены ли в модели возвраты, маржа, длина сделки и стоимость денег при отсрочке платежа.	Список тревожных признаков для руководителя и финансового директора, изложенный без жаргона.

51Переезд каталога и структуры без потери спроса

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

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

Результат. Протокол безопасного переезда или список страниц, через которые сайт уже потерял посетителей из поиска.

Проверка	Что делаем	Результат
51.1 Карта старых и новых адресов переезд / крупный каталог	Сравниваем выгрузку старых адресов из Вебмастера или аналитики с новыми. Проверяем, что каждая страница, которая приносит продажи, перенаправлена на свою новую страницу один к одному.	Страницы, которые приносят продажи, не ведут на 404 и не перенаправлены все на одну общую страницу.
51.2 Посадочные страницы под спрос переезд	Проверяем, сохранены ли страницы под частые запросы закупщиков и названия категорий, или от них отказались ради красивого дерева каталога.	Список потерянных посадочных страниц и отметка, учитывали ли SEO при проектировании.
51.3 Первые дни после переезда после запуска	Смотрим, на сколько процентов изменился поисковый трафик, выросло ли число ошибок 404 и нет ли скачка отказов на страницах, которые приносят продажи.	Цифры первых дней. Если трафик просел, а плана отката нет, это находка.

52Рутина продаж: CRM, 1С и время менеджера

Если менеджер по 4 часа в день переключается между чатом, CRM и 1С, у него не остаётся времени на отношения с клиентами. Рутина отнимает время у того, что человек делает лучше любой автоматизации.

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

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

Проверка	Что делаем	Результат
52.1 Двойной ввод B2B / продажи	Ищем поля, которые вручную вводят дважды: на сайте, в CRM и в 1С.	Карта двойного ввода и оценка, сколько часов в неделю на него уходит.
52.2 Скорость ответа на заявку продажи	Замеряем время от заявки или звонка до первого ответа по существу.	Фактическое время сравнено с обещанием на сайте. Регламент есть, или отмечено, что его нет.
52.3 Подготовка КП и статусы B2B	Выясняем, откуда в коммерческом предложении берутся цена и наличие: из системы или менеджер час уточняет их на складе.	Коммерческое предложение собирается из достоверных данных. Иначе сайт показывает дилеру и клиенту неверные сведения.

53Сборка отчёта

Аудит заканчивается реестром поломок, листом оценки модели бизнеса и отдельными приложениями по обменам, оплате, ROMI и регламенту восстановления из резервной копии. Их объём зависит от выбранной глубины аудита.

Что делаем. Записываем каждую находку в едином формате и присваиваем ей один уровень серьёзности. Отмечаем, какие выводы получены из кабинетов и сервисов, а какие из ручной проверки, и для каждой строки указываем способ повторной проверки.

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

Проверка	Что делаем	Результат
53.1 Каждая находка в одном формате все	Заполняем таблицу отчёта: где увидели, адрес страницы, чем проверили, какая норма, какой факт, уровень серьёзности, как проверить повторно.	По описанию находки дефект можно воспроизвести без автора аудита. В отчёт: таблица находок.
53.2 Уровень серьёзности все	Каждой находке присваиваем уровень по правилу. Блокер: сайт или оформление заказа недоступны, есть следы взлома, сайт целиком закрыт от индексации, оплата считает не ту сумму, из интернета можно открыть дамп (файл с копией базы или файлов сайта) или админку. Существенно: массовые дубли одной страницы по разным адресам, плохая скорость у реальных посетителей, заявки из форм не доходят, нет согласия на обработку персональных данных, сайт открывается по нескольким вариантам адреса как отдельные копии (разъезд зеркал). Улучшение: ошибки в отдельных заголовках страниц (title), недостаточный контраст текста с фоном в отдельных местах, мелкие замечания валидатора разметки.	У каждой находки ровно один уровень. В отчёт: число находок каждого уровня.
53.3 Что проверено автоматически все	Перечисляем сервисы из части 1. Отдельно отмечаем, что взято из замеров у реальных посетителей в кабинете поисковика, что из разового тестового замера, что из обхода сайта программой и что из ручного сценария.	Читатель видит, какой вывод сделан по данным кабинета, а какой по одному прогону Lighthouse (проверки страницы в браузере: скорость, удобство, базовые требования поисковиков). В отчёт: колонка «источник» в таблице.
53.4 Повторная проверка все	Проверяем те же адреса теми же инструментами. После правок повторяем только затронутый этап, а не весь аудит наугад. Для индекса нужен новый обход сайта поисковым роботом: старый отчёт кабинета не доказывает, что страница уже вернулась в поиск.	В плане исправлений у каждой строки указан способ проверки. В отчёт: колонка «как перепроверить».

Приложение. Чем проверяем

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

1Кабинеты поисковых систем

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

Сервис	Что снимает	Доступ
Яндекс Вебмастер (кабинет владельца сайта в Яндексе) · webmaster.yandex.ru	Индексация и причины, по которым страницы исключены из поиска, обход сайта роботом, карта сайта (sitemap), зеркала (тот же сайт по другому написанию адреса), регион, ИКС (индекс качества сайта в Яндексе), диагностика, безопасность и нарушения, переобход страниц, товары, ссылки, скорость, рекомендации.	Права владельца, вход через OAuth без передачи пароля нашей программе
Google Search Console (кабинет владельца сайта в Google) · search.google.com/search-console	Покрытие индекса, проверка отдельных адресов страниц, Core Web Vitals (три основных показателя скорости) по замерам у реальных посетителей, карта сайта (sitemap), ссылки, ручные меры (санкции, которые наложил сотрудник Google, а не алгоритм), безопасность, расширенные результаты в выдаче с ценой, звёздами или навигационной цепочкой, HTTPS, поисковые запросы и страницы.	Права владельца
Bing Webmaster Tools (кабинет владельца сайта в поисковике Microsoft) · bing.com/webmasters	Обход и индекс Bing, SEO-отчёты, ссылки, IndexNow (способ быстро сообщить Bing и другим поисковикам, что страница изменилась), проверка адресов страниц. Имеет смысл, если с Bing приходят посетители или нужен запасной канал индексации.	Права владельца
Валидатор микроразметки Яндекса (проверка данных для поисковика: цена, наличие, организация) · в кабинете Вебмастера	Разбор разметки Schema.org, Open Graph (данные для превью ссылки в мессенджерах и соцсетях) и микроданных так, как их читает Яндекс.	Публично, по адресу страницы
Google Rich Results Test (проверка расширенных результатов в выдаче Google) · search.google.com/test/rich-results	Подходит ли разметка для расширенных результатов Google с ценой, звёздами или навигационной цепочкой и какие ошибки мешают правильно показать сниппет, то есть заголовок и описание страницы в результатах поиска.	Публично, по адресу страницы
Schema Markup Validator (проверка разметки Schema.org) · validator.schema.org	Синтаксис разметки Schema.org без привязки к конкретному поисковику.	Публично
Google Safe Browsing (список опасных и взломанных сайтов, который ведёт Google) · transparencyreport.google.com/safe-browsing/search	Отмечен ли сайт как опасный: фишинг, вредоносное ПО, нежелательное ПО.	Публично

2Аналитика и поведение посетителей

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

Сервис	Что снимает	Доступ
Яндекс Метрика (статистика посещений от Яндекса) · metrika.yandex.ru	Счётчик на страницах, цели, электронная коммерция (передача в статистику состава и суммы заказа), Вебвизор (записи действий посетителей), карты кликов и прокрутки, отказы, скорость загрузки в отчётах, источники посетителей.	Права владельца
Google Analytics 4 (статистика посещений от Google)	События, конверсии, двойная установка счётчика, согласие на cookie, электронная коммерция.	Права владельца
Microsoft Clarity (бесплатные записи визитов и карты кликов) · clarity.microsoft.com	Записи визитов и карты кликов. Удобен как второй источник данных о поведении, если Метрики нет или Вебвизор выключен.	Права владельца
Google Tag Assistant (проверка срабатывания счётчиков на странице) / отладчик GA4	Какие теги действительно срабатывают на странице и не срабатывают ли они дважды.	Публично, в браузере

3Скорость загрузки и Core Web Vitals

Разовый тестовый замер помогает найти причину медленной загрузки на одной конкретной проверке. Статистика CrUX (данные о скорости у реальных пользователей Chrome) показывает, что видели посетители за 28 дней. В отчёт идут оба вида данных.

Сервис	Что снимает	Доступ
PageSpeed Insights (проверка скорости страницы от Google) · pagespeed.web.dev	Тестовый замер Lighthouse и данные реальных посетителей из Chrome UX Report: LCP (за сколько появляется главный крупный блок), INP (как быстро страница отвечает на нажатие) и CLS (насколько сдвигаются блоки при загрузке), если у страницы достаточно трафика.	Публично, с ограничением числа запросов через API
Lighthouse (проверка страницы: скорость, удобство, SEO) · в Chrome DevTools или из командной строки	Производительность, доступность, лучшие практики, SEO, вес файлов, скрипты (JS) и стили (CSS), которые задерживают отрисовку страницы. Это разовый тестовый замер, поэтому цифры меняются от запуска к запуску.	Локально, на нашем компьютере
Chrome UX Report / CrUX Vis (статистика скорости у реальных пользователей Chrome)	Скорость у реальных посетителей по всему сайту и по отдельной странице: как быстро появляется главный блок, как быстро страница отвечает на нажатие и сдвигаются ли блоки при загрузке. По этим данным мы определяем, медленный ли сайт у людей, а не только в одном тесте.	Публично, при достаточном трафике
WebPageTest (порядок загрузки файлов и покадровое появление страницы) · webpagetest.org	Кадры загрузки, водопад (схема, в каком порядке грузятся файлы и какой из них задерживает остальные), регион и тип соединения, повторный заход, когда часть файлов уже сохранена в браузере, сравнение до и после.	Публично
GTmetrix (замер скорости страницы) · gtmetrix.com	Сводка Lighthouse и водопад загрузки, история замеров на платном тарифе.	Регистрация
DebugBear (регулярный замер скорости)	Постоянный мониторинг скорости по тестовым замерам, в том числе у конкурентов.	Платно

4Программы обхода сайта и SEO-платформы

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

Сервис	Что снимает	Доступ
Screaming Frog SEO Spider (программа, которая обходит все страницы и собирает технические ошибки)	Обход сайта с нашего компьютера, в том числе с выполнением JavaScript. Коды ответа, редиректы, title, H1, тег canonical, hreflang (языковые версии страниц), микроразметка, ссылки, данные PageSpeed и Search Console через API, доступность.	Программа для компьютера, бесплатно до 500 URL
Sitebulb (программа обхода сайта с наглядной схемой структуры)	Обход с наглядной схемой структуры сайта и расстановкой приоритетов проблем. Удобен для отчёта заказчику.	Платно
Netpeak Spider (программа обхода сайта)	Обход и проверка индексации, удобен на русскоязычных проектах.	Платно
Ahrefs Site Audit	Облачный обход, общая оценка состояния сайта, каннибализация (несколько страниц сайта конкурируют за один запрос), ссылки, сравнение с конкурентами.	Платно
Semrush Site Audit	Более 140 технических проверок, обход по расписанию, отдельный блок о состоянии сайта в ИИ-поиске.	Платно, есть урезанный бесплатный лимит
SE Ranking	Технический аудит и позиции, удобно для регулярного контроля.	Платно
Serpstat	Аудит, видимость, семантика. Хорошо работает с русскоязычной выдачей.	Платно
MegaIndex	Аудит, видимость, ссылки, позиции в Яндексе и Google.	Регистрация / платно
PR-CY · pr-cy.ru	Быстрый внешний срез: доступность, заголовки, скорость, краткая SEO-сводка. Подходит для первого взгляда, но не заменяет программу обхода сайта.	Публично, глубина ограничена
Be1.ru	Похожий быстрый срез для российского сайта: индексация, внешние сигналы, техническое состояние.	Публично
Rush Analytics	Съём позиций, группировка запросов (кластеризация), проверка индексации списка адресов.	Платно
Topvisor · topvisor.com	Позиции по семантическому ядру, конкуренты, регионы. Показывает динамику, а не разовую техническую ошибку.	Платно
Keys.so	Видимость конкурентов и семантика по российской выдаче.	Платно
Lumar (бывший DeepCrawl), JetOctopus, OnCrawl, Ryte	Обход и анализ журналов сервера для больших каталогов, решения корпоративного уровня.	Платно
Xenu Link Sleuth	Простой поиск битых ссылок, если полноценная программа обхода недоступна.	Бесплатно, Windows

5Безопасность, шифрование, DNS и почта

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

Сервис	Что снимает	Доступ
Qualys SSL Labs (проверка настроек шифрования сайта) · ssllabs.com/ssltest	Сертификат, цепочка сертификатов, протоколы, шифры, HSTS (указание браузеру открывать сайт только по защищённому соединению). Ориентируемся на оценку A или A+.	Публично
SecurityHeaders.com (проверка защитных заголовков в ответе сервера)	Защитные заголовки CSP, HSTS, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy. Они ограничивают, откуда странице можно загружать скрипты, запрещают встраивать сайт в чужие страницы и определяют, какие данные и возможности браузера (камера, геолокация) доступны странице и другим сайтам.	Публично
Mozilla Observatory (сводная проверка шифрования и защитных заголовков) · observatory.mozilla.org	Сводка по заголовкам и TLS, дополняет SecurityHeaders.	Публично
CSP Evaluator (проверка политики CSP) · csp-evaluator.withgoogle.com	Слабые места в Content-Security-Policy: разрешение unsafe-inline (скрипты, вписанные прямо в страницу, из-за которых защиту легко обойти) и слишком широкие источники скриптов.	Публично
Sucuri SiteCheck (внешняя проверка на известный вредоносный код) · sitecheck.sucuri.net	Известный вредоносный код, попадание в чёрные списки почтовых сервисов и браузеров, устаревшее ПО по внешним признакам.	Публично
VirusTotal (проверка сразу многими антивирусами) · virustotal.com	Проверка адресов и файлов сразу многими антивирусами.	Публично
urlscan.io	Снимок страницы, запросы к сторонним сервисам, редиректы, подозрительные скрипты.	Публично
Hardenize	TLS, DNSSEC, сертификаты и почтовая политика домена в одном отчёте.	Регистрация
crt.sh	Все сертификаты, выпущенные на домен, по журналам Certificate Transparency. Помогает найти лишние поддомены (например, shop.site.ru) и сертификаты, выпущенные без ведома владельца.	Публично
MXToolbox (проверка почты, DNS и чёрных списков) · mxtoolbox.com	Записи DNS, MX (куда доставлять почту домена), SPF, DKIM и DMARC (записи, которые подтверждают, что письмо действительно отправлено с вашего домена), чёрные списки, открытый relay, SMTP.	Публично
DNSViz · dnsviz.net	Цепочка DNS и DNSSEC.	Публично
intoDNS	Типовые ошибки в настройках DNS-зоны: записи NS, SOA, MX, glue.	Публично
mail-tester.com (оценка, не попадёт ли письмо в спам)	Тестовое письмо с сайта: спам-оценка, SPF, DKIM, DMARC, содержимое письма.	Публично
dmarcian и другие DMARC-анализаторы (разбирают отчёты о том, кто отправляет почту от имени домена)	Политика DMARC и отчёты по ней, если почта домена уходит внешним получателям.	Регистрация
OWASP ZAP, Nikto, testssl.sh	Активное сканирование, а не пассивный просмотр. Запускаем только с явного разрешения владельца и в заранее согласованных границах.	Локально, нужно разрешение владельца

6Разметка, ошибки в коде страниц и превью ссылок в соцсетях

HTML-валидатор (программа, которая ищет ошибки в разметке страницы) запускаем по одной странице каждого типа: главная, карточка товара, корзина, статья. Каждую карточку каталога отдельно не проверяем. Превью ссылки, то есть картинку и текст, которые видны, когда ссылкой делятся, смотрим на главной и на одной карточке.

Сервис	Что снимает	Доступ
W3C Nu Html Checker (проверка HTML-разметки от консорциума веб-стандартов) · validator.w3.org/nu	Ошибки HTML на ключевых типах страниц. Проверять весь каталог обычно не нужно.	Публично
W3C CSS Validator (проверка таблиц стилей)	Ошибки в таблицах стилей. Говорит о качестве вёрстки, но на позиции в поиске не влияет.	Публично
W3C Link Checker · validator.w3.org/checklink	Битые ссылки, начиная с одной страницы и на несколько уровней вглубь.	Публично
W3C Internationalization Checker (проверка языка и кодировки страницы)	Язык страницы, направление текста, кодировка (при ошибке вместо букв видны непонятные символы).	Публично
Facebook Sharing Debugger	Как соберётся превью ссылки: og:title, og:image и копия превью, сохранённая в кэше соцсети.	Публично, нужен аккаунт
LinkedIn Post Inspector	Превью ссылки в LinkedIn.	Публично, нужен аккаунт
Открытые проверки Open Graph · opengraph.xyz и аналоги	Быстрый просмотр og-тегов без кабинета соцсети.	Публично

7Доступность для людей с ограничениями

Сервис	Что снимает	Доступ
WAVE (проверка доступности сайта для людей с ограничениями) · wave.webaim.org	Ошибки и предупреждения доступности прямо на странице: контраст текста и фона, alt (текстовое описание картинки), подписи, заголовки, ARIA (подсказки для программ чтения экрана).	Публично и как расширение браузера
axe DevTools / axe-core (автоматическая проверка доступности)	Автоматический поиск нарушений WCAG (международный стандарт доступности) в браузере или при каждой сборке сайта (CI). Находит то, что можно проверить машиной, но не заменяет проход по сайту с клавиатуры.	Расширение браузера / локально
Accessibility Insights · accessibilityinsights.io	Автоматическая проверка и пошаговый помощник для ручной проверки по сценариям Microsoft.	Бесплатно
Pa11y	Повторяемая проверка доступности из командной строки, её удобно встроить в наш набор проверок.	Локально
Colour Contrast Analyser	Точечная проверка пар цветов, если WAVE показал спорный контраст.	Локально
Экранный чтец NVDA (программа, которая озвучивает содержимое экрана)	Ручной проход ключевых сценариев: меню, форма, карточка товара, корзина.	Локально

8Тексты и уникальность

Сервисы дают только сигнал. Плох ли текст, мы решаем по самой странице и её задаче, а не по одной цифре «тошноты» (насколько часто в тексте повторяются ключевые слова).

Сервис	Что снимает	Доступ
text.ru (проверка уникальности русского текста)	Уникальность и «вода» в русском тексте.	Регистрация, лимиты
Content Watch (поиск копий текста на других сайтах)	Уникальность, поиск копий.	Регистрация
Advego Плагиатус	Уникальность и частотный анализ слов.	Программа на компьютере или онлайн-сервис
Тургенев · turgenev.ashmanov.com	Риск попасть под текстовые фильтры Яндекса: переспам (перегрузка текста ключевыми словами), «вода», стиль.	Регистрация
Главред · glvrd.ru	Читаемость и стоп-слова. Инструмент для редактуры, на индексацию не влияет.	Публично
Орфограммка · orfogrammka.ru	Орфография и грамматика длинных текстов.	Регистрация
Copyscape (поиск копий текста в интернете)	Копии англоязычных и смешанных страниц на других сайтах.	Платно

9Работает ли сайт без перебоев

Сервис	Что снимает	Доступ
UptimeRobot (регулярно открывает сайт и фиксирует, когда он был недоступен), Better Stack, Pingdom, StatusCake, Hetrixtools	История ответов сервера, время ответа, сколько осталось до окончания SSL-сертификата, периоды простоя. Для разового аудита смотрим уже накопленную историю, если мониторинг был включён.	Регистрация

10Приватность и сторонние трекеры

Сервис	Что снимает	Доступ
Blacklight · themarkup.org/blacklight	Какие трекеры и скрипты для снятия цифрового отпечатка браузера загружаются до того, как посетитель что-либо сделал на странице.	Публично
Сканеры cookie (файлы, которые сайт сохраняет в браузере) · Cookiebot или аналогичная проверка в браузере по заголовкам Set-Cookie и запросам до согласия	Маркетинговые и аналитические cookie, которые ставятся до нажатия «согласен».	Публично / расширение

11Редиректы и заголовки ответа сервера

Сервис	Что снимает	Доступ
httpstatus.io, wheregoes.com, redirect-checker	Цепочка кодов от исходного адреса до конечного: 301 (постоянный переезд), 302 (временный переезд), петли, лишние промежуточные переходы.	Публично
redbot.org	Кэширование, сжатие, условные запросы, заголовки ответа.	Публично

12Карточки компании на картах и товарные фиды

Этот блок нужен, если сайт продаёт товары или компания принимает клиентов в офисе или магазине. Для сайта со статьями, за которым не стоит компания, блок пропускаем.

Сервис	Что снимает	Доступ
Яндекс Бизнес	Карточка организации: название, адрес и телефон, рубрики, фото, статус модерации, совпадение данных с сайтом.	Права владельца
Google Business Profile (карточка компании в Google Картах)	То же для Google Карт.	Права владельца
Google Merchant Center (кабинет Google для товарного фида)	Товарный фид (файл со списком товаров для рекламы и каталогов площадок): цены, наличие, отклонённые товары, расхождения с карточками на сайте.	Права владельца
Товары в Яндекс Вебмастере	Товарные предложения, ошибки фида, связь с карточками на сайте.	Права владельца

13Разные браузеры и устройства

Сервис	Что снимает	Доступ
Режим эмуляции устройств в Chrome	Быстрая проверка на ширине экрана 320, 390, 768, 1280 и 1440 пикселей.	Локально, в браузере
BrowserStack, LambdaTest (удалённый доступ к настоящим телефонам и браузерам)	Настоящие устройства на iOS и Android и старые браузеры, если заказчику важны эти платформы.	Платно

14Встроенные инструменты 1С-Битрикс

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

Сервис	Что снимает	Доступ
Проверка системы · Настройки → Инструменты → Проверка системы · /bitrix/admin/site_checker.php	PHP, расширения, права на запись, база данных, почта, агенты (фоновые задачи сайта, например рассылка или пересчёт), соответствие требованиям продукта.	Доступ к административной панели
Сканер безопасности · Настройки → Проактивная защита → Сканер безопасности	Внутренние настройки и внешняя проверка сайта: трояны, открытые резервные копии, слабые места в конфигурации.	Доступ к административной панели
Проактивная защита (встроенная защита Битрикса от типичных атак)	Проактивный фильтр, контроль активности, защита сессий, стоп-лист, одноразовые пароли.	Доступ к административной панели
Панель производительности · Настройки → Производительность	Оценка конфигурации, медленные страницы, кэширование, композитный режим (готовая копия страницы для гостей, чтобы не собирать её заново при каждом заходе).	Доступ к административной панели
Монитор качества	Чек-лист готовности проекта к сдаче: тесты Битрикса по безопасности, производительности и интеграциям.	Доступ к административной панели
Система обновлений	Нет ли в ядре и модулях критичных уязвимостей из-за неустановленных обновлений. Версию фиксируем в отчёте.	Доступ к административной панели
Журнал вторжений и журнал событий	Попытки подбора пароля, срабатывания проактивного фильтра, ошибки PHP.	Доступ к административной панели

Реквизиты

Данные со страницы контактов веб-студии АКРИТ: https://www.acrit-studio.ru/about/contact_information.php

Поле	Значение
Название	ООО «Агентство Креативных Разработок Инновационных Технологий» / LLC «Agency of Creative Developments of Innovative Technologies» (ACDIT)
Бренд	Веб-студия АКРИТ
Директор	Панишев Александр Алексеевич
ИНН / КПП	6432029368 / 643201001
ОГРН	1256400003584, дата регистрации 28.03.2025
ОКПО	37798518
ОКВЭД	62.01, 62.02, 62.03, 62.09
Адрес	413042, Саратовская область, м.р-н Воскресенский, с.п. Елшанское, с. Усовка, ул. Нижняя, д. 14
Банк	ООО «Банк Точка»
БИК	044525104
Р/с	40702810020000195305
К/с	30101810745374525104
СБИС	2BE025f5d6b4e7d4759b0592ef3a6d1d8a9
Телефон	+7 499 938 8452
Почта	design@acrit.ru
Режим	пн–пт, 10:00–17:00
Сайт	https://www.acrit-studio.ru

Готовы провести аудит по этому сценарию. Напишите на design@acrit.ru или позвоните +7 499 938 8452, и мы пришлём состав проверки для вашего сайта и назовём срок.

Написать письмо +7 499 938 8452