Skip to content

Все для WordPress, веб-розробки — і не тільки

🚀 Як прибрати index.php та index.html з URL: 301 редирект у корінь сайту
SEOХостинг та сервери
8 хв1,557 слів

🚀 Як прибрати index.php та index.html з URL: 301 редирект у корінь сайту

Ви відкриваєте Google Search Console і бачите: головна сторінка проіндексована двічі, як site.ru/ і як site.ru/index.php. Або site.ru/index.html. Для пошуковика це дві різні URL-адреси з однаковим вмістом. Підсумок: вага сторінки ділиться навпіл між дублями, позиції просідають, бюджет сканування витрачається даремно.

Проблема стара як веб. Механіка проста: сервер за замовчуванням віддає index.html або index.php під час запиту кореня через директиву DirectoryIndex, але не забороняє прямий доступ до site.ru/index.php. З погляду Apache обидві адреси легітимні. А от пошуковик бачить дві різні сторінки з ідентичним контентом і починає гадати, яку з них ранжувати.

Нижче три способи налаштування 301 редиректу з index-файлів на корінь: від універсального .htaccess до Cloudflare і Nginx. Плюс спосіб перевірки, який займає дві хвилини.

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

  • Додайте правила mod_rewrite у .htaccess для перехоплення запитів до index.html і index.php
  • Для WordPress і CMS використовуйте PHP-редирект у вхідному index.php, він переживе оновлення постійних посилань
  • Перевірте результат через curl -I або redirectchecker.com, відповідь має бути 301 Moved Permanently
  • Пройдіться внутрішніми посиланнями сайту та замініть /index.php на / у меню, логотипі та віджетах

Чому дублі index-файлів шкодять сайту

Коли відвідувач набирає site.ru в адресному рядку, Apache мовчки підставляє index.html або index.php згідно з DirectoryIndex. Браузер показує сторінку, адреса залишається чистою, користувач підміни не помічає.

Але якщо в зовнішньому світі вже є посилання на повний шлях site.ru/index.php, пошуковий робот приходить за ним, бачить той самий контент, що й на site.ru/, і фіксує дубль. Звідки береться таке посилання? Варіантів безліч: стара публікація на сторонньому сайті, партнер вказав кривий URL, плагін соцкнопок згенерував шару з index.php у хвості, та й сам розробник на етапі верстки проставив href="/index.html" у навігації.

Що отримуємо за фактом:

  • Розділення посилальної ваги. Зворотні посилання розподіляються між / і /index.php, замість того щоб підсумовуватися на одній канонічній сторінці.
  • Перевитрата краулінгового бюджету. Робот витрачає час на обхід дублів замість корисних розділів сайту.
  • Розмита релевантність. Пошуковик не розуміє, яку з двох сторінок показувати у видачі, і може чергувати їх, збивається статистика поведінки користувачів і позиції нестабільні.

Ситуація повністю керована. Вирішується налаштуванням постійного 301 редиректу з index.html і index.php на корінь /. Розберемо доступні способи.

Спосіб 1: Редирект через.htaccess на Apache

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

Відкрийте .htaccess і знайдіть рядок RewriteEngine On. Якщо її немає, додайте найпершим рядком після коментарів. Вона вмикає модуль mod_rewrite, який відповідає за всі перенаправлення.

Нижче RewriteEngine On додайте правила. Ось мінімальний робочий набір:

1RewriteEngine On
2 
3RewriteCond %{THE_REQUEST} ^[A-Z]{3,9}\ /index\.php\ HTTP/
4RewriteRule ^index\.php$ https://%{HTTP_HOST}/ [R=301,L]
5 
6RewriteCond %{THE_REQUEST} ^[A-Z]{3,9}\ /index\.html\ HTTP/
7RewriteRule ^index\.html$ https://%{HTTP_HOST}/ [R=301,L]

Як це працює порядково:

  • RewriteCond %{THE_REQUEST} перевіряє вихідний рядок запиту, надісланий браузером серверу. У ньому явно міститься /index.php або /index.html, саме те, що ми відловлюємо.
  • RewriteRule перенаправляє запит на корінь домену з кодом 301 (постійний редирект). Прапор L (last) зупиняє подальшу обробку правил.
  • %{HTTP_HOST} автоматично підставляє домен сайту, вписувати його вручну не потрібно. Протокол вказано явно як https://.

Критичний нюанс: не використовуйте спрощену конструкцію Redirect 301 /index.php /. Директива Redirect модуля mod_alias зациклюється на index-файлах. Після перенаправлення на / Apache знову підставляє index.php через DirectoryIndex, правило спрацьовує повторно, і браузер видає помилку нескінченного циклу. Зв'язка RewriteCond + RewriteRule через mod_rewrite аналізує саме вихідний запит (%{THE_REQUEST}), а не переписаний внутрішніми правилами, тому зациклення не відбувається.

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

Спосіб 2: PHP-редирект для WordPress і CMS

На сайтах під керуванням WordPress, Joomla, Drupal та інших CMS правити .htaccess ризиковано: CMS перезаписує його під час оновлення постійних посилань, зміни структури URL або активації SEO-плагінів. Правила можуть зникнути під час наступного збереження налаштувань.

Для WordPress є більш стійкий спосіб, редирект прямо у вхідному файлі index.php. Він лежить у корені встановлення CMS і виконується під час кожного запиту, до завантаження ядра.

Відкрийте index.php WordPress і додайте на самому початку, одразу після відкривного тега <?php:

1<?php
2// 301 редирект с index.php на корень
3if ($_SERVER['REQUEST_URI'] === '/index.php') {
4    header('Location: /', true, 301);
5    exit();
6}
7 
8// Далее стандартный код WordPress
9define('WP_USE_THEMES', true);
10// ...

Для сайтів на чистому PHP без CMS логіка та сама, розмістіть код у вхідному index.php у корені публічної директорії. Якщо на сайті використовуються обидва індексні файли (index.php і index.html), додайте аналогічну перевірку для index.html на початок того самого скрипта.

Чому цей спосіб надійніший за правку .htaccess для CMS:

  • Код живе всередині PHP-файлу, який CMS не чіпає під час оновлення налаштувань постійних посилань.
  • Перевірка $_SERVER['REQUEST_URI'] ловить саме запитаний URL, а не переписаний внутрішніми правилами WordPress.
  • exit() гарантовано обриває виконання, жоден рядок далі не відпрацює.

На високонавантажених проєктах PHP-редирект трохи швидший за .htaccess-варіант: не запускається mod_rewrite для розбору регулярних виразів, економляться мілісекунди на кожному запиті.

Спосіб 3: Cloudflare, Nginx та інші сервери

Cloudflare. Якщо сайт працює через Cloudflare, редирект можна зробити на рівні CDN, взагалі не чіпаючи серверні файли. Зайдіть у розділ Rules → Redirect Rules, створіть правило:

  • Поле: URI Path
  • Оператор: equals
  • Значення: /index.php
  • URL редиректу: https://yourdomain.com/
  • Код статусу: 301

Аналогічне правило додайте для /index.html. Плюс підходу: редирект відпрацьовує на edge-серверах Cloudflare, запит навіть не доходить до вашого хостингу. Мінус: домен має бути делегований на Cloudflare NS.

Nginx. Сайти на Nginx не використовують .htaccess. Правила вносяться до конфігураційного файлу сервера, зазвичай /etc/nginx/sites-available/yourdomain:

1location = /index.php {
2    return 301 https://yourdomain.com/;
3}
4 
5location = /index.html {
6    return 301 https://yourdomain.com/;
7}

Після правки перевірте синтаксис командою nginx -t і застосуйте зміни: systemctl reload nginx.

LiteSpeed / OpenLiteSpeed. Сервер підтримує .htaccess із тими самими правилами mod_rewrite, що й Apache, спосіб 1 працює без змін. Додатково можна використовувати вбудований механізм редиректів у панелі керування LiteSpeed WebAdmin.

IIS (Windows Server). Для сайтів на IIS редирект налаштовується через модуль URL Rewrite у web.config:

1<rule name="Redirect index.php to root" stopProcessing="true">
2    <match url="^index\.php$" />
3    <action type="Redirect" url="/" redirectType="Permanent" />
4</rule>

Додайте аналогічне правило для index.html.

Як перевірити, що редирект працює

Найнадійніший спосіб, командний рядок. Виконайте:

1curl -I https://yourdomain.com/index.php

Перший рядок відповіді має бути HTTP/1.1 301 Moved Permanently, а в заголовку Location, корінь сайту. Повторіть для index.html. Головна сторінка за коренем / має відповідати кодом 200.

Альтернативні інструменти для перевірки:

  • Redirect Checker (redirectchecker.com), показує повний ланцюжок редиректів із кодами відповідей, зручно для швидкої діагностики без термінала.
  • Google Search Console → Перевірка URL, інструмент вставки та перевірки: показує, як Googlebot бачить сторінку після редиректу і чи доступна вона для індексації.

Після налаштування редиректу критично важливо перевірити внутрішні посилання сайту. Переконайтеся, що меню, логотип (зазвичай посилається на головну), хлібні крихти та блоки схожих записів вказують на /, а не на /index.php. Одне криве внутрішнє посилання здатне перестворити дубль, який ви щойно прибрали. Пройдіться по сайту пошуком за вихідним кодом: відкрийте будь-яку сторінку, натисніть Ctrl+U і пошукайте href="/index.php" або href="/index.html". Кожне таке входження замініть на href="/".

Відео: коротке пояснення 301 редиректів від Google

Чотирихвилинне відео від Google Search Central, обов'язкове до перегляду, якщо налаштовуєте редиректи вперше. Джон Мюллер пояснює, як пошуковик обробляє постійні перенаправлення і чи є обмеження на їхню кількість:

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

Що буде, якщо взагалі не налаштовувати редирект з index.php?

Пошуковик сам обере канонічну версію, але не обов'язково ту, яка потрібна вам. Частина посилальної ваги піде дублю, а у видачі можуть чергуватися обидва URL. Прямої загрози санкцій немає, але позиції будуть нижчими, ніж могли б бути за чистої структури. Джон Мюллер з Google неодноразово підкреслював: канонікалізація через rel="canonical" — це підказка пошуковику, а не директива. Google має право проігнорувати canonical і обрати іншу сторінку, якщо вважатиме її більш релевантною. 301 редирект, директива: він гарантовано передає вагу і виключає дубль з індексу.

Чи можна використовувати Redirect 301 /index.php / замість mod_rewrite?

Технічно так, але для index-файлів це небезпечно. Після редиректу на / Apache знову підставить index.php через DirectoryIndex, правило Redirect спрацює повторно, вийде нескінченний цикл, браузер обірве його помилкою ERR_TOO_MANY_REDIRECTS. RewriteCond із перевіркою %{THE_REQUEST} позбавлений цієї проблеми: він аналізує вихідний запит від браузера, а не переписаний внутрішніми правилами сервера.

Чи потрібно налаштовувати редирект, якщо сайт працює тільки за HTTPS?

Так. HTTPS і index-дублі, дві незалежні проблеми. Навіть за налаштованого редиректу HTTP→HTTPS і коректного rel="canonical" прямий запит https://site.ru/index.php віддасть код 200 без перенаправлення. Правила зі способу 1 закривають обидва протоколи: RewriteRule явно вказує https:// у цільовому URL.

Як перевірити, що редирект не зламав сайт?

Три контрольні точки: 1) головна сторінка відкривається за коренем / без перенаправлень, curl -I має дати 200; 2) URL з index.php і index.html повертають 301 і ведуть на /; 3) адмінка WordPress (/wp-admin/) працює без зациклень. Останнє критично: погано написане правило в .htaccess може перехопити запити до index.php всередині адмінки і зламати вхід. Конструкція зі способу 1 безпечна, вона перевіряє точний збіг URI і не чіпає /wp-admin/index.php.

Що робити з іншими індексними файлами, index.aspx, index.py?

Механіка та сама: копіюєте блок RewriteCond + RewriteRule, замінюєте розширення і додаєте в .htaccess. Для нестандартних розширень переконайтеся, що файл фізично існує в корені і вказаний у DirectoryIndex, інакше сервер і так не зможе обслужити його як індексний, редирект не знадобиться.

Що робити з дублями index-файлів: підсумковий чек-лист

Налаштування 301 редиректу з index.html і index.php на корінь, задача з розряду «п'ять хвилин роботи, роки захисту». Правило живе в .htaccess або index.php прозоро, не потребує обслуговування під час зміни дизайну або переїзду на інший хостинг.

Порядок дій після внесення правок:

  • Перевірте редирект через curl -I або redirectchecker.com, відповідь має бути 301.
  • Переконайтеся, що головна відкривається за коренем із кодом 200.
  • Пройдіться пошуком href="/index.php" і href="/index.html" за вихідним кодом сторінок, кожне входження замініть на href="/".
  • У Google Search Console запустіть перевірку головної сторінки, робот має побачити 200 і канонічний URL без /index.php.

Після цього в Search Console поступово зникнуть дублі зі звіту «Покриття», а вага зворотних посилань сконцентрується на одній канонічній сторінці. Результат не миттєвий, пошуковику потрібен час на переобхід, але неминучий.

Редакція
РедакціяРедакційна команда→ Усі публікації

Професійна команда авторів та редакторів, що спеціалізуються на створенні якісного контенту.