Як відновити окремі видалені сторінки без відкату всього сайту

Видалення окремих сторінок не завжди означає, що потрібно повністю відновлювати сайт із резервної копії. Повний відкат може знищити нові записи, замовлення, коментарі, налаштування та інші зміни, зроблені після створення бекапу. Безпечніший підхід — знайти потрібну версію сторінки, витягнути її дані та повернути на робочий сайт окремо.

Перед будь-якими діями бажано створити актуальну резервну копію файлів і бази даних. Відновлення з архівів, імпорт SQL або ручне редагування таблиць можуть призвести до втрати даних, якщо помилитися з версією файлу, префіксом таблиць чи ідентифікатором запису.

Якщо було видалено багато сторінок або є підозра на несанкціонований доступ, спочатку варто перевірити Відновлення сайту після масового видалення сторінок, а не відновлювати контент по одному без з’ясування причини інциденту.

Пошук сторінки в резервній копії

Спочатку потрібно визначити, де може зберігатися потрібна версія сторінки. Це може бути автоматична резервна копія хостингу, архів у панелі керування, копія від плагіна WordPress або ручний експорт бази даних. Важливо встановити дату створення бекапу: він має містити сторінку, але водночас бути якомога новішим, щоб не втратити інші актуальні зміни.

• Перевірте резервні копії в панелі хостингу та в плагіні для бекапів.
• З’ясуйте, чи є окремі архіви файлів і бази даних.
• Не відновлюйте архів одразу на робочий сайт — спочатку створіть тестову копію або окреме середовище.
• Перевірте кошик WordPress: іноді сторінку можна повернути через розділ видалених записів без роботи з базою.

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

Відновлення записів бази

У WordPress сторінки зберігаються переважно в таблиці wpposts, хоча фактичний префікс може відрізнятися. Додаткові параметри сторінки, зокрема шаблон, SEO-дані та службові значення, зазвичай розміщені в таблиці wppostmeta. Тому для коректного відновлення потрібно повернути не лише основний запис, а й пов’язані метадані.

Безпечний порядок дій виглядає так:

1. Зробити свіжу копію поточної бази даних.
2. Розгорнути резервну копію в окремій тестовій базі або на копії сайту.
3. Знайти потрібний запис за заголовком, старим URL, датою або ідентифікатором.
4. Перевірити його статус: publish, draft, private або інший.
5. Експортувати лише пов’язані записи, а не імпортувати всю стару базу поверх робочої.
6. Перевірити конфлікти ідентифікаторів, дублікати та залежності від плагінів.

Пряме редагування SQL-файлу або виконання запитів у phpMyAdmin небезпечне без розуміння структури бази. Помилка в умові WHERE, неправильне кодування або імпорт не тієї таблиці можуть пошкодити не одну сторінку, а значну частину сайту. Якщо сторінка використовує конструктор, кастомний тип запису чи складні зв’язки, простого копіювання одного рядка може бути недостатньо.

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

Медіафайли та метадані

Текст сторінки може відновитися, але зображення залишаться відсутніми, якщо в архіві не було каталогу wp-content/uploads. Медіафайли зберігаються на сервері окремо від записів бази, а зв’язок із ними підтримується через записи медіабібліотеки та метадані.

• Перевірте наявність оригінальних файлів і мініатюр у каталозі завантажень.
• Порівняйте шляхи до зображень у контенті та фактичні URL файлів.
• Перевірте записи вкладень у таблиці wpposts і відповідні дані в wppostmeta.
• Переконайтеся, що після перенесення не змінилися домен, протокол або структура каталогів.

Окрему увагу варто приділити SEO-метаданим, полям кастомних типів, даним конструктора сторінок і параметрам зображень. Вони можуть зберігатися не в тексті сторінки, а в додаткових таблицях або серіалізованих значеннях. Некоректне ручне редагування серіалізованих даних здатне зламати структуру запису, тому такі операції краще виконувати інструментами, які враховують формат WordPress.

Старий URL і редиректи

Після відновлення важливо зберегти або правильно повернути адресу сторінки. Якщо змінився slug, WordPress може сформувати новий URL, а старий почне повертати помилку 404. Це негативно впливає на переходи з пошуку, зовнішні посилання та закладки користувачів.

Перевірте:

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

Якщо сторінка повертається під іншим URL, налаштуйте постійний редирект 301 зі старої адреси на актуальну. Не варто масово змінювати правила перенаправлень без резервної копії конфігурації: помилка в .htaccess або налаштуваннях Nginx може зробити недоступним увесь сайт.

Повторна індексація

Після відновлення сторінки пошукові системи не завжди одразу бачать зміни. Спочатку переконайтеся, що сторінка доступна без авторизації, має правильний статус 200, не закрита директивою noindex і не блокується у файлі robots.txt.

Далі перевірте канонічну адресу, внутрішні посилання, карту сайту та метадані сторінки. Якщо URL залишився незмінним, достатньо дочекатися нового обходу або надіслати адресу на перевірку через інструмент для вебмайстрів. При зміні URL потрібно спочатку налаштувати редирект, а вже потім просити пошукову систему перевірити нову адресу.

Не слід багаторазово надсилати сторінку на індексацію одразу після кожної дрібної правки. Краще спершу завершити відновлення, перевірити контент, медіафайли, швидкість завантаження та доступність, а потім виконати повторну перевірку. Якщо сторінки видалялися через збій, шкідливий код або дії стороннього користувача, паралельно потрібно перевірити облікові записи, журнали змін, плагіни та резервні копії, інакше відновлений контент може знову бути пошкоджений.