Услуги
Сайты и магазиныЛендинги ★Создание сайтовИнтернет-магазины
ИИ и автоматизацияИИ-секретарь ★Автоворонка и прогрев ★Telegram-боты ★Автоматизация ★CRM-разработка
ПродвижениеSEO-продвижениеAI-продвижение ★Контекстная рекламаSMM и соцсети
Наружка, печать и производствоВывески и буквыНаружная рекламаБаннеры и штендерыТипографияВизиткиШирокоформатБрендированиеОклейка автоТорговое оборудованиеМатериалы для рекламы
Дизайн и поддержкаДизайнПоддержка
КомплексDigital под ключ ★
РешенияКейсыПортфолиоЦеныО студииБлогКонтакты Обсудить проект

Метод · приёмка · разбор 8 из 13

Как отличить «сделал» от «работает»: 33 класса ошибок из собственного реестра

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

Паспорт замера: Реестр ведётся с 18.07.2026 · пополняется в день инцидента, пока помнится причина

Зачем это нужно тому, кто просто хочет продвигать сайт

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

33

класса ошибок в реестре за полтора месяца

3 из 4

пакетов работ из массового аудита оказались фантомами

3 из 4

ложных находок отсёк контур перепроверки вторым проходом

2 дня

жила ошибка, обнулявшая базу заявок, — код ни разу не запустили

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

Четыре источника истины, и всё остальное

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

Источник истиныЧто им проверяетсяЧем его подменяют
Ответ живого серверачто видит робот и пользователь: код ответа, содержимое, заголовкифайл в репозитории, скриншот, статус выкладки
Код и содержимое файловесть ли правка физически, в скольких местах«я поправил», отчёт об изменениях
История измененийкогда и что реально менялосьпамять, запись в таск-трекере
Сырые данные панели вебмастерапоказы, клики, запросы по страницамагрегированные сводки и усреднения за длинный период

Самый массовый класс ошибки — действие по снимку

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

Обход один: перед действием — сверка с живым источником, а не с записью о нём. Это занимает минуту и экономит дни.

Шесть классов, в которые попадают чаще всего

Полный реестр — рабочий документ, здесь шесть самых частых с примерами из работы над сайтом.

1. Доверие пересказу вместо проверки

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

Обход: находка без проверки остаётся мнением. Подтверждать самому поиском по коду или запросом к серверу. И отдельно: «проверяющий не смог подтвердить» — не то же самое, что «опровергнуто»: чаще всего он просто не дошёл.

2. «Сделал» без перепрогона той самой проверки

Правка внесена — значит починено. Нет: починено, когда перепрогнана именно та проверка, которая ловила дефект. Ошибка, обнулявшая базу заявок при отправке формы, прожила два дня, потому что код ни разу не запустили локально. Мини-приложение прошло собственные 20 тестов из 20, а состязательная проверка нашла в нём 8 настоящих ошибок.

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

3. Чинили результат, а не его источник

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

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

4. Круговая логика: признак принят за подтверждение

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

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

5. Инструмент врёт на краю

Детектор цены требовал трёх цифр подряд перед знаком валюты, и читал «от 7,8 млн ₸» как отсутствие цены, а плейсхолдер «ИТОГО К ОПЛАТЕ 0 ₸» как её наличие. Прибор врал в обе стороны одновременно. Поисковик на один и тот же домен ответил «8 упоминаний», а затем — ноль.

Обход: каждый новый детектор прогонять на паре примеров «должен найти» и «не должен найти» до массового запуска. Две проверки за секунду ловят обе ошибки.

6. Автомат сломался и молчит

Фоновая задача сообщает об итоге строкой, которая выглядит одинаково при работе и при провале. «Собрано 1 видео» — это успех или авария? Без знаменателя не понять, и наш сборщик простоял мёртвым десять дней.

Обход: итоговая строка обязана нести знаменатель — «опрошено 1 из 23 каналов» не спутать с успехом; провал возвращает ненулевой код; дата изменения результатов старше периода запуска означает, что процесс мёртв.

Стандарт приёмки: семь правил

7 правил приёмки применяются к любой задаче — своей или подрядчика. Смысл у всех один: отделить «я это сделал» от «я проверил, что это работает».

  1. Фикс закрыт только после перепрогона именно той проверки, что ловила дефект. Внесённая правка сама по себе ничего не подтверждает.
  2. Перед выводом «дефект» — проверить свежесть данных. Рабочая копия может измерять прошлое: правда в актуальной версии и на живом сервере.
  3. Проверять против источника истины — код, сервер, история изменений. Не по памяти и не по пересказу.
  4. После правки страницы — прогнать релевантную проверку на ней самой, а поведение (форма, скрипт) — пройти сценарием руками.
  5. Красный тест — чинить одну точку. Шаблон, генератор, правило. Затем перепрогон всей пачки до нуля красных, а не ручная правка сотни страниц.
  6. Честный статус в отчёте: ✅ проверено (и чем именно) · ⚠️ частично · 🔴 не проверено (и почему). Третья метка — самая ценная, и её отсутствие в отчёте подозрительно само по себе.
  7. Рискованный или неожиданный вывод — второй проход с задачей найти ошибку, а не подтвердить. У нас такой контур отсёк три ложные находки из четырёх.

Почему «найди ошибку» работает лучше, чем «проверь»

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

Как принимать работу подрядчика: пять вопросов

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

  1. «Чем проверено?» Не «что сделано», а каким именно способом убедились, что оно работает. Ответ «мы всё проверили» ответом не является.
  2. «Покажите три адреса, чтобы я посмотрел сам.» Любая правка на сайте проверяема за минуту, если знать, куда смотреть. Отказ показать конкретику — сигнал.
  3. «Что из запланированного не сделано и почему?» Отчёт, где сделано всё, встречается реже, чем отчёт, где неудобное не упомянуто.
  4. «Какой был показатель до и каким он стал?» С датами замера и способом. «Позиции улучшились» — не показатель. «Было 37,4% страниц с дефектом, стало 7,5%, замер такой-то командой» — показатель.
  5. «Что вы проверили и решили не делать?» Хороший исполнитель отсеивает больше, чем внедряет, и может назвать причину отказа. Если отсеянного нет вовсе, значит внедряется всё подряд.

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

Почему реестр классов работает лучше чек-листа

Реестр из 33 классов работает лучше чек-листа, потому что отвечает на другой вопрос: чек-лист говорит «что проверить», реестр — «как мы обычно ошибаемся». Второе полезнее, потому что ошибки повторяются по устройству процесса, а не по невнимательности конкретного человека.

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

Записывать надо и то, что сработало

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

Реестр ведётся с 18.07.2026 и пополняется в день инцидента. Все примеры — из работы над собственной сетью сайтов; формулировки классов даны в общем виде, применимом к любому проекту.

Тот же случай в журнале замеров

Реестр с тех пор вырос: в журнале замеров разобран его формат записи и четыре самых дорогих класса.

70 классов ошибок: как перестать наступать дважды

Поставить эту приёмку у себя

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

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

Программа курса и модули

Частые вопросы

Как принимать SEO-работу у подрядчика, если не разбираешься в технике?

Требуйте в отчёте не список действий, а ответ на вопрос «чем проверено». Формулировка «оптимизированы метатеги на 40 страницах» не проверяема, а «40 страниц, вот три адреса, откройте и посмотрите заголовок вкладки» — проверяема за минуту. Отчёт без указания способа проверки отчётом не считается.

Что считать источником истины при проверке работы над сайтом?

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

Почему одинаковая ошибка повторяется у разных исполнителей?

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

Что делать с неожиданно хорошим результатом проверки?

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

Соседние разборы

Каждый самодостаточен и начинается с вывода, а не с подводки.

Техническое SEO · диагностика

Тихие отказы: когда всё зелёное, а страницы не работают

Редирект прописан, но статический файл его глушит и отдаёт 200. Робот ИИ отрезан не в robots.txt, а настройкой хостинга. Сборщик пишет «готово», собрав ноль. Семь отказов, которые не видны ни в одной панели.

Метод · контроль качества

Кто проверяет проверяющих: 8 из 18 гейтов пропустили дефект, который обязаны были поймать

Мы подсунули своим же проверкам заведомо сломанные страницы. Треть приборов показала зелёное на браке — и это объясняет, почему «все проверки пройдены» не равно «работает».

Все 13 разборов

Оглавление раздела: измерение ИИ-видимости, аудит 2196 страниц, пассажная оптимизация, предел гео-страниц, тихие отказы, приёмка работы.

Обсудим ваш проект

Оставьте заявку — свяжемся в течение 15 минут в рабочее время, зададим пару вопросов и пришлём ориентир по цене и срокам. Бесплатно, без обязательств.

  1. 1. Заявка или квиз
  2. 2. Короткий созвон / переписка
  3. 3. Бесплатная смета и план
  4. 4. Договор и старт

Бесплатно и ни к чему не обязывает. Ответим за 15 минут.