Многоязычное SEO в Next.js: hreflang, карты сайта и fallback-локали

Перевод контента — это лишь половина дела в многоязычном SEO. Вторая половина — объяснить поисковым системам, что именно вы сделали: какой URL-адрес какому языку соответствует, какой из них основной, и что показывать пользователю, если для его региона перевод еще не готов. Если здесь ошибиться, Google начнет индексировать ваши французские страницы по английским запросам или посчитает десяток переводов дублями одного текста.

Ниже приведен чек-лист, которым мы пользуемся, и описание того, как Scribe берет на себя бóльшую часть работы, опираясь на уже известные ему данные о контенте.

Атрибуты hreflang на каждой странице

Каждая локализованная страница должна ссылаться на все свои версии, включая саму себя, а также содержать атрибут x-default, указывающий на версию для языков, которые не попали в список. В Next.js за это отвечает поле alternates.languages в метаданных страницы.

Самое сложное здесь — переведенные URL (slugs). Если английская страница /docs/getting-started во французской версии превращается в /fr/docs/premiers-pas, ваши альтернативные ссылки должны использовать именно локализованный URL, а не английский с префиксом языка. Scribe хранит переведенный URL вместе с самим переводом, а вспомогательная функция alternates() возвращает готовую карту для каждого документа. Таким образом, код метаданных работает как цикл, избавляя вас от необходимости вручную обновлять таблицы соответствий.

Вот два правила, которые помогут избежать типичных ошибок:

• Ссылки hreflang должны быть взаимными. Если французская страница ссылается на немецкую, немецкая обязана сослаться в ответ. Генерация обеих сторон из единого хранилища гарантирует соблюдение этого условия.
• Канонические URL должны указывать сами на себя в пределах каждой локали. Канонический адрес французской страницы — это ее собственный URL. Если сделать канонической английскую версию для всех языков, вы фактически прикажете Google удалить ваши переводы из индекса.

Карта сайта с поддержкой локалей

Каждый URL в карте сайта должен содержать те же альтернативные ссылки плюс x-default. Функция Scribe sitemapEntries() возвращает для каждого документа одну запись со всеми языковыми версиями URL и датой lastmod, которая вычисляется на основе встроенных полей publishedAt и updatedAt. Благодаря этому карта сайта всегда остается актуальной без необходимости вручную проставлять даты.

Удаленные документы не должны просто исчезать. Scribe хранит редиректы в файле _redirects.json для каждого типа контента, и устаревшие URL отдают код 301, перенаправляя пользователя на новую страницу в любой локали. Это помогает сохранить накопленный ссылочный вес.

Резервные локали вместо ошибок 404

Что должно открываться по адресу /fr-CA/guide, если вы перевели страницу на французский, но не адаптировали ее для Канады? Отдавать 404 ошибку — значит обесценить уже имеющийся перевод, а молча показывать английскую версию — сбивать читателей с толку.

Scribe автоматически проходит по цепочке резервных вариантов: региональная локаль откатывается к базовому языку, прежде чем переключиться на английский. То есть fr-CA сначала пробует fr, а затем en. Запрос к zh-Hant-TW перейдет к zh-Hant, затем к zh и только потом к en. Система сообщает, какая именно локаль была использована, через параметр actualLocale, поэтому в макете можно честно указать язык страницы. А параметры предварительного рендеринга включают эти резервные URL, чтобы страницы существовали уже на этапе сборки.

Метаданные — это тоже контент

Заголовки и мета-описания напрямую влияют на ранжирование, поэтому переводить их нужно так же тщательно, как и основной текст. В Scribe это обычные переводимые поля во frontmatter, которые хешируются и валидируются наравне со всем остальным. Наш алгоритм перевода заточен на транскреацию (творческий перевод), а не на дословную кальку, что особенно важно, когда нужно уместить смысл в 60 символов тега title.

Главный вывод

В этих процессах нет никакой магии. Это просто учет: альтернативные ссылки, канонические URL, карты сайта, редиректы и резервные локали — все это ответы на один вопрос: «какой документ существует в какой локали и по какому адресу». CMS, которая хранит переводы как полноценные данные, способна ответить на этот вопрос централизованно. А вот когда приходится вручную связывать облачную CMS, платформу для переводов и роутер, тогда многоязычное SEO обычно и дает сбой.

Посмотрите, как эти компоненты работают вместе, в руководстве по Runtime API или начните с раздела «Первые шаги».