Редирект с index php на корень: Настраиваем 301 редирект с index.html или .php в корень сайта

alexxlab

Редиректы NGINX. Примеры перенаправлений в NGINX.

Обновлено: Опубликовано:

Используемые термины: NGINX, http, https, веб-сервер.

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

Настройка перенаправлений
С HTTP на HTTPS
На другой домен
Без www на www (добавить www)
С www на без www (убрать www)
C index.php на /
Перенаправление по умолчанию
С IP-адреса на домен
Для домена и всех его поддоменов
Файл
Часть url на другой сервер
Редирект со слешем
Удалить расширение в URL
На другую страницу
Удалить часть URL
Запросы без расширений
Перевод запросов, если файла не существует
Настройка проксирования
    На другой сервер
    Часть url на другой сервер
    Другой сайт
    На другой сайт по части URL
    Редиректы при проксировании
Немного о 301 и 302

Настройка перенаправлений

Настройки необходимо вносить в файлах конфигураций виртуальных доменов. https://$host$request_uri? <флаг>;

* $host — имя хоста из запроса, если отсутствует — имя в поле «Host» заголовка, если тоже отсутствует — имя сервера; $request_uri — первоначальный запрос с аргументами (все, что идет после доменного имени).
** где флаги могут быть следующие:

  • permanent — перенаправление с кодом 301.
  • redirect — перенаправить с кодом 302.
  • last — закончить обработку с переходом в новый location.
  • break — закончить обработку и остаться в текущем location.

2. Второй: 

return <код> https://$host$request_uri;

* где коды могут использоваться любые, но чаще всего — 301, 302, 404.

Есть различные мнения, какой из методов лучше и безопаснее, поэтому каким воспользоваться — решать по ситуации. В данных примерах используются оба варианта.

После внесения изменений, необходимо проверить их корректность:

nginx -t

И для их применения перезапустить веб-сервер:

systemctl restart nginx

service nginx restart

* в первом примере перезапуск выполняется на новых системах Linux. Второй пример — на устаревших или FreeBSD.

Проверяя редиректы в браузере, следует учесть, что настройки могут кэшироваться. Для обновления кэша используйте комбинацию Ctrl + F5. Если и это не помогает, закрывайте вкладку и открывайте новую.

С HTTP на HTTPS (другой порт)

Пример конфигурации для перенаправления запросов на другой порт — с 80 (http) на 443 (https):

server {
        listen 80;
        server_name domain.ru www.domain.ru;
        return 301 https://$host$request_uri;
}

* в данном примере для всех обращений к сайту domain.ru по 80 порту (http) будет работать редирект на 443 порт (https) с кодом 301 (для склеивания доменов).

Также мы можем добавить условие, чтобы не перенаправлять на https для определенных ссылок, например:

server {
        listen 80;
        server_name domain.ru www.domain.ru;
        if ($uri !~ /page.html){
                return 301 https://$host$request_uri;
        }
}

* в данном примере запрос на страницу /page. html будет открыт по http.

Есть еще способ настройки директивы server сразу для http и https. При этом, если зайти по 80 порты, нас перекинет на 443:

server {
    listen       80;
    listen       443 ssl;
    server_name  domain.ru www.domain.ru;

    if ($scheme = ‘http’) {
        return 301 https://$host$request_uri;
    }

    ssl_certificate     /etc/nginx/ssl/cert.pem;
    ssl_certificate_key /etc/nginx/ssl/cert.key;

    …
}

* данный способ удобен, чтобы не создавать несколько секций server со своими настройками.

С одного домена на другой

server {
        …
        server_name domain1.ru;
        return 302 http://domain2.ru$request_uri;
}

C домена без www на домен с www

server {
        …
        server_name domain.ru;
        return 301 http://www.$host$request_uri;
}

С www на без www

Конкретный домен:

server {
        . (.*)index\.(?:php|html)») {
                return 301 $1;
        }
}

Перенаправление запросов для отсутствующих доменов (перенаправление по умолчанию)

Если обращение к веб-серверу идет по IP-адресу или домену, который не прописан в конфигурационном файле, можно перенаправить весь трафик на домен по умолчанию:

server {
        listen 80 default_server;
        return 302 https://welcome.domain.ru$request_uri;
}

или независимо от протокола:

server {
        listen 80 default_server;
        return 302 $scheme://welcome.domain.ru$request_uri;
}

server {
        listen 443 ssl default_server;
        return 302 $scheme://welcome.domain.ru$request_uri;

        ssl_certificate /etc/nginx/ssl/cert.pem;
        ssl_certificate_key /etc/nginx/ssl/cert.key;
}

* $scheme позволяет перевести запрос на тот же протокол (http или https), по которому он был инициирован.
* если nginx должен слушать и обрабатывать запросы по https, необходимо указывать в настройках пути к сертификатам. /page1$ /page2 permanent;
}

б) с помощью return:

server {
        …
        location = /page1 {
            return 301 /page2;
        }
}

Удалить часть URL

Иногда нужно удалять часть url. Это можно сделать следующими способами:

server {
        …
        rewrite /deleted-url/(.*) /$1 permanent;
}

или:

server {
        …
        if ($request_uri ~ «/deleted-url/(.*)») {
                return 301 $1;
        }
}

* в данном примере из url мы удалим deleted-url/.

Перенаправить запрос в случае обращения к несуществующим файлам

Предположим, что нам нужно обращаться к скриптам на сервере, но без прописывания в URL .php на конце. Запрос будет выглядеть, примерно, http://url/. Чтобы nginx перекинул запрос на url.php вставляем следующее:

server {
    …
    location / {
       root /var/www;
       try_files $uri $uri/ $uri. (.*)$ /$1.php;
        }
}

* в данном примере мы проверяем наличие файла, к которому идет обращение. И если его нет, то происходит замена адреса на такое же имя файла с .php на конце.

Перевод запросов, если файла не существует

Данное действие не является редиректом, но близко по смыслу — NGINX проверяет наличие файла скрипта, к которому идет обращение, и если его нет, переводит запрос на другой файл. Как правило, это используется для того, чтобы перевести все обращения на файл index.php.

server {
    …
    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }
    …
}

* в данном примере мы скажем веб-серверу сначала проверить наличие скрипта по пути $uri, затем $uri/ и если ответ будет 404, запросы будут обрабатываться с помощью файла index.php в корневой директории.

Проксирование

Проксирование, в отличие от редиректа, не передает инструкции браузеру перейти на другой url — NGINX сам выполняет http-запрос по другому адресу и возвращает готовый ответ. Эта возможность может применяться для внутреннего распределения серверных ресурсов.

Хоть это и не совсем редирект, рассмотрим примеры его настройки, так как очень часто нужно не перенаправление, а, как раз, обратное проксирование.

1. На другой сервер

Пример внутреннего перенаправления http-запроса на другой веб-сервер:

…
location / {
            proxy_pass $scheme://192.168.0.15:8080/;
            proxy_redirect     off;
            proxy_set_header   Host             $host;
            proxy_set_header   X-Real-IP        $remote_addr;
            proxy_set_header   X-Forwarded-For  $proxy_add_x_forwarded_for;
}

* в данном случае, принимать запросы от браузера и отвечать на них будет NGINX, а сама обработка будет выполняться на сервере с IP-адресом 192.168.0.15 на порту 8080.

Использование NGINX в качестве http-прокси:

server {
        …
        server_name site1.ru www.site1.ru;
        location / {
            proxy_pass http://192. 168.1.21/;
            proxy_redirect     off;
            proxy_set_header   Host             $host;
            proxy_set_header   X-Real-IP        $remote_addr;
            proxy_set_header   X-Forwarded-For  $proxy_add_x_forwarded_for;
        }
}

server {
        …
        server_name site2.ru www.site2.ru;
        location / {
            proxy_pass http://192.168.1.22/;
            proxy_redirect     off;
            proxy_set_header   Host             $host;
            proxy_set_header   X-Real-IP        $remote_addr;
            proxy_set_header   X-Forwarded-For  $proxy_add_x_forwarded_for;
        }
}

* в данном примере запросы на site1.ru будут перекинуты на сервер 192.168.1.21, а запросы на site2.ru — 192.168.1.22.

HTTP proxy с авторизацией (если удаленный веб-сервер требует аутентификации):

server {
    . /page1/(.*)$ {
        proxy_pass   $scheme://10.10.10.10/$1;
    }
}

* и так, в данном примере при обращении по адресу site.ru/page1/<что-то еще>, nginx сделает внутренний запрос на сервер 10.10.10.10 по адресу 10.10.10.10/<что-то еще> и вернет готовый ответ.

3. На другой сайт

Мы можем сделать так, что при переходе по одному адресу у нас будет открываться совершенно другой сайт:

server {
    …
    server_name dmosk.local;
    location / {
        proxy_pass https://www.dmosk.ru;
        proxy_set_header   Host             www.dmosk.ru;
        proxy_set_header   X-Real-IP        $remote_addr;
        proxy_set_header   X-Forwarded-For  $proxy_add_x_forwarded_for;
    }
}

* в данном случае мы при обращении к нашему серверу (до доменному имени dmosk.local) будем попадать на сайт https://www.dmosk.ru. Обратите внимание, что в proxy_set_header мы передаем хосту его имя — в противном случае, как правило, другой сервер вернет ошибку. Также мы не указываем proxy_redirect, иначе, nginx будет переводить запросы на реальный сайт (отправлять инструкции браузеру перейти на него), а не тот, что мы используем за http-прокси.

4. На другой сайт по части URL

Если нам нужно настроить проксирование на другой сайт при обращении к определенной странице сайта, настраиваем NGINX так:

server {
    …
    server_name www.dmosk.ru;
    location /page {
        rewrite /page/(.*) /$1  break;
        proxy_pass https://www.site.ru;
        proxy_set_header   Host             www.site.ru;
        proxy_set_header   X-Real-IP        $remote_addr;
        proxy_set_header   X-Forwarded-For  $proxy_add_x_forwarded_for;
    }
}

* в данном примере, если мы перейдем на страницу www.dmosk.ru/page, то мы попадем на сайт www. site.ru.

5. Редиректы при проксировании

Если при проксировании хост возвращает инструкцию браузеру для выполнения редиректа, обозреватель может сменить адрес сайта. Это особенно не удобно, когда проксирование мы выполняем на другой сайт. Чтобы отловить редиректы и заменить их своими значениями, мы должны воспользоваться опцией proxy_redirect. Рассмотрим ее применение для предыдущего примера, когда мы проксировали запрос на сайт www.dmosk.ru:

server {
    listen 80;
    server_name dmosk.local www.dmosk.local;
    location / {
        proxy_pass https://www.dmosk.ru;
        proxy_set_header   Host             www.dmosk.ru;
        proxy_set_header   X-Real-IP        $remote_addr;
        proxy_set_header   X-Forwarded-For  $proxy_add_x_forwarded_for;

        proxy_redirect https://www.dmosk.ru/url1 http://dmosk.local/url2;
        proxy_redirect https://www.dmosk.ru/ http://dmosk.local/;
    }
}

* в конкретном случае мы проксируем запросы http://dmosk. local на сайт www.dmosk.ru, но если он вернет инструкцию для редиректа https://www.dmosk.ru/url1, в браузере он должен быть заменен на http://dmosk.local/url2. А также любое перенаправление для https://www.dmosk.ru/ будет заменено на http://dmosk.local/.

Немного о 301 и 302

В чем принципиальная разница между ответом с кодом 301 и 302? Для обычного посетителя сайта разницы нет. А вот для поискового робота разница огромная.

301-й редирект говорит о склеивании страниц. Это означает для поисковика то, что старая и новая страницы — это одно и то же. Таким образом, результаты ранжирования необходимо сохранить для новой страницы.

302-о перенаправление просто говорит о том, что нужно перейти по другому адресу. Поисковый робот не сохраняет результат выдачи для новой страницы, индексируя его с нуля.

Шпаргалка по mod_rewrite. 301 редирект

Любой вебмастер не раз сталкивался с необходимостью сделать 301 редирект (при изменение адреса страницы, склейке доменов, удалении дублей). abc]не «a», не «b» и не «c»\sПробел

a?0 или 1 символ «а»a*0 или больше «а»a*?0 или больше «а», нежадныйa+1 или больше «а»a+?1 или больше «а», нежадныйa{3}ровно 3 символа «а»a{3,}3 или больше «а»a{3,6}от 3 до 6 «а»a{3,6}?от 3 до 6 «а», нежадный!(…)Префикс «не» (действует если шаблон не подходит)
Флаги RewriteCond
NCНе учитывать регистр
ORКомбинировать по принципу «или»

Флаги RewriteRule
R[=code]Редирект, опционально с кодом
FДоступ запрещен (посылает 403 заголовок)
G«Мертвая» страница (удалена)
PПрокси
LПоследнее правило
NСледующий круг
CЦепочка
T=mime-typeУстановить MIME-тип
NSПропустить внутренний подзапрос
NCНе учитывать регистр
QSAДобавить строку запроса
NEНе экранировать при выводе
PTПропустить через следующий
S=xПропустить следующие х правил
E=var:valueУстановить переменную окружения
Коды заголовков перенаправления
301Перенесен постоянно
302Перенесен временно
403Доступ запрещен
404Страница не найдена
410«Мертвая» страница

Переменные: HTTP заголовкиПеременные: время
%{HTTP_USER_AGENT}		%{TIME_YEAR}
%{HTTP_REFERER}%{TIME_MON}
%{HTTP_COOKIE}%{TIME_DAY}
%{HTTP_FORWARDED}%{TIME_HOUR}
%{HTTP_HOST}%{TIME_MIN}
%{HTTP_PROXY_CONNECTION}%{TIME_SEC}
%{HTTP_ACCEPT}%{TIME_WDAY}
%{TIME}
Переменные: запросПеременные: сервер
%{REMOTE_ADDR}%{DOCUMENT_ROOT}
%{REMOTE_HOST}%{SERVER_ADMIN}
%{REMOTE_IDENT}%{SERVER_NAME}
%{REQUEST_METHOD}%{SERVER_ADDR}
%{SCRIPT_FILENAME}%{SERVER_PORT}
%{PATH_INFO}%{SERVER_PROTOCOL}
%{QUERY_STRING}%{SERVER_SOFTWARE}
%{AUTH_TYPE}
Переменные: специальныеДирективы
%{API_VERSION}RewriteEngine
%{THE_REQUEST}RewriteOptions
%{REQUEST_URI}RewriteLog
%{REQUEST_FILENAME}RewriteLogLevel
%{IS_SUBREQ}RewriteLock
RewriteMap
RewriteBase
RewriteCond
RewriteRule

Для того чтобы нижеизложенные шаблоны работали нужно перед их использованием прописать в файле . /])$ /$1/ [R=301,L]Подписывайтесь на канал

Яндекс.Дзен и узнавайте первыми о новых материалах, опубликованных на сайте.

Перенаправить index.php в корень

Блоги WordPress показывают одинаковый дублированный контент для https://www.askapache.com/index.php и https://www.askapache.com/ . Если вы читали об использовании файла robots.txt для WordPress SEO, то вы уже понимаете, что эта настройка приводит к штрафам

Duplicate Content , взимаемым с вашего блога и веб-сайта поисковыми системами.

Обычный запрос — удалить или перенаправить index.php от появления в URL-адресе. Это возможно только с технологией на стороне сервера, такой как файлы конфигурации .htaccess или конфигурация вашего основного сервера с использованием модуля перезаписи Mod_Rewrite.

Исправление перенаправления

Исправление представляет собой немного умного кода .htaccess, использующего mod_rewrite для перенаправления index. php только в том случае, если запрос /index.php поступил от клиента (например, браузера или веб-робота) , а не если запрос является внутренним перенаправлением 9index.php$ https://www.askapache.com/blog/ [R=301,L] RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d Правило перезаписи. /blog/index.php [L]

Проблема в том, что любой запрос «/» внутренне перезаписывается Apache mod_dir в index.php, если у вас есть index.php в списке DirectoryIndex (обычная настройка ), поэтому трудно избежать бесконечного цикла.

Htaccess

« Хотите знать, как по-настоящему взломать? Устранение неполадок аутентификации Apache .htaccess »

Информация — это свобода. Свобода не подлежит обсуждению. Не стесняйтесь изменять, копировать, переиздавать, продавать или использовать что-либо на этом сайте в любое время

Онлайн-инструменты
  • Преобразователь изображений Base64
  • Отладчик HTTP-запросов
  • Whoami — Ваша информация
  • Поиск поставщиков Mac-адресов
  • Файлы Htaccess с Github
Популярные статьи
  • Абсолютный Htaccess
  • Mod_Rewrite Советы и рекомендации
  • Сумасшедший расширенный Mod_Rewrite
  • Шпаргалка Mod_Rewrite
Взлом и хакеры

Использование слова «хакер» для обозначения «взломщика безопасности» является путаницей со стороны средств массовой информации. Мы, хакеры, отказываемся признавать это значение и продолжаем использовать это слово для обозначения кого-то, кто любит программировать, кого-то, кто наслаждается игривым умом, или их комбинации.
— Ричард М.

Столмен

Конфигурация

.htaccess. Как я могу перенаправить все index.php с URL-адресов, чтобы предотвратить дублирование URL-адресов?

Моя команда SEO сообщила о повторяющихся URL-адресах. Я включил URL-адреса SEF и переименовал htaccess.txt в .htaccess .

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

example.com/имя_папки/

example.com/index.php/foldername/

Как сделать перенаправление, которое удалит index.php из любой комбинации папок и перенаправит его?

  • .htaccess-configuration
  • перенаправление
  • seo

Вы можете добавить что-то вроде следующего в начало корневого файла .htaccess в 301 запрос перенаправления для / index.php/<что-нибудь> назад на /<что-нибудь> (канонический URL-адрес) — чтобы сделать вашу SEO-команду счастливой: 9индекс\.

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

Где example.com — ваше каноническое имя хоста (с www или без www и т. д.). Включив сюда абсолютный/канонический URL-адрес, вы потенциально сможете избежать многочисленных переадресаций позже.

Обратная ссылка $1 содержит URL-путь, следующий за index.php (если есть), за вычетом префикса косой черты — как указано в шаблоне RewriteRule . Таким образом, это также будет соответствовать как /index.php , так и 9.0005 /index.php/ и перенаправить на https://example.com/ (домашняя страница) в обоих случаях.

Это перенаправление необходимо для SEO , если вы только недавно активировали URL-адреса SEF, а старые URL-адреса, содержащие index.php , уже были проиндексированы поисковыми системами или связаны с внешними третьими лицами. Однако, если вы реализуете URL-адреса SEF с самого начала, маловероятно, что поисковые системы/третьи стороны найдут неканонические URL-адреса, поэтому это вряд ли вызовет проблемы (но не невозможно).

Вам не нужно включать дополнительную директиву RewriteEngine On , так как она уже встречается позже в файле. Либо включить вышеприведенное правило сразу после директивы RewriteEngine — для большей «читабельности».

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

4

Гугл не дурак. На мой взгляд, это бессмысленно, и я не буду вставлять код, который делает это перенаправление. SEO-дураки будут стонать, но боты Google — нет.

Повторяющиеся записи видны, когда вы вводите site:mysite.xxx в Google. Я с трудом верю, что они видят какие-либо дубликаты, каноники и т. д.

Люди, которые утверждают, что SEO могут потребовать деньги. Сначала проверьте тег «сайт» в Google и отправьте свой сайт в службы Google, чтобы получить ошибки и т.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *