Логика структуры мультиязычного сайта?

Студия выкатила мультиязычный сайт. 3 языка (украинский, русский, английский). По умолчанию основной язык - украинский.
Программист делает структуру следующим образом: делает под каждый язык свой подраздел: https://домен/ua/, https://домен/ru/, https://домен/en/, а домен клеит 301 редиректом к подразделу, т.е. по умолчанию как главная страница открывается подраздел.
На аргументацию, что для варианта с основным языком по умолчанию не надо делать никаких подразделов, а должна быть структура алиасов без паразитной языковой категории, а на дополнительные языки подразделы- ок, для организации структуры -можно. Программист отвечает, что, мол, я всем так делаю и все клиенты довольны... это что, такая новая мода или программист просто чайник? Подскажите, можно ли так делать структуру или нельзя?
Сам сайт: Ссылка удалена модератором.

Дополнительно:

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

P.s. Субъективно мне больше нравится решение программиста, так как оно более универсально и не требует костылей при дальнейшей разработке и развитии сайта.

  • Алан Гибизов, да вы философ! я тут за техническими аргументами в ту или иную сторону. если вы считаете, что клеить домен к подразделу- это нормально, лишь бы работало, то извините. просто поболтать я выберу другое место
  • Crazy Cat, вы бы сначала теги нормально расставили, господин привереда.
  • Ну да, какой аргумент можно услышать от веб- разработчика? "Сам дурак!" Видимо у меня действительно проблема с тегами и вопрос лучше задавать сеошникам)
  • Я так понимаю, автора волнуют проблемы дальнейшей поисковой оптимизации, нежели эксплуатации и развития. Т.е. ему надо продавать, а как оно потом будет жить - подумаем потом.

    В этом есть резон. Потом будут деньги, а «за деньги я могу сделать всё».
    https://youtu.be/TaXqIMQiaHM

  • Алан Гибизов, покажите мне хоть одну рекомендацию подобным образом делать структуру сайта? покажите мне хоть один значимый проект, реализованный подобным образом?(я вам в ответ приведу 100500 проектов с чистым языковым доменом) что хорошего в том, что лично вам как разработчику будет что-то удобней в навигации, а в реальности домен склееный в подраздел- это тупой костыль, который в дальнейшем в продвижении сайта так или иначе будет вылазить боком, в том числе и в финансовом плане.
    И мне не надо ничего продавать, я не маркетолог. Вы видимо далеки от понимания профессии "seo-специалист"... и да, никаких денег не будет.
  • Crazy Cat, ну а я о чем? Продвижение! Продвижение! В этом и причина вашего негодования.
    Вы совершенно не думаете о технической стороне вопроса с точки зрения развития продукта (а потом будете возмущаться - как так, почему всё надо переделывать?) Продвижение это ваше всё.

    В любом случае - если вы записали в ТЗ своё требование - требуйте от исполнителей его исполнения. Не записали - доплачивайте за хотелку.

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

  • Алан Гибизов, Вы странный человек. Во-первых, я думаю как раз о технической стороне вопроса: как Гугл воспримет отчередной вывих психики очередного "гениального" веб-разработчика. Во вторых, я не писал ТЗ, не заказывал сайт. Я аудирую заказанный сайт. Мне всё равно, мне деньги заплатят за аудит. Однако я впервые за 15 лет практики встретил подобный прием и заверения разработчика, что он всегда так делает. А так не делает никто. Так не рекомендует никто. Я знаю ответ и аргументы, почему так делать нельзя, но хочу услышать мнения других специалистов.
    Ну и в третьих. На ваше сладкое. Я не являюсь постоянным посетителем данного ресурса. Сюда я зашел только с одной целью- найти ответ. Если я его найду, то ок, когда- нибудь я прийду сюда во второй раз, чтобы решить еще какую-нибудь проблему. А если вместо вполне аргументированных ответов я получу ответ типа: так можно, потому что разработчику так удобнее или так можно, потому что сайт все равно работает, то тут я задаю вопрос в первый и последний раз. Так что десертик оставьте себе. И наслаждайтесь... и да, зарегистрировать новый аккаунт или зайти под ВПН- вопрос 2 минут... да? вы больше не пишите, судя по ответам - вы не специалист и не умеете оперировать аргументами. Спасибо.
  • Crazy Cat, вот смешно. Аудитор с 15-летним опытом, ищущий аргументы на ресурсах вопросов и ответов. Впрочем, если за такое деньги платят… почему бы нет?

    А в аудиторском отчете ссылку на ресурс поставите? А укажете, что при этом на правила ресурса вам плевать?

  • Алан Гибизов, вы удивитесь, человек не выдумывает знания, он их нарабатывает с практикой и посредством общения с людьми, которые также практикуют. Мне показалось, что это приличный ресурс и люди тут тусуются практикующие. Я всегда задаю людям вопросы, потому что полезно рассматривать проблему с разных точек зрения. Я постоянно читаю мануалы Гугл и ведущих IT- компаний, я всегда стараюсь смотреть все вебинары по теме. В этом смысл прогресса и развития любого человека, а в it тематике - это вообще аксиома.
    Пока что тут я услышал 2 мнения: так удобнее разработчику и сайт же будет все равно работать. Это не аргументация, а болтология. Пока что не на что ссылаться. И не на кого.
  • Crazy Cat, вы услышали не мнение, а свою интерпретацию мнения.
    Мнение было - всё, что не оговорено в договоре и приложениях - на усмотрение исполнителя.
    Также мнение было - делать показанную структуру с точки зрения разработчика может быть вполне логичным, если ему явно не сказано, что надо учесть такой-то и такой-то нюанс.
    Разработчик ведь не должен читать мысли. Он должен сделать продукт так, чтобы он соответствовал ТЗ и содержал минимум ошибок.

    В ТЗ или договоре было хоть что-нибудь про организацию структуры и её заточку под условно «рекомендации лучших собаководов»? Или про предварительное согласование эскизного проекта?

    Я ни в коем разе не защищаю конкретное решение конкретного программиста. Возможно, он делает полную пургу с точки зрения эксперта. Но если в договоре указано «сделайте мне красиво», а с точки зрения конкретного программера пурга - красива, то за что платили, то и получили. Garbage in - garbage out.

  • Evgenii, apple.com может игнорировать базовые принципы поисковой оптимизации - к ним не из поиска заходят. И на их объёмах трафика и пользовательских сигналов Гугл уж как-нибудь понимает, что и где, и разберется с любым вывихом структуры.
    Здесь человеку с хоста клей на подпапку замастырили. Это, мягко выражаясь, очень странная идея.
  • Crazy Cat,

    покажите мне хоть одну рекомендацию подобным образом делать структуру сайта?

    https://developers.google.com/search/docs/specialt..., и в ответе даже дал.

    Кроме прочего, легко ищется самим гуглом https://www.google.com/search?q=%D0%BF%D0%BE%D0%B8...

    • Ответы:

    А давйте без "воможно", "наверное" и "я так думаю". Есть четкие правила, которые рекомендуют поисковые системы, и в данном случае программист абсолютно верно вывел все языки в отдельные урл: https://developers.google.com/search/docs/specialt...

    • Программист при этом настроил редиректы на эти подразделы, склеив домен верхнего уровня с папками, что в принципе недопустимо. Предполагается, что Гугл должен понимать основной язык и знать, где лежат копии для других. В данном случае hreflang и выступает в качестве софт-редиректа - а вовсе не реальный 301.
    • Виктор Петров,

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

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

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

      Альтер и хрефланг никуда не деваются, никто не предлагает их выкинуть или не использовать. Вопрос был в другом - делать всем версиям урл с указанием локализации или нет. И согласно рекомендациям гугла - всем. Соответственно редирект нужен.

      Программист при этом настроил редиректы на эти подразделы, склеив домен верхнего уровня с папками,

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

    • ThunderCat, против указания языка в url никаких возражений, это правильный вариант.
      Проблема в редиректе с основного домена. Редирект в этом случае - это домену серпом по сердцу. Гугл сам разберется, если указать альтернативные версии, ему hreflang хватит.

    Я так понимаю, что целевая поисковая система – Гугл. И если так, то программиста надо как-то осадить.
    Структура многоязычного сайта должна использовать hreflang. Вот у вас основной, дефолтный домен - на украинском. У него есть вспомогательные языковые версии - русская и английская. И вы просто метатегом указываете поисковой системе, что у странички есть альтернативные версии на других языках. Соответственно, в поиске гугл и будет показывать страницу, соответствующую языку запроса и определенной локации. Вы таким образом просто подклеиваете языковые разделы к основному домену, к главной странице – самой весомой странице сайта.
    Клеить домен к папкам - это, конечно, сильная идея. Прогерам стоит вообще запретить трогать редиректы без разрешения и чёткого ТЗ, это каждый раз настоящая авария.

    Вопрос определенно к SEO спецу.

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

    А поисковику (не сеошник, личное мнение маленького человека) - "лишь бы вкусно покормили". Ссылки разные, контент "разный", канонические юрлы проставлены, редиректы есть, условия ясны, теги и прочая лабуда имеется. Входящие ссылки на лице! "Чего ж тебе еще надо, собака?" Скажет любой поисковик))

    + Заказать

     

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

     

      • Логика структуры мультиязычного сайта?Есть ответ
      • 09.04.2024
      Ответить

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

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

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

      3. Использование мультиязычных URL: Для каждой языковой версии сайта рекомендуется использовать языковые поддомены или подпапки в URL. Например, для английской версии сайта можно использовать "en.example.com" или "example.com/en".

      4. Реализация переключения языка: Для удобства пользователей необходимо предоставить им возможность легко переключаться между языковыми версиями сайта. Это можно сделать с помощью выпадающего меню или языковых флажков.

      Пример использования

       для подсветки синтаксиса PHP:
 
<pre lang="php">
$language = $_SERVER['HTTP_ACCEPT_LANGUAGE'];
if($language == 'en') {
    // Переключение на английский язык
    header('Location: /en');
} elseif($language == 'fr') {
    // Переключение на французский язык
    header('Location: /fr');
} else {
    // По умолчанию используем английский язык
    header('Location: /en');
}

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

      • Логика структуры мультиязычного сайта?Есть ответ
      • 07.04.2024
      Ответить

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

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

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

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

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

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

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

    Оставить комментарий