Ограничения для URI перенаправления (URL-адресов ответа)
URI перенаправления, или URL-адрес ответа, — это расположение, в которое сервер авторизации будет отправлять пользователя после успешной авторизации приложения и которому был предоставлен код авторизации или маркер доступа. Сервер авторизации отправляет код или токен в URI перенаправления, поэтому важно зарегистрировать правильное расположение в рамках процесса регистрации приложения.
Модель приложения Microsoft Entra указывает эти ограничения для перенаправления URI:
- URI перенаправления должен начинаться со схемы https . Существуют некоторые исключения для URI перенаправления localhost.
- URI перенаправления чувствительны к регистру и должны соответствовать регистру URL-пути выполняемого приложения. Например, если приложение включает в состав своего пути . /abc/response-oidc , не указывайте . /ABC/response-oidc в URI перенаправления. Так как веб-браузер обрабатывает пути с учетом регистра, файлы cookie, связанные с . /abc/response-oidc , могут быть исключены при перенаправлении на не совпадающий по регистру знаков URL-адрес . /ABC/response-oidc .
- URI перенаправления без сегмента пути возвращаются с замыкающей косой чертой ( / ) в ответе. Это применимо только в том случае, если режим ответа имеет значение query или fragment . Примеры:
- https://contoso.com возвращается в виде https://contoso.com/
- http://localhost:7071 возвращается в виде http://localhost:7071/
- https://contoso.com/abc возвращается в виде https://contoso.com/abc
- https://contoso.com/abc/response-oidc возвращается в виде https://contoso.com/abc/response-oidc
Максимальное число URI перенаправления
В этой таблице указано максимальное число URI перенаправления, которые можно добавить для зарегистрированного приложения на платформе удостоверений Майкрософт.
Учетные записи для входа Максимальное число URI перенаправления Description Рабочие или учебные учетные записи Майкрософт в клиенте Microsoft Entra любой организации 256 Для поля signInAudience в манифесте приложения установлено AzureADMyOrg или AzureADMultipleOrgs Личные учетные записи Майкрософт и рабочие и учебные учетные записи 100 Для поля signInAudience в манифесте приложения установлено AzureADandPersonalMicrosoftAccount Максимальное количество URI перенаправления невозможно вызвать по соображениям безопасности. Если вам требуется большее число URI перенаправления, используйте следующую схему с параметром состояния в качестве решения.
Максимальная длина URI
Длина каждого URI перенаправления, добавляемого для зарегистрированного приложения, должна составлять не более 256 символов.
Перенаправление URI в главных объектах приложений и субъектов-служб
- Всегда добавляйте URI перенаправления только к объекту приложения.
- Не добавляйте значения URI перенаправления к субъекту-службе, так как эти значения могут быть удалены при синхронизации объекта субъекта-службы с объектом приложения. Это может произойти из-за любой операции обновления, которая запускает синхронизацию между двумя объектами.
Поддержка параметров запроса в URI перенаправления
Параметры запроса разрешены в URI перенаправления для приложений, которые выполняют вход только с помощью рабочих или учебных учетных записей.
Параметры запроса запрещены в URI перенаправления для регистрации приложений, настроенных для входа пользователей с помощью личных учетных записей Майкрософт, таких как Outlook.com (Hotmail), Messenger, OneDrive, MSN, Xbox Live или Microsoft 365.
Аудитория входа в систему регистрации приложений Поддерживает параметры запроса в URI перенаправления Учетные записи только в этом каталоге организации (только Contoso — один арендатор) 
Учетные записи в любом каталоге организации (любой каталог Microsoft Entra — с несколькими клиентами) Учетные записи в любом каталоге организации (любой каталог Microsoft Entra — Multitenant) и личных учетных записей Майкрософт (например, Skype, Xbox) 
Только личные учетные записи Майкрософт Поддерживаемые схемы
HTTPS: схема HTTPS ( https:// ) поддерживается для всех URI перенаправления на базе протокола HTTP.
HTTP: схема HTTP ( http:// ) поддерживается только для URI перенаправления localhost и используется исключительно на этапах локальной разработки и тестирования приложения.
Пример URI перенаправления Срок действия https://contoso.com Действительно https://contoso.com/abc/response-oidc Действительно https://localhost Действительно http://contoso.com/abc/response-oidc Недопустимо http://localhost Действительно http://localhost/abc Действительно Исключения для localhost
В соответствии с разделами RFC 8252 8.3 и 7.3, для URI перенаправления с замыканием на себя (localhost) действуют два особых правила:
- Схемы URI http допустимы, поскольку перенаправление никогда не покидает устройство. Таким образом, оба этих URI допустимы:
- http://localhost/myApp
- https://localhost/myApp
- Из-за временного характера диапазонов портов, часто используемых собственными приложениями, компонент порта (например, :5001 или :443 ) при сопоставлении URI перенаправления игнорируется. В результате все эти URI считаются эквивалентными:
- http://localhost/MyApp
- http://localhost:1234/MyApp
- http://localhost:5000/MyApp
- http://localhost:8080/MyApp
С точки зрения разработки это означает несколько моментов:
- Не регистрируйте несколько URI перенаправления, если в них различается только порт. Сервер входа будет произвольным образом выбирать один из них и использовать связанные с этим URI параметры (например, в зависимости от того, относится ли это перенаправление к типу web , native , или spa ). Это особенно важно, если вы планируете использовать в одном зарегистрированном приложении разные потоки проверки подлинности (например, и выдачу кода авторизации, и неявный поток). Чтобы связать с каждым URI перенаправления правильные параметры ответа, сервер входа должен иметь возможность различать эти URI, что невозможно, если различается только порт.
- Чтобы зарегистрировать несколько URI перенаправления по адресу localhost для тестирования различных потоков в процессе разработки, используйте для них разный компонент пути. Например, http://localhost/MyWebApp не эквивалентно http://localhost/MyNativeApp .
- IPv6-адрес замыкания на себя ( [::1] ) в настоящее время не поддерживается.
Выбор 127.0.0.1 вместо localhost
Чтобы работу приложения не нарушали неправильно настроенные брандмауэры или переименованные сетевые интерфейсы, используйте в URI перенаправления IP-адрес замыкания на себя в виде localhost вместо 127.0.0.1 . Например, https://127.0.0.1 .
При этом текстовое поле URI перенаправления на портал Azure нельзя использовать для добавления URI замыкания на себя со схемой http :
Чтобы добавить URI перенаправления, использующий схему http с 127.0.0.1 -адресом замыкания на себя, в настоящее время необходимо изменить атрибут replyUrlsWithType в манифесте приложения.
Ограничения на подстановочные знаки в URI перенаправления
URI с подстановочными знаками, такие как https://*.contoso.com , кажутся удобными, но их следует избегать из-за проблем с безопасностью. Согласно спецификации OAuth 2.0 (раздел 3.1.2 RFC 6749), URI конечной точки перенаправления должен быть абсолютным. Таким образом, если настроенный дикий карта URI соответствует URI перенаправления, строки запроса и фрагменты в URI перенаправления удаляются.
URI с подстановочными знаками в настоящее время не поддерживаются для зарегистрированных приложений, настроенных для входа как в личные, так и в рабочие и учебные учетные записи Майкрософт. Однако для приложений, настроенных для входа только рабочих или учебных учетных записей в клиенте Microsoft Entra организации, разрешены URI карта.
Чтобы добавить URI перенаправления с подстановочными знаками для зарегистрированных приложений, которые входят в рабочие или учебные учетные записи, используйте редактор манифеста приложения в разделе Регистрация приложений на портале Azure. Хотя с помощью редактора манифеста действительно можно задать URI перенаправления с подстановочными знаками, мы настоятельно рекомендуем придерживаться требований раздела 3.1.2 RFC 6749 и использовать только абсолютные URI.
Если вам требуется больше URI перенаправления, чем разрешено, вместо подстановочных знаков вы можете воспользоваться следующей схемой с параметром состояния.
Использование параметра состояния
Если у вас есть несколько поддоменов и вам необходимо после успешной проверки подлинности перенаправлять пользователей на ту же страницу, с которой они начали, можно использовать параметр состояния.
Если вы используете этот подход:
- Создайте «общий» URI перенаправления для каждого приложения, чтобы обрабатывать маркеры безопасности, полученные от конечной точки авторизации.
- Приложение может отсылать параметры, зависящие от приложения (например, URL-адрес поддомена, откуда перешел пользователь, или настройки фирменного оформления), в параметр состояния. При использовании параметра состояния защита ОТ CSRF, как указано в разделе 10.12 RFC 6749.
- Параметры, зависящие от приложения, будут включать всю информацию, необходимую приложению для корректного отображения для пользователя, то есть для создания соответствующего состояния приложения. Конечная точка авторизации Microsoft Entra полосирует HTML из параметра состояния, поэтому убедитесь, что вы не передаете HTML-содержимое в этом параметре.
- Когда идентификатор Microsoft Entra отправляет ответ на универсальный код ресурса (URI) перенаправления «shared», он отправит параметр состояния обратно в приложение.
- Затем приложение может использовать значение в параметре состояния, чтобы определить URL-адрес для отправки пользователю. Убедитесь, что вы проверили защиту CSRF.
Такой подход позволяет скомпрометированному клиенту изменять дополнительные параметры, отправляемые в параметре состояния, поэтому пользователь перенаправляется на другой URL-адрес, что является угрозой открытого перенаправления, как описано в стандарте RFC 6819. Таким образом, клиент должен защищать эти параметры, шифруя состояние или проверяя его с помощью других средств, таких как проверка доменного имени в URI перенаправления по маркеру.
Перенаправления в HTTP
URL перенаправление (redirecting), также известное как URL пересылка (forwarding), это метод представления страницы, формы или целого веб-приложения, более чем одним URL адресом. HTTP предоставляет специальный вид ответов, HTTP redirect, для выполнения этой операции, используемой для многих целей: временного перенаправления, пока выполняется обслуживание сайта, постоянное перенаправление, для сохранения работоспособности внешних ссылок, после смены архитектуры сайта, страниц прогресса, пока загружается файл, и так далее.
Принцип работы
В HTTP, перенаправление вызывается при отправке сервером специального ответа на запрос: redirects. HTTP перенаправление, это ответы с кодом статуса 3xx . Когда браузер получает ответ перенаправления, он использует новый предоставленный URL-адрес и немедленно загружает его: в большинстве случаев переадресация невидима для пользователя, за исключением небольшого влияния производительность.
Есть несколько типов перенаправлений и делятся на три категории: постоянные, временные и специальные перенаправления.
Постоянные перенаправления
Эти перенаправления призваны длиться вечно. Они подразумевают, что оригинальный URL-адрес больше не должен использоваться, а вместо него должен быть использован новый. Поисковые роботы запускают обновление связанного URL-адреса для ресурса в своих индексах.
Код Текст Обработка метода Случаи использования 301 Moved Permanently GET методы неизменны. Другие методы могут быть превращены в GET .[1] Реорганизация веб-сайта. 308 Permanent Redirect Метод и тело запроса неизменны. Реорганизация веб-сайта, с не-GET ссылками/операциями. [1] Спецификация не была намерена разрешать изменение метода, но на практике, клиентские приложения делают это. Код 308 был создан чтобы избавиться от неоднозначности в поведении, при использовании не- GET методов.
Временные перенаправления
Иногда, доступ к запрашиваемому ресурсу не может быть предоставлен из определённого места, но может быть предоставлен из другого. В этом случае, могут быть использованы временные перенаправления. Поисковые роботы не запоминают новую, временную ссылку. Временные перенаправления также используются, когда создаются, обновляются, или удаляются ресурсы, которые представляют временные страницы.
Код Текст Обработка метода Случаи использования 302 Found GET методы неизменны. Другие методы могут быть превращены в GET .[2] Веб-страница недоступна по непредвиденным причинам. В этом случае поисковые роботы не будут обновлять свои ссылки. 303 See Other GET методы неизменны. Другие превращены в GET (тело запроса теряется). Используется для перенаправления после PUT или POST для предотвращения обновления страницы, что может спровоцировать повторный вызов операции. 307 Temporary Redirect Метод и тело запроса неизменны. Веб-страница недоступна по непредвиденным причинам. В этом случае поисковые роботы не будут обновлять свои ссылки. Лучше чем код 302 когда не-GET ссылки/операции доступны на сайте. [2] Спецификация не была намерена разрешать изменение метода, но на практике, клиентские приложения делают это. Код 307 был создан чтобы избавиться от неоднозначности в поведении, при использовании не- GET методов.
Специальные перенаправления
В добавок к обычным перенаправлениям, есть 2 специальные. Перенаправление с кодом 304 (Not Modified) перенаправляет страницу к локальной закешированной копии (которая была устаревшей), и перенаправление с кодом 300 (Multiple Choice) это ручное перенаправление: тело, представленное браузером, как веб-страница, перечисляет возможные перенаправления и пользователь выбирает одно из них.
Код Текст Случаи использования 300 Multiple Choice Не так много: варианты перечислены на HTML странице. Может быть обслужен со статусом 200 OK . 304 Not Modified Обновление кеша: означает, что значение кеша все ещё актуально и может быть использовано. Альтернативные способы указания перенаправлений
HTTP перенаправления это не единственный способ переадресации. Есть ещё два метода: HTML перенаправления используют элемент , и JavaScript перенаправления используют DOM.
HTML перенаправления
HTTP перенаправления более предпочтительный способ создания перенаправлений, но, иногда, у веб-разработчиков нету контроля над сервером или возможности настроить его. Для таких особых случаев, разработчики могут создать HTML страницу с элементом и установить атрибуту http-equiv значение refresh в блоке . Когда страница отображается, браузер найдёт этот элемент и перейдёт на указанную страницу.
head> meta http-equiv="refresh" content="0; URL=http://www.example.com/" /> head>
Атрибут content начинается с числа, которое означает, сколько секунд браузер должен ждать, прежде чем перейти по данной ссылке. Всегда устанавливайте 0, для лучшей доступности.
Очевидно, этот метод работает только с HTML страницами и не может использоваться для изображений или другого типа контента.
Примечание: что перенаправления не позволяют работать должным образом кнопке «Назад» в браузере: вы можете вернуться на страницу назад, но мгновенно будете перенаправлены на страницу с которой пришли.
JavaScript перенаправления
Перенаправления в JavaScript создаются установкой значения свойства window.location и новая страница загрузиться.
.location = "http://www.example.com/";
Как и HTML перенаправления, этот тип не будет работать на всех ресурсах, и очевидно, что работает только на стороне клиента, который выполнит JavaScript. С другой стороны, вы можете вызвать перенаправление, только тогда, когда исполнится определённое условие.
Приоритетность
При использовании трёх возможных способов URL перенаправления, некоторые методы могут быть вызваны одновременно, но какой из них будет примёнён первым? Порядок приоритетов следующий:
- HTTP перенаправления всегда выполняются первыми, пока ещё страница даже не была передана, и конечно же, пока ещё не прочитана.
- HTML перенаправления ( ) выполняются только, если перенаправление не было в выполнено в HTTP.
- JavaScript перенаправления используются как последняя возможность перенаправления, и работают только если разрешено выполнение JavaScript на клиентской стороне.
Случаи использования
Есть много случаев для использования перенаправлений, но поскольку они влияют на производительность, то должны использоваться как можно реже.
Связывание доменов
В идеале, есть только одно место, и следовательно один URL адрес, для одного ресурса. Но, есть несколько причин, чтобы иметь альтернативные имена для ресурса (несколько доменов, как с, так и без префикса www или более короткие и лёгкие для запоминания адреса, …). В этих случаях, использовать перенаправление к одному истинному URL адресу, более подходящий вариант, чем дублировать ресурс.
Связывание доменов может быть необходимым по нескольким причинам:
- Расширение вашего сайта. Распространённый случай, когда ваш сайт находится под доменом www.example.com , а доступ к страницам должен быть возможным также из example.com . В этом случае создаются перенаправления для страниц из example.com к страницам www.example.com . Вы также можете предоставлять обычно используемые имена синонимов или частые опечатки ваших доменных имён.
- Переезд на другой домен. К примеру, ваша компания была переименована и вы хотите чтобы люди которые обычно использовали старый сайт компании находили вас под новым именем.
- Принуждённый HTTPS. Запросы к HTTP версии вашего сайта буду перенаправлены к HTTPS версии.
Сохранения ссылок рабочими
Когда вы изменяете структуру веб-сайта, URL адреса ресурсов меняются. Даже, если вы можете обновить внутренние ссылки вашего сайта в соответствии с новой схемой имён, у вас нет контроля на URL адресами используемыми внешними ресурсами. Вы не хотите, чтобы эти ссылки не работали, так как они приносят вам ценных пользователей (и помогают вашей SEO), так что вы устанавливаете перенаправления из старых URL адресов на новые.
Примечание: Не смотря на то, что данный метод работает также для внутренних ссылок, вы должны избегать внутренних перенаправлений. Перенаправления имеют большое влияние на производительность, и если вы имеете возможность избежать их, корректируя внутренние ссылки, тогда делайте так.
Временные ответы для небезопасных запросов
Небезопасные запросы изменяют состояние сервера и пользователь не должен не нарочно запросить их. Обычно, вы не хотите чтобы ваши пользователи повторно отправляли PUT , POST или DELETE запросы. Если вы только обслуживаете запросы, простое нажатие кнопки перезагрузки повторно отправит запрос.
В этом случае, сервер вернёт ответ 303 (Смотреть другие), который будет содержать правильную информацию, но если кнопка перезагрузки будет нажата, эта страница просто отобразится повторно без ответа на небезопасный запрос.
Временные ответы на долгие запросы
Некоторые запросы могут потребовать больше времени сервера, например запрос DELETE , который срабатывает по расписанию. В этом случае, ответом будет перенаправление 303 (Смотреть другие), которое связывает со страницей показывающей, что действие было запланировано, и в результате информирует о процессе или позволяет отменить запрос.
Настройка перенаправлений на распространённых серверах
Apache
Перенаправления могут быть установлены или в настройках сервера, или в каждой директории в файле .htaccess .
У модуля mod_alias есть директивы Redirect и Redirect_Match которые, по умолчанию, устанавливают код ответа 302 :
ServerName example.com Redirect / http://www.example.com URL http://example.com/ будет перенаправлен к http://www.example.com/ (но не к http://example.com/other.html )
Redirect_Match делает то же, но использует регулярное выражение, чтобы определить множество URL адресов, которые подпадут под эффект:
RedirectMatch ^/images/(.*)$ http://images.example.com/$1
Все документы в папке images/ будут перенаправляться к другому домену.
Если вы не хотите устанавливать временное перенаправление, дополнительный параметр (используйте или код статуса HTTP, или ключевое слово permanent ) может использоваться чтобы установить другое перенаправление:
Redirect permanent / http://www.example.com Redirect 301 / http://www.example.com
Также модуль mod_rewrite может использоваться для создания перенаправлений. Они более гибкие, но сложнее в использовании.
Nginx
В Nginx, вы создаёте особый серверный блок для контента, который вы хотите перенаправлять:
server < listen 80; server_name example.com; return 301 $scheme://www.example.com$request_uri; >
Чтобы применить перенаправления к папке или подмножеству страниц, используйте директиву rewrite :
rewrite ^/images/(.*)$ http://images.example.com/$1 redirect; rewrite ^/images/(.*)$ http://images.example.com/$1 permanent;
IIS
Циклы перенаправлений
Циклы перенаправлений случаются когда за успешным перенаправлением следует другое, которое уже было выполнено. Другими словами, существует такой цикл, который никогда не закончится и в конечном счёте ни одна страница не будет найдена.
В большинстве случаев это проблема сервера, и если сервер не может обнаружить её, то отправит код статуса 500 Internal Server Error . Если вы встретите такую ошибку вскоре после редактирования настроек сервера, то это скорее всего цикл перенаправлений.
В случае, когда сервер не может обнаружить его: цикл перенаправлений может распространиться на несколько серверов, каждый из которых не имеет полной картины происходящего. В этом случае, браузеры покажут сообщение об ошибке. Firefox выведет:
Firefox has detected that the server is redirecting the request for this address in a way that will never complete.
тогда, как Chrome:
This Webpage has a redirect loop
В обоих случаях, пользователь не может ничего сделать (в отличие от ошибки на стороне клиента, например, несоответствие файлов куки или кеша).
Важно избегать циклов перенаправлений, так как они полностью нарушают работу пользователя.
Found a content problem with this page?
- Edit the page on GitHub.
- Report the content issue.
- View the source on GitHub.
This page was last modified on 7 авг. 2023 г. by MDN contributors.
Your blueprint for a better internet.
Що таке редірект і як його прописати
Редирект (перенаправлення) — автоматична переадресація користувача на URL, відмінну від спочатку запитаного. Якщо внутрішній редирект налаштований коректно, процес перенаправлення залишається непоміченим.
Зміст
- ⏩ Основні види редиректів
- ⏩ Як перевірити код відповіді сервера
- ⏩ Ланцюжки редиректів
- ⏩ Для чого потрібний файл htaccess і як його знайти
- ⏩ 301 редирект з погляду SEO-оптимізації
- ⏩ Види 301 редиректів у файлі .htaccess з прикладами реалізації
- ⏩ 301 редиректи на WordPress за допомогою плагіна
- ⏩ 301 редиректи на Opencart за допомогою плагіна
- ⏩ 301 редиректи на платформі Хорошоп
- ♻ Підсумки
Найпростіший приклад редиректу: користувач в адресний рядок вводить один URL інтернет-магазину, а при переході потрапляє на інший, більш актуальний сайт цієї компанії. У цьому випадку сторінка, на яку перенаправили користувача, називається донор; сторінка, на яку його направили – акцептор. Тобто це редирект на інший сайт.
Як це працює?
Припустимо, користувач (браузер) звертається до сторінки за адресою https://inweb.ua/seo, а сервер сайту віддає користувачеві код відповіді 301 і перенаправляє на інший документ — https://inweb.ua/seo/, оскільки таке встановлене правило.
Коли використовують редиректи?
Редирект зі сторінки на сторінку – це направлення на актуальний розділ, якщо за старою URL-адресою він недоступний, тобто переадресація сторінки.
З точки зору SEO, перенаправлення дуже важливі, адже якщо поміняти URL-адресу на сторінці без 301 редиректу – втратимо трафік і позиції.
Приклади використання редиректів:
- Зміна адреси сайту або сторінки.
- Видалення категорії або розділу сайту.
- Перенаправлення користувачів на мобільну версію сайту.
- Перенаправлення з http на https.
- Склеювання або заміна доменного імені.
- Зміна CMS.
- Видалення дублів сторінок, коли проблему не можна вирішити іншим методом.
�� Код відповіді сервера: Основні редиректи: 1️⃣ 301 редирект Постійний редирект, він означає, що ресурс назавжди переміщений на нову адресу. �� 302 редирект “Зайдено”. Цей код відповіді означає, що ресурс, що його запитують, тимчасово змінений. �� 303 редирект 303 редирект означає «дивіться інший ресурс». �� 307 редирект Тимчасове перенаправлення. Тобто сторінка, що запитують, в даний момент знаходиться за іншою адресу. ⭐️ Як налаштувати редирект: Налаштувати редирект можно кількома способами: змінюючи код у файлі .htaccess, через адмінку сайту або у спеціальних сервісах. �� Що таке редирект і коли він потрібен Редирект — це перенаправлення користувача з одного URL на інший. Коли потрібно робити 301 редирект?
- Коли сторінка (група сторінок або цілий розділ) змінила свою адресу. Найчастіше це трапляється при зміні структури сайту, перейменуванні основотворчої частини URL або зміні принципу формування адрес (простіше кажучи, людинозрозумілий урл).
На жаль, не всі замислюються про наслідки змін на сайті, коли виникає безліч неіснуючих сторінок, і як наслідок – втрати позицій.
- Зміна адреси сайту або склеювання дзеркал. Якщо ви вирішили змінити адресу сайту у зв’язку з ребрендингом компанії або зареєстрували новий красивий і короткий домен, для друку на промо-продукції, дуже важливо, щоб при зверненні до адреси на старому домені користувач потрапляв на ту саму сторінку (а не на головну сторінку), але на новому домені. Тому важливо знати всі деталі про те, як налаштувати редирект.
Важливо! Не можна редирект писати зі сторінки товару на категорію.
Коли можна робити 301 редирект?
Redirect 301 можна використовувати як відповідь сервера замість помилки 404 Not Found. Іншими словами, користувач, перейшовши за неправильним посиланням або на неіснуючу сторінку, не побачить повідомлення «Вибачте, такої сторінки більше немає», а буде переміщений на іншу існуючу сторінку.
Коли не слід робити 301 редирект?
Перманентний редирект не варто використовувати для тимчасових рішень, це очевидно з його назви – для тимчасового переміщення використовуйте 302 Moved Temporarily. При цьому не станеться склеювання сторінок і сторінку з редиректом можна буде будь-коли відновити.
Якщо з вашим доменом трапилися проблеми, наприклад, фільтри, бан і т.п., і ви вирішили змінити адресу сайту (домен), то не варто робити 301 редирект зі старого домену на новий – в результаті ви приклеїте до нового домену все проблеми старого. Тобто, зрештою, нічого й не зміниться.
Існує дуже багато способів зробити 301-редирект: прописати редирект у htaccess, php, javascript, налаштування сервера та інші. Ми рекомендуємо не намагатися використовувати відразу всі методи одночасно, занадто велика ймовірність «розбіжностей» між різними способами і, наприклад, можна отримати нескінченний циклічний перенапрямок.
Важливо! Потрібно вивантажувати неіснуючі сторінки з SC і прописувати редиректи на існуючі. Виняток: товар (у випадку, якщо він може знову з’явитися в наявності).
Основні види редиректів
Всього інсує 10 різних кодів, які реалізують перенаправлення, але в своїй роботі в 98% випадків ви зустрічатимете 301, 302 і 304, про них нижче.
301 Moved Permanently
Запитуваний документ переміщений на іншу URL-адресу назавжди. Це код відповіді сервера, який викликає найбільше запитань у початківців.
Насправді відповідь проста: всі сторінки, з яких користувачів потрібно назавжди переправити на іншу сторінку (дублі, віддалені сторінки, дзеркала і всякі штучки), повинні відповідати цим кодом.
Після краулінгу таких сторінок пошукові системи рано чи пізно «склеять» їх із цільовою сторінкою редиректу та передадуть вагу.
Намагайтеся прибирати всередині сайту всі посилання на сторінки, які віддають код відповіді 301, і проставте відразу цільову сторінку редиректа.
Google стверджує, що для нього всі редиректи рівнозначні, але є ще інші пошукові системи, тому ставимо завжди 301.
302 Found
Повідомляє клієнта, що сторінка знайдена та тимчасово розташована за іншою адресою.
Пошукові системи зазвичай не видаляють її з індексу. Раніше цей код відповіді використовувався під час доопрацювань на сайті або випадків, коли товару тимчасово немає, але сторінка приносить трафік, тому є сенс перенаправити користувачів на сторінку каталогу чи схожого товару.
304 Not Modified
Насправді це не зовсім редирект, це «повідомлення» про те, що сторінка не змінювалася з попереднього відвідування.
Код 304 Google використовує і це позитивно впливає на бюджет краулінгу.
При зверненні, якщо GoogleBot бачить 304 код відповіді сервера, він не завантажує сторінку.
Як перевірити код відповіді сервера
Багато способів: панель інструментів розробника в браузері (F12 + вкладка «Network»), плагіни в браузері, спеціальні онлайн-служби, різні SEO-сервіси, Netpeak Spider , Screaming Frog.
Перевірка за допомогою Screaming Frog
- Запускаємо програму, починаємо сканувати сайт.
- Знаходимо вкладку “Response Codes”.
- Вибираємо Redirection (3xx).
Як перевірити через Netpeak Spider:
- Запустіть Netpeak Spider.
- На бічній панелі відкрийте вкладку «Параметри» та позначте пункт «Код відповіді сервера».
- Щоб переглянути джерела, на яких поставлені посилання з редиректами, скористайтесь поєднанням клавіш Shift+F1.
- Для експорту отриманих даних клацніть по кнопці «Експорт» у правому верхньому кутку екрана, потім виберіть одну з опцій: «Результати в поточній таблиці» — щоб вивантажити відфільтровані результати, або один із спеціальних звітів по редиректах.
Ланцюжки редиректів
Що це і чому це погано?
Ланцюжок редиректів — це перенаправлення не в один, а більше, ніж у 2 кроки. Фахівці сперечаються про їхню шкідливість: не дуже шкідливими називають до 5 переходів, оскільки пошукові роботи здатні по них перейти.
Для ефективного просування сайту ланцюжків не має бути на сайті взагалі. Ланцюжок редиректів може призвести до циклічного редиректу, якщо його некоректно налаштувати. І це негативно позначиться на пошуковій видачі. Причиною появи ланцюжків переходів та циклічного перенаправлення може бути зараження вірусами. Пошукові системи можуть вважати ваш сайт небезпечним для користувачів та перешкоджати відвідуванню.
Як знайти?
Для пошуку ланцюжків використовуйте чекери або спеціальні сервіси. Найпопулярніші:
Webmasta
Тут зібрано багато корисних інструментів для веб-майстра, у тому числі і для перевірки редиректів сайту. Сервіс працює швидко і показує весь ланцюжок редиректів, а не один перенапрямок.
Netpeak Spider
Це інструмент для комплексного SEO-аудиту, який дозволяє також знаходити ланцюжки редиректів.
Redirectdetective
Дозволяє побачити весь ланцюжок перенаправлень. З його допомогою можна переконатися, що редиректи працюють правильно або на якому етапі в ланцюжку підхоплюються cookies — вони позначаються круглим жовтим значком. Сервіс безкоштовний.
Також для перевірки можна використовувати розширення для браузерів:
- Redirect Path для Google Chrome;
- Live HTTP Header для Mozilla Firefox, Chrome.Знайшовши ланцюжок перенаправлень, необхідно встановити джерело проблеми. Якщо ви самі налаштували редирект, вам слід їх прибрати або поміняти на одиночні.
Як усунути?
Вам знадобиться з’ясувати причину та зрозуміти, чому виникає перенаправлення. Перевірте логи, чи там є ці перенаправлення. Якщо не знайшли, то пошукайте в основному коді подібні рядки:
Якщо сторінка, на якій виявлено перенаправлення, має динамічну адресу, яка генерується при переході, можливо, скрипт сам генерує і редиректи. Будьте пильні при перезапису URL-адрес сторінок, особливо використовуючи шаблони. Це поширена причина ланцюжків та циклів перенаправлення.
Важливо! Варто прибрати з сайту внутрішні посилання на редиректи або замінити посиланнями на доступні сторінки. Щоб побачити вхідні посилання на такі URL, достатньо натиснути комбінацію клавіш Shift+F1.
Для чого потрібен файл htaccess і як його знайти
Файл htaccess — є файлом конфігурації веб-сервера Apache і визначає правила роботи веб-сервера в тих каталогах і підкаталогах, де розміщений.
Мається на увазі файл htaccess відповідно в тому каталозі, для якого задає правила роботи. Найчастіше для вашого сайту це буде коренева папка.
301 редирект застосовують у ситуації, якщо URL-адреси сайту змінилися на нові, і необхідно «склеїти» старі та нові сторінки. Наприклад:
-
-
- при зміні домену;
- склейки з метою SEO-оптимізації. Наприклад, сторінок виду: «www.sitexample.com» та «sitexample.com»;
- при зміні URL-адреси сторінки для збереження трафіку, що приноситься сторінкою;
- при зміні протоколу з http на https;
- для переадресації зі сторінок з кодом відповіді 404 на актуальні.
301 редирект з погляду SEO-оптимізації
Редирект корисний, оскільки він допомагає:
- зберегти трафік;
- не допустити втрати «ваги» сторінки;
- позбутися дублів сторінок.
- позбутися наявності неякісних сторінок у пошуковій видачі.
З точки зору роботи з користувачами, 301 редирект корисний, оскільки дозволяє перенаправити трафік на суміжні продукти, якщо той, що шукають, видалений. Тим самим знижується ймовірність виходу користувача .
Що таке дублі сторінок і чим вони погані?
«Дублями» називаються сторінки, які містять однаковий контент. Вони можуть бути повними або частковими.
Частковими дублями називаються сторінки, де контент збігається в повному обсязі. Сторінки, на яких весь контент ідентичний один одному, називаються повними дублями. Чим небезпечні?
- Дублі негативно впливають на ранжування сайту, не дозволяючи високо ранжуватися на запит.
- Коли на веб-сайті є дві (і більше) однакові сторінки, пошукові системи не можуть зрозуміти, яку з них потрібно показувати користувачам за релевантним запитом і яку з них необхідно ранжувати.
Не дивлячись на те, що роботи пошукових систем аналізують і інші параметри, їм все одно важко вирішити, який з дублів потрібно вибирати.
Види 301 редиректів у файлі .htaccess з прикладами реалізації
Існує безліч різних ситуацій, коли необхідно застосувати 301 редирект. Давайте розглянемо їх докладніше:
Что такое redirect uri и как его сделать в django?
После подключения allauth приступил к созданию приложений для разных соцсетей. Везде есть такое поле как redirect uri. Где-то это обязательное поле, где-то нет. Я не совсем понял, что это за поле и почему нельзя просто указать реальную страницу, на которую после авторизации под аккаунтом соцсети, пользователя будет перекидывать (Например корень).
— в VK это поле необязательное и его можно оставить пустым. Если указать главную страницу сайт, то каждый раз будет возвращаться json «Redirect URI does not match registered redirect URI». В итоге оставил поле пустым и после этого стал залогиниваться под учеткой вк.
— в facebook такого нет. Есть Домены приложений куда надо добавить адрес своего сайта. Я добавил, но так и не могу зайти под учеткой fb — пишет «Невозможно загрузить URL: Домен этого URL не включен в список доменов приложения. Чтобы загрузить этот URL, добавьте все домены и поддомены своего приложения в поле «Домены приложения» в настройках вашего приложения.»
— в twitter все просто (как же я люблю твитур с ним всегда все просто). Поле Callback URL есть. Оно не обязательное и если ввести тот адрес, что указан в докусентации, то все отлично работает «127.0.0.1:8000/accounts/twitter/login/callback»
— Одноклассники — то же самое поле есть в приложении и оно обязательное, если указать то что написано в документации — «example.com/accounts/odnoklassniki/login/callback» то при авторизации через ОК получаем ответ от одноклассников «Указанный redirect_uri не зарегистрирован в настройках приложения.
redirect_uri: xxx.com/accounts/odnoklassniki/login/callback»Что это за адрес? Как его зарегистрировать в django? что нужно что бы api перестали ругаться и начали нормальн опускать?
p.s. — естественно вместо адреса example.com и 127.0.0.1:8000 я использовал адрес своего сайта.
- Вопрос задан более трёх лет назад
- 2618 просмотров
-