Skip to content

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

🚀 Как убрать index.php и index.html из URL: 301 редирект в корень сайта
SEO и продвижениеХостинг и серверы
8 мин1,552 слов8 845

🚀 Как убрать 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 постепенно исчезнут дубли из отчёта «Покрытие», а вес обратных ссылок сконцентрируется на одной канонической странице. Результат не мгновенный, поисковику нужно время на переобход, но неизбежный.

Редакция
РедакцияРедакционная команда→ Все публикации

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