301 перенаправить все адреса страниц и постов с .html на /

Вопрос или проблема

У меня есть текущий сайт, где все URL-адреса заканчиваются на .html.

Я создал новый сайт, и URL-адреса практически такие же, но без .html.

Я пробовал коды, найденные здесь, в своем файле .htaccess, и большинство из них вызывают внутреннюю ошибку сервера.

http://example.com/page1.html to http://example.com/page1/
http://example.com/page1/page2.html to http://example.com/page1/page2/

Мой текущий код файла .htaccess:

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

# END WordPress

Просто имейте в виду, что при возникновении внутренней ошибки сервера (код 500) вам следует проверить журнал ошибок вашего сервера, чтобы узнать детали ошибки. Если вы вносили изменения в mod_rewrite в .htaccess, то это может быть связано с простой синтаксической ошибкой или циклом переадресации.

Если у вас на новом сайте нет файлов с .html, вы можете выполнить безусловную переадресацию, чтобы убрать .html в конце URL. Например:

RewriteRule (.*)\.html$ /$1 [R=301,L]

Это необходимо разместить перед существующими директивами WordPress.

Или, если у вас есть некоторые файлы с .html, которые нужно оставить в том виде, как они есть, то нужно переадресовывать только запросы, которые не соответствуют существующему файлу. Например:

RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule (.*)\.html$ /$1 [R=301,L]

Вам нужно будет очистить кэш браузера перед тестированием.

Ответ или решение

Для успешного перенаправления URL-адресов, оканчивающихся на .html, на адекватные структуры URL без этого окончания, в Apache сервере обычно используется файл .htaccess, который может управлять правилами переадресации благодаря мо́ду mod_rewrite.

Теория

При переезде сайта с URL-структуры с .html на новую структуру, которая не включает этот суффикс, вам может понадобиться перенастроить сайт так, чтобы старые URL-адреса автоматически перенаправляли посетителей на новые. Это не только обеспечивает безошибочное и удобное пересечение между старым и новым сайтом, но также важно для сохранения положительных позиций в поисковых системах благодаря применению 301 редиректов, которые указывают на постоянное перемещение страниц.

Пример

В вашем случае, если у вас нет файлов с реальными .html окончаниями на новом сайте, вы можете использовать простое правило, которое будет автоматически убирать суффикс .html и перенаправлять на соответствующий URL без него. Например:

RewriteRule (.*)\.html$ /$1 [R=301,L]

Это правило выполнит 301 редирект всех запросов на страницы с .html на эквивалентный путь без указанного суффикса.

Применение

Данное правило следует разместить в файле .htaccess перед основными директивами WordPress, поскольку WordPress директивы могут перекрыть ваши правила из-за их глобального характера. Это правило будет перехватывать любой запрос на URL, заканчивающийся на .html, и перенаправлять на адрес без этого окончания.

Вот как может выглядеть ваш файл .htaccess:

# BEGIN Redirection
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule (.*)\.html$ /$1 [R=301,L]
</IfModule>
# END Redirection

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

Обратите внимание на наличие условия RewriteCond %{REQUEST_FILENAME} !-f, которое важно включить, если у вас есть некоторые реальные .html файлы, которые должны остаться неизменными – это предохранит их от перенаправления, проверяя, что запрашиваемый файл действительно существует.

Рекомендации

Проверка на ошибки 500: Если после внесения изменений вы получите "Internal Server Error" (ошибка 500), проверьте лог ошибок вашего сервера для получения более детальной информации. Иногда такие ошибки могут быть вызваны синтаксическими ошибками или бесконечными циклами переадресации.
Очистка кэша: После внесения изменений рекомендуется очистить кэш браузера или протестировать изменения в режиме инкогнито, чтобы избежать ситуации, когда кэшированные страницы могут мешать увидеть правильные результаты редиректов.
Тестирование: Постарайтесь протестировать правило с различными URL адресами для убедительности, что оно работает как следует и не вызывает неожиданное поведение сайта.

Важно помнить, что изменение структуры URL на стадии развертывания нового сайта может существенно повлиять на поисковую оптимизацию. Рекомендовано следовать подобного рода переадресациям аккуратно, с предварительными тестами, чтобы обеспечить корректную работу вашего сайта.