Ви заходите на свій сайт, а замість звичної сторінки браузер видає «ERR_TOO_MANY_REDIRECTS». Сайт не завантажується, адмінка недоступна, відвідувачі бачать помилку. Паніка? Ні, це можна виправити.

Технічно помилка означає, що браузер потрапив у нескінченний цикл переадресації: сторінка A скеровує на сторінку B, та назад на A, і так по колу, доки браузер не здається. У WordPress така ситуація трапляється частіше, ніж хотілося б, і майже завжди винні не хакери, а невинна зміна налаштувань.

Нижче шість перевірених способів повернути сайт до ладу. Від найшвидшого (почистити кеш браузера) до серверного (перевірити HTTPS-редиректи). Застосовуйте по черзі, один із них вирішить проблему.

💡 Швидкий огляд:

• Очистіть кеш і cookie браузера: виключіть локальну причину проблеми
• Перевірте URL сайту в налаштуваннях WordPress та wp-config.php: розбіжність WP_HOME/WP_SITEURL ламає редиректи
• Скиньте кеш WP-плагінів (WP Super Cache, WP Rocket, W3 Total Cache) та CDN: кеш зберігає старі правила
• Перестворіть .htaccess: пошкоджений файл часто генерує зайві редиректи
• Вимкніть плагіни та знайдіть конфліктний: особливо ті, що керують редиректами або SSL
• Перевірте налаштування HTTPS: некоректний примусовий редирект з HTTP на HTTPS зациклює трафік

1. Очистіть кеш і cookie браузера

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

У Chrome: три крапки у правому верхньому куті → «Налаштування» → «Конфіденційність і безпека» → «Очистити історію». Позначте «Файли cookie» та «Кешовані зображення», діапазон «За весь час», натисніть «Видалити дані».

У Firefox: три смужки → «Налаштування» → «Приватність і захист» → розділ «Куки та дані сайтів» → «Видалити дані». Позначте обидва чекбокси, підтвердьте.

Після очищення відкрийте сайт у режимі інкогніто (Ctrl+Shift+N у Chrome). Запрацювало? Отже, проблема була локальною. Ні, рухаємося далі. До речі, якщо потрібно повністю скинути кеш у різних браузерах, у нас є окрема інструкція з очищення кешу браузера, пошукайте її на сайті.

2. Перевірте URL сайту в налаштуваннях WordPress

Розбіжність адреси сайту та адреси WordPress, одна з найчастіших причин циклу редиректів. Зайдіть в адмінку: «Налаштування» → «Загальні». Поля «Адреса WordPress (URL)» та «Адреса сайту (URL)» мають збігатися (або відрізнятися свідомо, якщо WordPress лежить у підпапці).

Переконайтеся, що:

• Протокол скрізь однаковий: або скрізь https://, або скрізь http://
• www або є в обох полях, або відсутнє в обох
• Домен написаний без помилок і зайвих слешів у кінці

Натиснули «Зберегти», але помилка залишилася? Або адмінка взагалі не відкривається через редиректи? Тоді правимо через wp-config.php.

Підключіться до сервера через FTP/SFTP або через файловий менеджер хостингу. Знайдіть у корені сайту файл wp-config.php і додайте до нього два рядки (одразу після <?php або перед /* That's all, stop editing! */):

1
define('WP_HOME', 'https://vash-sait.com');
2
define('WP_SITEURL', 'https://vash-sait.com');

Замініть vash-sait.com на ваш реальний домен, із правильним протоколом і без www, якщо сайт відкривається без нього. Збережіть, залийте назад на сервер, перевірте сайт, редиректи часто зникають одразу після цього кроку.

3. Видаліть кеш WordPress і CDN

Якщо на сайті встановлено плагін кешування, він міг запам’ятати «криві» редиректи й продовжує їх віддавати, навіть коли джерело виправлено.

Зайдіть в адмінку та знайдіть сторінку керування кешем:

• WP Super Cache: «Налаштування» → «WP Super Cache» → «Видалити кеш»
• W3 Total Cache: «Performance» → «Purge All Caches»
• WP Rocket: «Settings» → «WP Rocket» → «Clear Cache»

Використовуєте Cloudflare або інший CDN? Зайдіть у панель CDN і скиньте кеш там. Після скидання тимчасово поставте CDN на паузу, у режимі «Development Mode» або «Bypass Cache», і перевірте сайт. Іноді саме CDN зациклює редиректи через незбіг HTTP/HTTPS на рівні проксі.

4. Перестворіть файл.htaccess

.htaccess — це текстовий файл у корені сайту, через який Apache керує редиректами. Один зайвий рядок, кривий плагін або ручне редагування, і сайт зациклюється.

Підключіться до сервера через FTP/SFTP, знайдіть .htaccess і перейменуйте його на .htaccess_old. Це вимкне всі кастомні правила, але збереже копію, на випадок, якщо всередині було щось важливе.

Тепер потрібно створити новий, чистий .htaccess зі стандартними правилами WordPress. Якщо адмінка доступна: «Налаштування» → «Постійні посилання» → просто натисніть «Зберегти зміни» (нічого не змінюючи). WordPress сам перестворить .htaccess.

Адмінка недоступна? Створіть файл вручну та скопіюйте в нього:

1
<IfModule mod_rewrite.c>
2
RewriteEngine On
3
RewriteBase /
4
RewriteRule ^index\.php$ - [L]
5
RewriteCond %{REQUEST_FILENAME} !-f
6
RewriteCond %{REQUEST_FILENAME} !-d
7
RewriteRule . /index.php [L]
8
</IfModule>

Збережіть, завантажте в корінь сайту та перевірте. Якщо використовуєте Nginx, правила прописуються в конфігурації сервера, і .htaccess на нього не впливає; для редагування конфігурації Nginx потрібен доступ до /etc/nginx/sites-available/.

5. Знайдіть конфліктний плагін

Плагіни редиректів, SSL-плагіни (Really Simple SSL, WP Force SSL) і навіть деякі плагіни кешування, часті винуватці ERR_TOO_MANY_REDIRECTS. Особливо після оновлення WordPress або самого плагіна.

Якщо адмінка працює: вимкніть УСІ плагіни разом («Плагіни» → вибрати всі → «Деактивувати» → «Застосувати»). Перевірте сайт. Помилка зникла? Вмикайте плагіни по одному й після кожного перевіряйте, так знайдете винуватця.

Адмінка не завантажується через редиректи? Підключіться до сервера через FTP, перейдіть у wp-content/ і перейменуйте папку plugins на plugins_disabled. WordPress побачить, що папки plugins немає, і деактивує всі плагіни автоматично.

Сайт відкрився без помилки? Повертайте плагіни по одному: перейменуйте папку конкретного плагіна назад (наприклад, plugins_disabled/wordpress-seo → plugins/wordpress-seo), перевірте сайт, повторіть. Плагін, після повернення якого помилка з’являється знову, і є джерелом проблеми. Видаліть його або знайдіть заміну.

6. Виправте налаштування HTTPS-редиректу

Помилка часто виникає після встановлення SSL-сертифіката, коли сайт починає примусово перенаправляти HTTP на HTTPS, але налаштування виконано некоректно.

Якщо у вас Apache, відкрийте .htaccess і перевірте, чи немає там дубльованих або конфліктних правил переспрямування. Коректне переспрямування з HTTP на HTTPS для Apache має такий вигляд:

1
RewriteEngine On
2
RewriteCond %{HTTPS} off
3
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Для Nginx правило прописується в конфігурації сервера:

1
server {
2
    listen 80;
3
    server_name vash-sait.com www.vash-sait.com;
4
    return 301 https://vash-sait.com$request_uri;
5
}

Поширена пастка: сайт працює за Cloudflare або іншим проксі-сервісом, SSL виставлено на рівні проксі, а WordPress намагається переспрямовувати на HTTPS самостійно. Виходить подвійне переспрямування → зациклення. Розв'язання: у Cloudflare увімкніть режим «Full (strict)» у розділі SSL/TLS, а на сервері налаштуйте сертифікат (можна ориджин-сертифікат Cloudflare). На боці WordPress приберіть плагіни примусового HTTPS, достатньо налаштувань проксі.

⁉️🤔 Часті запитання

Чому помилка з’являється раптово, якщо я нічого не змінював?

Найчастіше через автооновлення. WordPress оновився сам, плагін підтягнув нову версію, хостинг змінив налаштування PHP або увімкнув примусовий HTTPS. Зовні «нічого не чіпав», а під капотом зміни є. Перевірте історію оновлень в адмінці, зазвичай винуватця видно одразу.

Чи можна вирішити проблему без доступу до адмінки WordPress?

Так, більшість кроків із цього посібника виконуються саме без адмінки: через FTP/SFTP правите wp-config.php і .htaccess, перейменовуєте папку plugins. Тільки очищення кешу плагінів потребує входу в адмінку, але й без неї можна просто перейменувати папку плагіна кешування — це його деактивує.

Чи допоможе зміна браузера або пристрою?

Тимчасово так, але проблему на сервері це не вирішить. Помилка з’являється незалежно від браузера, якщо корінь на стороні сервера. Зміна браузера лише підтверджує, що справа не в локальному кеші, і тоді треба йти за кроками 2-6.

Що робити, якщо жоден із шести способів не спрацював?

Перевірте ланцюжок редіректів інструментом на кшталт Redirect-Checker.org, він покаже, між якими URL відбувається зациклення. Зверніться до підтримки хостингу: іноді проблема в серверних налаштуваннях (nginx-конфіг, балансувальник), до яких у вас немає доступу. І про всяк випадок увімкніть WP_DEBUG у wp-config.php, логи можуть показати конкретний плагін або тему, що спричиняє помилку.

Чи може тема WordPress викликати цю помилку?

Може, хоча й рідше, ніж плагіни. Деякі теми додають власні правила редіректу в functions.php, наприклад, для примусового HTTPS або редіректу після логіну. Якщо вимкнення плагінів не допомогло, тимчасово перемкніться на стандартну тему (Twenty Twenty-Five), перейменувавши папку вашої теми в wp-content/themes/.

Помилку виправлено. Що далі?

ERR_TOO_MANY_REDIRECTS виглядає страшно, але лікується за 10-15 хвилин, якщо йти за кроками. У дев’яти випадках із десяти винні або налаштування URL (крок 2), або кривий .htaccess (крок 4), або SSL-редірект (крок 6). Почніть із них, скоріш за все, далі йти не доведеться.

І коли сайт знову запрацює, зробіть бекап прямо зараз. Серйозно. wp-config.php, .htaccess і всю папку wp-content збережіть у надійне місце. Наступна помилка (а вона буде, WordPress є WordPress) зустріне вас у всеозброєнні.

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