Собственный проект / 17.09.2026

От аудита до проверенного изменения.

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

Собственный сайтАудит → внедрение → production validationБез вымышленных KPI

Что было подтверждено до изменений

Перед реализацией отдельно зафиксировали production и повторили старые дефекты. В список вошло только то, что удалось воспроизвести или подтвердить кодом и HTTP.

01

Мобильная навигация

На узких экранах не было полноценного доступного меню.

02

Reflow

На 320 px сохранялся скрытый горизонтальный выход содержимого.

03

Контраст

Две проверенные пары не проходили целевой порог обычного текста.

04

Контакт

Прямые каналы на /razbor/ находились после длинного объяснения.

05

OG

Типовой адрес превью части услуг возвращал 404.

06

Аналитика

page_view и contact_click были предусмотрены, но не работали как единый контракт.

Каждое изменение привязано к проверяемому результату

Целью выпуска не было «освежить сайт». Задачи формулировались так, чтобы после релиза можно было получить PASS/FAIL, а не субъективное впечатление.

  1. Native dialog для мобильного меню, Escape и возврат фокуса.
  2. Исправление shrink/reflow вместо маскировки overflow.
  3. Коррекция подтверждённых цветовых пар.
  4. Telegram, VK, email и телефон в hero первичного разбора.
  5. Стабильный /images/og-default.png для типовых метаданных.
  6. Контракт r1-2026-09-17 и события page_view, contact_click, article_to_service.
  7. Отдельный hotfix после post-deploy обнаружения остаточного 320 px overflow.

После deploy проверили не workflow, а живой сайт

Первый релиз не объявили готовым автоматически: post-deploy проверка нашла остаточный hidden overflow на 320 px. Его исправили отдельным hotfix и повторили измерение.

01

320 / 360 / 390 / 768 px: ширина документа совпадает с viewport.

02

Меню: фокус на первый пункт, Escape закрывает, фокус возвращается на trigger.

03

OG: 200, image/png, 53 208 байт.

04

Контраст проверенных пар: примерно 4.58:1 и 4.67:1.

05

Production dataLayer содержит версионированные page_view и contact_click без PII.

Открытые ограничения. Приём целей внутри авторизованного отчёта Яндекс Метрики в этом цикле не подтверждён. Реальные Safari/iPhone и NVDA/VoiceOver остаются отдельной accessibility-проверкой. Эти пункты не скрыты и не превращены в PASS.

Краткий протокол можно открыть без заявки

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

Открыть протокол R1 ↗

Доказательство процесса, а не рекламной цифры

Материал показывает полный инженерный цикл: наблюдение → граница вывода → задача → реализация → автоматические проверки → релиз → production-проверка → исправление остаточного дефекта.

ДА

Можно заключить

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

НЕТ

Нельзя заключить

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

Следующий шаг

Нужен такой же путь от факта до проверяемого изменения?

Можно начать с диагностики, если причина неясна, либо сразу с ограниченного внедрения, если задача уже определена.