Папка wp-content містить значну частину даних WordPress, які формують вигляд і функціональність сайту. Якщо вона була видалена, пошкоджена або частково перезаписана, сайт може втратити теми, плагіни, зображення та інші завантажені файли. Водночас відновлення лише цієї папки не завжди повертає сайт до робочого стану: результат залежить від стану бази даних, структури файлів і наявності доступних копій.
Перед будь-якими діями варто створити резервну копію того, що залишилося: файлів сайту, бази даних і, за можливості, вмісту пошкодженої папки. Не слід одразу видаляти залишки або встановлювати поверх них нові плагіни. Якщо потрібно розібратися з наслідками видалення, корисно ознайомитися з матеріалом Як відновити сайт після помилкового видалення файлів.
Що зберігається у wp-content
У стандартній інсталяції WordPress у wp-content розміщені основні компоненти, які змінюються під час роботи сайту:
themes— встановлені теми та дочірні теми;plugins— файли плагінів;uploads— зображення, документи, відео та інші медіафайли;languages— мовні файли WordPress, тем і плагінів;- інші директорії, створені окремими плагінами: кеш, журнали, резервні копії або службові дані.
Важливо розуміти, що сама папка не містить усі дані сайту. Записи, сторінки, налаштування, меню, користувачі та частина параметрів тем і плагінів зберігаються в базі даних. Тому відновлення файлів без перевірки бази може усунути помилки сервера, але не повернути потрібні налаштування.
Безпечною послідовністю буде визначення масштабу пошкодження, збереження залишків файлів, перевірка доступних резервних копій і лише після цього — заміна або відновлення окремих директорій. Розпаковану копію краще спочатку перевірити в окремій директорії або на тестовому середовищі.
Теми та плагіни
Якщо відсутні themes і plugins, WordPress може показувати білий екран, повідомлення про критичну помилку або стандартну тему. У такій ситуації спочатку потрібно з’ясувати, чи збереглися назви активної теми та плагінів у базі даних. Ці записи можуть залишатися навіть після видалення відповідних файлів.
Тему можна відновити з резервної копії, архіву розробника або офіційного репозиторію. Плагіни бажано встановлювати з надійного джерела та тієї самої або сумісної версії. Випадкове завантаження файлів з неперевірених сайтів створює ризик повторного зараження або появи прихованого шкідливого коду.
Якщо невідомо, яка тема була активною, або сайт використовував дочірню тему, просте встановлення батьківської теми може не відновити дизайн і функціональність. Дочірня тема, власні шаблони та зміни в її файлах можуть бути втрачені. Після копіювання файлів слід перевірити права доступу, власника файлів і відповідність версії PHP вимогам теми та плагінів.
Для тимчасового повернення доступу до панелі WordPress інколи перейменовують директорію плагінів, наприклад у plugins.disabled. Це лише діагностичний крок, а не повноцінне відновлення. Перед ним потрібно мати копію файлів, оскільки помилки в назвах директорій або правах доступу можуть ускладнити подальшу роботу.
Медіафайли uploads
Директорія wp-content/uploads зазвичай містить завантажені через адмінпанель файли. WordPress часто розподіляє їх за роками та місяцями, наприклад uploads/2025/06. Окрім оригіналів, там можуть бути автоматично створені мініатюри та зображення різних розмірів.
Якщо медіафайли були видалені, їх можна шукати в резервних копіях хостингу, архівах плагінів резервування, старому сервері, локальних копіях або CDN. Повернення лише бази даних не відновить самі зображення: у записах залишаться посилання на файли, але браузер отримуватиме помилки 404 Not Found.
Під час відновлення не варто без перевірки замінювати всю директорію uploads. Свіжі файли можуть бути перезаписані старішою копією. Краще порівняти вміст і дати змін, зберегти поточний стан окремо, а потім дозавантажити відсутні файли. Якщо резервна копія містить підозрілі PHP-файли всередині uploads, її потрібно перевірити на шкідливий код до розміщення на робочому сайті.
Після повернення файлів варто перевірити їхні URL, регістр символів у назвах і права доступу. На Linux назви image.jpg та Image.jpg можуть вважатися різними, тому перенесення між серверами іноді призводить до непомітних помилок у посиланнях.
Узгодження з базою
База даних містить посилання на медіафайли, активну тему, налаштування плагінів і адресу сайту. Після відновлення wp-content ці дані мають відповідати фактичній структурі файлів. Якщо домен, протокол або шлях до WordPress змінилися, частина посилань може залишатися старою.
Спочатку потрібно визначити, чи є база даних актуальною та чи не була вона пошкоджена одночасно з файлами. Перед будь-якими SQL-змінами слід зробити її окрему копію. Масова заміна URL через звичайний пошук і заміну може пошкодити серіалізовані дані WordPress, тому для таких операцій потрібні інструменти, які враховують серіалізацію, або допомога спеціаліста.
Після відновлення файлів перевіряють таблиці налаштувань, активну тему, статус плагінів і наявність помилок підключення до бази. Якщо активний плагін більше не має відповідних файлів, WordPress може записувати критичні помилки. У такому разі спочатку відновлюють сумісну версію плагіна або тимчасово вимикають його контрольованим способом.
Окремо потрібно перевірити файл wp-config.php: доступи до бази, префікс таблиць і параметри підключення не слід змінювати навмання. Помилка в цьому файлі може повністю заблокувати сайт, а невірно відкриті права доступу створюють додатковий ризик для безпеки.
Перевірка після відновлення
Після копіювання файлів і узгодження бази сайт потрібно перевіряти поетапно, а не лише відкривати головну сторінку. Рекомендований порядок:
- перевірити доступність головної сторінки та кількох внутрішніх URL;
- увійти до адміністративної панелі та переглянути журнал помилок;
- відкрити сторінки із зображеннями, документами та галереями;
- перевірити форми, пошук, кошик, оплату та інші критичні функції;
- очистити кеш лише після перевірки файлів і налаштувань;
- переконатися, що немає помилок PHP, проблем із правами доступу та підозрілих змін у файлах.
Якщо сайт відкривається, але працює нестабільно, потрібно переглянути журнали вебсервера і PHP. Причиною можуть бути несумісні версії плагінів, пошкоджені файли, неправильні права, відсутні залежності або зараження. Не слід маскувати проблему вимкненням журналювання чи видаленням повідомлень про помилки.
Спеціаліст потрібен, коли немає достовірної копії, пошкоджені одночасно файли та база, сайт містить ознаки злому або відновлення потребує роботи з SQL і серверними налаштуваннями. До завершення діагностики краще обмежити зміни на робочому сайті, зберегти всі доступні копії та зафіксувати, які файли вже замінювалися. Після відновлення варто налаштувати регулярні резервні копії, оновлення та моніторинг, щоб наступна несправність не призвела до втрати єдиної копії сайту.