Как мы создали многоязычный каталог ИИ-инструментов

Каталогу нужна единая идентичность на каждом языке

Каталог ИИ-инструментов решает две связанные задачи: помогает людям находить полезное программное обеспечение и даёт каждой карточке устойчивую идентичность. Добавление языков расширяет обе задачи. Переведённый интерфейс может выглядеть завершённым, хотя лежащие в его основе страницы по-прежнему расходятся в том, какой URL представляет инструмент, существует ли перевод и какую версию должна учитывать поисковая система.

Toolso — многоязычная платформа для поиска и запуска ИИ-инструментов. В этой статье мы объясняем, как в Toolso связаны языковые маршруты, URL canonical, аннотации языковых альтернатив и записи sitemap. Основа материала — изучение исходного кода и небольшая проверка работающих страниц, выполненные 26 октября 2026 года. Здесь не измеряется улучшение позиций в поиске и не предполагается, что у каждой карточки есть контент на всех настроенных языках.

Полезно начать с простого вопроса: когда один и тот же инструмент представлен на нескольких языках, могут ли все части приложения согласованно описать эти версии? Этот вопрос связывает работу с контентом и техническое SEO. Перевод — это не просто ещё один пункт меню: ему нужны согласованные между собой контент, маршрут и метаданные.

Рисунок 1. Главная страница на английском языке. Скриншот предоставлен 26 октября 2026 года.

1. Отделяйте языковые маршруты от идентификаторов языков

Сейчас в конфигурации заданы десять языков: английский, упрощённый китайский, традиционный китайский, корейский, японский, французский, немецкий, русский, испанский и португальский. Язык по умолчанию — английский. Конфигурация маршрутизации использует языковые префиксы по необходимости, поэтому языку по умолчанию не требуется префикс /en, а остальные языки используют префикс.

Реальный пример — карточка Raphael AI: её адрес на английском — /tool/raphael, а на упрощённом китайском — /zh/tool/raphael. Мы проверили обе страницы 26 октября 2026 года. URL canonical в сформированных страницах указывали на соответствующие языковые версии.

Внутренние ключи маршрутизации отделены от идентификаторов языков, передаваемых поисковым системам. В текущей конфигурации zh соответствует zh-CN, tw — zh-TW, es — es-ES, а pt — pt-BR. Короткий внутренний ключ удобен для маршрутизации, но он не должен незаметно становиться языковой аннотацией с другим значением.

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

Рисунок 2. Страница Raphael AI на Toolso. Скриншот предоставлен 26 октября 2026 года; он показывает интерфейс, но не подтверждает корректность языковых аннотаций страницы.

2. Формируйте идентичность URL в одном месте

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

Вспомогательные функции Toolso для canonical, hreflang и sitemap используют общий конструктор абсолютных URL. Он передаёт формирование локализованных путей одной и той же логике маршрутизации и применяет единое правило нормализации корневого пути. В этой реализации URL главной страницы на языке по умолчанию нормализуется без завершающей косой черты. Это наше соглашение для согласованности, а не утверждение, что все сайты обязаны выбирать такое написание.

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

Аннотации canonical сообщают предпочтительный URL. Они не гарантируют, какой URL выберет Google. Это различие объясняется в рекомендациях Google по канонизации.

3. Пусть языковую группу определяют реальные переводы

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

Наша вспомогательная функция языковых ссылок принимает набор доступных языков. Когда вызывающий код передаёт его, функция создаёт альтернативы только для этих языков. Она включает альтернативу x-default, ведущую на версию на языке по умолчанию, лишь в том случае, если эта версия входит в доступный набор. Если набор не передан, объявляются все настроенные языки, поэтому точная передача доступности контента — важная обязанность вызывающего кода.

В конфигурации маршрутизации отключён автоматический вывод HTTP Link с языковыми альтернативами в next-intl. Вместо этого реализация формирует языковые аннотации с учётом сопоставления идентификаторов через метаданные страниц и вспомогательные функции sitemap. Так не приходится поддерживать ещё один автоматически созданный набор на основе исходных ключей маршрутизации параллельно с явным сопоставлением языков.

Результат необходимо проверять после развёртывания. В нашей выборке Raphael страницы на английском и упрощённом китайском объявляли одни и те же десять языковых альтернатив плюс x-default, включая обратную ссылку на другую страницу. Это подтверждает сформированные аннотации в данной выборке, но не качество перевода или индексацию в поиске. Документация Google по локализованным страницам объясняет коды языков, обратные ссылки и резервную роль x-default.

4. Рассматривайте sitemap как перечень, основанный на контенте

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

Запрос данных об инструментах в генераторе sitemap Toolso выбирает опубликованные инструменты. Отдельно он формирует набор доступных переводов из записей с пригодным для использования названием и корректным описательным содержимым. Эти записи переводов читаются пакетами с пагинацией по курсору. Генератор сохраняет сведения о языках, необходимые для сборки URL, вместо того чтобы накапливать все описания в памяти.

Затем записи страниц инструментов создаются только для доступных языков. Аналогично записи страниц статей блога фильтруются по набору языков каждой публикации. Оба типа используют общие вспомогательные функции URL для адресов в sitemap и языковых альтернатив. Поэтому само по себе наличие места под язык в базе данных недостаточно для создания записи страницы с подробным содержимым.

Даты изменения тоже требуют внимания. Записи страниц инструментов используют связанное с контентом поле seoUpdatedAt, а записи блога — соответствующую дату обновления контента или публикации. Цель — отражать значимые изменения содержимого, а не выдавать каждое обновление счётчика просмотров за новую редакционную правку.

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

5. Сделайте резервный контент явным состоянием

Для отсутствующих переводов нужна политика. Иначе одно и то же описание на исходном языке может появляться по множеству языковых URL, хотя сайт представляет их как завершённые переводы.

Метаданные страниц инструментов содержат явную ветку резервного отображения при отсутствии перевода. Когда она выдаёт резервный контент, страница получает noindex, URL canonical указывает на английскую версию инструмента, а группа языковых альтернатив для этого ответа отключается. Временно недоступные или отсутствующие данные перевода обрабатываются отдельно; их не следует описывать как успешно переведённую страницу.

Реализация страниц статей блога следует похожей политике: резервная версия указывает на исходный язык статьи, отключает языковые альтернативы и использует noindex. Архивный контент блога также помечается noindex. Это редакционные и технические решения конкретного проекта, а не рекомендация применять одно и то же правило ко всем многоязычным сайтам.

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

6. Проверяйте выдаваемый результат отдельно от реализации

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

В репозитории есть скрипт аудита sitemap, который может проверять статус ответа, директивы robots, URL canonical и, при необходимости, связи между языками. Мы изучили скрипт и проверили сформированные метаданные двух страниц Raphael и их записи в sitemap. В этих записях использовались те же URL canonical и языковые альтернативы, что и на страницах выборки. Мы не запускали полный аудит рабочей среды и не изучали Search Console.

Три снимка экрана показывают главную страницу, карточку Raphael AI и начальный экран добавления инструмента. Они фиксируют интерфейс на момент съёмки. Чтобы повторить техническую проверку, сравните URL canonical и языковые ссылки, выданные для одной карточки на двух доступных языках, а затем сопоставьте эти URL с sitemap. Зафиксируйте URL и дату. Поведение при отсутствии перевода проверяйте отдельно: для завершённого перевода и резервного контента нужны разные проверочные условия.

Наблюдения из Search Console следует вести отдельно: что Google просканировал, какой URL canonical выбрал и что проиндексировано. Аналитические показатели и данные о конверсиях относятся к другой записи. Раздельный учёт не позволяет пересказать локальную проверку реализации как результат в поиске или выручке.

Что могут использовать разработчики других каталогов

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

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

Рисунок 3. Форма отправки после импорта URL инструмента с заполненными медиаматериалами. Скриншот предоставлен 26 октября 2026 года; завершённая отправка на нём не показана. Цены и счётчики отражают состояние интерфейса на момент снимка.

Если вы создаёте многоязычный каталог, можете изучить Toolso, держа в уме эти вопросы: содержит ли каждая языковая страница полезный контент и точно ли её URL-сигналы описывают этот контент?