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

Question

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

Теперь есть несколько мест для определения языка в URL:

1. • www.example.com/en/articles/random
   • www.example.com/nl/articles/random
2. • en.example.com/articles/random
   • nl.example.com/articles/random
3. • www.example.com/articles/random?lang=en
   • www.example.com/articles/random?lang=nl

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

Answer 1

Я скажу вам, что НЕ является лучшей практикой - использование параметров (3-й). Заставление пользователей вводить сложные URL-адреса вызывает проблемы.

Ваши страницы могут внутренне использовать параметры GET для поиска языка, но используйте модуль перезаписи URL, доступный на вашем веб-сервере, чтобы упростить его, например, первый - www.mydomain.com/en/articles/random

Даже со вторым все в порядке, за исключением того, что большинство пользователей вводят доменное имя и нажимают Ctrl + Enter.

https://addons.mozilla.org/en-US/firefox/

http://msdn.microsoft.com/en-us/default.aspx

http://www.apple.com/in/

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

Answer 2

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

• Подход 1: ИМХО хорошо, когда вы хочу запустить все статьи во всех языки одновременно. Но потом, когда вы вносите изменения в одном месте, вам нужно идти во всех местах и сделать то же самое изменение.
• Подход 2: Аккуратно для использования, как Википедия, где разные языки имею в виду фактические разные сайты ( статьи не переводы с один другого, а скорее другой содержание)
• Подход 3: Хороший выбор, если вы обычно запускают на каком-то языке, и переводы приходят позже (случай Google, например). Вы можете иметь язык по умолчанию в случае, если язык не указан, или даже сохраните его в сеансе, чтобы сохранить его среди изменений страницы.

Answer 3

Я нашел хороший ресурс от Google о вариантах, которые вы можете сделать. Есть раздел с за и против каждого метода, который вы можете использовать.

Я уже давно борюсь с многоязычными сайтами.

В статье определенно есть некоторые моменты, которые не упомянуты в упомянутых ответах. Вот почему я почувствовал необходимость опубликовать это как ответ. Надеюсь, это кому-нибудь поможет.

Answer 4

Я хотел бы добавить один, который мы выбрали для www.openimages.eu:

4)
www.mydomain.com/articles/random.en
www.mydomain.com/articles/random.nl

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

Accept-Language nl,en;q=0.7,en-us;q=0.3

и по умолчанию обслуживать ваши страницы на этом языке, если он доступен. Вы можете предоставить пользователям возможность выполнять действия «.en» или «.nl».

Answer 5

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

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

2 особенно уместно, если вы вызывали перенаправление на уровне веб-сервера, и имеет преимущество, заключающееся в том, что URL-адреса могут быть разрешены или не потеряны в настройках языка вашего пользователя. Другими словами, ссылка на / home приведет вас к правильной языковой версии «домашней» страницы.

Последний вариант - сохранить язык в качестве предпочтения пользователя в файле cookie, а не заполнять его в URL-адресе.

Answer 6

Я бы определенно пошел на

www.mydomain.com/articles/random?lang=en
www.mydomain.com/articles/random?lang=nl 

потому что более естественно сказать: «эта ссылка (полная ссылка) на английском или голландском языке».

В противном случае (domain / lang / restof url) создается впечатление, что у вас есть какая-то структура, которая содержит разные вещи для en и nl. То же относится и к lang.domain / ...

Answer 7

Если вы ищете «дружественные для поисковых систем» и «красивые» URL, вам следует избегать немаскированных параметров GET. Они не так хороши для глаз, как поддомен или подкаталог, и не совсем подходят для SEO.

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

Answer 8

Поисковые системы считают поддомены независимыми веб-сайтами. Я не уверен, как это влияет на SEO.

Answer 9

Я не знаю, есть ли «лучшая практика» в этом случае, поскольку это, вероятно, сводится к личному мнению.

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

Answer 10

Первый имеет больше смысла. Потому что, если кто-то хочет перейти непосредственно на вашу страницу, и он / она может просто напечатать blabla.com/en и достичь того, что он / она хочет ...