Помилка 404 під час відкриття /wp-admin або /wp-login.php означає, що сервер не знаходить потрібний маршрут. Це не завжди свідчить про видалення WordPress: причиною можуть бути неправильна адреса, пошкоджені правила постійних посилань, плагін безпеки, зміни після перенесення сайту або помилки конфігурації сервера.

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

Причини 404 у wp-admin

Найчастіше помилка виникає через одну з таких причин:

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

Важливо відрізняти 404 від помилки 403, 500 або повідомлення про неправильний пароль. Якщо сторінка входу не відкривається взагалі, спочатку перевіряють адресу та маршрутизацію. Якщо форма входу завантажується, але авторизація не проходить, проблема може бути в облікових даних, cookie, плагінах або налаштуваннях WordPress.

Перевірка URL входу

Стандартна адреса входу має виглядати як https://example.com/wp-login.php, а панель керування зазвичай відкривається за адресою https://example.com/wp-admin/. Перевірте протокол http або https, написання домену, наявність підпапки та завершального слеша.

Якщо сайт встановлений у підкаталозі, правильна адреса може бути, наприклад, https://example.com/site/wp-admin/. Також не варто плутати адресу WordPress із доменною адресою сайту: після перенесення або зміни домену вони іноді залишаються різними.

Спробуйте відкрити безпосередньо /wp-login.php у приватному вікні браузера та очистити кеш. Якщо один URL дає 404, а інший відкривається, це допомагає визначити, чи проблема пов’язана з маршрутом wp-admin, чи зі всією системою входу.

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

Додатково про послідовність дій можна прочитати в матеріалі Як повернути доступ до адмінки WordPress.

Постійні посилання й .htaccess

У WordPress правила постійних посилань впливають на обробку запитів до сторінок і службових маршрутів. Пошкоджений або порожній .htaccess може спричинити 404, особливо на серверах Apache.

Якщо доступ до адмінки частково працює, відкрийте налаштування постійних посилань і просто натисніть «Зберегти зміни», не змінюючи структуру URL. WordPress спробує оновити правила маршрутизації. Перед цим бажано зберегти поточний .htaccess, щоб за потреби повернути попередню версію.

Для типової інсталяції WordPress на Apache файл може містити такі правила:

# BEGIN WordPress
<IfModule modrewrite.c> RewriteEngine On RewriteBase / RewriteRule ^index\.php$ - [L] RewriteCond %{REQUESTFILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule . /index.php [L] </IfModule>
END WordPress

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

На Nginx файл .htaccess зазвичай не обробляється. Тоді потрібно перевіряти конфігурацію сервера та правила передачі запитів до index.php. Такі зміни зазвичай доступні лише адміністратору сервера або технічній підтримці хостингу.

Плагіни безпеки

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

Якщо 404 з’явилася після встановлення або оновлення плагіна безпеки, тимчасово вимкніть його через файловий менеджер хостингу. Для цього зазвичай перейменовують папку конкретного плагіна в wp-content/plugins, наприклад додають до назви суфікс -disabled. Перед дією переконайтеся, що маєте резервну копію та розумієте, як повернути початкову назву.

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

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

Відновлення стандартного маршруту

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

1. Зробіть резервні копії файлів і бази даних та зафіксуйте поточні налаштування.
2. Перевірте правильність домену, протоколу, підкаталогу й адрес wp-login.php та wp-admin.
3. Очистіть кеш браузера, кеш плагіна, серверний кеш і CDN, якщо вони використовуються.
4. Тимчасово вимкніть плагіни безпеки або всі плагіни для пошуку конфлікту.
5. Перевірте та відновіть правила постійних посилань або конфігурацію вебсервера.
6. Переконайтеся, що в базі даних значення siteurl і home відповідають фактичній адресі сайту.
7. Перевірте цілісність файлів WordPress і права доступу до них.

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

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