Диспетчерская вебмастера: как это считается

Диспетчерская превращает отчёты, события, изменения стража и задачи в ответ на вопрос «что делать сегодня». Никакого ИИ в рантайме: все формулы детерминированы, одни и те же данные всегда дают тот же результат. Код: src/Dispatch/, страницы /today, /incidents, /timeline, карточка сайта /site/{host}.

Master Index v2 (MasterIndex)

Число 1–100 из пяти подиндексов (веса): техническое здоровье 25, скорость 15, безопасность 20, поисковая видимость 25, доверие домена 15. Каждая проверка отчёта относится к подиндексу по коду; подиндекс — взвешенное среднее её проверок. Итог — среднее по подиндексам с данными. Ограничители (rank.caps: noindex ≤40, нет HTTPS ≤60, ошибка главной ≤15 …) срезают итог сверху; «молодой домен» учитывается только в «Доверии». Достоверность = доступный вес подиндексов − 10 (пока нет данных Search Console / Яндекс.Вебмастера). Уровни: Эталон ≥95, Отлично ≥85, Хорошо ≥70, Удовлетворительно ≥50, Плохо ≥30, Критично. gain() считает прирост, если исправить выбранные проверки.

Priority Engine (Priority)

Приоритет = 0.25·критичность + 0.25·влияние + 0.15·охват + 0.15·достоверность + 0.10·свежесть + 0.10·простота исправления, ×1.1 если сайт сейчас недоступен. Горизонты: «сейчас» ≥75, «сегодня» ≥60, «на неделе» ≥45, «позже». Для каждой задачи хранятся человекочитаемые причины.

Сигналы и лента (Signal, Timeline)

События, изменения стража и закрытые задачи приводятся к единому виду: вид (availability.down, robots.changed, …), категория, серьёзность 0–100. Дубли стража и событий склеиваются.

Инциденты (Incidents)

Связанные сигналы одного сайта в окне 48 ч объединяются по правилам: server, indexing, security, infra (≥2 вида), template (≥2), rank (только вместе с другими сигналами). Идентификатор = sha1(правило | сайт | время первого сигнала) — стабилен между запусками. Сервер-инцидент закрывается событием «снова доступен».

Динамические пороги (Baseline)

Норма сайта — медиана его собственной истории, разброс — MAD; аномалия — модифицированная оценка Z = 0.6745·(x − медиана)/MAD ≥ 3.5 и заметное отклонение в абсолютных цифрах (иначе на очень стабильных рядах шум давал бы ложные тревоги). Нужно не меньше 6 замеров. Метрики: время отклика (последние 3 ч против 14 суток), TTFB и загрузка главной, ранг (падение). Событие anomaly-… попадает в ленту и правило инцидента «Деградация скорости или отклика»; повтор подавляется на 24 часа. Запускается после каждой проверки мониторинга, доступности и ручной перепроверки. На карточке сайта — блок «Норма сайта».

Поисковые системы (src/Providers/)

Яндекс.Вебмастер (GET /v4/user/{id}/hosts/{host}/summary): страницы в индексе, ИКС, проблемы по уровням. Google Search Console (searchAnalytics.query по датам): клики и показы; авторизация — JWT RS256 сервисного аккаунта. Снимки (последние 60 на сайт) лежат в provider_snaps; события: search-indexed (индекс заметно ниже нормы по MAD, при короткой истории — падение ≥30%), search-problem (выросло число критичных проблем), search-clicks (клики за 3 дня ниже нормы). Каждая подключённая система даёт +5 к достоверности Master Index (максимум +10). Сопоставление сайтов — по домену без www. Сетевые вызовы идут через Providers\Client, в тестах он подменяется функцией.

Единый поток действий (Actions\Feed, версия 55)

Разделы без собственных проверок сайта превращают выводы в задачи (источник → ключ): репутация reputation → v:unanswered|surge|drop:<площадка>|low:<площадка>; каталоги presence → k:<каталог> (только отмеченные «нет», «неизвестно» задачей не становится); глубокий обход deep → d:<проблема> (уровни «ошибка» и «внимание» последнего завершённого обхода, число страниц в подробностях); ссылки backlinks → b:toxic, b:lost (считаются после синхронизации ссылок, чтобы не читать до 50 000 строк при каждом открытии). Три первых источника обновляются в Plan::sync, то есть при каждой проверке, при открытии «Сегодня» и карточки сайта. Приоритет считается той же формулой (охват и достоверность по первой букве ключа), время — Planner::FEED_MINUTES, для d: — по 5 минут на страницу. Исчезнувшая причина закрывает задачу. Вклад в приоритет хранится в tasks.eff (в impact — ноль), поэтому прогноз ранга не завышается. Результаты обхода старше 60 дней задач не порождают.

«Готово» вручную (taskSync, параметр $dataTs): задача открывается снова, только если данные источника получены после отметки; для источников без метки времени — если с отметки прошло больше трёх суток, а проблема на месте.

Подтверждение исправления

Кнопка «Перепроверить и подтвердить» (POST /today/verify) запускает свежую проверку сайта; Store::taskSync закрывает исчезнувшие проблемы и фиксирует это в ленте.

Проверка

Набор самотестов Dispatch и Rank (/admin/tests) покрывает формулы, правила и детерминизм.

Важность сайтов

У каждого сайта есть важность: низкая ×0.85, обычная ×1.0, высокая ×1.15, критичная ×1.3 (site_prefs, выбор на карточке сайта). Множитель применяется в Priority::rank через siteCtx[host]['weight'] (в пределах 0.5–1.5, итог не выше 100); в причинах задачи появляется «важный сайт».

Тихие часы

В кабинете задаётся окно (от/до, часовой пояс). Внутри окна несрочные уведомления копятся в notice_queue и уходят одним сообщением после его окончания (Notifier::flush, вызывается из cron: uptime, watchdog). Срочные проходят всегда: падение сайта, безопасность, вход в аккаунт, тест, недельная сводка.

Сквозные тесты

Набор Pipeline прогоняет весь путь данных на подставном сайте (Http::$fake, SelfTest\FakeWeb) без обращения в сеть.

Поисковые запросы

Яндекс.Вебмастер и Search Console отдают запросы за два равных периода (14 дней и 14 дней до них, с отступом 3 дня). Dispatch\Queries сопоставляет их и находит: потерянные (клики упали на 70% и больше при 5+ кликах раньше), просадку позиции (на 3+ при 8+ кликах), рост (вдвое) и новые. Событие search-queries создаётся, если потерян запрос с 10+ кликами или три и больше любых; оно входит в инцидент «Падение поискового трафика». В снимке хранится 40 строк; таблица показывается на карточке сайта.

Журнал изменений

На карточке сайта можно добавлять пометки («сменили тему», «перенесли хостинг») с датой. Они попадают в ленту как note.user (сами инцидентов не создают) и показываются в инциденте и в «Сегодня» как вероятная причина, если сделаны за двое суток до начала инцидента или во время него. На сайт хранится до 200 пометок (annotations, модуль схемы prefs версии 2).

Проверка индексации (Google URL Inspection)

Для главной и до трёх контролируемых страниц сайта запрашивается состояние в индексе Google. Выпадение (вердикт FAIL или NEUTRAL, например из-за noindex) создаёт событие search-inspect — для главной критичное; повтор не дублируется, пока состояние не изменится. Событие входит в инцидент «Риск потери индексации». Яндекс такого API не даёт.

Отчёт о проделанной работе

WorkReport::build собирает за 7–90 дней: оценку в начале и конце периода, подтверждённые исправления, инциденты (с вашими пометками как причиной), пометки об изменениях, доступность и оставшиеся задачи; из них складываются итоговые фразы. Страница /work/{сайт} печатается в PDF; краткая версия («за 30 дней исправлено…») добавляется в письмо клиенту.

Публичная ссылка на отчёт о работе

Кнопка «Публичная ссылка» на /work/{сайт} создаёт /s/<токен> (вид work). Публичная версия показывает итог, исправления и инциденты, но не показывает ваши пометки, причины инцидентов и список задач в работе; ссылку можно отключить там же.

Карты сайта в Search Console

Google отдаёт отправленные карты сайта с числом ошибок. Рост числа ошибок создаёт событие search-sitemap (классифицируется как изменение sitemap и входит в инцидент индексации); состояние карт видно на карточке сайта.

Конкуренты

На /rivals/{сайт} добавляются до пяти конкурентов; их публичные проверки сравниваются с вашей. Dispatch\Gap показывает разницу по пяти подиндексам Master Index, проверки, где конкурент заметно лучше (на 20+ баллов; с выигрышем к вашему индексу от их исправления), и проверки, где вы впереди. Раз в сутки bin/rivals.php перепроверяет конкурентов старше недели и создаёт событие rival, если конкурент обошёл вас по Master Index на 10 пунктов и больше (не чаще раза в неделю).

План на неделю

/week раскладывает открытые задачи всех сайтов по рабочим дням (1–7 дней, 30–480 минут в день) в порядке приоритета. Трудоёмкость — таблица Planner::MINUTES по коду проверки (например, title — 15 минут, TTFB — 2 часа); для проблем на страницах — 5 минут на страницу (от 15 минут до 4 часов). Задача длиннее дня занимает целый пустой день; что не поместилось — «на следующую неделю».

Выгрузки CSV

/export/work/{сайт}.csv (исправления, инциденты, пометки), /export/queries/{сайт}.csv (запросы Яндекса и Google), /export/rivals/{сайт}.csv (отставания и преимущества). Ячейки с формулами экранируются.

Группы запросов

Собственные группы поисковых запросов сайта («Бренд», «Купить», «Информационные»…): список слов, запрос входит в группу, если содержит любое из них; слово с дефисом («-вакансии») исключает запрос. Группы считаются при каждой синхронизации по 200 самым частым запросам Яндекса и Google (клики, показы, средняя позиция, клики за прошлый период) и хранятся в снимке. Падение кликов группы на 40% и больше при 20+ кликах в прошлом периоде создаёт событие search-group и входит в инцидент «Падение поискового трафика». До 10 групп на сайт (query_groups, схема prefs v4). Открытого API групп у Яндекс.Вебмастера нет — их можно вести только в интерфейсе Яндекса, поэтому группы SEOMaster работают на собственных данных и одинаково для Яндекса и Google.

Запросы Яндекса: query-analytics/list

Запросы Яндекса берутся из «Мониторинга поисковых запросов» (POST …/query-analytics/list, показатели по дням). Яндекс хранит там только две недели, поэтому периоды сравнения — 7 + 7 дней (у Google 14 + 14), данные отстают на 1 день (у Google на 3). Клики и показы суммируются по дням периода, позиция — средневзвешенная показами. Если новый метод ответил ошибкой или пустотой, используется прежний search-queries/popular (произвольный период). Длина периода и отставание задаются провайдером (queryPeriod(), queryLag()), длина сохраняется в снимке (qp) и показывается в интерфейсе.

Страницы из поиска

Рядом с запросами синхронизация сохраняет в снимке pgs до 30 самых посещаемых страниц (URL, клики, показы, позиция, значения прошлого периода). Яндекс: тот же query-analytics/list с text_indicator = URL; Google: searchAnalytics с измерением page. Классификация та же, что у запросов (Queries::movers): теряет трафик (клики упали на 70% и больше при 5+ кликах раньше), позиция хуже, растёт, новая. Если страницы теряют трафик, создаётся событие search-pages (не чаще раза в 72 часа), которое входит в инцидент «Падение поискового трафика» (search.queries_lost). Пути в интерфейсе сокращаются без схемы и домена (Queries::short).

Календарь

/week.ics?days=5&min=120 отдаёт план недели в iCalendar. Дни плана — рабочие (суббота и воскресенье пропускаются, счёт от сегодняшнего дня или ближайшего понедельника), задачи идут подряд с 10:00 по плавающему времени (календарь покажет его по местным часам). Событие содержит сайт, задачу, подсказку, приоритет и ссылку на карточку сайта (если задан base_url). UID = SHA-1 от «сайт + ключ задачи», поэтому повторный импорт обновляет события.

Возможности роста и каннибализация

Opportunities::find обходит запросы (после слияния периодов) и возвращает до 10 строк. «Почти в топе»: позиция 3,5–15,5, не меньше 100 показов; ожидаемый прирост = показы × CTR(3-й позиции, 10%) − текущие клики, берутся от +5. «Низкий CTR»: позиция выше 3,5, не меньше 200 показов, кликов меньше половины ожидаемого по кривой Opportunities::CTR; прирост = 80% разницы. Кривая типовая и служит ориентиром — у сайтов с расширенными сниппетами или рекламой CTR отличается. Список хранится в снимке (opps).

Opportunities::cannibal работает на парах «запрос — страница» (Provider::pairs, сейчас только Google: измерения query + page). Запрос попадает в список, если показов в сумме не меньше 50 и как минимум две страницы получили по 20% и больше показов. Если таких запросов три и больше и их стало больше, чем в прошлом снимке, создаётся событие search-cannibal (раз в неделю); вид сигнала search.cannibal не образует инцидент — это справочная информация. Яндекс пары не отдаёт.

Plan::fromSearch превращает до трёх возможностей и двух случаев каннибализации на систему в задачи плана (source = search, ключи o:near:, o:ctr:, o:cann:). Польза условная: 50 кликов ≈ 1 балл, не больше 8; уверенность в приоритете ниже, чем у проверок (65 против 90–100), потому что прирост — оценка.

Календарь и FullCalendar

/calendar показывает три потока: задачи плана недели (Ics::slots — те же слоты, что в .ics), инциденты (Incidents::build за период, на весь день от первого до последнего сигнала; закрытые — серым) и пометки журнала. Лента — CalendarFeed::build, отдаётся как /calendar.json?start=…&end=… (окно не больше 100 дней; без входа — 401).

Библиотека: FullCalendar 7.1.1, раскладка каталога dist/ официального архива: fullcalendar.global.js, skeleton.css, locales-all/global.js, themes/<тема>/{global.js,theme.css,palettes/<палитра>.css} (у classic — palette.css), fullcalendar-scheduler.global.js. Лежит в public/assets/vendor/fullcalendar; CalendarAssets::detect собирает список скриптов и стилей по настройкам calendar.theme/palette. Обязательны ядро и каркас стилей. Установка: bin/vendor-fullcalendar.php <архивы или --from=dist> (берёт только dist/, отбрасывает пути с .., печатает SHA-384, определяет версию по заголовку файла; --remove снимает). Scheduler (лицензия не MIT) подгружается только при заданном scheduler_key и добавляет шкалу «Сайты» (resourceTimelineWeek: ресурсы — ваши сайты, resourceId каждого события — сайт). Тёмная тема: calendar.js ставит атрибут data-color-scheme на контейнер при смене data-theme сервиса. Параметры 7.x отличаются от 6.x (buttons, resourceColumnHeaderContent, resourceColumnsWidth; buttonText не существует). public/assets/calendar.js запускает FullCalendar.Calendar, а при отсутствии библиотеки или ошибке запуска — встроенный календарь на месяц, читающий ту же ленту. Подгонка вида под тему сервиса — public/assets/calendar.css; для настоящего FullCalendar она минимальна (шрифт, прозрачность закрытых инцидентов), цвета берутся из темы Monarch и палитры.

Диспетчерская 2.0 (версия 59)

Три механизма замыкают цикл «увидели проблему → сделали → проверили → поняли, помогло ли». Код: src/Dispatch/{Causes,Effect,Verify,Series}.php, схема DispatchSchema, экраны /causes, /effects, блоки в /today и /plan/{host}, cron bin/verify.php.

Вероятные причины (Causes)

Следствия: падение трафика, запросов, индекса, ранга, проблемы в вебмастере. Причина должна произойти раньше следствия (допуск 2 часа) и не дальше окна правила (от 7 до 30 суток). Правила: закрытие от индексации (robots/noindex), недоступность, безопасность, карта сайта, шаблон (canonical/title/H1), смена инфраструктуры, просадка скорости, потеря ссылок, ваши пометки о работах, каннибализация. Падения на нескольких сайтах одновременно без сайтовых причин объединяются в гипотезу «внешний фактор». Если причины нет — честное «причина не найдена» со списком проверок. Уверенность 5–95: база правила + близость по времени (+12…−6) + число подтверждающих признаков + серьёзность причины ± опыт (отзывы «да/нет» по правилу, до ±15 и тем сильнее, чем их больше). Подтверждённая вами гипотеза — 90+, отклонённая — ≤10 и в конце списка. Близкие по вероятности объяснения помечаются как неоднозначные. Идентификатор гипотезы стабилен.

Эффект «до/после» (Effect, Series)

Для выполненной задачи (отмечена «Готово» или проблема ушла сама; момент — tasks.done_at) выбираются показатели по типу задачи: визиты, клики Google, видимость в поиске, доступность, время отклика, индекс, ранг, TTFB, рейтинг. Плотные ряды: медиана 14 суток до против медианы после (с задержкой 3 суток для поиска; не меньше 7 дней, для доступности 3). z = (после − до)/(σ·√(1/n₁+1/n₂)), σ = max(1.4826·MAD, нижняя граница, 3% нормы); «улучшилось/ухудшилось» только при |z| ≥ 2.5 и изменении не меньше порога показателя; иначе «без заметных изменений». Редкие ряды сравниваются по трём последним точкам до и первым после. Рядом пишутся помехи (другие задачи в те же дни, сбои доступности) и прогноз плана для ранга. Итоги замораживаются через 45 суток. Это оценка, не доказательство. Обучение: если у вас не меньше трёх измеренных задач типа, приоритет таких задач корректируется множителем 0.85…1.2 по доле успехов (сглаживание (успехи+1)/(n+2), нейтраль 40%); причина видна в «почему».

Автопроверка (Verify)

«Готово» ставит задачу в очередь. Через 30 минут, затем 6 часов и сутки: задачи проверок сайта — перепроверка сайта целиком, аудита страниц — новый аудит, остальные — ожидание обновления данных их источника. Исходы: подтверждено (задача «исправлено»), не подтвердилось (открыта снова, с причиной и подсказкой про кэш/CDN), подтвердить не удалось (нет ответа сайта или данные не обновлялись 14 суток). События action-verified / action-failed попадают в ленту. Кнопка «Проверить сейчас» на странице плана делает то же сразу.

Cron

5-59/15 * * * * php bin/verify.php — очередь и пересчёт эффекта.

Диспетчерская 4.0 (версия 87)

Свежесть источников (Freshness)

Источники: доступность (порог 36 ч), страж (2 интервала проверок + 6 ч), полные проверки (14 дн.), Google (72 ч), Яндекс (10 дн.), посещаемость (72 ч), позиции (5 дн.), ссылки (14 дн.), обход (30 дн.), данные об организации (45 дн.), отзывы (10 дн.). Состояние: fresh / stale / none. «Покрытие» момента — есть ли точка источника не дальше порога от момента падения; у стража истории проверок нет, он считается наблюдавшим сайт с момента подключения. Данные дня считаются известными к концу суток.

Модель нескольких источников (Evidence, подключается через Causes::build(..., ['ctx' => …]), forUser делает это сам)

1. Независимость. Признаки причины группируются по источнику (Evidence::SOURCE_OF). Бонус за «несколько признаков» (до +10) заменяется бонусом за число независимых источников (+6 за каждый сверх первого, до +10).
2. Сверка падения. Для следствия берутся ряды Evidence::CONFIRM; probe: плотные — медиана 2…16 суток до против последних дней (не меньше 3), z ≥ 2,5 и падение не меньше порога показателя → подтверждает; падение меньше половины порога → не видит; между ними — слабое. Редкие ряды — точки до/после и порог показателя. Подтверждение: +5 (один ряд) / +8 (два и более); свежие ряды не видят падения: −12; расходятся: −3. Устаревшие или не охватывающие момент ряды в сверке не участвуют (об этом сказано).
3. Слепые зоны. Источники, способные показать другие причины по правилу (для «не найдено» — по всем подходящим правилам), но устаревшие, не подключённые или не наблюдавшие сайт в момент падения: −3 за каждый, не больше −9, названы в карточке. Для «причина не найдена» уверенность не меняется (10), а подпись и проверки сообщают, чего не хватает.
4. Время причины. Для правок, найденных стражем, пишется, что момент — обнаружение, а правка могла быть раньше (при интервале ≥ 48 ч −3).

Отзыв пользователя «подтверждено/отклонено» фиксирует оценку (≥90 / ≤10); поправки модели при этом только показываются. Итоговая уверенность 5–95.

«До и после» для правок (Compare, /before-after)

Правка — пометка, изменение стража, выполненная задача или дата (не старше 120 дней, не позже чем час назад). По каждому показателю — Effect::judge. Контроль: те же ряды других сайтов пользователя (до 8) за тот же период; adjust считает разность разностей. Значимое изменение сайта при разности меньше порога показателя → «общий фон» (external); значимое при разности больше → вердикт по разности; почти не изменившийся сайт при заметно сдвинувшихся контролях → вердикт относительно фона. Контроль — только плотные ряды. Надёжность = 80 − нет контроля (15) / один контроль (6) + 4 за два и более − меньше 10 дней «после» (8) − устаревшие данные (12) − ждущие показатели (5) − помехи (8 за каждую, до 24) − разнонаправленные изменения (6); 5–95. Помехи: сбои доступности после правки и другие правки сайта (пометки, стража, задачи) в пределах ±3 суток и в окне «после».

Диспетчерская 4.1 (версия 106)

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

Сезонность год к году (Season)

Те же окна «до» и «после», сдвинутые на 364 дня (дни недели совпадают), оцениваются через Effect::judge. Если год назад в эти даты показатель изменился так же — это сезонность, а не правка. Сезонными считаются визиты, клики и видимость. Источники хранят ряды недолго, поэтому Season::archiveHost раз в сутки копирует их в таблицу series_archive (хранится 800 дней); Series::get достраивает ряд архивом, живые значения важнее. Архивация идёт из bin/verify.php (cron). Пока истории меньше года, поправка не применяется и причина названа («накоплено N дн.»). Вес оценки: 1,0 при полном окне год назад, 0,5 при неполном.

Контрольные сайты (Controls)

Кандидаты — другие сайты пользователя. Оценка = тематика сайта (0,35) + общие слова запросов (до 0,25) + совместное движение недельных изменений за 16 недель (до 0,40). Без данных о движении оценка не выше 0,6. Хороший контроль — от 0,30; если хороших нет, берётся слабый (0,2) с понижением надёжности. Отбрасываются: сайты без данных, с уровнем ниже порога, с движением в обратную сторону (корреляция ниже 0,15) и сайты с собственной правкой рядом с датой (пометка, выполненная задача, события контента/инфраструктуры/индексации в пределах ±3 суток, сбой доступности в окне «после»). Причина отказа показана на странице. Тематика задаётся в карточке сайта («Тематика»).

Фон: контроли и сезонность

Compare::background — взвешенное среднее: контроли (вес до 2) и сезонность (вес до 1). Если есть только сезонность — она берётся с понижением (×0,8 при полном окне, ×0,65 при неполном). Источник фона (controls, season, controls+season) показан в строке и в тексте вывода. Надёжность: хороший контроль +4, один −4, слабый −9, без контроля, но с сезонностью −8, совсем без фона −15; учтённая сезонность +3.

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

Каждая проверка стража пишется в wd_cover (по дню: число проверок, первая и последняя, самый долгий перерыв). Freshness::covers использует журнал, а до его начала остаётся допущение «наблюдал с момента подключения» — об этом сказано в выводе Evidence. Freshness::guardHistory показывает процент дней с проверками за год и перерывы от двух суток; карточка свежести выводит «Покрытие стража».

Калибровка уверенности (Calibration)

Каждый отзыв «подтверждено/отклонено» сохраняет исходную уверенность модели (первую, повторный отзыв её не меняет). От 8 отзывов (не меньше двух каждого вида) строится монотонная (PAV) кривая «уверенность → доля подтверждений», со сглаживанием (n·кривая + 10·исходная)/(n + 10) и границами 5–95. Калибровка включается, только если по скользящему контролю (leave-one-out) оценка Брайера улучшается; иначе уверенность остаётся прежней, причина показана. Исходная уверенность хранится в confidence_raw, у скорректированных гипотез есть пояснение. Подтверждённые и отклонённые гипотезы не меняются. Таблица по уровням уверенности — на странице причин.

Простой и профессиональный вид (версия 155)

Экран «Сегодня» показывается в двух видах. Переключатель «Просто / Профи» стоит в шапке экрана и связан с режимом бокового меню: это одна настройка на всё приложение, она хранится в базе (nav_prefs) и в cookie меню. По умолчанию включён простой вид.

Простой вид (Guide)

Класс Dispatch\Guide ничего не выводит и не переводит, он отдаёт коды и числа, а тексты подставляет шаблон. Расчёт детерминированный, без ИИ.

• Главный вывод: none (сайтов нет), down (сайт не открывается), critical (есть срочные дела), todo (много дел или оценка ниже 60), fine (мелочи), ok (всё хорошо).
• Блок «Начните отсюда» — первая задача по приоритету: время по таблице Planner, ссылка на пошаговую инструкцию (/fix), если она есть для этой проверки, и кнопка «Я исправил — проверить».
• Задачи по срокам: срочно, сегодня, на этой неделе, позже; порядок внутри группы — по приоритету.
• Чек-лист настройки из восьми шагов считается по реальным данным: сайт, первая проверка, наблюдение, доступность, подтверждение владения, поисковые системы, уведомления, конкурент.
• Рекомендация об устаревшей CMS показывается только по сайтам с подтверждённым владением (правила из Versions\Advisor).

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

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