Как настроить 301 редирект в .htaccess, чтобы добавить косую черту в корень документа, если кто-то ссылается на вас без нее? Согласно исследованиям, которые я провел, большинство поисковых систем…

Я занят тем, что делаю сайт многоязычным. Выбор языка, который я хочу получить с помощью url. Так например: https://www.website.com/spain/en/ Но я также хочу, чтобы он работал без косой черты…

я сделал перезапуск сайта, и теперь мне нужно 301 перенаправление, чтобы сохранить свой рейтинг страницы 🙂 Мой старый сайт выглядел так: www.domain.com / start / или www.domain.com / start Новый…

У меня есть несколько URL-адресов, которые выглядят так: redirect 301 /some/old/url/ http://example.com/url redirect 301 /some/old/test/ http://example.com/test То, что я действительно хочу, это…

Я пытаюсь удалить косую черту trailing из всех URL-адресов. Какие бы строки сценария htaccess я ни пробовал, он всегда перенаправляет на то, что кажется полным каталогом сервера. example.com/XYZ/…

Мне нужно выполнить 301-редирект с домашней страницы, но без перенаправления моих поддоменов. Пример : http://info.org => http://newpage.org http://www.info.org => http://newpage.org…

Удаление косой черты trailing в конце имен файлов в папке http:/ / www.example.com/directory/index. php / должен вернуться к http:/ / www.example.com/directory/index. php (то есть без косой черты…

Если я использую что-нибудь в подстановочном знаке, это перенаправляет меня на example. com/shop . Но я хочу, чтобы, когда кто-то использует anything.example.com/code , он перенаправляет на…

301 редирект для Joomla 3.x

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

Начнем с начала и максимально просто объясним для тех, кто не знает что такое редирект, зачем он нужен и как его настроить.

ЧТО ТАКОЕ РЕДИРЕКТ

По своей сути это перенаправление с одной страницы, на другую. Любой редирект воспринимается поисковиком с негативом. Любой кроме 301-го. Именно поэтому, на своих сайтах, крайне рекомендуется использовать только его.

ЗАЧЕМ НУЖЕН РЕДИРЕКТ

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

В качестве второго примера хотелось бы привести требования SEO. Не использовать редирект и говорить о полноценном продвижении сайта, по крайней мере, на сегодняшний день — невозможно. Убрать слэш из URL ( / ) — без проблем. Спрятать дубли страниц тоже не проблема. Даже банальный адрес сайта с www и без — не сделать без редиректа.

КАК ДЕЛАЮТ РЕДИРЕКТ

Дабы не усложнять восприятие кучей терминов, будем выражаться просто. (.*)$ http://%{HTTP_HOST}/$1 [R=301,L]

301 редирект через .htaccess и еще 18 настроек файла .htaccess

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

Название происходит от англ. hypertext access (доступ к гипертексту). Благодаря .htaccess можно менять настройки наиболее популярного типа веб-серверов Apache или аналогичных. Далее вы можете ознакомиться с применением файла для других целей и увидеть примеры кода.

Файл позволяет оптимизатору более гибко настроить сервер. Не советуем задавать в .htaccess правила, если вы можете работать с главным конфигурационным файлом сервера .httpd.conf либо apache.conf. Эти 2 файла не дают запросам перегружать сервер и быстрее их применяют. Но во многих случаях оптимизатор не имеет доступа к указанным файлам, скажем, на виртуальном хостинге. В таком случае необходимые настройки прописываются через .htaccess.

Благодаря .htaccess можно оптимизировать сайт:

Ищем и редактируем .htaccess

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

Файл .htaccess можно переименовать. Создание и редактирование доступно из любого текстового редактора. В некоторых CMS работать с файлом можно через админпанель. Для Битрикса поиск тоже прост – «Контент», далее «Файлы и папки».

Для WordPress’а редактирование возможно благодаря модулям плагинов All in One SEO Pack и Yoast SEO.

В случае отсутствия .htaccess следует создать его через текстовый редактор и разместить в корневом каталоге сайта или любом другом. – начало строки.

Основные переменные:

• %{HTTP_USER_AGENT} – поле User-Agent, полученное от браузера пользователя.
• %{REMOTE_ADDR} – IP-адрес юзера.
• %{REQUEST_URI} – запрашиваемый URI.
• %{QUERY_STRING} – параметры запроса после ?.

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

Настройка редиректов для SEO

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

Применяйте 2 важных для редиректов правила:

1. Не используйте несколько последовательных редиректов – это увеличит нагрузку на сервер и снизит скорость работы ресурса.
2. Последовательность переадресаций должна быть от частной до глобальной. Скажем, редирект со страницы 1 на страницу 2, а потом общий на странички со слэшем. Это работает не всегда, нужно тестировать.

Настройка постраничных 301 редиректов

Необходимо для следующих случаев:

• смена структуры сайта с изменением уровня вложенности страницы;
• страницы уже нет, но необходимо перенаправить её трафик;
• смена URL.

Удаление страницы не очень эффективно. Рекомендуем не доходить до ошибки 404, а сделать редирект на другой URL. Это уменьшит риск потери сайтом позиций в поисковой выдаче. Настройка 301 переадресации со страницы 1 на страницу 2 возможна с помощью директивы простого перенаправления:

Redirect 301 /page1/  https://mysite.com/page2/

• /page1/ – адрес страницы от корневой папки, без домена и протокола. Пример: /catalog/ofisnaya-mebel/kompjuternye-stoly/. Zeus [NC] <limit get=”” post=”” head=””> Order Allow,Deny Allow from all Deny from env=bad_bot </limit>

  Список «плохих» пользователей легко редактируется. На этом ресурсе можно ознакомиться с хорошими и плохими ботами.

  Если вас интересует запрет для роботов из поиска, используйте следующий код:

  RewriteEngine on
  RewriteCond %{USER_AGENT} Googlebot
  RewriteRule .* - [F]

  Для всех ботов, за исключением конкретных IP

  ErrorDocument 403 https://mysite.com
  Order deny,allow
  Deny from all
  Allow from IP1
  Allow from IP2 и т. д.

  Для указанных IP

  allow from all
  deny from IP1
  deny from IP2 и т. д.

  Подсеть

  allow from all
  deny from 192.168.0.0/24

  IP-адреса спамеров определяются логами сервера либо сервисами статистики. В админке WordPress видны IP-адреса тех, кто оставляет комментарии.

  К конкретному файлу

  <files myfile.html>
  order allow,deny
  deny from all
  </files>

  Пользователь увидит ошибку 403 – «доступ запрещен».

  Советуем сделать ограничение доступа к самому файлу .htaccess, а настроив все правила, поставьте на него права доступа 444.

  <Files .htaccess>
  order allow,deny
  deny from all
  </Files>

  Для ресурсов на WordPress стоит наложить ограничения доступа к wp-config.php, содержащему информацию о базе данных:

  <files wp-config.php>
  order allow,deny
  deny from all
  </files>

  Для пользователей, которые пришли с конкретного сайта

  Можно заблочить юзеров с нежелательного ресурса (порноконтент и др.).

  <IfModule mod_rewrite.c>
  RewriteEngine on
  RewriteCond %{HTTP_REFERER} bad-site.com [NC,OR]
  RewriteCond %{HTTP_REFERER} bad-site.com [NC,OR]
  RewriteRule .* - [F]
  </ifModule>

  Защита доступа к конкретной папке или файлу

  Сперва нужно создать файл . (.*)/$ /$1.html [R=301,L]

  Убираем .html:

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

  Аналогично для php.

  Настройка кодировки

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

  • UTF-8 – универсальная.
  • Windows-1251 – кириллица.
  • Windows-1250 – для Центральной Европы.
  • Windows-1252 – для Западной Европы.
  • KOI8-R – кириллица (КОИ8-Р).

  Первые две применяются чаще всего.

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

  Для UTF-8:

  AddDefaultCharset UTF-8

  Для Windows-1251:

  CharsetSourceEnc WINDOWS-1251

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

  Создание кастомных страниц ошибок

  Используя правила, в .htaccess легко настраивается отображение страниц, специально созданных для наиболее популярных ошибок. Примеры:

  ErrorDocument 401 /error/401.php
  ErrorDocument 403 /error/403.php
  ErrorDocument 404 /error/404.php
  ErrorDocument 500 /error/500.php

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

  Оптимизация работы сайта

  Скорость загрузки вашего ресурса – важный фактор ранжирования в поисковиках. Директив в .htaccess помогут её увеличить.

  Сжатие компонентов сайта модулями mod_gzip либо mod_deflate

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

  Gzip считается модулем с более гибким синтаксисом, также умеет использовать маски:

  <ifModule mod_gzip. Content-Encoding:.*gzip.*
  </ifModule>

  В mod_deflate нужно перечислить типы файлов для сжатия:

  <ifModule mod_deflate.c>
  AddOutputFilterByType DEFLATE text/html text/plain text/xml application/xml application/xhtml+xml text/css text/javascript application/javascript application/x-javascript
  </ifModule>

  Усиление кэширования

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

  FileETag MTime Size
  <ifmodule mod_expires.c>
  <filesmatch “.(jpg|gif|png|css|js)$”>
  ExpiresActive on
  ExpiresDefault “access plus 1 week”
  </filesmatch>
  </ifmodule>

  Можно задать срок жизни кэша – hours, month, year и др.

  Или так:

  <IfModule mod_expires.c>
  ExpiresActive On
  ExpiresByType application/javascript "access plus 7 days"
  ExpiresByType text/javascript "access plus 7 days"
  ExpiresByType text/css "access plus 7 days"
  ExpiresByType image/gif "access plus 7 days"
  ExpiresByType image/jpeg "access plus 7 days"
  ExpiresByType image/png "access plus 7 days"
  </IfModule>

  Другие возможности

  Настройки php

  Выполняются программистами в случае отсутствия доступа к php.ini. Нас интересуют выражения php_value, отвечающие за объем данных, загружаемых на сайт, и время обработки скриптов, поскольку это влияет на производительность.

  <ifModule mod_php.c>
    php_value	upload_max_filesize	125M
    php_value	post_max_size		20M
    php_value	max_execution_time 60
  </ifModule>

  «post_max_size» – максимальный объем постинга, «max_execution_time» – время в секундах для обработки скриптов.

  Борьба со спам-комментами на WordPress

  Для закрытия доступа спамерам к wp-comments-post.php следует добавить следующие команды в . 12\.345\.678\.90 RewriteRule $ https://mysite.ru/info.html [R=302,L]

  Общие принципы работы с .htaccess

  • Перед тем, как внести изменения, сохраняйте копию файла для возможного «отката».
  • Делайте изменения поэтапно, добавляя по одному правилу. Далее оцените результат и переходите к следующему этапу.
  • Размещая несколько файлов .htaccess в разных папках, следует прописать в дочерних только новые команды, актуальные для конкретной папки. Остальные будут унаследованы от родительской папки либо файла в корневом каталоге.
  • Чистите кэш браузера.
  • При возникновении ошибки 500 следует проверить синтаксис правила на опечатку. Можно использовать сервисы проверки .htaccess в сети, скажем, этот. Нет ошибок – скорее всего, такая команда запрещена в главном файле конфигурации. Нужна консультация программиста и хостинг-провайдера.
  • В командах .htaccess символы кириллицы недопустимы. При указании адреса домена на кириллице (вашсайт.рф) используйте любой whois-сервис, чтобы определить название по методу punycode.
  • Если директив в .htaccess слишком много, это снизит работоспособность ресурса. Применяйте изменения файла исключительно при отсутствии других путей решения задачи.
  • Мало времени на изучение особенностей директив – примените генератор .htaccess.

  Подпишись на новости

  Как сделать 301 редирект на без www и с слешем на конце адреса страницы на сайте с 1С Битрикс?

  08.11.2016

  Как сделать 301 редирект на без www и с слешем на конце адреса страницы на сайте с 1С Битрикс?

  Сама переадресация делается так же, как и на других сайтах, которые работают на сервере под управлением Apache 2. Но в 1С Битрикс есть небольшой нюанс. В этой системе используется свой обработчик адресов urlrewrite.php, который подключается в файле .htaccess. Поэтому код переадресации необходимо вставлять перед подключением urlrewrite.php.

  Готовый код переадресации я взял отсюда:

  RewriteCond %{REQUEST_URI} !\?
  RewriteCond %{REQUEST_URI} !\&
  RewriteCond %{REQUEST_URI} !\=
  RewriteCond %{REQUEST_URI} !\. (.*)$ http://%1/$1/ [L,R=301]

  Для того, чтобы сделать переадресацию на без www и с слешем на конце адреса страницы на сайте с 1С Битрикс, откройте файл .htaccess, который находится в корневой директории вашего сайта. Вставьте код переадресации в блоке mod_rewrite перед подключением urlrewrite.php.

  У меня это 14 строка, после:

  <IfModule mod_rewrite.c>
    Options +FollowSymLinks
    RewriteEngine On

  Переадресация заработает сразу, без перезагрузки веб сервера.

  
  

  Как принудительно использовать 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.com

  Я начну с создания файла .htaccess в корневом каталоге сайта со следующим кодом.

    ## Включить модуль перезаписи
  RewriteEngine на
  
  ## Force WWW
  RewriteCond% {HTTP_HOST} ^ 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 Снижение PageRank ссылок было основано на возможности «случайного пользователя», перешедшего по ссылке. С самого начала цель 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 . (.*) $ 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.

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

  Срезать или не рубить | Центральный блог 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. Выгода! (шутка) Но вы можете погреться на солнышке своей эффективной конфигурации сервера, согретая знанием того, что ваш сайт лучше оптимизирован.
  
  Автор: Мэйл Охе, технический руководитель программ для разработчиков

  Когда и как их использовать

  Понимание 301 редиректа как SEO очень важно.Хотя сначала они могут показаться простыми, понять, как их следует (и не следует) использовать в различных сценариях, немного сложнее, хотя вы сможете довольно быстро освоить их.

  Вам может потребоваться перенаправить страницу по ряду причин, например:

  • Вы нашли неработающий URL.

  • Ваша страница переехала в новое место.

  • Вы меняете свое доменное имя.

  • Вам нужно удалить страницу.

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

  Проверьте работоспособность вашего веб-сайта

  С помощью инструмента аудита сайта SEMrush

  Это руководство поможет вам узнать все, что нужно знать о переадресации 301 и о том, как они вписываются в вашу стратегию SEO, и мы рассмотрим:

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

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

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

  И, по крайней мере, в большинстве случаев, вам нужно реализовать здесь перенаправление 301.

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

  На практике это выглядит так:

  Допустим, вы исторически размещали свой блог на субдомене — https://blog.website.com — и решили переместить его во вложенную папку — https: //www.website.com/blog/.

  Этот оригинальный блог будет проиндексирован Google, включен в сообщения в социальных сетях и электронные письма и, вероятно, отмечен посетителями. Он получает трафик, и вы не хотите его терять.

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

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

  Но если вы установите 301 редирект, и любой, кто посещает старые URL, будет перенаправлен на новый, а поисковые системы со временем обновят страницы в своем индексе.

  Короче сохраните трафик.

  Вы также могли встретить переадресацию 302 и подумать, что это одно и то же. Они не.

  В то время как 301 — постоянное перенаправление, 302 — временное перенаправление, и его следует использовать при временном перемещении страницы.

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

  Исторически сложилось так, что при использовании перенаправления 302 вместо перенаправления 301 можно было увидеть любые рейтинги, которые потеряла исходная страница, поскольку считалось, что они не проходят PageRank. Однако в 2016 году Джон Мюллер из Google подтвердил, что это не так (по крайней мере, больше) и что 302-е действительно проходят PageRank.

  Вы можете увидеть комментарий Мюллера ниже:

  @dhinckley @randfish. На 302/301 все еще есть путаница с давних времен; 302-е в порядке. Я напишу еще что-нибудь, когда у меня будет время.

  -? Джон ? (@JohnMu) 23 марта 2016 г.

  Перенаправление 307 также используется как временное перенаправление. Разница между 302 и 307 заключается в том, что метод HTTP остается неизменным при использовании перенаправления 307. С 302, метод HTTP может измениться.

  Если изменение является постоянным, используйте 301.

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

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

  • Перенаправление https: // blog.website.com на https://www.website.com/blog/
  • Перенаправить https://blog.website.com/blog-post/ на https://www.website.com/blog/post-name/

  Или, в качестве другого примера, вы можете использовать перенаправление с подстановочным знаком на изменить структуру URL-адресов категории в магазине электронной коммерции, перенаправив все URL-адреса продуктов и подкатегорий в этой категории на новый:

  • Redirect https://www.website.com/old-category/ на https : //www.website.com/new-category/
  • Перенаправить https: // www.website.com/old-category/product/ с по https://www.website.com/new-category/product/
  • Перенаправить https://www.website.com/old-category/subcategory/ с на https://www.website.com/new-category/subcategory/

  В этом примере будут перенаправлены только URL-адреса в подпапке / old-category /; любой, скажем, в / разные-категории / не будет.

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

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

  С https://www.website.com/old-page-name/ на https://www. website.com/new-page-name/

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

  Может случиться так, что название продукта немного изменилось, и вам нужно его обновить, или вы приступили к проекту, чтобы лучше классифицировать страницы вашего сайта по тематическим кластерам, или у вас есть совершенно другая причина (причины бесконечны).

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

  Часто возникает путаница относительно того, что лучше всего делать, когда вы удаляете страницу со своего сайта.

  Следует ли 301 перенаправлять на другой URL-адрес или оставить его, чтобы он стал страницей 404? Или даже присвоить ему статус 410?

  Ну, это зависит от обстоятельств.

  Ошибки 404 или 410 определенно не то, что пользователи хотят видеть. Они также не являются тем, с чем Google хочет столкнуться при сканировании вашего сайта.

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

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

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

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

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

  Ошибка 404 означает, что контент не может быть найден, тогда как статус 410 означает, что он был удален.

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

  С https://www. website.com на https://www.newwebsite.com

  Иногда компаниям необходимо изменить свое доменное имя по одной из нескольких причин.

  Возможно, они переходят с.com в ccTLD .co.uk, например, или переименовали и должны перейти на доменное имя, которое отражает новое название компании.

  Редирект 301 необходим при переходе с одного доменного имени на другое и должен сопровождаться использованием инструмента изменения адреса в консоли поиска Google.

  С https://www.website.com/old-category/post/ на https://www.website.com/new-category/post/

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

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

  С https://website.com на https://www.website.com

  Хотя одно или другое не дает преимуществ для SEO, вам необходимо убедиться, что ваш сайт находится на одном из них. URL-адреса без www или www.

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

  С http://www.website.com на https://www.website.com

  По-прежнему только 60% Интернета используют протокол HTTPS, что означает, что 40% которые еще не внесли изменений.

  Если вы переключаете свои URL-адреса с HTTP на HTTPS, вам нужно будет использовать перенаправление 301, чтобы убедиться, что Google правильно индексирует новый протокол и что пользователи отправляются на правильную страницу, а не на 404, что произошло бы без поместив это на место.

  С https://www. website.de на https://www.website.com/de/

  Допустим, вы решили, что ваша международная стратегия SEO будет предполагать объединение нескольких ccTLD в вложенные папки вашего основного домена .com.

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

  С https://www.website.com/page-name на https://www.website.com/page-name/

  Были ли вы осведомлены о том, что варианты URL-адреса с конечным и без него косая черта на самом деле разные страницы и так ли их увидит Google?

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

  С https://www.website.com/Page-Name/ на https://www.website.com/page-name/

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

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

  Имеет смысл использовать нижний регистр для ваших URL-адресов и не смешивать верхний и нижний регистры.

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

  Вот некоторые из наиболее распространенных способов использования 301 для повышения эффективности SEO:

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

  Как комментирует Кевин Индиг в своем пошаговом руководстве по сокращению SEO:

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

  — Кевин Индиг

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

  Мы говорили о переносе вашего блога из поддомена в подпапку в одном из приведенных выше примеров, и это один из наиболее распространенных способов использования 301 редиректа для быстрого выигрыша в SEO.

  Содержимое вашего блога часто играет важную роль в вашей стратегии SEO.

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

  Зачем вам нужны отличные ссылки, указывающие на поддомен, если они могут усерднее работать над повышением эффективности SEO вашего основного сайта, если блог находится в корне сайта?

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

  На самом деле, если вам нужно что-то убедительное, просто взгляните на результаты, которыми Джанлука Фиорелли поделился в Twitter после того, как он объединил блог из поддомена в корень сайта в виде подпапки:

  Этим все сказано, не правда ли? не так ли?

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

  Скорее, это проблема, связанная с намерением. Только когда цель двух (или более) страниц одинакова, вы соревнуетесь с самим собой и страдаете от проблем каннибализации.

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

  К настоящему времени вы заметили преимущества SEO, которые возможны при переносе блога из поддомена в подпапку на вашем сайте.

  Если ваша компания управляет несколькими веб-сайтами, скажем, вы управляете сетью отелей и у вас есть разные сайты для каждого отеля, возможно, имеет смысл объединить их все в один, как это делает Marriott.

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

  Управление продуктами, снятыми с производства, — это одна из составляющих SEO, на которую часто приходят разные мнения.

  Мнение 1 : если товар закончился из-за того, что он был снят с производства и вряд ли когда-либо снова появится на складе, часто рекомендуется 301 перенаправить товар на следующую лучшую альтернативу. Это намного предпочтительнее, чем просто удалить страницу и позволить пользователям столкнуться с ошибкой 404, когда они попытаются купить старый продукт, на который они наткнулись — и это обычное дело.

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

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

  Другой вариант, вы также можете превратить эту страницу в страницу сравнения: «Продукт 2019 г. и продукт 2020 г.» — люди часто сравнивают характеристики продуктов. Потом включены сопутствующие товары.

  Итак, теперь вы знаете, что такое 301 редирект и когда их следует использовать, но как их реализовать?

  К сожалению, нет единого способа сделать это — это очень сильно зависит от вашего сервера и CMS, которую вы используете.

  Но вот как реализовать 301 в некоторых общих настройках, которые вы, вероятно, будете использовать.

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

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

  Если вы видите файл .htaccess, он запускает Apache.

  Чтобы добавить перенаправление к файлу, используйте следующие примеры:

  Redirect 301 / old-page / / new-page /

  Redirect 301 / https: // www./(.*)$ http://www.website.com/$1 постоянно;
}

  Если ваш сайт работает на сервере Windows в ASP.NET, вам необходимо добавить перенаправления в файл web.config, который вы должны найти в корне сайта.

  Вот как реализовать наиболее распространенные типы перенаправления 301:

  

website.com/new-page/ "httpResponseStatus =" Постоянно "/>



  



  <конфигурация>





< условия>














  Если ваш сайт работает на WordPress, вам повезло, потому что внедрение 301 редиректа — это на самом деле просто и понятно.

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

  Redirection — самый популярный менеджер переадресации для WordPress в настоящее время, на момент написания которого было установлено более 1 миллиона активных установок. Вы можете добавить свои перенаправления за считанные минуты; Это очень простой в использовании.

  Если вы используете альтернативу Yoast, такую ​​как RankMath, вы найдете диспетчер перенаправления, включенный в плагин, который также позволяет вам обслуживать 410 заголовков и многое другое.

  Если ваш магазин электронной коммерции работает на Magento, в платформу встроена функция добавления 301 редиректа.

  Вот как их создать …

  Если вы используете Magento 1, перейдите в Каталог> Управление перезаписью URL

  Теперь вы увидите все перенаправления, которые были созданы ранее.

  Продолжайте и «добавьте перезапись URL».

  Выберите «индивидуальную» перезапись.

  Заполните необходимую информацию о перезаписи URL следующим образом:

  ID Path = Имя вашей перезаписи, которое используется только для административных целей.
  Путь запроса = Исходный / исходный URL-адрес
  Целевой путь = Новый / целевой URL-адрес
  Перенаправление = Постоянное (301)
  Описание = Любое описание, которое вы хотите добавить для перенаправления

  Во-первых, перейдите в URL Rewrites:

  Marketing> SEO & Search> URL Rewrites

  Продолжайте и «добавьте перезапись URL» и заполните необходимую информацию для перезаписи URL следующим образом:

  Изображение предоставлено: Magefan

  Create URL Rewrite: Custom
  Store = Магазин, в который вы хотите добавить перенаправление для
  Путь запроса = Исходный / из URL
  Целевой путь = Новый / целевой URL
  Тип перенаправления = Постоянный (301)
  Описание = Любое описание, которое вы хотите добавить для перенаправления

  Как и в случае с WordPress и Magento, реализация 301 редиректа cts в магазине Shopify довольно прост и понятен.

  Зайдите на страницу Каналы продаж> Интернет-магазин> Навигация

  Затем вы увидите довольно незаметную ссылку «Перенаправления URL-адресов» вверху страницы. Идите и щелкните по нему.

  Теперь вы можете «Создать перенаправление URL».

  Это так же просто, как добавить свои URL-адреса «от» и «к» и сохранить перенаправление. Просто как тот.

  Если вы используете магазин электронной коммерции на BigCommerce, вот как добавить 301 редирект:

  Перейдите к Server Settings ›301 Redirects .

  Добавьте перенаправление и добавьте свой старый URL.

  Изображение предоставлено: BigCommerce

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

  Кредит изображения: BigCommerce

  Введите URL-адрес вашей новой страницы или выберите страницу для перенаправления, если вы выбрали вариант динамической ссылки выше.

  Изображение предоставлено: BigCommerce

  Изображение предоставлено: BigCommerce

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

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

  Вы можете использовать инструмент SEMrush Site Audit для выявления страниц, которые возвращают ошибку 404 (и другие ошибки 4XX), чтобы вы могли перейти и устранить их с помощью перенаправления.

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

  Опять же, инструмент Site Audit может помочь вам найти их, помеченные как «страницы с временными перенаправлениями».

  Затем вам следует обновить эти перенаправления до 301 с 302, если нет смысла устанавливать их как временные.

  Использование JavaScript для перенаправления без надлежащей настройки

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

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

  Во избежание проблем обычно рекомендуется использовать перенаправление 301, 302 или 307.

  Вы не должны выполнять перенаправление просто ради этого, так как это может негативно повлиять на пользовательский опыт вашего сайта.

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

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

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

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

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

  ---

  Вот и все; все, что вам нужно знать об использовании 301 редиректа.

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

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

  Что такое 301 редирект?

  У всех нас был случай, когда мы переходили по неработающей ссылке веб-сайта.Обычно вы увидите сообщение «404» или «Страница не найдена». Часто это происходит, когда страница перемещается на новый URL-адрес, а старая ссылка не была направлена ​​на новую страницу.

  Какое разочарование!

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

  Поддержание переадресации важно для технической стратегии SEO вашего сайта.

  Что такое 301 редирект?

  Редирект 301 сообщает веб-браузерам и поисковым роботам переходить со страницы A на страницу B.Вы должны определить перенаправление в конфигурации вашего веб-сервера, например в файле .htaccess на веб-сервере Apache.

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

  Когда следует использовать 301 редирект?

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

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

  Когда страницы объединяются, все страницы, которые больше не нужны, должны содержать 301 редирект на оставшуюся страницу.

  Если URL-адрес страницы должен быть изменен, необходимо создать 301 редирект со старого URL-адреса на новый URL-адрес.

  Переадресация 301 для канонических URL-адресов

  Вы должны использовать 301 редирект, чтобы направлять посетителей на канонические URL-адреса для каждой страницы.У каждой страницы вашего сайта должен быть только один URL-адрес, который отображает контент для этой страницы.

  Что за канонический URL?

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

  Например, «domain.com/page» и «domain.com/page?utm_source=google» считаются двумя разными URL-адресами для Google. Установка канонического URL-адреса на domain.com/page сообщит поисковым системам, что оба URL-адреса представляют одну и ту же страницу.

  Одна простая ошибка — иметь страницу, доступную по адресам «https://www.domain.com/page» и «https://domain.com/page». В этом случае вам потребуется перенаправление на канонический URL-адрес этой страницы. Какая версия URL-адреса требует перенаправления, зависит от того, использует ли ваш сайт URL-адреса с префиксом www или без него.

  URL с косой чертой в конце, например «https://domain.com/page/», и URL без косой черты, например https://domain.com/page, должны обрабатываться таким же образом. Это снова решается с помощью перенаправления 301 на канонический URL.

  Как создать 301 редирект

  Создайте переадресацию 301 в конфигурации вашего веб-сервера с наименьшим количеством переходов со страницы A на страницу B. Вы не хотите создавать цепочку переадресации, которая переводит посетителей и поисковые системы с URL-адреса A на URL-адрес B, а затем на URL-адрес C.

  Неправильный способ перенаправления URL-адреса

  Например, вы НЕ хотите создавать цепочку переадресации, которая выглядит следующим образом от www.domain.com на domain.com.

  ---

  Правильный способ перенаправления URL-адреса

  Вы хотите создать единственное перенаправление, которое переходит с исходного URL-адреса на целевой URL-адрес за один шаг.

  Правила, которые следует учитывать при перенаправлении одиночного перехода

  Есть два решения, которые вы должны принять в отношении архитектуры вашего сайта, которые влияют на структуру URL и перенаправления.

  1. Используете ли вы «www» в своем домене? Пример: www.domain.com
  2. Используете ли вы в конце домена косую черту? Пример: www.domain.com/page/

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

  «www» и завершающая косая черта
  • HTTP, без www, завершающая косая черта http://domain.com/page/ ➡️ https://www.domain.com/page/
  • HTTP, без www, без косой черты http://domain.com/page ➡️ https://www.domain.com/page/
  • HTTP, www, завершающая косая черта http://www.domain.com/page/ ➡️ https://www.domain.com/page/
  • HTTP, www, без косой черты http://www.domain.com/page ➡️ https: // www.domain.com/page/
  • HTTPS, без www, завершающая косая черта https://domain.com/page/ ➡️ https://www.domain.com/page/
  • HTTPS, без www, без косой черты https://domain.com/page ➡️ https://www.domain.com/page/
  • HTTPS, www, завершающая косая черта https://www.domain.com/page/ ⏹ Перенаправление не требуется
  • HTTPS, www, без косой черты https://www.domain.com/page ➡️ https://www.domain.com/page/
  «www» без косой черты
  • HTTP, без www, завершающая косая черта http: // domain.com / page / ➡️ https://www.domain.com/page
  • HTTP, без www, без косой черты http://domain.com/page ➡️ https://www.domain.com/page
  • HTTP, www, завершающая косая черта http://www. domain.com/page/ ➡️ https://www.domain.com/page
  • HTTP, www, без косой черты http://www.domain.com/page ➡️ https://www.domain.com/page
  • HTTPS, без www, завершающая косая черта https://domain.com/page/ ➡️ https://www.domain.com/page
  • HTTPS, без www, без косой черты https: // domain.com / page ➡️ https://www.domain.com/page
  • HTTPS, www, завершающая косая черта https://www.domain.com/page/ ➡️ https://www.domain.com/page
  • HTTPS, www, без косой черты https://www.domain.com/page ⏹ Перенаправление не требуется
  Без www и завершающей косой черты
  • HTTP, без www, завершающая косая черта http://domain.com/page/ ➡️ https://domain.com/page/
  • HTTP, без www, без косой черты http: // domain.com / page ➡️ https://domain.com/page/
  • HTTP, www, завершающая косая черта http://www.domain.com/page/ ➡️ https://domain.com/page/
  • HTTP, www, без косой черты http://www.domain.com/page ➡️ https://domain.com/page/
  • HTTPS, без www, завершающая косая черта https://domain.com/page/ ⏹ Перенаправление не требуется
  • HTTPS, без www, без косой черты https://domain.com/page ➡️ https://domain.com/page/
  • HTTPS, www, завершающая косая черта https: // www.domain.com/page ➡️ https://domain.com/page/
  • HTTPS, www, без косой черты https://www.domain.com/page ➡️ https://domain.com/page/
  Без www и косой черты в конце
  • HTTP, без www, завершающая косая черта http://domain.com/page/ ➡️ https://domain.com/page
  • HTTP, без www, без косой черты http://domain.com/page ➡️ https://domain.com/page
  • HTTP, www, завершающая косая черта http: // www. domain.com/page/ ➡️ https://domain.com/page
  • HTTP, www, без косой черты http://www.domain.com/page ➡️ https://domain.com/page
  • HTTPS, без www, завершающая косая черта https://domain.com/page/ ➡️ https://domain.com/page
  • HTTPS, без www, без косой черты https://domain.com/page ⏹ Перенаправление не требуется
  • HTTPS, www, завершающая косая черта https://www.domain.com/page ➡️ https://domain.com/page
  • HTTPS, www, без косой черты https: // www.domain.com/page ➡️ https://domain.com/page

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

  Только не забывай! Перенаправления могут влиять на несколько аспектов вашего веб-сайта, поэтому оставайтесь в курсе и привлекайте на свой веб-сайт больше людей — и продвигайте их дальше в вашу воронку продаж! Узнайте о других способах улучшения вашего веб-сайта, а также о 10 вещах, которые НЕ следует делать на своем веб-сайте, в нашем бесплатном руководстве 25 Обязательно к использованию веб-сайта .

  Перенаправление для принудительного применения / удаления завершающего слэша на URL-адресах

  В этой статье

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

  Добавьте косую черту в конце для Apache

  Если вам нужно принудительно установить завершающую косую черту в конце ваших URL-адресов, вы можете использовать следующий вспомогательный плагин . ./(.*)/$ / $ 1 навсегда; }

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

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

  Это означает, что рассматриваемый 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-адреса содержат ошибочную ссылку в части шаблона страницы (например, в заголовке). Выделение их вашему разработчику было бы особенно полезно, так как им просто нужно обновить один файл, и это исправит сразу множество ссылок перенаправления.

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

  Косая черта в конце 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 — это забота о деталях. Необходимо оптимизировать множество факторов ранжирования, каждый из которых имеет разную степень важности.Конечно, важно распределять ресурсы с умом, но игнорирование проблем с дублирующимся контентом и условных обозначений в конце косой черты — это выстрел себе в ногу.

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