(.*)index\.(php|html|htm)$ https://site.ru/$1 [R=301,L]

Описание

Очень важные редиректы. Страницы дубли с index.php можно часто наблюдать в выдаче, когда забывают сделать редиректы. И как правило не на первых страницах выдачи. Также часто забывают закрывать заглушки CMS/темы/хостинга в виде index.html или index.htm

Хочу обратить внимание еще на тот факт, что проверять редиректы лучше не только для главной страницы, но и для страниц категорий, разделов. Особенно часто тут грешат многие CMS (в частности Битрикс, Drupal, Joomla) и страницы категории доступны по адресу а-ля https://site.ru/category/index.php, а то и внутри урла, как у Друпала https://site.ru/index.php/node/

Не забудьте после настройки редиректов, особенно когда убираете index.php, проверить доступность админки и других важных разделов вашего сайта, т.к. скорее всего на них также распространяется правило из htaccess и бывают случаи, что в админку невозможно попасть.

(.*)$ https://example.ru/$1 [R=301,L]

htaccess

.htaccess — перенаправление с www на не www и перенаправление на index.php

Судя по тому, что вы указали в комментариях, не требуется поддерживать два отдельных файла .htaccess . В этом случае было бы проще поддерживать только один файл .htaccess в корне документа (при условии, что они связаны).

Я также делаю следующие предположения о вашем «апи», что также упрощает директивы:

  • Все запросы вида 9апи/. API/index.php [L] # Переписать запросы для корневого приложения RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d Правило перезаписи. index.php [Л]

    Директива RewriteBase здесь не требуется.

    Обратите внимание, что сначала следует протестировать перенаправление 302 (временное), чтобы избежать возможных проблем с кэшированием. И вам, вероятно, потребуется очистить кеш вашего браузера (и любого посредника) перед тестированием.

    Однако небольшое беспокойство по этому поводу (как я упоминал в комментариях) связано с реализацией канонического перенаправления запросов на ваш /апи/ . Скрипты, отправляющие запросы к API, обычно не следуют перенаправлениям — ожидается, что эти запросы уже направляются на канонический URL-адрес. Таким образом, реализация перенаправления для этих запросов потенциально может

    сломать эти «неправильные» вызовы API к неканоническому имени хоста. Имеет ли значение, если вызовы API выполняются на неканоническое имя хоста? Перенаправление с www на не-www обычно предназначено только для SEO, что не относится к API.

    Обслуживание двух

    Файлы .htaccess (альтернативный вариант)

    В качестве альтернативы, если вы поддерживаете два отдельных файла .htaccess (возможно, это два несвязанных проекта). Один в корне, а другой в подкаталоге /api , тогда вам нужно будет повторить перенаправление с www на не-www (каноническое) в обоих файлах . index\.php$ - [L] # Переписать запросы для корневого приложения RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d Правило перезаписи. index.php [Л] 9индекс\.php$ - [L] # Переписываем все в API Правило перезаписи. index.php [Л]

    В отличие от исходного /api/.htaccess , подкаталог api не нужно явно указывать, поскольку мы используем относительных URL-путей (и нет необходимости в директиве RewriteBase ). Относительный URL-путь относится к каталогу, содержащему файл .htaccess , поэтому в данном случае он относится к директиве /api .

    htaccess — Мой веб-сайт продолжает перенаправлять на учетную запись «index.php» в приложении Instagram

    спросил

    5 лет, 10 месяцев назад

    Изменено 5 лет, 10 месяцев назад

    Просмотрено 777 раз

    Мой код htaccess позволяет example. com/username перенаправлять на любое имя пользователя в приложении Instagram. Но когда я открываю example.com , он перенаправляется на учетную запись Instagram под названием 9.0003 index.php . Как я могу это исправить? Вот мой htaccess

     RedirectMatch 302 /(.+) instagram://user?username=$1
    • htaccess
    • редиректы
    • глубокие ссылки
    2

    Вероятно, это связано с тем, что mod_dir выдает подзапрос для индекса каталога (т.е. index.php ).

    Вы можете попробовать добавить в регулярное выражение отрицательный прогноз, чтобы исключить запросы на index.php . Например:

     RedirectMatch 302 /(?!index\.php)(.+) instagram://user?username=$1

    ОБНОВЛЕНИЕ: Если теперь у вас возникла проблема с index.html (другой возможный индекс каталога), вы также можете исключить это:

     RedirectMatch 302 /(?!index\.
     
    No related posts.