301 редирект с помощью .(.*)$ http://%{HTTP_HOST}/$1 [R=301,L]

Original: web-optimizator.com

Настройка редиректов в Nginx | serveradmin.ru

Хочу сегодня рассмотреть тему редиректов в Nginx. Я обычно настраиваю их в лоб. То есть нужен какой-то редирект, я его добавляю. На днях меня попросили СЕО специалисты переработать редиректы одного проекта и сделать так, чтобы для клиента был ровно один 301 редирект, который включает в себя сразу все необходимые преобразования url.

Если у вас есть желание научиться работать с роутерами микротик и стать специалистом в этой области, рекомендую по программе, основанной на информации из официального курса MikroTik Certified Network Associate. Курс стоящий, все подробности читайте по ссылке. Есть бесплатные курсы.

Пример двойного редиректа

Для того, чтобы было понятно, о чем идет речь, приведу пример. Допустим, у вас настроен редирект с http на https и добавление к урлу в конце слеш./])$ $1/ permanent; ………………. }

В целом все нормально, редиректы работают. Но если перейти по ссылке http://site.ru/catalog, мы получим 2 301-х редиректа.

# curl -I -L http://site.ru/catalog

HTTP/1.1 301 Moved Permanently
Server: nginx
Content-Type: text/html
Content-Length: 162
Connection: keep-alive
Location: https://site.ru/catalog

HTTP/2 301 
server: nginx
content-type: text/html
content-length: 162
location: https://site.ru/catalog/

HTTP/2 200 
server: nginx
content-type: text/html; charset=UTF-8
vary: Accept-Encoding

На выходе у вас 2 редиректа вместо одного, что плохо для СЕО. Надо по возможности все реализовать в одном. В данном случае напрашивается простое и очевидное решение:

server {
 listen 80;
 server_name site.ru www.site.ru;
 root   /var/www/site./(.*)/$ /$1;
  return 301 https://site.ru$uri/;
 }
}

Обращаю внимание на то, что сделано. Я использую rewrite без какого-либо флага на конце, чтобы не прекращать обработку директив. В данном случае просто меняется uri и передается дальше. Если запрос приходит со слешом на конце, мы его обрезаем и отправляем в правило редиректа на https. Если слеша нет, то он сразу на редирект уходит. Теперь все в порядке.

Встроенные редиректы WordPress

Очевидно, что выше описана простая ситуация. На нее достаточно обратить внимание и исправить. Но не всегда бывает так просто. Например, вы сами не настраивали редирект урлов без слеша на урлы со слешом, он вам не нужен. Но, к примеру, WordPress реализует подобный редирект своими средствами. В итоге, при запросе http://site.ru/catalog вы получите такую картину с редиректами.

# curl -I -L http://site.ru/catalog

HTTP/1.1 301 Moved Permanently
Server: nginx
Content-Type: text/html
Content-Length: 162
Connection: keep-alive
Location: https://site.ru/catalog

HTTP/2 301 
server: nginx
content-type: text/html; charset=UTF-8
location: https://site.ru/catalog/
x-powered-by: PHP/7.4.2
x-redirect-by: WordPress

HTTP/2 200 
server: nginx
content-type: text/html; charset=UTF-8
vary: Accept-Encoding

Сначала nginx сделал редирект на https, так как вы это настроили у него в конфигурации, а потом wordpress на страницу со слешом на конце. В итоге у вас два редиректа, а надо один. Причем, два редиректа получились не по вашей воле. Если не обратите на это внимание, так и будете с ними жить. По факту, все типовые редиректы лучше сразу реализовывать в одном месте в веб сервере.

Все стандартные редиректы в nginx

Рассмотрю типовой пример, когда у нас одновременно присутствуют следующие редиректы:

1. С http на https.
2. С www на без www для обоих протоколов.
3. Без слеша на конце на урл со слешем./(\.ht|xmlrpc\.php)$ { return 404; } location ~ \.php$ { try_files $uri =404; fastcgi_pass unix:/var/run/php-fpm/php7-fpm.sock; fastcgi_index index.php; fastcgi_param DOCUMENT_ROOT /web/sites/site.ru/www/; fastcgi_param SCRIPT_FILENAME /web/sites/site.ru/www$fastcgi_script_name; fastcgi_param PATH_TRANSLATED /web/sites/site.ru/www$fastcgi_script_name; include fastcgi_params; fastcgi_param QUERY_STRING $query_string; fastcgi_param REQUEST_METHOD $request_method; fastcgi_param CONTENT_TYPE $content_type; fastcgi_param CONTENT_LENGTH $content_length; fastcgi_param HTTPS on; fastcgi_intercept_errors on; } location = /favicon.ico { log_not_found off; access_log off; } location = /robots.txt { allow all; log_not_found off; access_log off; } } server { listen 443 ssl http2; server_name www./(.*)/$ /$1; return 301 https://site.ru$uri/; } }

   Получилось примерно так. Призываю не копировать бездумно конфиг, а проверить то, что я предлагаю. Хотя я сам внимательно проверил, как мог, но все равно не застрахован от ошибки. На мой взгляд здесь рассмотрены все основные моменты с редиректами. На выходе всегда один 301 редирект, какой бы запрос мы не сделали. При этом все реализовано средствами самого веб сервера, а значит, будет работать максимально быстро.

   Корректный редирект с одного url на другой

   Допустим вы корректно настроили стандартные редиректы в nginx. А потом в какой-то момент у вас поменялась структура сайта, или просто нужно было сделать редиректы для отдельных страниц. К примеру, запрос https://site.ru/main/hello/ перенаправить в https://site.ru/main/. По идее ничего сложного. Добавляем редирект:

   server {
    listen 443;
   ........................
    location /main/hello {
     return 301 /main/;
    }
   ./(.*)/$ /$1;
   	return 301 https://site.ru/main/;
       }
   }

   Ну и так далее. Думаю, идея ясна. Следует следить за всеми редиректами и стараться всегда оставлять только один.

   Заключение

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

   Материал полностью написан и протестирован мной от начала до конца, поэтому призываю не копировать слепо к себе, а проверить. Я могу где-то ошибаться, что в такой важной теме может быть чревато проблемами с индексацией и работой сайта. Так что внимательно все проверяйте, прежде чем внедрять у себя. Ну а замечания все, как обычно, жду в комментариях.

   В завершении рекомендую мою статью про настройку nginx. Я там частично рассматриваю и эту тему. А вообще там рассказаны все основные моменты, на которые стоит обращать внимание при работе с nginx.

   Онлайн курс по Kubernetes

   Онлайн-курс по Kubernetes – для разработчиков, администраторов, технических лидеров, которые хотят изучить современную платформу для микросервисов Kubernetes. Самый полный русскоязычный курс по очень востребованным и хорошо оплачиваемым навыкам. Курс не для новичков – нужно пройти вступительный тест.

   Если вы ответите «да» хотя бы на один вопрос, то это ваш курс:

   • устали тратить время на автоматизацию?
   • хотите единообразные окружения?;
   • хотите развиваться и использовать современные инструменты?
   • небезразлична надежность инфраструктуры?
   • приходится масштабировать инфраструктуру под растущие потребности бизнеса?
   • хотите освободить продуктовые команды от части задач администрирования и автоматизации и сфокусировать их на развитии продукта?
   Сдавайте вступительный тест по и присоединяйтесь к новому набору!.

   Помогла статья? Подписывайся на telegram канал автора

   Анонсы всех статей, плюс много другой полезной и интересной информации, которая не попадает на сайт.

   Как принудительно использовать https, www и косую черту с помощью одного перенаправления

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

   Позвольте мне объяснить проблему … и мою проблему с типичными решениями.

   Вы можете использовать файл .htaccess, чтобы заставить ваш сайт использовать только https: // или только www. как поддомен. Это может помочь гарантировать, что на вашем сайте не будет повторяющихся страниц. Каждый специалист по поисковой оптимизации (SEO) знает, что дублировать контент — это плохо.

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

   Проблема дублирования контента

   Допустим, вы являетесь веб-мастером веб-сайта, и на нем установлен протокол SSL (Secure Socket Layer).Если вы не создали никаких правил перезаписи, все следующие страницы, вероятно, вернут действительные 200 страниц.

   1. http://example.com/blog
   2. http://example.com/blog/
   3. http://www.example.com/blog
   4. http://www.example.com/blog/
   5. https://example.com/blog
   6. https://example.com/blog/
   7. https://www.example.com/blog
   8. https: // www.example.com/blog/

   Проблема здесь в том, что вы можете иметь http: // или https: // поверх www. или нет, а конечные / или нет. Следует отметить, что Google не рассматривает завершающую косую черту в корневом домене как отдельную страницу.

   Джон Мюллер из Google пояснил, что считается дублированным контентом в этом твите.

   Я заметил некоторую путаницу вокруг конечных косых черт в URL-адресах, поэтому надеюсь, что это поможет.tl; dr: косая черта для root / hostname = не имеет значения; косая черта в другом месте = имеет значение (это разные URL) pic.twitter.com/qjKebMa8V8

   — John ☆ .o (≧ ▽ ≦) o. ☆ (@JohnMu) 19 декабря 2017 г.

   Как исправить проблему и убить ваш сайт.

   Ладно … «убить» — это гипербола. Но об этом должно заботиться больше людей!

   Вы можете найти множество полезных статей и сообщений на форуме о том, как принудительно использовать https: // или как принудительно использовать www. и еще как форсировать замыкающие /.(. *) / $ http://www.example.com/$1 [L, R = 301]

   Идеальное решение . danielmorell \.(. *) / $ http://www.danielmorell.com/$1 [L, R = 301]

   Теперь, когда я атаковал свой бедный сервер этим чудовищем, я протестирую его. Чтобы проверить это, я войду в корневой домен своего сайта без https: // или www. и /. Тест будет состоять в том, чтобы увидеть, правильно ли он изменяется.

   Я ввожу URL-адрес, который выглядит так.

   Когда я нажимаю клавишу Enter , страница загружается и URL-адрес выглядит следующим образом.

   Вам, наверное, интересно, в чем дело. Я хотел заставить https: // wwww. и избавьтесь от конечных /. Если это был результат, почему я не счастлив?

   Проблема в том, чего вы не видите.

   Если мы внимательно посмотрим на сетевые запросы, мы обнаружим кое-что, что должно беспокоить. Вот первые три файловых ответа от сервера.

   Как видите, нас дважды перенаправляли.Нам нужно внимательнее взглянуть на то, что произошло.

   Как видите, заголовки ответа HTTP дают нам четкое представление о проблеме. Когда мы нажимаем , введите после ввода http://danielmorell.com/ , мы 301 перенаправляем на http://www.danielmorell.com/ .

   Когда браузер запрашивает «новое местоположение» http://www.danielmorell.com/ , он 301 снова перенаправляется на https://www.danielmorell.com/ .

   Наконец, браузер пробует наше третье местоположение https: // www.danielmorell.com/ и получает ответ 200 Success.

   Почему https://www.danielmorell.com/ не перенаправлялись на https://www.danielmorell.com ? Причина в том, что это корневой каталог домена. Условие перезаписи для завершающей косой черты проверяет, не является ли это каталогом. Если это каталог, последнее правило перезаписи игнорируется.

   Завершающая косая черта удаляется браузером, поскольку ответ представляет собой файл index.php , который был переписан на имя домена.

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

   Редиректы и PageRank

   Мэтт Каттс из Google заявил в 2013 году, что около 15% PageRank теряется при переадресации 301. Это основано на опасениях Google, что люди будут использовать 301 вместо стандартных ссылок, чтобы получить больше PageRank.

   В анатомии крупномасштабной гипертекстовой поисковой системы 0.85 Снижение рейтинга страниц по ссылкам было основано на возможности «случайного пользователя», перешедшего по ссылке. С самого начала цель Google заключалась в том, чтобы ранжировать веб-страницы, пытаясь создать алгоритм, который отражает поведение человека. Вот почему Google обновил свою модель «случайного серфера» до модели «разумного серфера».

   Поэтому неудивительно, что со временем Google определил, что переадресация 301 не теряет PageRank. Одно перенаправление имеет одно происхождение и одно место назначения. Неразумно полагать, что человек уйдет с перенаправления после того, как будет запрошен перенаправляемый URL.

   Следовательно, логично, что в 2016 году Гэри Илес из Google написал в Твиттере: «30-кратная переадресация больше не теряет PageRank».

   30x редиректы больше не теряют PageRank.

   — Гэри «鯨 理» Иллис (@methode) 26 июля 2016 г.

   Что это означает для редиректов и SEO? Можем ли мы иметь столько перенаправлений, сколько захотим? Ответ — нет. Не будем обманывать себя. PageRank — это не единственный показатель ранжирования, который имеет значение. Если «выкачивание ссылочного веса» — единственное, что нас волнует, мы должны уйти из бизнеса SEO.

   Мы должны смотреть на это с точки зрения возможности сканирования, индексации и качества, а не только PageRank. Google заявил, что они не будут сканировать более пяти переадресаций.

   Если бы мы были таковыми, мы бы признали, что перемещаем контент и создаем 301 по другим причинам. Вместо обычных одного или двух, мы могли бы искать от пяти до шести перенаправлений, если мы не указываем на правильный протокол и т. Д.

   Пример: цепочка перенаправления в дикой природе

   Вот пример небрежной цепочки переадресации, которую я обнаружил в дикой паутине.

   Запрошенный URL

   http://example.com/contact/

   Первая 301

   http://www.example.com/contact/

   Второй 301

   https://www.example.com/contact/

   Третий 301

   http://www.example.com/contact

   Четвертый 301

   https://www.example.com/contact

   Конечный URL

   https://www.example.com/contact

   Этого достаточно, чтобы заставить плакать хорошего веб-мастера или SEO.

   У нас явно проблема. Нам нужно решение.

   https, www и завершающая косая черта с одним перенаправлением.

   На самом деле способ исправить это довольно просто. Помните, что файлы .htaccess, как и другие файлы конфигурации Apache, читаются сверху вниз. Наши предыдущие правила перезаписи .htaccess сначала проверялись на www. . Если этого не было, он добавил его с перенаправлением. После этого перенаправления он добавил перенаправление https: // . Последнее перенаправление — удалить завершающую косую черту.

   Правильный способ — выполнить проверку .htaccess для /, а затем проверить www. и https: // . Если какой-либо из желаемых нами параметров URL-адреса неверен, мы используем одно правило RewriteRule для изменения URL-адреса. Этот метод приводит только к одному редиректу 301.

   Чтобы наше перенаправление работало правильно, мы также должны внести несколько изменений в способ проверки каждой проблемы.

   Шаг 1: Мы проверим включение Rewrite Engine.

     RewriteEngine на  

   Это легко забыть.

   Шаг 2: Проверьте наличие косой черты в конце URL-адресов без файлового пути.

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

   Мы также хотим определить, заканчивается ли URL-адрес косой чертой.

     RewriteCond% {REQUEST_URI} / (.https://www.example.com/%1 [R = 301, L]  

   Это правило RewriteRule берет URL-адрес из группы захвата (. +) в нашем первом RewriteCond и добавляет его в домен. Вы можете видеть, что URL-адрес сайта включает в себя как www, , так и https: // . Это означает, что с первого раза он попадет в нужное место.

   Шаг 3: Нам нужно принудительно применить политику завершающей косой черты для каталогов.

     RewriteCond% {REQUEST_URI}! (.(. +) $ https://www.example.com/$1/ [R = 301, L]  

   Наш RewriteRule берет запрошенный путь URL и добавляет его к домену, за которым следует косая черта в конце. Группа захвата (. +) захватывает путь, только если есть один или несколько символов. Это гарантирует, что мы не разместим второй / в корне веб-сайта.

   Шаг 4: Нам нужно проверить, есть ли www. включен в запрошенный URL, а https — это используемый протокол или схема.www \. (. *) $ [ИЛИ, NC] RewriteCond% {https} со скидкой

   Первая строка проверяет, отсутствует ли наш www .

   Важно использовать флаги no case [NC] и [OR] . Домены не чувствительны к регистру. Если вы не используете флаг отсутствия регистра, он может перенаправить на Www. (.*) $ https://www.danielmorell.com/$1 [R = 301, L]

   Наконец, наше последнее правило RewriteRule берет запрошенный путь и добавляет его в домен с добавленными www и https .

   Для этого мы используем группу захвата (. *) , которая захватывает ноль или более символов. Это гарантирует, что мы перенаправляем любой запрос в корень веб-сайта, у которого нет www и https .

   Собираем все вместе. Должно получиться вот так.(. *) $ https://www.example.com/$1 [R = 301, L]

   Давайте воспользуемся этим на моем сайте, чтобы увидеть, что произойдет.

   Как видите, есть только один редирект 301! Это лучше для вашего сайта, чем цепочка переадресации, которую используют многие люди.

   Никогда раньше не видели? Ты не одинок!

   Когда я впервые написал это руководство, на некоторых известных веб-сайтах была эта проблема. В их число вошли neilpatel.com, hubspot.com и searchchenginewatch.com. Вы в хорошей компании.

   Большинство сайтов используют как минимум метод двух перенаправлений.(. *) / $ https://www.example.com/$1 [R = 301, L]

   Этот метод приводит к двум перенаправлениям. Это не страшно, но зачем создавать два, если можно использовать один?

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

   Нужна другая конфигурация?

   Вы можете получить образцы кода конфигурации .htaccess для каждого варианта ( http, vs. https и www vs. нет www ) в разделе «Образец кода» данного руководства.

   Вы также можете использовать созданный мною генератор перенаправлений для создания оптимизированных для SEO перенаправлений .htaccess.

   Перенаправить образцы Генератор перенаправления

   Убрать косую черту в конце ссылок

   Модератор т-п

   (@ t-p)

   Вы уверены, что переадресация вызывается конечными косыми чертами? Обычно бывает наоборот, отсутствие заставляет WP перенаправлять на с.В этом случае, ИМО, лучше везде включать завершающие слэши, чем пытаться бороться с этим.

   Не уверен, откуда вы взяли, что косая черта в конце была неправильной — так как это правильно.

   Сделайте этот быстрый тест, предполагая, что у вас есть функция поиска на вашем сайте / теме. Найдите что-нибудь и посмотрите, что произойдет, без косой черты в конце. Будет интересно узнать результаты и то, как WordPress с этим справляется.

   Автор темы Slavek

   (@jackoneill)

   Это будет замена исходного веб-сайта, на котором не используются завершающие косые черты.И по причинам SEO (https://ahrefs.com/blog/trailing-slash/) мне нужно оставить его таким. Теперь Google индексирует все URL без косой черты.
   Это промежуточный веб-сайт http://test.adeon.cz/, а это исходный https://www.adeon.cz/.
   Но поправьте меня, если я ошибаюсь.

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

   Привет! @bcworkz @jackoneill
   Моя проблема противоположна этой теме.

   Возможно, вы знаете об этой проблеме:
   Мои постоянные ссылки со знаком «/» в конце.
   Но мой веб-сайт генерирует 2 URL с «/» и без «/»:
   1.domain.com/category — с 301 редиректом
   2. domain.com/category/ — 200 OK`

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

   Срезать или не рубить | Центральный блог Google Search

   21 апреля 2010 г., среда

   Уровень веб-мастера: средний

   Это вопрос, который мы часто слышим. Вперед к ответам! Исторически сложилось так, что URL-адреса с косой чертой в конце указывают каталог, а URL-адреса без косой черты — для обозначения файла:

   http: // example.com / foo / (с косой чертой в конце, обычно это каталог)
   http://example.com/foo (без косой черты в конце, обычно файл)

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

   Различный контент на / и без / URL подходит для Google, часто менее идеален для пользователей

   С технической точки зрения, с точки зрения поисковой системы, эти две версии URL, безусловно, могут содержать разный контент.Однако ваши пользователи могут найти эту конфигурацию ужасно запутанной — просто представьте, если www.google.com/webmasters а также www.google.com/webmasters/ произвел два отдельных опыта.

   По этой причине URL-адреса с косой чертой в конце и без косой черты часто обслуживают одно и то же содержимое. Самый распространенный случай — когда сайт настроен со структурой каталогов:
   http://example.com/parent-directory/child-directory/

   Конфигурация вашего сайта и ваши возможности

   Вы можете быстро проверить свой сайт, чтобы убедиться, что URL-адреса:
   

   1. http: // <здесь- ваш-домен> / <здесь-некоторый-> /
      (с косой чертой в конце)
   2. http: // <здесь-ваш-домен> / <здесь-некоторый-каталог>
      (без косой черты в конце)
   не оба возвращают 200 код ответа, но эта одна версия перенаправляет к другому.
   
   • Если может быть возвращена только одна версия (т. Е. Другая перенаправляет на нее), это прекрасно! Такое поведение выгодно, поскольку снижает дублированный контент. В конкретном случае перенаправления на завершающие URL-адреса косой черты в наших результатах поиска, скорее всего, будет отображаться версия URL-адреса с кодом ответа 200 (чаще всего URL-адрес завершающей косой черты) — независимо от того, было ли перенаправление 301 или 302.
   
   
   • Если версии с косой чертой и без косой черты содержат одно и то же содержимое и каждая из них возвращает 200, вы можете:
     • Рассмотрите возможность изменения этого поведения (подробнее см. Ниже), чтобы уменьшить дублирование контента и улучшить эффективность сканирования .
     • Оставьте как есть. На многих сайтах дублируется контент. Наш процесс индексации часто решает этот случай для веб-мастеров и пользователей. Хотя это не совсем оптимальное поведение, это вполне законно и нормально. 🙂
     • Будьте уверены, что конкретно для корневого URL-адреса http://example.com эквивалентно http://example.com/ и не может быть перенаправлен, даже если вы Чак Норрис.
   Шаги для обслуживания только одной версии URL

   Что делать, если ваш сайт обслуживает дублированный контент по этим двум URL-адресам:

   http: // <здесь-ваш-домен> / <здесь-некоторый-каталог> /
http: // <здесь-ваш-домен> / <здесь-некоторый-каталог>

   означает, что оба URL возвращают 200 (ни один не имеет перенаправления и не содержит rel = «canonical» ), а вы хотите изменить ситуацию?

   1. Выберите один URL-адрес в качестве предпочтительной версии.Если на вашем сайте есть структура каталогов, это больше обычно использовать косую черту в конце URL-адресов каталогов (например, example.com/directory/ , а не example.com/directory ), но вы свободно выбирать то, что вам нравится.
   
   
   2. Соответствовать предпочтительной версии. Используйте его в своих внутренних ссылках. Если у тебя есть Sitemap, включите предпочтительную версию (и не включайте повторяющийся URL).
   
   
   3. Используйте 301 редирект с дубликата на предпочтительную версию.Если это невозможно, хорошим вариантом будет rel = "canonical" . rel = "canonical" работает аналогично 301 для целей индексирования Google, а также других основных поисковых систем.
   
   
   4. Протестируйте свою конфигурацию 301 через Загрузить как Googlebot в Инструменты для веб-мастеров. Убедитесь, что ваши URL:
      http://example.com/foo/
http://example.com/foo
      ведут себя должным образом. Предпочтительная версия должна вернуть 200.Повторяющийся URL-адрес должен соответствовать 301 предпочтительному URL-адресу.
   
   
   5. Проверить Ошибки сканирования в Инструментах для веб-мастеров, и, если возможно, ваш веб-сервер выполняет журналы для быстрой проверки того, что 301-е реализованы.
   
   
   6. Выгода! (шутка) Но вы можете погреться на солнышке своей эффективной конфигурации сервера, согретая знанием того, что ваш сайт лучше оптимизирован.
   
   Автор: Мэйл Охе, технический руководитель программ для разработчиков

   .htaccess Redirect 301 с завершающей косой чертой добавляет конечную косую черту к месту назначения

   Но это перенаправляет на example.php /

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

   Директива Redirect соответствует префиксу (сегменты всего пути), и все, что находится после совпадения, добавляется в конец целевого URL.Итак, первая директива перенаправляет:

   • / пример от до /example.php
   • / example / — /example.php/ и
   • / пример / abc – /example.php/abc

   Если директивы упорядочены таким образом, они должны «работать» для двух опубликованных примеров URL:

     Перенаправить 301 / example / /example.php
   Перенаправление 301 / пример /example.php
     

   Однако директива Redirect на самом деле не является правильной директивой для использования здесь, так как вам нужны две директивы для обработки этого./ пример /? $ /example.php

   Это соответствует только / example или / example / и перенаправляет на /example.php .

   Redirect и RedirectMatch являются частью mod_alias.

   Однако, если вы уже используете mod_rewrite, рассмотрите возможность использования вместо него mod_rewrite RewriteRule , чтобы избежать потенциальных конфликтов, поскольку mod_rewrite всегда запускает до mod_alias, несмотря на очевидный порядок директив в .example /? $ /example.php [R = 301, L]

   Обратите внимание, что в шаблоне RewriteRule при использовании в .htaccess нет префикса косой черты, поскольку URL-путь, которому соответствует шаблон , имеет префикс каталога (который всегда заканчивается косой чертой . ) удаленный.

   Обратите также внимание на то, что порядок директив в каждом модуле может иметь значение.

   В сторону: Если ваш веб-сайт был «переделан», то почему «новые» URL-адреса в форме / example.php ? Это казалось бы отсталым?

   ---

   ОБНОВЛЕНИЕ: У меня был кто-то, кто преобразовал исходный веб-сайт wordpress в (почти) эквивалентный сайт, который использовал только HTML и немного javascript и php

   Вы потенциально можете сохранить исходные URL-адреса WordPress (например, / example ) и внутренне переписать запрос в базовый файл, который обрабатывает запрос (например, example. example /? $ Example.php [L]

   (Я также удалил префикс косой черты в RewriteRule подстановке , которая теперь не требуется, поскольку мы переписываем путь к файловой системе.)

   Если вы укажете ссылку на / example в вашем HTML-источнике, тогда пользователь не знает, что запрос действительно сопоставлен с example.php .

   Как косая черта влияет на оптимизацию веб-сайта

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

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

   https://www.onlineassetpartners.co.nz/about-online-asset-partners
   https://www.onlineassetpartners.co.nz/about-online-asset-partners/

   Щелкните по ним, они оба попадут в одно и то же место. Единственная разница — это небольшая, казалось бы, незначительная косая черта в конце. Конечно, это не имеет значения. Это одно и то же, правда?

   Неправильно!

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

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

   Каким образом завершающие косые черты в URL могут вызывать проблемы?

   Есть несколько причин, по которым необходимо правильно обрабатывать завершающие косые черты. На фундаментальном уровне Google сканирует и ранжирует отдельные URL-адреса. Значит, они должны быть уникальными. Если одна и та же страница может загружаться по двум разным URL-адресам, мы сталкиваемся с проблемами дублирования контента.Он может выглядеть почти идентично, и технически может работать отлично, но он не оптимизирован для поиска.

   Конечные косые черты могут разделить ваш ссылочный капитал пополам.

   Ссылочный вес, часто называемый «ссылочным соком», является фактором ранжирования SEO. Идея заключается в том, что когда веб-страницы ссылаются на другие страницы, они подтверждают этот контент, передавая долю ссылок. Чем больше ссылок на страницу, тем сильнее ее поддержка. Это основной принцип, лежащий в основе PageRank, одного из оригинальных алгоритмов Google.

   Наличие двух версий одной и той же страницы на двух разных URL-адресах сбивает с толку тех, кто пытается перейти по ссылке на вашу страницу. Они используют косую черту в конце или нет? Выбор должен быть сделан. Если 50% людей ссылаются на URL с косой чертой в конце, а 50% не добавляют его, то ваш ссылочный вес делится пополам.

   Завершающие косые черты могут плохо сказаться на эффективности сканирования

   Google не сканирует ваш сайт каждый день. Бюджет сканирования определяет, какая часть вашего веб-сайта будет исследована и проиндексирована.Для небольших сайтов это не имеет большого значения, скорее всего, будет просканировано все, что меньше 100 страниц. Однако для более крупных сайтов с тысячами страниц это становится еще одной областью, которую необходимо оптимизировать. Размер бюджета сканирования для вашего веб-сайта определяется рядом факторов, включая:

   1. Размер веб-сайта (общее количество URL-адресов для сканирования).
   2. Состояние сайта (сколько ошибок находит Google).
   3. Ссылки на веб-сайт (сколько у вас обратных ссылок и на какие URL они ссылаются).

   Дублированный контент, вызванный неправильно управляемыми конечными косыми чертами, заставляет Google без необходимости сканировать несколько версий одной и той же страницы. Хотя вы вряд ли будете вручную наказаны за такой дублированный контент, это все же немного усложняет работу поисковой системы. Игнорирование дублированного контента из завершающих слэшей по сути противоположно SEO.

   Конечные косые черты могут плохо сказаться на пользовательском опыте

   Пользовательский опыт (или UX) — это половина успеха SEO.Хороший пользовательский интерфейс означает, что люди будут оставаться на вашем веб-сайте дольше и больше взаимодействовать с ним (нажимать на элементы). Подобные действия посылают в Google убедительные сигналы о том, что ваш сайт заслуживает ранжирования.

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

   Чем длиннее существуют два отдельных URL-адреса для одной страницы, тем выше вероятность изменения их индивидуального содержания. Теперь подумайте, насколько запутанным было бы для пользователя наткнуться на обе версии или перейти по ссылке с внешнего сайта на более старую версию вашей страницы. Игнорирование вопросов, связанных с завершающей косой чертой, только усложняет задачу для всех: пользователя, поисковых систем и всех, кто имеет дело с вашим сайтом.

   Google сообщает вам, как исправить проблемы с конечной косой чертой

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

   Последнее предложение в сообщении действительно подчеркивает суть вопроса, объясняя, что если вы примените исправление для конечных проблем с косой чертой: «Вы можете погреться на солнышке своей эффективной конфигурации сервера, согретой знанием того, что ваш сайт лучше оптимизирован. .

   Слово «оптимизированный» написано прямо здесь. Существует много загадок в отношении важности SEO и факторов ранжирования, поскольку Google официально не раскрывает, как работает их алгоритм. Если затем Google опубликует сообщение, в котором сообщается, что определенное действие оптимизирует ваш веб-сайт, то следовать их совету не составит труда.

   Как исправить проблему с косой чертой в конце?

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

   Хорошая новость заключается в том, что исправить проблемы с конечной косой чертой не так уж сложно, в зависимости от платформы вашего веб-сайта. Важно отметить, что корневой домен (часто домашняя страница — в нашем случае https: // www.onlineassetpartners.co.nz) всегда разрешается без косой черты в конце. Google делает это автоматически, и вы не сможете это изменить.

   Перенаправления

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

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

   Канонические теги

   В редких случаях переадресация 301 невозможна или у вас могут быть причины ее избегать. В таких ситуациях канонический тег решит большинство проблем. Тег rel = «canonical» может использоваться для указания сканерам веб-сайта «истинной» или «исходной» версии страницы. Если вы не можете перенаправить страницу, канонический тег, по крайней мере, исправит любые проблемы с дублированием контента в глазах поисковых систем.

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

   Текущее обслуживание для устранения проблем с конечной косой чертой

   После того, как вы внедрили соглашение о конечной косой черте и исправили все существующие проблемы, есть несколько вещей, которые вы можете сделать, чтобы проблема не вернулась.

   1. Регулярно обновляйте карту сайта — убедитесь, что в карте сайта всегда указаны правильно структурированные URL-адреса.
   2. Воспользуйтесь инструментом проверки URL-адресов Google — проверьте, какая версия ваших важных страниц индексируется.
   3. Покрытие консоли поиска — это представление в консоли поиска Google выделяет все ошибки, отмеченные во время сканирования сайта.

   SEO — это забота о деталях. Необходимо оптимизировать множество факторов ранжирования, каждый из которых имеет разную степень важности.Конечно, важно распределять ресурсы с умом, но игнорирование проблем с дублированием контента и условных обозначений в конце косой черты — это удар себе в ногу.

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

   Конечные косые черты и SEO | SiteGuru

   Неправильное использование завершающих слэшей может повредить вашей SEO-деятельности. В этой статье объясняется, как правильно настроить и избежать ущерба для SEO.

   Содержание

   Конечные косые черты и SEO — в чем проблема?

   Завершающая косая черта — это косая черта, которую вы иногда видите в конце URL-адреса:

   https://www.example.com/folder (без косой черты в конце)
   

   https://www.example.com/folder / (с косой чертой в конце)

   Вы можете или не можете добавлять косую черту в конце URL-адреса — оба варианта подходят.Важно понимать, что поисковые системы рассматривают URL с косой чертой и без нее как две разные страницы. Это имеет серьезные последствия для SEO.

   Проблема с дублированием содержимого

   Если страница работает с косой чертой в конце и без нее, у вас есть одна и та же страница на разных URL-адресах. Это дублированный контент, и теперь у вас есть два URL, конкурирующих за одни и те же ключевые слова в Google.

   Google сканирует и ранжирует отдельные URL-адреса на самом базовом уровне. Это значит, что они должны быть единственными в своем роде.Если к одной и той же странице можно получить доступ по двум отдельным URL-адресам, у нас есть проблема с дублированием контента. Он может казаться почти идентичным и может функционировать безупречно, но он не оптимизирован для поиска.
   

   Проблема равноправия ссылок

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

   Проблема с бюджетом сканирования

   Google не сканирует весь ваш веб-сайт ежедневно. Бюджет сканирования определяет, какая часть вашего веб-сайта будет исследована и проиндексирована. Это не является серьезной проблемой для небольших сайтов; все, что меньше 100 страниц, скорее всего, будет проиндексировано.

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

   • Размер веб-сайта: Общее количество URL-адресов для сканирования.
     
   • Состояние сайта: Сколько ошибок находит Google.
     
   • Ссылки на веб-сайт: Сколько у вас обратных ссылок и на какие URL-адреса они ссылаются.

   Дублирующийся материал, созданный из-за неправильно управляемых конечных косых черт, позволяет Google без необходимости сканировать многочисленные копии одной и той же страницы. Хотя вы вряд ли будете наказаны вручную за такой тип дублирующейся информации, это значительно усложняет работу поисковой системы. Игнорирование повторяющегося материала, вызванного конечными косыми чертами, является полной противоположностью SEO.

   Проблемы взаимодействия с пользователем

   Независимо от того, есть ли в URL-адресе косая черта в конце, он рассматривается как отдельная и индивидуальная веб-страница. Если один и тот же URL отображается с косой чертой в конце и без нее, содержание страницы может быть технически различным. Страница идентична в большинстве сценариев с косой чертой, но, учитывая количество людей, которые работают на веб-сайтах, все вносят коррективы, а иногда и вводят собственный код, вы не можете гарантировать, что они останутся неизменными навсегда.

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

   Следует добавить или удалить косую черту в конце

   С точки зрения SEO не имеет значения, есть ли в URL косая черта или нет. Еще в 2010 году Google объявил, что это не имеет значения, если у вас нет обоих вариантов, возвращающих код состояния 200 (ОК).Вместо этого верните код состояния 200 для предпочтительного варианта и перенаправление 301 на предпочтительный вариант для другого:

   https://www.example.com/folder (200)
   https://www.example.com/folder/ (301 редирект)? https://www.example.com/folder

   История конечных косых черт

   Почему все же существуют оба варианта? Исторически URL с косой чертой в конце был каталогом , а URL без него был файлом . В настоящее время это различие больше не актуально, и вам не нужно его учитывать.

   
   

   Используйте один и тот же вариант на своем сайте

   После того, как вы определились с предпочтительным вариантом URL для своего сайта, убедитесь, что вы используете этот вариант на своем сайте. Обратите особое внимание на:

   • Канонические URL
   • Теги Hreflang
   • Внутренние ссылки
   • URL в вашей карте сайта
   • Перенаправления

   Если вы не используете правильный вариант, сканирование вашего сайта станет менее эффективным./]) $ 1 / перманентно;

   Проверка SiteGuru

   SEO-аудит SiteGuru включает проверку на наличие дублированного контента в URL-адресах с косой чертой в конце. Если вы не перенаправляете один вариант на другой, это будет помечено как проблема.

   Внутренние перенаправления из-за несоответствия завершающей косой черты

   Высокий Этот совет очень важен и определенно требует внимания. Проблема Этот совет представляет собой ошибку или проблему, которую необходимо исправить.

   Это означает, что рассматриваемый URL-адрес перенаправляется на другой внутренний URL-адрес, где единственное различие между URL-адресами заключается в наличии / отсутствии завершающей косой черты.

   Почему это важно?

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

   Перенаправления

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

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

   Что проверяет подсказка?

   Этот совет будет запускаться для любого внутреннего URL-адреса, который возвращает код состояния HTTP 3XX, где перенаправленный URL-адрес добавляет завершающую косую черту к URL-адресу без таковой или удаляет конечную косую черту для URL-адреса с одним.

   Примеры, которые запускают эту подсказку:

   Рассмотрим URL: https://example.com/page

   Подсказка сработает для этого URL, если он вернет ответ HTTP-заголовка 3XX, который, например, добавляет завершающую косую черту;

    HTTP / ... 301 перемещен навсегда 
    ... 
    Расположение: https://example.com/page/ 

    ... 

   Обратно рассмотрим URL: https://example.com/page/

   Подсказка сработает для этого URL-адреса, если он вернет ответ HTTP-заголовка 3XX, который, например, удаляет завершающую косую черту;

    HTTP /... 301 Перемещено навсегда 
    ... 
    Расположение: https://example.com/page 

    ... 

   Это справедливо и для любого другого HTTP-ответа 3XX.

   Как решить эту проблему?

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

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

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

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

   .