Власник відкриває сайт без проблем, а частина клієнтів бачить помилку або нескінченне завантаження. Така ситуація ще не доводить, що потрібно терміново змінювати хостинг. Причина може бути в DNS, сертифікаті, окремому мережевому маршруті, правилах захисту чи локальному кеші. Без перевірки переїзд ризикує додати нові змінні до вже незрозумілого збою.
Почніть із точного опису: не «сайт не працює», а яка адреса не відкривається, у кого, коли й з яким повідомленням. Одна літера в піддомені або різниця між HTTP та HTTPS може означати зовсім інший сценарій.
Як розділити проблеми DNS, сертифіката й доступності сервера
DNS відповідає за визначення адреси сервера за доменним ім’ям. Якщо браузер повідомляє, що не знаходить домен, перевіряють записи й відповіді DNS, а не починають із плагінів WordPress. Після зміни записів різні резолвери можуть тимчасово використовувати різні кешовані відповіді; універсального строку «все точно запрацює за годину» немає.
Помилка сертифіката — окрема категорія. Потрібно перевірити строк його дії, відповідність імені домену, ланцюжок довіри та налаштування HTTPS. Не просіть клієнтів обходити попередження браузера або вводити дані на сторінці з проблемним захищеним з’єднанням.
Якщо ім’я визначається й захищене з’єднання встановлюється, далі перевіряють сервер, застосунок і правила доступу. Код 403, тайм-аут і відповідь 502 означають різні речі. Окремий випадок пояснено в статті Помилка 502 Bad Gateway на WordPress: причини та терміновий ремонт.
- Порівняйте ту саму адресу через домашню мережу й мобільний інтернет.
- Перевірте варіанти з www і без нього, якщо обидва використовуються.
- З’ясуйте, чи збій стосується всього сайту, окремої сторінки або адміністративної панелі.
- Передайте спеціалісту точний текст помилки, не замінюючи його припущенням про причину.
Які результати перевірок передати підтримці
Найкорисніше повідомлення містить час із часовим поясом, URL, скриншот помилки, назву браузера й тип мережі. Якщо проблема повторюється лише в одного провайдера, зазначте це. Не потрібно збирати паролі чи зайві персональні дані клієнта: для первинної перевірки важливі умови відтворення.
Попросіть технічного спеціаліста зіставити результати з журналами сервера та системи захисту. Якщо одна мережа бачить стару адресу, перевірка піде в бік DNS; якщо сервер відхиляє конкретні запити — в бік правил доступу. Відсутність запису в журналі теж може допомогти визначити, чи доходить запит до потрібного сервера.
Не змінюйте одночасно DNS, PHP, плагіни та налаштування захисту. Після кількох паралельних втручань важко зрозуміти, яке з них усунуло або погіршило проблему. Фіксуйте кожну дію, її час і результат повторного тесту. Для організації такого процесу корисні матеріали про технічну підтримку сайту.
Що передати спеціалісту для діагностики та оцінки вартості
Підготуйте коротку історію змін: переїзд, заміна сертифіката, підключення CDN, оновлення сайту чи зміна DNS. Вкажіть, хто керує доменом і хостингом, та погодьте безпечний спосіб надання необхідного доступу. Не публікуйте облікові дані в загальному листуванні чи коментарях.
Попросіть розділити оцінку на діагностику, усунення встановленої причини й перевірку результату. Критерієм завершення має бути не тільки відкриття сайту на комп’ютері виконавця, а повторна перевірка проблемного сценарію та ключових дій: перегляду сторінок, надсилання форми, оформлення замовлення.
Якщо переїзд усе-таки обґрунтований, спочатку підготуйте можливість відновлення. Допоможе матеріал Як перевірити резервну копію магазину перед зміною сервера. Заміна хостингу має бути висновком діагностики з погодженим планом, а не першою реакцією на будь-яку скаргу про недоступність.