Технічний аналіз завдань

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

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

Сайт працює нестабільно: періодично не відкривається, видає помилки або перериває шлях користувача від реклами до форми заявки.

Власник отримує не лише сайт, що працює, а й зрозуміле пояснення причин внесених змін та ризиків, що залишаються.

Щоранку сайти ставали недоступними. Візуально це виглядало як випадкова проблема з сервером або SSL, але регулярність таких випадків вказувала на системну причину.

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

Листи не доходять, потрапляють у спам, форми на сайті не надсилають заявки або доменна пошта налаштована через кілька несумісних сервісів.

Пошта стає контрольованою: стає зрозуміло, хто отримує листи, хто їх надсилає, які записи за це відповідають і де шукати помилки.

Пошта формально існувала, але довіри до домену не було: налаштування MX, SPF, DKIM, DMARC та SMTP були неповними або несумісними. Для бізнесу це означає втрачені відповіді клієнтів та за…

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

Незрозуміло, хто контролює домен, DNS, хостинг, пошту, CRM, рекламу, 2FA та резервні облікові записи після звільнення співробітників або підрядників.

Власник розуміє, де знаходяться ключі від інфраструктури, хто має доступ і які ризики потрібно усунути в першу чергу.

Форма показує, що відправлення відбулося успішно або що сталася помилка без пояснення, але заявка не надходить на електронну пошту, у CRM чи у вигляді повідомлення в Telegram.

Після виправлення стає зрозуміло, де створюється заявка, куди вона надсилається, яка служба підтверджує її отримання та де шукати помилку у разі повтору.

Перевірка з одного комп’ютера показала, що сайт працює, але користувачам з інших мереж він не відкривався. Це небезпечна ситуація: власник бачить 200 OK, а реальні клієнти бачать порожнечу…

Проблему перестали шукати навмання. Стало зрозуміло, де сайт дійсно доступний, де трафік обривається, а де потрібно використовувати дзеркала, проксі або DNS.

Сертифікат є, але браузер показує «Not secure», з’являються попередження про змішаний вміст, перенаправлення замикаються у коло або частина URL-адреси залишається на HTTP.

Користувач бачить одну стабільну HTTPS-адресу, браузер не виявляє помилок, форми та зовнішні ресурси працюють без змішаного контенту.

Після зміни DNS частина трафіку надходить на стару IP-адресу, частина — на нову. Через це користувачі бачать різні версії сайту та надсилають запити в різні місця.

Домен стабільно вказує на потрібний сервер, старий сайт не приймає випадковий трафік, а власник розуміє, де тепер здійснюється управління DNS.

Користувач надсилає форму, сайт показує, що надсилання відбулося успішно, але в CRM заявка не з’являється або з’являється не повністю.

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

Після переїзду сайт візуально працює, але пошукові та рекламні посилання ведуть на старі URL-адреси, з’являються помилки 404, неправильні canonical та пошкоджена карта сайту.

Новий домен стає основною робочою версією без втрати заявок через старі посилання та технічне сміття.