Технические разборы задач

После переноса WordPress на новый домен обычно ломаются внутренние ссылки, формы заявок, sitemap, robots.txt, канонические URL и старые редиректы. Визуально сайт может открываться, но реклам…

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

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

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

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

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

Письма не доходят, попадают в спам, формы сайта не доставляют заявки или доменная почта настроена через несколько несогласованных сервисов.

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

Почта формально существовала, но доверия к домену не было: MX, SPF, DKIM, DMARC и SMTP-настройки были неполными или несогласованными. Для бизнеса это означает потерянные ответы клиентов и за…

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

Неясно, кто контролирует домен, DNS, хостинг, почту, CRM, рекламу, 2FA и резервные входы после сотрудников или подрядчиков.

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

Форма показывает успешную отправку или ошибку без объяснения, но заявка не приходит в почту, CRM или Telegram-уведомление.

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

Проверка с одного компьютера показывала, что сайт работает, но у пользователей из других сетей он не открывался. Это опасная ситуация: владелец видит 200 OK, а реальные клиенты видят пустоту…

Проблему перестали искать вслепую. Стало видно, где сайт реально доступен, где падает маршрут, а где нужно работать с зеркалами, прокси или DNS.

Сертификат есть, но браузер показывает Not secure, появляются предупреждения mixed content, редиректы ведут по кругу или часть URL остаётся на HTTP.

Пользователь видит один стабильный HTTPS-адрес, браузер не ругается, формы и внешние ресурсы работают без смешанного контента.

После изменения DNS часть трафика идёт на старый IP, часть — на новый. Из-за этого пользователи видят разные версии сайта и отправляют заявки в разные места.

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

Пользователь отправляет форму, сайт показывает успешную отправку, но в CRM заявка не появляется или появляется не полностью.

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

После переезда сайт визуально работает, но поисковые и рекламные ссылки ведут на старые URL, появляются 404, неправильные canonical и битая карта сайта.

Новый домен становится основной рабочей версией без потери заявок из-за старых ссылок и технического мусора.