Якщо головна сторінка сайту працює, а один конкретний матеріал або розділ не відкривається, проблема зазвичай пов’язана не з усім хостингом, а з URL, правилами маршрутизації, шаблоном, плагіном або записом у базі даних. Відвідувач може бачити помилку 404, 403, 500, білий екран або нескінченне перенаправлення.
Перед будь-якими змінами в адмінпанелі, файлах і базі даних варто створити резервну копію сайту та бази даних. Без неї навіть проста на вигляд правка може призвести до втрати контенту або ускладнити подальше відновлення.
Проблема однієї сторінки
Спочатку потрібно визначити, чи справді пошкоджено лише одну сторінку. Перевірте кілька URL цього самого типу: інші записи блогу, товари, категорії або сторінки. Також відкрийте проблемну адресу в іншому браузері чи в режимі інкогніто, щоб виключити кеш і локальні розширення.
Зверніть увагу на код відповіді сервера:
- 404 — сторінка або її адреса не знайдена;
- 403 — сервер забороняє доступ;
- 500 або 502 — помилка PHP, сервера чи плагіна;
- 301/302 у циклі — некоректне перенаправлення;
- білий екран — часто наслідок критичної помилки PHP.
Перевірте URL вручну: правильність протоколу, домену, написання slug, регістру символів і наявність зайвих пробілів чи знаків. Якщо сторінка відкривається за старою адресою, але не працює за новою, причиною може бути зміна постійного посилання або відсутність редиректу.
Перевірка постійних посилань
У WordPress правила формування URL зберігаються в налаштуваннях постійних посилань. Іноді після перенесення сайту, зміни структури адрес або оновлення системи вони перестають відповідати правилам вебсервера.
У панелі керування відкрийте розділ налаштувань постійних посилань і без зміни структури натисніть кнопку збереження. WordPress повторно сформує правила маршрутизації. Перед цим бажано мати резервну копію, особливо якщо сайт працює на нестандартній конфігурації.
Якщо це не допомогло, перевірте файл .htaccess на сервері Apache або конфігурацію Nginx. Випадкове видалення чи неправильне редагування системних правил може зробити недоступним увесь сайт. Не замінюйте конфігурацію шаблонним кодом, якщо не впевнені, який вебсервер і яка структура WordPress використовуються.
Також перевірте, чи не змінилися адреси сайту в загальних налаштуваннях WordPress, чи не встановлено неправильний SSL-сертифікат і чи немає конфлікту між версіями URL з www та без нього.
Конфлікт шаблону або плагіна
Окрема сторінка може не відкриватися через помилку в шаблоні, конструкторі, плагіні SEO, кешуванні, оптимізації або захисті. Особливо часто це трапляється після оновлення, встановлення нового розширення чи зміни версії PHP.
Якщо доступ до адмінпанелі збережено, тимчасово очистіть кеш WordPress, кеш плагіна та кеш CDN. Потім перевірте журнал помилок і повідомлення в консолі браузера. Не варто одразу вимикати всі розширення на робочому сайті без резервної копії: це може змінити функціональність, меню, форми та правила доступу.
Для пошуку конфлікту плагіни можна тимчасово вимикати по одному, щоразу перевіряючи проблемний URL. Якщо після вимкнення конкретного розширення сторінка запрацювала, потрібно перевірити його налаштування, сумісність із поточною версією WordPress і PHP, а не просто залишати його деактивованим без оцінки наслідків.
Якщо помилка виникає тільки для певного типу записів або сторінок, перевірте файл шаблону, кастомні поля, умови виведення та код, який підключається саме до цього типу контенту. За відсутності доступу до адмінпанелі діагностику іноді проводять через файловий менеджер або SSH, але такі зміни краще доручити спеціалісту.
Записи в базі даних
Пошкоджений URL може бути наслідком проблеми не у файлах, а в записі бази даних. Сторінка могла бути видалена, переведена в чернетку, переміщена до кошика або мати некоректний slug. Інша можливість — пошкоджені метадані, зв’язок із шаблоном або записами таксономії.
У редакторі WordPress перевірте статус матеріалу, його видимість, дату публікації, батьківську сторінку та значення поля постійного посилання. Якщо запис є в адмінпанелі, але не відкривається на сайті, причину слід шукати в маршрутизації, правах доступу, шаблоні або фільтрах плагінів.
Робота безпосередньо в phpMyAdmin або іншому інструменті бази даних потребує особливої обережності. Перед SQL-запитами необхідно зробити експорт бази. Не видаляйте рядки навмання і не змінюйте ідентифікатори, URL чи серіалізовані дані без розуміння структури WordPress. Навіть одна неправильна операція може пошкодити меню, зв’язки між записами або налаштування розширень.
Якщо сторінки були масово видалені, змінені або сайт перенесено на інший сервер, корисно перевірити доступні резервні копії хостингу, WordPress-плагіна та бази даних. У такій ситуації може знадобитися Відновлення сайту після масового видалення сторінок, але результат залежить від стану резервних копій і того, які саме дані збереглися.
Відновлення без втрати контенту
Безпечне відновлення починається з діагностики, а не з видалення проблемного запису чи встановлення нового шаблону. Спочатку зафіксуйте точний URL, код помилки, час появи проблеми та останні зміни на сайті. Потім створіть повну копію файлів і бази даних та окремо збережіть поточний стан конфігурації.
- Перевірте URL, статус публікації та доступність інших сторінок.
- Очистіть кеш і повторно збережіть постійні посилання.
- Перегляньте журнали помилок сервера та WordPress.
- Перевірте останні оновлення плагінів, теми й версії PHP.
- Порівняйте проблемний запис із резервною копією, не перезаписуючи робочі дані одразу.
- Після виправлення перевірте внутрішні посилання, карту сайту, редиректи та індексацію.
Зверніться до спеціаліста, якщо помилка повторюється після стандартної перевірки, немає доступу до адмінпанелі, підозрюється зараження, пошкоджена база даних або необхідно відновити сторінку з резервної копії. Фахівець зможе спочатку зняти копію поточного стану, локалізувати причину й оцінити ризик змін, не роблячи необґрунтованих операцій із файлами та базою даних.