Первый получатель отчёта — мы сами. Мы запускаем Site Checker на каждом сайте — не потому что агентство-партнёр просит, а потому что предпочитаем находить свои ошибки сами, а не ждать, когда их найдёт клиент. К тому моменту, когда работа доходит до вашего QA-слоя, наш барьер перед сдачей уже закрыт. Что бы ваше агентство ни нашло после сдачи — это наши правки, не ваши.
Пять категорий. Каждая страница сайта, каждое окружение.
Категории упрощены для публичной страницы; внутренняя таксономия более детализирована. Каждая выдаёт структурированный статус ошибка / предупреждение / успех по известному набору ожидаемых состояний.
-
CATEGORY 01
Базовые настройки WordPress
Версия WordPress актуальна; флаг индексирования поисковыми системами соответствует окружению (разработка / тестовая среда / продакшен); заголовок сайта настроен; нет оставшихся демо- или тестовых аккаунтов; отладочное логирование и вывод ошибок не открывают базу данных в публичных ответах.
-
CATEGORY 02
Контент и SEO-разметка
Каждая страница имеет уникальные meta title и description в пределах допустимой длины; один H1 на страницу с чистой иерархией H2/H3; нет «Hello World», lorem ipsum и стандартного образцового контента WordPress; sitemap.xml существует, проверен и содержит ожидаемые URL.
-
CATEGORY 03
URL структура
Слаги в нижнем регистре, через дефис, без ID записей и параметров запроса, без посторонних не-латинских символов.
-
CATEGORY 04
Контакты и интеграции
Телефонные номера на сайте соответствуют утверждённому списку (нет оставшихся dev-заглушек); ссылки на адреса ведут в правильное место на карте; заголовки страниц следуют согласованному стилю написания.
-
CATEGORY 05
Паритет ребилдаТолько для ребилдов
Исходный сайт сканируется и снимается снимок до начала работ. Site Checker сравнивает ребилд с этим снимком — отсутствующий контент, битые внутренние ссылки, структурное расхождение — и фиксирует каждое расхождение как ошибку. Неактивен при новых разработках; активен при ребилдах, где есть исходный сайт для сравнения.
Результат попадает в административный интерфейс в виде карты скриншотов — каждая страница так, как она реально выглядит, а не так, как её представляет команда разработки. Одна страница глазами каждого устройства — в том же проверочном проходе, что и структурированные категории.
Здесь всплывают дефекты, видимые только на адаптивных размерах, а не в баг-задаче от агентства после сдачи: переполняющийся текст, сломанные пропорции hero-блока, схлопывание навигации, позиционирование модальных окон, sticky-заголовки, перекрывающие контент на узких экранах. Мы ловим их на барьере, на каждой странице, на каждом сданном разрешении.
При ребилдах тот же процесс захвата запускается против исходного сайта до начала работ. Сравнение после сборки с этим снимком — одновременно визуальное и структурированное: мы можем показать агентству, что ребилд совпадает с оригиналом на каждой важной точке адаптации.
На каждом WordPress-проекте, который мы ведём сегодня, ни одна сдача не уходит с открытой ошибкой Site Checker.
Это не маркетинговая фраза — это операционное правило. Красный статус любой проверки — жёсткий стоп: работа не покидает тестовую среду, пока проверка не пройдена или отклонение не задокументировано и не подтверждено. Предупреждения разбираются, но не блокируют. Каждый успешный прогон логируется с временной меткой и ID запуска — история проверок доступна для аудита.
Барьер существует потому, что альтернатива — доверять памяти команды разработки и рукописному контрольному списку — давала промахи. Плагин, читающий базу данных напрямую и перерендеривающий публичный сайт, не устаёт, не забывает, не пропускает пятничный вечер.
Каждый кейс в разделе /work/ содержит раздел «Операционная целостность на момент сдачи» — специфичная для проекта запись о том, что прошло этот барьер до сдачи работы.
Если ваше агентство хочет увидеть сам отчёт — структурированный результат по каждой категории с временными метками — мы экспортируем его по запросу. Отчёт легко переслать дальше: без внутренних комментариев, без ссылок на исходный код, без упоминания агентства-партнёра. White-label — в его основе.
Каждая выпущенная версия тегируется; каждый запуск фиксирует, какая версия дала результат, — поэтому отчёт шестимесячной давности можно воспроизвести или сравнить с текущим запуском.
Плагин внутренний — не в каталоге WordPress.org. Текущая версия, кодовая база и набор правил по каждой проверке доступны для изучения по запросу. Если ваше агентство рассматривает нас как white-label партнёра и хочет разобраться в QA-слое до подписания объёма — мы готовы к такому разговору.
Есть проект, которому нужна сдача с нулевыми ошибками?
Пришлите Figma, URL или ТЗ. В течение 24 часов ответим с фиксированной оценкой часов и датой. Запуск Site Checker — часть каждого проекта: не дополнение, не отдельная строка, просто так работа уходит из наших рук.