MainWP Domain Monitor - Плагин WordPress

Руководство по настройке и использованию MainWP Domain Monitor

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

Материал рассчитан на владельца нескольких WordPress-сайтов, вебмастера, агентство поддержки и администратора, который уже использует MainWP Dashboard. Мы не будем повторять короткое описание продукта. Вместо этого пройдём путь от подготовки и установки до реального сценария: проверить портфель клиентских доменов, настроить порог уведомлений, вручную заполнить данные для проблемного TLD, добавить доменную информацию в клиентский отчёт и разобрать типичные сбои.

Важно понимать ограничение заранее: доменная проверка зависит от доступности RDAP или WHOIS-данных по конкретному TLD. Поэтому MainWP Domain Monitor лучше воспринимать как рабочий центр контроля и напоминаний, а не как абсолютный источник истины по каждому домену мира. Там, где реестр домена не отдаёт дату окончания или отдаёт неполный ответ, придётся использовать ручной ввод, внешнюю проверку у регистратора или отдельный мониторинг.

Какую задачу закрывает расширение в рабочем контуре MainWP

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

MainWP Domain Monitor переносит эту задачу внутрь MainWP Dashboard. Расширение показывает доменную информацию для подключённых Child Sites, умеет запускать проверку вручную, выполняет автоматические проверки по расписанию, отправляет email-уведомления при приближении даты окончания и даёт данные для Pro Reports, WP-CLI и REST API. Это особенно полезно там, где MainWP уже используется как центральная панель обслуживания: обновления, мониторинг, отчёты, клиенты и теперь домены находятся рядом.

На практике расширение помогает не только "узнать дату окончания". Оно помогает выстроить повторяемый процесс:

• Быстро проверить домены всех подключённых сайтов после импорта или аудита портфеля.
• Выделить домены, у которых срок окончания близко к внутреннему порогу агентства.
• Заметить домены с неполными или подозрительными данными и вынести их в ручной контроль.
• Добавить статус домена в клиентский отчёт, если используется MainWP Pro Reports.
• Запустить проверку из консоли или внешней автоматизации, если у команды есть серверные регламенты.

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

Что видно в доменной карточке

Официальная документация и страница продукта указывают, что расширение работает с такими данными, как домен, регистратор, WHOIS-сервер, контактные данные, серверы имён, текущий статус, дата создания, дата обновления, дата окончания и время последней проверки. Набор фактически видимых полей может зависеть от того, что вернул источник доменной информации. Если регистр скрывает часть данных или TLD отдаёт урезанный ответ, не стоит ждать полноценной карточки.

Самая важная строка для ежедневной работы - не только дата окончания, но и последняя проверка. Если дата окончания выглядит нормально, но последняя проверка давно не обновлялась, это уже отдельный симптом: автоматическая задача могла не сработать, Dashboard мог быть недоступен для cron-триггера, или сам источник доменных данных временно не ответил.

Чем доменный мониторинг отличается от проверки доступности и SSL

В MainWP есть отдельные направления мониторинга: доступность сайта, SSL-сертификаты, безопасность, уязвимости и другие операционные проверки. Domain Monitor решает другую задачу. У сайта может быть рабочий хостинг, корректный SSL и зелёная проверка доступности, но домен при этом может приближаться к окончанию. И наоборот: домен может быть продлён, но сайт может падать из-за сервера или ошибки приложения.

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

Кому подходит MainWP Domain Monitor и где он может быть лишним

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

Когда расширение будет полезным

MainWP Domain Monitor хорошо ложится на регулярную поддержку WordPress-сайтов. Особенно там, где у каждого сайта есть ответственный клиент, а администратор должен заранее сообщить о риске и не держать эту информацию в личной памяти.

• У агентства есть несколько десятков Child Sites, подключённых к MainWP Dashboard.
• Домены клиентов зарегистрированы у разных регистраторов, и письма о продлении не всегда приходят администратору.
• Внутренний регламент требует предупреждать клиента за определённое количество дней до окончания домена.
• Команда использует Pro Reports и хочет показывать доменный статус в отчётах.
• Администратор хочет запускать массовую проверку через WP-CLI или получать данные через REST API.

Отдельная сильная сторона продукта - связка с MainWP. Если все сайты уже заведены в Dashboard, не нужно переносить список доменов в ещё один сервис вручную. Расширение берёт контекст из подключённых сайтов и превращает его в доменный список для проверки.

Когда стоит выбрать другой подход

Есть ситуации, где MainWP Domain Monitor не будет лучшим единственным инструментом. Например, если вы ведёте большое количество доменов, которые не привязаны к WordPress-сайтам, вам может подойти отдельный SaaS-мониторинг доменов или внутренний реестр с API регистратора. Если важны DNS-изменения, бренд-мониторинг, обнаружение похожих доменов или юридический контроль портфеля, Domain Monitor не закрывает эти задачи.

Также расширение может быть неудобным, если большая часть доменов находится в TLD, по которым RDAP или WHOIS отдаёт неполные данные. Документация MainWP прямо предусматривает ручной ввод для неподдерживаемых или проблемных зон. Это нормальный рабочий обход, но он меняет характер процесса: вместо полностью автоматической проверки вы получаете комбинированную схему, где часть доменов проверяется автоматически, а часть ведётся вручную.

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

Что проверить перед установкой на MainWP Dashboard

Domain Monitor ставится на сайт, где установлен MainWP Dashboard, а не на каждый Child Site. Это важная деталь: расширение работает как надстройка центральной панели, а Child Sites должны быть уже подключены к Dashboard через MainWP Child. Если установить расширение не туда, ожидаемой страницы мониторинга в рабочем контуре MainWP не появится.

Минимальная подготовка

Перед установкой проверьте не только наличие MainWP Dashboard, но и состояние самого списка сайтов. Расширение будет полезным только тогда, когда список Child Sites актуален, URL сайтов корректны, а клиентские связи не перепутаны.

• Убедитесь, что MainWP Dashboard установлен, активен и доступен администратору.
• Проверьте, что нужные WordPress-сайты подключены через MainWP Child и видны в списке сайтов.
• Сверьте основные URL сайтов: доменный мониторинг бессмысленен, если в Dashboard остались старые staging-домены или временные адреса.
• Проверьте email-доставку с Dashboard, потому что уведомления зависят от способности WordPress отправлять письма.
• Проверьте работу WP-Cron или внешнего cron-триггера, если собираетесь использовать автоматические проверки.
• Составьте список доменов с нестандартными TLD, IDN, региональными зонами или ручным продлением, чтобы после первой проверки уделить им внимание.

Если Dashboard почти не получает внешних запросов, автоматические задачи WordPress могут выполняться с задержкой. Для MainWP это особенно важно, потому что Dashboard часто расположен на служебном сайте, куда пользователи не заходят. Документация MainWP рекомендует следить за cron на низкотрафиковом Dashboard и при необходимости запускать WP-Cron внешним запросом или серверным расписанием.

Проверка email до включения предупреждений

Расширение может отправлять письма при приближении срока окончания домена, но оно не решает проблемы доставки почты на уровне сервера. Если WordPress на Dashboard отправляет письма через стандартную PHP-функцию, они могут попадать в спам или вообще не уходить. Поэтому перед тем как полагаться на уведомления, отправьте тестовое письмо через проверочный плагин или настройте SMTP.

Не пропускайте этот шаг, если доменные напоминания будут использоваться как часть клиентского регламента. Отсутствие письма в нужный момент может выглядеть как ошибка Domain Monitor, хотя настоящая причина будет в почтовой конфигурации Dashboard.

Порог уведомлений как управленческое решение

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

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

Установка расширения и первая проверка доменов

Официальная установка выполняется из панели MainWP. Если расширение доступно в вашем наборе Add-ons, используйте штатный установщик, потому что он проще ручной загрузки архива и снижает риск поставить файл не на тот сайт. В статье не разбираем покупку, лицензию или оплату - предполагаем, что расширение уже доступно администратору.

Установка через Add-ons

1. Откройте сайт с MainWP Dashboard.
2. Перейдите в MainWP > Add-ons или MainWP > Add-ons > Manage Add-ons, в зависимости от версии интерфейса.
3. Нажмите Install Add-ons.
4. Найдите Domain Monitor, отметьте расширение и запустите установку.
5. После установки нажмите Activate Add-ons или активируйте расширение в карточке Add-on.
6. Перейдите в настройки Domain Monitor и сохраните базовые параметры перед первой массовой проверкой.

Если вы устанавливаете расширение вручную через Plugins > Add New, помните главное правило: ZIP-файл загружается на Dashboard site. Устанавливать его на Child Sites не нужно. Child Sites уже участвуют в системе через MainWP Child, а логика расширения живёт в центральной панели.

Первая ручная проверка

После активации откройте MainWP > Add-ons > Domain Monitor > Dashboard. На первой итерации не стоит сразу полагаться на автоматическое расписание. Сначала запустите ручную проверку через Check All Sites Domains и дождитесь завершения процесса. Это даст стартовую картину: какие домены проверились, какие поля заполнены, какие сайты требуют внимания.

Если нужно проверить только часть сайтов, используйте Bulk Actions или действие Check Domain в меню конкретного сайта. Это удобно после исправления одной записи: не нужно гонять всю таблицу, если вы хотите перепроверить только один домен после ручного обновления или смены регистратора.

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

Как читать таблицу после первого запуска

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

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

Настройка уведомлений, расписания и ручного ввода

После первой проверки переходите к настройкам. В документации Domain Monitor описаны три ключевых параметра: Notifications threshold, Automatically check domains и Automated domain checks frequency. Именно они превращают расширение из ручной таблицы в рабочую систему предупреждений.

Порог уведомлений

Notifications threshold задаёт, за сколько дней до окончания домена система должна отправить письмо. Универсального значения нет, потому что оно зависит от процесса продления. Для личного сайта можно выбрать короткий интервал. Для агентства лучше отталкиваться от того, сколько времени требуется на согласование с клиентом, оплату, проверку продления и повторную доменную проверку.

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

Автоматические проверки

Automatically check domains включает проверки по расписанию. Если функция выключена, расширение остаётся полезным для ручного аудита, но не сможет само обновлять состояние доменов. Automated domain checks frequency задаёт частоту автоматической проверки. Выбор частоты зависит от размера портфеля и важности ранних уведомлений.

Для большинства сайтов ежедневная или регулярная проверка с разумным порогом уведомлений выглядит достаточной. Если портфель маленький, ручная проверка перед ежемесячным отчётом тоже может быть рабочей. Но если вы используете Domain Monitor как систему предупреждений, автоматическая проверка должна быть включена, а cron на Dashboard должен реально выполняться.

Что проверять после сохранения

• Включена ли автоматическая проверка в настройках Domain Monitor.
• Обновляется ли время последней проверки после ручного запуска.
• Есть ли активность в MainWP > Info > Cron Schedules, если вы диагностируете расписание.
• Приходит ли тестовая почта с Dashboard и не попадает ли она в спам.
• Не блокирует ли firewall, CDN или HTTP-аутентификация запросы к Dashboard, если cron запускается внешним монитором.

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

Ручной ввод для неподдерживаемых или проблемных доменов

Официальная документация предусматривает ручной ввод данных, если домен находится в неподдерживаемой зоне или автоматический источник возвращает неполную информацию. Для этого нужно открыть конкретный Child Site в Domain Monitor, перейти на вкладку Settings, включить Manual Domain information entry, сохранить настройку, затем открыть Edit Domain Info и заполнить данные вручную.

Ручной ввод не стоит считать "костылём". Для некоторых доменных зон это единственный честный способ держать информацию в MainWP, не выдавая неполный WHOIS-ответ за правду. Главное - пометить такие домены во внутреннем процессе. Например, можно вести список вручную управляемых доменов и проверять их у регистратора перед клиентским отчётом.

Что не стоит включать без причины

В Domain Monitor нет большого набора рискованных переключателей, но есть риск организационной ошибки. Не включайте автоматические проверки, пока не проверили доставку писем и cron. Не выставляйте слишком короткий порог, если клиенту нужно время на реакцию. Не считайте пустую строку "доменом без срока" - это может быть проблема источника данных. Не добавляйте вручную дату окончания без пометки, откуда она взята и когда её нужно сверить снова.

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

Особенности RDAP, WHOIS и поддерживаемых TLD

Самая продуктовая часть Domain Monitor - не кнопка проверки, а работа с доменными источниками данных. Документация MainWP указывает список поддерживаемых TLD и отдельно предупреждает, что проверка может не вернуть данные или вернуть неполную информацию для некоторых зон из-за ограничений или отсутствия доступных данных в RDAP. В community-обсуждениях похожие симптомы встречаются по отдельным региональным зонам и по случаям, где WHOIS-сервер отдаёт пустой или недостаточный ответ.

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

Как работать с проблемными TLD

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

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

Почему данные могут отличаться от регистратора

RDAP и WHOIS не всегда возвращают полную картину. Некоторые реестры ограничивают публичный вывод. Некоторые источники меняют формат ответа. Иногда после продления данные обновляются не сразу. Иногда сторонние сервисы и MainWP могут получить один и тот же временно неверный ответ. Поэтому при споре между таблицей Domain Monitor и кабинетом регистратора лучше ориентироваться на регистратора, а в MainWP обновлять или перепроверять запись.

Это не делает расширение бесполезным. Наоборот, оно показывает, какие домены требуют внимания. Но если вы строите процесс для клиентов, важно зафиксировать границу ответственности: Domain Monitor предупреждает и агрегирует данные, а спорные случаи подтверждаются внешней проверкой.

Как связать доменный контроль с Pro Reports, WP-CLI и REST API

MainWP Domain Monitor интересен не только веб-интерфейсом. Официальные источники подтверждают три дополнительных направления: Pro Reports tokens, WP-CLI команду проверки и REST API endpoint для данных Domain Monitor. Для агентства это полезно, потому что доменная информация может попасть в отчёт, консольный регламент или внешнюю систему контроля.

Данные в клиентском отчёте

В Pro Reports доступны токены Domain Monitor: доменное имя, регистратор, дата обновления, дата создания, дата окончания, количество дней до окончания, статус и время последней проверки. Это позволяет добавить в клиентский отчёт небольшой раздел о домене. Такой блок особенно полезен, если клиент оплачивает поддержку и ожидает не только список обновлённых плагинов, но и контроль важных внешних рисков.

Не перегружайте отчёт всеми полями. Для клиента чаще всего важны три вещи: домен, срок, статус. Дополнительные поля вроде регистратора и последней проверки полезны, если вы хотите показать прозрачность процесса. Если в отчёте печатается сам токен, а не значение, проверьте, что расширение установлено и активно, данные для сайта действительно есть, а шаблон Pro Reports собран по документации. В community-обсуждениях подобные ситуации разбираются как вопрос шаблона и наличия данных, а не как автоматическое доказательство поломки Domain Monitor.

Проверка через WP-CLI

Документация Domain Monitor приводит команду для проверки одного или нескольких сайтов и вариант для всех сайтов. Это удобно, если администратор ведёт регламент через серверную консоль или хочет запускать проверку перед формированием отчёта.

wp mainwp-domain-monitor check 129
wp mainwp-domain-monitor check --all

Перед использованием убедитесь, что WP-CLI установлен на сервере Dashboard, команда выполняется в контексте нужного WordPress-сайта и ID сайта известен. Если команда не видит MainWP или возвращает неожиданный результат, сначала проверьте базовые WP-CLI команды MainWP, а уже потом диагностируйте Domain Monitor.

Данные через REST API

MainWP REST API v2 использует Bearer token и отдаёт данные по HTTP. Postman-коллекция MainWP содержит endpoint для Domain Monitor в ветке Pro Reports. API-сценарий подходит техническим командам: например, можно подтянуть данные в внутреннюю панель агентства, сверить доменные сроки с CRM или добавить контроль перед ежемесячной отправкой отчётов.

Здесь важно не путать доступ к API с публичностью Dashboard. Документация REST API подчёркивает, что Dashboard должен быть доступен системе, которая отправляет запросы, а ключи нужно хранить безопасно. Не передавайте токены в Codex, в публичные инструкции или в клиентские письма. Для обычного пользователя веб-интерфейс и email-уведомления обычно достаточно, API нужен только когда есть понятная интеграционная задача.

Практический сценарий: аудит портфеля клиентских доменов

Теперь соберём настройки в реальный рабочий сценарий. Представим агентство, которое обслуживает группу клиентских WordPress-сайтов через MainWP. Цель - один раз навести порядок в доменной информации, затем получать предупреждения заранее и включать доменный статус в ежемесячный контроль.

Цель

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

Подготовка

Перед началом убедитесь, что Child Sites подключены, список сайтов не содержит старых тестовых URL, email с Dashboard доставляется, а Domain Monitor установлен на Dashboard. Если вы ведёте клиентов в MainWP, полезно заранее связать сайты с клиентскими карточками. Так доменные предупреждения легче превратить в действие: написать нужному клиенту, приложить отчёт или назначить задачу внутри команды.

Шаги

1. Откройте Domain Monitor > Settings и задайте порог уведомлений по внутреннему регламенту.
2. Включите автоматическую проверку, если готовы полагаться на расписание, и выберите частоту.
3. Откройте Domain Monitor > Dashboard и запустите Check All Sites Domains.
4. После завершения отсортируйте таблицу по ближайшему сроку и отдельно отметьте строки с неполными данными.
5. Для доменов с неподдерживаемыми или проблемными TLD включите Manual Domain information entry и заполните данные после сверки у регистратора.
6. Для спорных строк выполните Check Domain повторно и сравните результат с внешней проверкой.
7. Если используете Pro Reports, добавьте в шаблон только нужные токены и проверьте отчёт на одном тестовом клиенте.

Проверка результата

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

Нюанс, который часто мешает

Главная ловушка - считать первую таблицу окончательной. Если часть доменов показывает неправильную дату или пустые поля, это не повод сразу менять весь процесс. Сначала разделите проблемы: расписание, email, источник WHOIS/RDAP, TLD, ручной ввод, шаблон отчёта. Тогда исправления будут точными. Например, если ручной запуск обновляет данные, а автоматический нет, вероятнее всего нужно смотреть cron. Если и ручной запуск не помогает только для определённой зоны, смотрите поддержку TLD и возможность ручного ввода.

Проверка результата после настройки

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

Проверка данных

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

Проверка расписания

Проверьте, обновляется ли время последней автоматической проверки. Если Dashboard низкотрафиковый, проверьте MainWP > Info > Cron Schedules и убедитесь, что нужные cron-события реально выполняются. Если события задерживаются, настройте внешний мониторинг Dashboard URL или серверный запрос к wp-cron.php?doing_wp_cron по рекомендациям MainWP. Не заменяйте это собственным мониторингом Child Sites: задача состоит в том, чтобы триггерить Dashboard, где живёт расширение.

Проверка уведомлений

Если у вас есть тестовый домен с близким сроком или ручная запись, которая позволяет безопасно смоделировать уведомление, используйте её для проверки email. Если такой возможности нет, проверьте хотя бы доставку обычных писем WordPress с Dashboard и убедитесь, что почтовый домен не режется фильтрами. Для продакшен-процесса стоит использовать SMTP и журнал отправки, чтобы в спорной ситуации видеть, отправлялось ли письмо.

Проверка отчёта

Если вы добавляете доменные данные в Pro Reports, создайте тестовый отчёт по одному сайту. Проверьте, что токены заменяются значениями, а не печатаются как обычный текст. Если часть данных пустая, вернитесь к Domain Monitor Dashboard и убедитесь, что данные для этого сайта есть. Отчёт не сможет показать то, что расширение не получило или не сохранило.

Мини-итог: рабочая настройка подтверждается не одним зелёным экраном, а цепочкой: данные получены, cron обновляет проверку, email доставляется, спорные TLD вынесены в ручной контроль, отчёт показывает значения.

Как встроить доменный мониторинг в регламент обслуживания

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

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

Роль администратора

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

Для больших портфелей полезно вести короткий журнал исключений. В него попадают домены с ручным вводом, домены с нестабильным TLD, домены у сторонних подрядчиков и домены, где регистратор не отдаёт полные публичные данные. Такой журнал не должен дублировать всю таблицу Domain Monitor. Его задача - объяснить, почему конкретная строка требует особого обращения.

Роль менеджера клиента

Менеджер не обязан разбираться в RDAP и WHOIS. Ему нужен понятный сигнал: домен скоро заканчивается, продление подтверждено или данные требуют уточнения у владельца. Поэтому в коммуникации с клиентом лучше не отправлять длинный технический отчёт. Достаточно указать домен, действие, срок реакции и источник подтверждения. Если Domain Monitor показывает проблему, но регистратор подтверждает продление, менеджер должен видеть эту пометку, чтобы не пугать клиента неверным предупреждением.

Роль отчёта

Pro Reports стоит использовать как витрину результата, а не как единственный механизм контроля. В отчёте можно показать доменный статус, но рабочее решение принимается до отправки отчёта. Если отчёт показывает, что домен требует внимания, рядом должен быть комментарий или задача. Если отчёт показывает пустое поле, это не "мелкая косметика", а сигнал вернуться к Domain Monitor и проверить данные для конкретного сайта.

Мини-чек-лист ежемесячного контроля

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

Хороший результат регламента - когда любой член команды может открыть Dashboard, понять, какие домены требуют действия, и увидеть, какие строки нельзя трактовать автоматически. Тогда Domain Monitor становится не просто инструментом проверки, а частью управляемой поддержки WordPress-сайтов.

Практичные идеи применения для разных команд

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

Для агентства поддержки

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

Для технического администратора

Администратор может использовать WP-CLI или REST API, чтобы связать Domain Monitor с внутренним регламентом. Например, консольная проверка запускается перед еженедельным отчётом, а API-данные попадают в внутренний список рисков. Это уместно только если команда умеет безопасно хранить ключи и поддерживать автоматизацию. Для маленькой команды веб-интерфейс часто проще и надёжнее.

Для клиентских отчётов

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

Для сайтов с проблемными зонами

Если часть портфеля находится в TLD, где автоматические данные нестабильны, используйте Domain Monitor как смешанную систему. Автоматические домены остаются в обычном режиме, а проблемные домены получают ручные записи и отдельную проверку у регистратора. Такой сценарий лучше, чем полностью отказаться от мониторинга из-за нескольких доменных зон.

Частые проблемы и диагностика MainWP Domain Monitor

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

Автоматическая проверка не обновляет домены

Симптом: ручная проверка через Check Domain работает, но автоматическое расписание не меняет время последней проверки или данные долго остаются старыми.

Возможная причина: WP-Cron на Dashboard не запускается регулярно. Это особенно вероятно для служебных Dashboard-сайтов с низким трафиком.

Что проверить

• Включена ли опция Automatically check domains.
• Обновляется ли активность в MainWP > Info > Cron Schedules.
• Есть ли внешний запрос к Dashboard URL или к wp-cron.php?doing_wp_cron.
• Не блокирует ли запрос CDN, WAF, basic authentication или firewall.

Как исправить: настройте регулярный внешний GET-запрос к Dashboard или серверный cron-запрос по документации MainWP. После этого выполните ручную проверку и наблюдайте, обновляется ли расписание. Если cron работает, но данные всё равно не меняются, переходите к проверке источника доменных данных.

Домен показывает неправильную дату или статус "истёк"

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

Возможная причина: WHOIS/RDAP-источник вернул неполные или устаревшие данные. В community-обсуждениях MainWP встречались случаи, где отдельные TLD отдавали пустой ответ или данные, которые требовали повторной проверки.

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

Как исправить: для стабильного автоматического домена иногда помогает повторная проверка. Для домена, где источник регулярно не отдаёт нужные данные, включите ручной ввод и ведите дату по данным регистратора. Если проблема массовая и касается важной зоны, проверьте свежую документацию и support-каналы MainWP.

Письма о доменах не приходят

Симптом: домен подходит к порогу, но администратор не получает уведомления.

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

Что проверить: проверьте значение Notifications threshold, убедитесь, что данные домена обновлены, отправьте тестовое письмо с Dashboard и проверьте спам. Если письма WordPress в целом не доставляются, Domain Monitor не сможет исправить это своими настройками.

Как исправить: настройте SMTP на Dashboard, включите журнал отправки писем и повторите тест. Если email работает, но уведомление не приходит, проверьте, попадает ли домен в порог и не устарела ли последняя проверка.

Pro Reports показывает токен вместо значения

Симптом: в отчёте появляется строка вроде [domain.monitor.expiry.date], а не дата окончания.

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

Что проверить: убедитесь, что Domain Monitor установлен и активен на Dashboard, данные по конкретному сайту видны в таблице, а шаблон Pro Reports использует актуальные токены из документации. Создайте тестовый отчёт по одному сайту, чтобы не диагностировать проблему на большом пакетном отчёте.

Как исправить: сначала добейтесь корректных данных в Domain Monitor Dashboard, затем упростите шаблон до одного-двух токенов и проверьте замену. Если после этого токен всё равно печатается как текст, смотрите документацию Pro Reports и support-обсуждения по шаблонам.

Расширение не подходит для части доменов

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

Возможная причина: TLD или конкретный WHOIS/RDAP-источник не отдаёт нужную информацию в формате, который расширение может использовать. В таких случаях ошибка может быть вне кода расширения.

Как исправить: не отключайте весь мониторинг, если остальные домены работают. Вынесите проблемные домены в ручной ввод, проверяйте их у регистратора и добавьте внутреннюю пометку. Если большинство вашего портфеля находится в таких зонах, сравните Domain Monitor с внешним сервисом, который лучше покрывает нужные TLD.

Ограничения, безопасность и аккуратная эксплуатация

Доменный мониторинг выглядит простой задачей, но вокруг него много быстро устаревающих и спорных данных. Поэтому в руководстве нельзя обещать стопроцентную точность, автоматическое продление или полную совместимость со всеми зонами. Безопасная эксплуатация MainWP Domain Monitor строится на проверяемых действиях и понятной границе ответственности.

Не храните лишние секреты в процессе

Для обычной работы Domain Monitor не нужно передавать кому-либо пароли от регистратора, API-ключи клиента или доступы к DNS. Если спорный домен нужно проверить у регистратора, делайте это через ответственного владельца доступа или через внутреннюю систему агентства. Не вставляйте секреты в отчёты, шаблоны, внешние запросы и служебные задачи.

Не полагайтесь только на одну проверку

Если домен критичен для бизнеса, используйте несколько уровней подтверждения: Domain Monitor как центральную панель, кабинет регистратора как источник продления, email или тикет как подтверждение клиенту, и при необходимости внешний сервис для независимого мониторинга. Это особенно важно для магазинов, проектов с платным трафиком и доменов, где смена владельца или просрочка может создать юридические или репутационные проблемы.

Не добавляйте неподтверждённый код

Для Domain Monitor нет необходимости писать PHP-сниппеты, менять ядро WordPress или править код расширения. Официально подтверждённые технические пути - настройки расширения, ручной ввод, WP-CLI, REST API и Pro Reports tokens. Если вам нужен нестандартный экспорт или интеграция, лучше использовать REST API или WP-CLI, чем придумывать внутренние хуки без документации.

Единственная безопасная "правка", которую можно рекомендовать в общем виде, - организационная: добавить доменные проверки в регламент обслуживания и настроить cron/email на Dashboard. Это не ломает расширение и легко откатывается.

Когда MainWP Domain Monitor будет удачным выбором

MainWP Domain Monitor стоит использовать, если вы уже обслуживаете WordPress-сайты через MainWP Dashboard и хотите добавить к обновлениям, отчётам и мониторингу ещё один важный слой контроля - сроки доменов. Расширение особенно полезно для агентств, где один забытый домен может превратиться в срочный тикет, потерю доверия и ненужный простой сайта.

Перед внедрением проверьте Dashboard, Child Sites, email, cron и список TLD. После установки не останавливайтесь на первой таблице: выполните ручную проверку, настройте порог уведомлений, отметьте проблемные зоны, добавьте ручной ввод там, где автоматический источник ненадёжен, и проверьте, как данные попадают в отчёт. Такой подход превращает расширение в рабочий регламент, а не в ещё одну вкладку в админ-панели.

Если ваш сценарий совпадает с этим контуром, можно перейти к блоку загрузки и получить файл MainWP Domain Monitor, затем безопасно проверить его на Dashboard: сначала ручной аудит, потом расписание, потом уведомления и только после этого клиентские отчёты.