SEO витрины на хинди и английском: URL, hreflang и рабочий процесс

Почему витрины на хинди и английском часто создают SEO‑дублирование

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

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

Каннибализация — следующая проблема. Это значит, что две страницы вашего сайта конкурируют за один и тот же поиск, и ни одна из них не показывает свой лучший результат. Например, если у вас есть английская категория и хинди‑категория, которые обе пытаются ранжироваться по “men shoes” (потому что хинди‑страница всё ещё в основном на английском), Google может переключаться между ними или показывать более слабую.

Цель SEO для витрины на хинди и английском простая: одна явная страница на язык и намерение. Английские страницы должны явно нацеливаться на английские запросы, хинди‑страницы — на хинди‑запросы, с чётким разделением и явными связями между ними.

В Индии это сложнее, потому что люди не ищут на одном языке. Многие пользователи ищут на английском, хинди и смешанно (Hinglish), например “best pressure cooker 5 litre” или “saree under 1000”. Если ваши хинди‑страницы — это лишь слегка отредактированные английские, они могут начать конкурировать с английскими страницами за такие смешанные запросы.

Быстрый способ понять риск дублирования — проверить:

• Одинаковые заголовки и описания на разных языках
• Очень похожий основной текст и заголовки, просто с заменой слов
• Хинди‑страницы, которые по сути читаются как английские
• Несколько страниц, отвечающих на одно и то же покупательское намерение без явного фокуса по языку

Выбор структуры URL, которая масштабируется

Структура URL — первое решение, которое либо предотвращает дублирование, либо тихо его создаёт. Она влияет на то, как поисковики сканируют сайт, как вы измеряете результаты и как сложно поддерживать согласованность английских и хинди‑страниц со временем.

Есть три распространённых подхода:

• Subfolders: example.com/en/ и example.com/hi/
• Subdomains: en.example.com и hi.example.com
• Separate domains: example.in и example.com (или выделенный домен для хинди)

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

Subdomains могут работать, но по факту ведут себя как отдельные сайты. Часто получается разрыв в аналитике, дублирование настроек трекинга и два набора технических проверок SEO. Поддержка со временем расходится: сначала улучшают английскую часть, а хинди‑сайт отстаёт, что создаёт разрыв в качестве.

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

Одна важная рекомендация важнее выбора: выберите шаблон и применяйте его везде. Если категории в /hi/, то и товары, фильтры, блог и страницы поддержки должны следовать той же структуре. Несогласованные шаблоны — частая причина, по которой многоязычные сайты случайно публикуют несколько URL для одного и того же намерения.

Чистые шаблоны URL для английских и хинди страниц

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

Обычный, понятный шаблон — использование папок языка:

• Английский: /en/
• Хинди: /hi/

Так страницы легче понимать:

• Категория: /en/mens-shoes/ и /hi/purush-joote/
• Товар: /en/puma-running-shoe-12345/ и /hi/puma-daudne-joota-12345/
• Блог: /en/blog/how-to-measure-feet/ и /hi/blog/pair-kaise-mapen/
• Справка: /en/help/returns/ и /hi/help/returns/

Что локализовать, а что оставить стабильным

Локализуйте то, что читают пользователи. Оставьте стабильным то, от чего зависят системы.

Локализуйте:

• Человеко‑понимаемые слаги для категорий, товаров, статей и разделов помощи
• Слова вроде "returns", "shipping", "size-guide" если такие секции есть на обеих языках

Оставьте стабильным (не переводите):

• SKU, ID товара, ID варианта и любые стабильные числовые идентификаторы (например 12345)
• Параметры трекинга и внутренние коды для аналитики или учёта

Оставление ID в конце URL полезно, если позже хинди‑слаг поменяется — URL всё равно будет ссылаться на тот же товар.

Выбор языка для главной страницы без дубликатов

Избегайте нескольких URL, которые выглядят как «главная» страница. Выберите один дефолт и сделайте остальные явными.

Простая схема:

• Главная по умолчанию: / (выберите английский или нейтральный селектор)
• Языковые корни: /en/ и /hi/

Если вы используете селектор языка на /, убедитесь, что он не создаёт индексируемые копии вроде /?lang=hi и /?lang=en. Они легко размножаются и сложны в контроле. Привязывайте переключение языка к папкам, чтобы у каждого языка был один чистый адрес.

Основы hreflang для хинди и английского

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

Для Индии чаще всего используют язык плюс страну:

• Хинди для Индии: hi-IN
• Английский для Индии: en-IN

Если вы также обслуживаете английский для других стран, можно использовать en для глобальной английской страницы и en-IN для индийской версии (цены в INR, условия доставки, локальные термины). Выберите минимальный набор, который отражает реальное отличие страниц.

Как hreflang «группирует» страницы

Hreflang работает как кластер. Каждая языковая версия должна ссылаться на другие версии и на саму себя. Например, английская страница товара указывает на хинди‑версию, а хинди‑страница — обратно на английскую. Если одна страница забудет ссылаться на другую, сигнал ослабнет и Google может расценить их как отдельные страницы.

Здесь многие проекты ошибаются: добавляют hreflang только на английские страницы или только в некоторых шаблонах — тогда Google видит неполный набор.

Что такое x-default и когда его использовать

x-default нужен для «запасной» страницы, когда вы не можете уверенно определить язык или регион пользователя. Полезен для страницы‑селектора языка или нейтральной страницы, где просят выбрать хинди или английский.

Не направляйте x-default на одну из основных языковых страниц, если только эта страница действительно подходит всем. Иначе вы запутаете Google и создадите смешанные сигналы о том, какая версия должна ранжироваться.

Канонические теги и правила индексирования, которые предотвращают дубли

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

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

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

Правила индексирования особенно важны для страниц, которые быстро размножаются:

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

Параметры и сортировка — частый источник раздутия индекса. Если у вас есть URL вроде ?sort=price или ?utm_source=, выберите чистую «основную» версию (обычно неотфильтрованную категорию) и канонизируйте к ней все версии с параметрами. Если какие‑то фильтры заслуживают собственных посадочных страниц (например «Men’s running shoes»), создайте фиксированный URL для такого фильтра и относитесь к нему как к реальной категории с уникальным текстом, а не к параметрной странице.

Практический рабочий процесс перевода (шаг за шагом)

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

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

1. Начните с инвентаризации страниц и правила «оба или только один». Сохраняйте в обоих языках страницы с высоким коммерческим намерением (главная, топ‑категории, бестселлеры, доставка, возвраты, контакт). Оставляйте длиннохвостые фильтры, почти дубль‑категории и низкотрафиковые лендинги на одном языке, пока не появится доказательство, что они приносят поиски.

2. Напишите бриф для перевода до того, как кто‑то начнёт менять тексты. Укажите тон (формальный хинди или разговорный), глоссарий для названий товаров и материалов, как показывать размеры и единицы, и точные слова для доставки, наложенного платежа, возвратов, гарантии и акций. Это предотвратит появление 20 вариантов одного и того же термина в шаблонах.

3. Локализуйте коммерческие страницы в первую очередь, а не весь каталог целиком. Переведите и адаптируйте вступления категорий, руководства по покупке, FAQ и разделы доверия. Для карточек товара фокусируйтесь на том, что влияет на решение о покупке: заголовок, ключевые преимущества, характеристики, уход и условия доставки/возврата. Если товар в английском описан одной короткой строкой, перевод создаст тонкую хинди‑страницу. В таком случае держите товар на одном языке и переводите категорию и страницы поддержки вместо этого.

4. Проведите структурированный QA, включаюший SEO‑элементы. Проверьте тайтлы и мета­описания на предмет смысла (не дословного перевода). Убедитесь в одном чётком H1, чистых заголовках и хлебных крошках на нужном языке. Проверьте внутренние ссылки и якорный текст — они должны соответствовать языку назначения, чтобы хинди‑навигация не вела на английские страницы и наоборот.

5. Публикуйте небольшими партиями и следите за показателями по языкам. Выпускайте 20–50 URL, затем мониторьте показы, клики и запросы для каждого языка. Если хинди‑страницы начинают ранжироваться по английским запросам (или наоборот), корректируйте тексты и внутренние ссылки, чтобы каждая страница отвечала нужному языковому намерению. Здесь выигрывается или теряется SEO витрины на хинди и английском.

Простой пример: если английская категория называется “running shoes”, а хинди‑версия использует разные варианты по страницам, в брифе выберите одну основную хинди‑формулировку и держитесь её последовательно. Последовательность помогает пользователям и снижает шанс, что две страницы будут восприниматься как взаимозаменяемые.

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

Избегание тонких страниц в шаблонах товаров и категорий

Самый быстрый путь к SEO‑дублированию — публиковать хинди‑версию для каждого товара, даже если на странице почти нет информации. Если хинди‑страница — это только переведённый заголовок и одна короткая строка, Google может посчитать её низкоценностной, и это повредит всему разделу (а иногда и запутает, какая языковая версия должна ранжироваться).

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

Хороший шаблон помогает избежать «практически пустых» страниц. Постройте постоянные блоки, которые нужно заполнять для каждого SKU и каждой категории:

• Заголовок страницы + один явный заголовок на странице (не набивайте ключевые слова)
• Мета‑описание, соответствующее содержимому страницы
• 3–5 FAQ (наличие, размеры, оплата, возвраты)
• Сниппет по доставке и возвратам (коротко и понятно)
• Доверительные элементы: гарантия, правила COD или окна обмена

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

Практические правила могут быть такими:

• Индексировать только если на странице есть полное хинди‑описание (не одна строка)
• Индексировать только если как минимум 2 FAQ отвечены на хинди
• Индексировать только если ключевые атрибуты переведены (размер, материал, совместимость)
• Иначе держать страницу доступной для пользователей, но пометить как не индексируемую, пока она не будет готова

Пример: вы запускаете хинди для каталога моды из 2 000 SKU. Начните с индексации только топ‑200 товаров и основных категорий, где вы сможете правильно заполнить шаблон. Остальное публикуйте с хинди‑элементами интерфейса, но не индексируйте, пока контент не достигнет минимума. Если вы строите на Koder.ai, можно встроить эти проверки в шаблоны и использовать снимки/откат при массовой публикации, если партия создаёт слишком много тонких страниц.

Работа с Hinglish и смешанными запросами

Hinglish‑запросы распространены в Индии, потому что люди смешивают скрипты и языки в одном запросе, например “wireless earbuds price” или “मिक্সर grinder 750w”. Для SEO это обычно значит, что пользователь ищет тот же товар, но формулировка смешанная из привычек, настроек клавиатуры и уровня комфорта.

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

Держите бренды, номера моделей и технические идентификаторы одинаковыми на всех языках. Эти термины часто вводят латиницей даже внутри хинди‑запросов, и согласованность помогает пользователям и поисковикам найти нужную страницу. Например, сохраняйте “Philips HL7756/00” без изменений на английской и хинди‑странице.

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

Что обычно работает лучше всего:

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

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

Пример: запуск хинди без вреда для английских позиций

D2C‑магазин персонального ухода продаёт 500 товаров. Их английский сайт уже ранжируется по товарным и категорийным запросам, поэтому они хотят хинди‑страницы без дубликатов и без вытеснения английских результатов. Классическая задача: расширить охват, а не создать 2 версии, которые будут бороться друг с другом.

Они выбирают понятную папочную структуру:

• Английский: /en/ (пример: /en/category/face-wash/)
• Хинди: /hi/ (пример: /hi/category/face-wash/)

Запуск проходит по фазам, а не путём перевода всего одновременно. Сначала переводят топ‑20 категорий и топ‑100 товаров с наибольшим трафиком и продажами. Для остальных 400 товаров не публикуют тонкие хинди‑страницы с копированным английским текстом. Те остаются только на английском, пока для хинди‑контента не будет готово качество.

Дубликаты избегаются тремя простыми правилами. Каждая языковая страница имеет self‑referencing canonical, английские страницы продолжают работать как прежде. Каждая переведённая страница получает hreflang‑аннотации, указывающие на свою пару (en <-> hi). И хинди‑страницы не создаются путём замены только заголовка и пары слов — в них переписывают ключевые части (вступление категории, преимущества товара, инструкции по применению, FAQ), чтобы страница действительно была полезной на хинди.

После запуска они еженедельно мониторят Search Console и аналитику. На второй неделе замечают каннибализацию: хинди‑категория начинает появляться по английским запросам, а английская страница чуть падает. Исправление простое: подправляют хинди‑страницу — естественные хинди‑заголовки и хинди‑ключевые слова (не английские термины), приводят внутренние ссылки в порядок, чтобы английские меню вели на английские страницы, и проверяют корректность hreflang. Через две недели результаты разделились: английские страницы выигрывают по английским запросам, хинди‑страницы растут по хинди‑запросам.

Частые ошибки, приводящие к каннибализации

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

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

Ошибки в hreflang — ещё одна частая причина. Если хинди‑страница указывает на английскую, но английская не отвечает взаимностью (нет обратной ссылки), сигнал слаб. Неправильные коды языка/региона или hreflang, указывающий на неканонические URL, тоже создают путаницу.

Канонические теги могут усугубить ситуацию. Если вы канонизируете и английскую, и хинди‑страницу на один английский URL, вы говорите поисковику: «это дубликаты, оставьте только английскую». Это может убрать хинди из результатов или вызвать борьбу за индексирование.

Следите за «одно намерение — много страниц». Это проявляется, когда команды создают несколько хинди‑вариантов категории, которые означают одно и то же (например, два разных перевода в навигации и внутреннем поиске). В результате они нацеливаются на один и тот же запрос с разными URL.

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

Паттерны для первичной проверки:

• Индексация каждой машинно‑переведённой страницы без проверки качества
• Hreflang без обратных ссылок или указывающий на неправильный URL
• Canonical, схлопывающий хинди и английский в один URL
• Дубли хинди‑категорий из‑за несогласованного именования
• Фильтры и сортировка, которые допускают массовую индексацию

Быстрая проверка реальности: найдите свой топ‑категорийный термин в обеих языковых версиях. Если вы находите несколько URL, которые человек назвал бы «той же страницей», вероятно, Google видит то же самое.

Краткий чек‑лист перед публикацией

Перед публикацией хинди‑страниц сделайте спокойный проход по базовым вещам. Большинство падений в ранжировании случаются потому, что небольшие сигналы (URL, canonicals, hreflang, внутренние ссылки) противоречат друг другу.

Чек‑лист готовности к публикации

Используйте это как финальный фильтр при запуске витрины на хинди и английском:

• Одна схема URL везде. Выберите одно правило и применяйте его к главной, категориям, товарам, блогу/помощи и любым лендингам. Избегайте смешения паттернов, например некоторые страницы в папках, другие — в параметрах.

• Self‑canonical на каждой языковой странице. Английская страница должна канонизироваться сама на себя, и хинди‑страница тоже. Кросс‑каноники используйте только если действительно хотите, чтобы одна страница была единственной индексируемой версией.

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

• Noindex для низкоценностных дубликатов. Фильтры, внутренние результаты поиска, почти‑дубликаты сортировок и тонкие вариации должны быть закрыты от индексации (обычно noindex плюс аккуратные внутренние ссылки), при этом разрешая обход основных страниц.

• QA перевода — это не только текст. Проверьте тайтлы, H1/H2, метаописания, важные alt‑теги изображений, внутренние ссылки (они должны оставаться на нужном языке) и локализуемые поля структурированных данных (например названия товаров). Также проверьте валюту, текст по доставке и условия возврата для соответствующего рынка.

После запуска разделите отчётность по /en/ и /hi/ отдельно (позиции, клики, индексируемые страницы, топ‑запросы). Если хинди растёт, а английский падает, замедлите релиз и исправляйте шаблоны прежде, чем переводить дальше.

Следующие шаги: простой план релиза и инструменты

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

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

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

• Добавьте минимум 2–3 уникальных локальных данных (доставка, размеры, заметки по использованию, FAQ).
• Убедитесь, что заголовки и метаописания написаны под хинди‑намерение, а не машинно‑переведены.
• Проверьте, что внутренние ссылки ведут на правильную языковую версию.
• Проверьте полноту пара «hreflang» (hi‑IN и en‑IN или выбранная вами схема).
• Держите низкоценностные страницы под noindex, пока они не соответствуют стандарту.

Для инструментов используйте Google Search Console для раннего обнаружения проблем с индексированием и каннибализацией, а также краулер для проверки hreflang и canonical массово. Если вы перестраиваете сайт, можно прототипировать маршруты /en/ и /hi/ в Koder.ai, описывая структуру в чате, быстро генерируя React‑страницы и используя снимки и откаты перед деплоем. Это делает работу с витриной контролируемой, измеримой и обратимой.