Интересно, какой код статуса HTTP мне нужно отправить в переадресации языка.
У меня есть следующий PHP-код для перенаправления через HTTP-заголовки на самый важный язык в заголовке браузера Accept-Language.
<? $langs = array(); if (isset($_SERVER['HTTP_ACCEPT_LANGUAGE'])) { // break up string into pieces (languages and q factors) preg_match_all('/([az]{1,8}(-[az]{1,8})?)\s*(;\s*q\s*=\s*(1|0\.[0-9]+))?/i', $_SERVER['HTTP_ACCEPT_LANGUAGE'], $lang_parse); if (count($lang_parse[1])) { // create a list like "en" => 0.8 $langs = array_combine($lang_parse[1], $lang_parse[4]); // set default to 1 for any without q factor foreach ($langs as $lang => $val) { if ($val === '') $langs[$lang] = 1; } // sort list based on value arsort($langs, SORT_NUMERIC); } } // look through sorted list and use first one that matches our languages foreach ($langs as $lang => $val) { if (strpos($lang, 'ca')===0) { header("location: ca/"); exit; } else if (strpos($lang, 'es')===0) { header("location: es/"); exit; } echo "$lang => $val<br>"; } // show default site or prompt for language header("location: en/"); ?> Связанный вопрос: статус HTTP для функционального перенаправления
Может быть, 300, 301, 302, 303? Зачем?
РЕДАКТИРОВАТЬ
Недавно Google опубликовал это: http://googlewebmastercentral.blogspot.com/2011/12/new-markup-for-multilingual-content.html
Я нашел это:
HTTP STATUS 300 Множественный выбор
Запрошенный ресурс соответствует любому из наборов представлений, каждый со своим конкретным местоположением, и информация о согласовании с агентом (раздел 12) предоставляется так, что пользователь (или пользовательский агент) может выбрать предпочтительное представление и перенаправить его запрос в это место.
Если это не был запрос HEAD, ответ СЛЕДУЕТ включать объект, содержащий список характеристик и местоположений ресурса, из которых пользователь или пользователь может выбрать наиболее подходящий. Формат сущности задается типом носителя, указанным в поле заголовка Content-Type. В зависимости от формата и возможностей
пользовательский агент, выбор наиболее подходящего варианта МОЖЕТ быть выполнен автоматически. Однако эта спецификация не определяет какой-либо стандарт для такого автоматического выбора.
Если сервер имеет предпочтительный выбор представления, он ДОЛЖЕН включать конкретный URI для этого представления в поле «Место»; пользовательские агенты МОГУТ использовать значение поля Location для автоматического перенаправления. Этот ответ можно кэшировать, если не указано иное.
И это:
Ошибка HTTP 300 – множественный выбор
Введение
Ваш веб-сервер считает, что URL-адрес, предоставленный клиентом (например, ваш веб-браузер или наш робот CheckUpDown), недостаточно специфичен, и необходимо выбрать другой выбор из нескольких вариантов.
Обычно это тот случай, когда URL-адрес представляет собой группу высокого уровня, для которой необходимо выбрать более низкий уровень, например каталог, в котором пользователь должен выбрать конкретный файл для доступа.
300 ошибок в HTTP-цикле
Любой клиент (например, ваш веб-браузер или наш робот CheckUpDown) проходит через следующий цикл, когда он общается с веб-сервером:
Получите IP-адрес от IP-адреса сайта (URL-адрес сайта без ведущего «http: //»). Этот поиск (преобразование IP-адреса на IP-адрес) предоставляется серверами доменных имен (DNS). Откройте соединение IP-сокета с этим IP-адресом. Запишите поток данных HTTP через этот сокет. Получите в ответ HTTP-поток данных с веб-сервера. Этот поток данных содержит коды состояния, значения которых определяются протоколом HTTP. Разбирайте этот поток данных для кодов состояния и другой полезной информации. Эта ошибка возникает на последнем шаге выше, когда клиент получает код состояния HTTP, который он распознает как «300».
Фиксирование 300 ошибок – общий
Первое, что вам нужно сделать, это проверить свой URL-адрес в веб-браузере. Если вы видите какую-то веб-страницу с запросом на дальнейшие действия / варианты выбора, то ваш URL-адрес пока не будет достаточно подробным для веб-сервера для обработки.
Исправление 300 ошибок – CheckUpDown
Вы никогда не должны видеть эту ошибку в своей учетной записи CheckUpDown, если вы указали нам URL верхнего уровня (например, www.isp.com) для проверки. Если это происходит для URL верхнего уровня, очень вероятно, что программное обеспечение веб-сервера было неправильно запрограммировано или настроено. Если вы указали нам URL-адрес низкого уровня (например, www.isp.com/products/index.html) для проверки, то, скорее всего, этот URL-адрес недоступен даже через веб-браузер.
Первое, что вам нужно сделать, это проверить свой URL-адрес в веб-браузере. Если вы видите разумную веб-страницу, это может указывать на дефект в нашем программном обеспечении. Если, однако, вы видите какую-то веб-страницу, предлагающую вам дальнейшие действия / варианты выбора, то ваш URL-адрес не подходит для проверки, потому что наша система не может сделать такой выбор.
Пожалуйста, свяжитесь с нами напрямую (желательно по электронной почте) всякий раз, когда вы сталкиваетесь с 300 ошибками. Только мы можем разрешить их для вас. Если есть дефект в нашем программном обеспечении, мы исправим его. Если, однако, ваш URL-адрес принципиально непригоден для использования, вам нужно изменить его в своей учетной записи CheckUpDown (сначала нажмите кнопку «Управление»).
Вы можете обслуживать каждый язык под одним и тем же URL-адресом, а затем использовать контент-согласование заголовка Accept-Language , но я бы не рекомендовал его.
Я бы предпочел, чтобы на вашем корневом URL-адресе веб-сайтов вы отправили перенаправление (303 – См. Раздел «Другое») на дополнительную страницу языка (Eg /en ). Когда вы это сделаете, ответьте на заголовок Vary , который указывает Accept-Language (и любые другие соответствующие заголовки, такие как Cookie ). Таким образом, любые посредники (прокси, кэши) смогут кэшировать ответ. Я бы специально не выдавал 301, так как вы все еще хотите, чтобы ссылки указывали на корневой URL. На странице, rel="canonical" к языку, я бы поставил rel="canonical" в корневой URL.
Смотрите также эти темы:
Google использует 302 Found для перенаправления на локализованную страницу.
Я думаю, что это безопасно, если Google использует его …
Тем не менее, всегда хорошо проверять, что должен сделать выбранный ответ и для чего он предназначен, и влияет ли это на кеширование:
Возможно, HTTP 300 "Multiple Choices" поскольку это технически одни и те же данные / документы, но доступные на нескольких языках?
Я думаю, что вопросы более связаны с тем, чего вы хотите достичь:
1: Ваша индексная страница должна быть целевой страницей для вашего посетителя, и вы хотите, чтобы эта страница была проиндексирована поисковыми системами.
Плюсы: у вас есть одна страница входа для всех ваших посетителей, которая может размещать дополнительную информацию до фактической целевой страницы. Однако у него не будет контента для определенного языка.
Минусы: у вас нет страниц контента для всех языков в поисковых системах.
2: Фактически переведенная страница должна быть целевой страницей, и, если возможно, ваши посетители должны попасть на переведенную страницу напрямую, если это возможно. Страница перенаправления предназначена только для посетителей, которые попали прямо на ваш сайт, введя имя узла в адресной строке.
Плюсы: у вас есть несколько «целевых страниц» для каждого отдельного языка, который помогает выигрывать и прокручивать клики.
Минусы: у вас нет общей целевой страницы.
На эти два варианта есть больше плюсов и минусов, но я не могу думать об этом прямо сейчас.
Если опция 1: используйте 302, потому что вы все еще хотите, чтобы она была частью индекса поиска. если опция 2: используйте 301, потому что вы не хотите, чтобы эта страница была проиндексирована. Кроме того, используйте noindex на странице выбора языка.
Afaik, Google учитывает только 301, 302 и 307 (временное обслуживание), и я думаю, что он рассматривает все остальное как 302 (кажется наиболее логичным). Что касается браузера, я думаю, что это не имеет значения. Это может повлиять на кеширование, но я думаю, что в наши дни они довольно агрессивны в кэшировании даже 3хх ответов.
HTTP 303, потому что у него есть наиболее подходящая формулировка – см. Раздел «Другое» (302 – перемещение временно и 301 – перемещение на постоянной основе). Фактически HTTP 303 ответ в этой ситуации, чтобы браузер веб-пользователя мог затем безопасно обновить ответ сервера, не вызывая повторный запрос первоначального HTTP POST.