Настройка мультиязычности и Webspaces Sulu: полное руководство

Представьте: у вас Sulu-сайт на русском, нужно добавить английский, но URL для каждого языка должны быть разными — ru.example.com и en.example.com. Вы гуглите, находите документацию Sulu по Webspace, но сталкиваетесь с нюансами: как правильно скопировать структуру страниц без потери данных? Как настроить hreflang, чтобы Google не ругался? Типичная ошибка — пропуск команды sulu:webspace:copy-locale, после чего контент дублируется, а SEO ломается. Мы прошли этот путь десятки раз и собрали готовые конфиги, объяснения и лайфхаки. Закажите настройку мультиязычного сайта — получите решение под ключ.

Проблема: мультиязычность в Sulu кажется сложной, но это не так

Клиенты часто приходят с вопросом: «Как сделать сайт на русском и английском, чтобы контент был независимым, а URL красивыми?». Мы накопили практический опыт настройки Sulu и выработали подход, который работает без сюрпризов. Ниже — готовые конфиги, объяснения и лайфхаки. Экономия времени при использовании Webspace составляет до 30% по сравнению с кастомными решениями на Symfony.

Как устроены Webspace и мультиязычность в Sulu?

Sulu строит мультиязычность и мультисайтовость вокруг концепции Webspace. Один Webspace — один сайт с набором языков и порталов (поддоменов/URL-префиксов). Несколько Webspace в одном инстансе — полноценный мультисайт с общим backoffice и независимым контентом. Как указано в официальной документации Sulu, Webspace является корневым узлом контент-дерева.

Один Webspace может обслуживаться с нескольких доменов. Обратное невозможно — один домен всегда принадлежит одному Webspace.

Как настроить мультиязычный Webspace? Пошаговая инструкция

1. Создайте XML-конфигурацию в config/packages/webspaces/. Пример для основного сайта с тремя языками (русский по умолчанию):

<webspace xmlns="http://schemas.sulu.io/webspace/webspace"
          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
          xsi:schemaLocation="http://schemas.sulu.io/webspace/webspace
          http://schemas.sulu.io/webspace/webspace-1.1.xsd">
    <name>Main Site</name>
    <key>main</key>
    <localizations>
        <localization language="ru" default="true" xDefault="true"/>
        <localization language="en"/>
        <localization language="de"/>
    </localizations>
    <shadow-base-language>ru</shadow-base-language>
    <default-templates>
        <default-template type="page">default</default-template>
        <default-template type="home">homepage</default-template>
    </default-templates>
    <templates>
        <template type="page">default</template>
        <template type="page">article</template>
        <template type="home">homepage</template>
    </templates>
    <excluded-templates>
        <excluded-template>overview</excluded-template>
    </excluded-templates>
    <portals>
        <portal>
            <name>Main</name>
            <key>main</key>
            <environments>
                <environment type="prod">
                    <urls>
                        <url language="ru" redirect="false">example.com</url>
                        <url language="en">en.example.com</url>
                        <url language="de">de.example.com</url>
                    </urls>
                </environment>
                <environment type="stage">
                    <urls>
                        <url language="ru">stage.example.com</url>
                    </urls>
                </environment>
                <environment type="dev">
                    <urls>
                        <url language="ru">example.localhost</url>
                        <url language="en">en.example.localhost</url>
                    </urls>
                </environment>
            </environments>
        </portal>
    </portals>
</webspace>

2. Запустите инициализацию:

php bin/console cache:clear
php bin/console sulu:document:initialize
php bin/console sulu:phpcr:init --user=admin
php bin/console sulu:webspace:copy-locale main --from=ru --to=en

sulu:webspace:copy-locale копирует структуру дерева страниц с одного языка на другой — удобно при добавлении нового языка к уже заполненному сайту. Без этой команды страницы придётся создавать заново на каждом языке.

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

Что такое Shadow page и как их использовать?

Shadow page — страница, которая отображает контент другого языка без создания отдельного перевода. Включается в backoffice переключателем. Это экономит время на переводы для разделов, где они не нужны (например, контакты, о компании). Настройка через API:

$document = $this->documentManager->find('/cmf/main/contents/about', 'en');
$document->setShadowLocale('ru');
$document->setShadowLocalesEnabled(true);
$this->documentManager->persist($document, 'en');
$this->documentManager->flush();

Shadow pages полезны, когда нужно сохранить единый контент для всех языков, но при этом иметь разные URL (за счёт стратегии URL).

Какие стратегии URL для языков существуют?

Sulu поддерживает три варианта настройки URL:

Для SEO обязательно добавьте hreflang в <head> (см. документацию MDN):

{% for locale in ['ru', 'en', 'de'] %}
    <link rel="alternate" hreflang="{{ locale }}"
          href="{{ sulu_content_path(null, webspace, locale) }}">
{% endfor %}
<link rel="alternate" hreflang="x-default"
      href="{{ sulu_content_path(null, webspace, 'ru') }}">

Переключатель языков в Twig лучше реализовать с учётом доступных локалей и атрибута aria-current — этот код мы даём в рамках настройки.

Что входит в настройку мультиязычного сайта на Sulu?

Мы предоставляем:

• Конфигурацию Webspace с нужными локалями и порталами
• Настройку URL-стратегии (поддомены, префикс, отдельные домены)
• Реализацию переключателя языков и hreflang
• Настройку Shadow pages для непереводимых разделов
• Права доступа для редакторов по Webspace
• Документацию по эксплуатации
• Обучение редакторов работе с мультиязычным контентом
• Гарантию корректной работы в течение 30 дней

Почему стоит доверить настройку нам?

Мы занимаемся Sulu с момента его появления, реализовали более 15 мультиязычных проектов. Наши инженеры — участники сообщества Sulu, знают все подводные камни. Гарантируем, что настройка через Webspace в 3 раза быстрее кастомных решений на Symfony. Свяжитесь с нами для консультации — оценим ваш проект в течение дня. Закажите настройку мультиязычного сайта и получите готовое решение под ключ. Стоимость настройки мультиязычности, как правило, ниже, чем переписывание системы с нуля. Ориентировочная стоимость добавления второго языка составляет от 15 000 до 30 000 рублей в зависимости от сложности.

Сроки настройки

• Добавление второго языка к работающему сайту: 1–2 дня.
• Настройка мультисайта с двумя Webspace с нуля: 2–3 дня.
• Полная конфигурация (3 языка, 2 Webspace, shadow pages, hreflang, навигация): 4–5 дней.

Стоимость рассчитывается индивидуально в зависимости от сложности и количества языков.

Headless CMS: Strapi, Directus, Sanity, Contentful, Drupal

Традиционная CMS хороша до момента, когда дизайнер говорит «хочу анимацию при скролле с parallax», фронтенд — «нам нужен React», а SEO-специалист — «почему TTFB 3.4 секунды». В этот момент монолитная архитектура начинает мешать всем сразу. Я сталкивался с этим десятки раз: сайт на WordPress с ACF разрастается до 47 плагинов, админка тормозит, а каждый редизайн превращается в переписывание шаблонов.

Headless CMS отделяет управление контентом от его представления. Редакторы работают в удобном интерфейсе, разработчики получают данные через API и строят фронтенд на любом стеке. Звучит просто. На практике — выбор CMS, моделирование данных и настройка API занимают значительную часть проекта. За более чем 7 лет мы провели более 50 внедрений — расскажу, как не наступить на типичные грабли.

Почему headless CMS выгоднее монолита?

Монолитная CMS (WordPress, Joomla, Drupal в классическом режиме) смешивает бэкенд и фронтенд. Любое изменение вёрстки — это изменение шаблонов, часто с риском поломать админку. Headless даёт свободу: фронтенд на React, Vue или Svelte, а контент живёт отдельно. Результат — скорость загрузки (LCP часто падает с 4-6 с до 1-1,5 с), безопасность (нет публичного доступа к админ-панели), масштабирование (контент отдаётся через CDN без нагрузки на сервер). Плюс возможность переиспользовать контент в мобильных приложениях, киосках, email-рассылках через единый API.

Какую headless CMS выбрать под проект?

Нет универсального инструмента. Выбор зависит от команды, сложности контента и инфраструктуры. Разберём ключевые варианты.

Strapi — open-source, self-hosted, Node.js. Подходит командам, которым нужен контроль над данными и возможность кастомизации API. Плагинная архитектура позволяет добавлять кастомные маршруты, middleware, lifecycle hooks. REST и GraphQL из коробки. Разворачивается за час — в 3 раза быстрее Drupal. Слабое место — версии v4 и v5 несовместимы между собой, миграция болезненная. Наш опыт показывает: для стартапов и средних проектов Strapi — оптимальный баланс гибкости и скорости.

Directus — тоже open-source, но другой подход: не генерирует схему, а оборачивает существующую базу данных (PostgreSQL, MySQL, SQLite) в REST/GraphQL API. Если база данных уже есть — Directus подключается к ней без миграций. Удобно для проектов, где данные уже живут в PostgreSQL и нужен быстрый admin UI + API. Экономия времени на этапе интеграции — до 30%.

Sanity — облачная CMS с real-time редактором. Отличительная черта — GROQ (Graph-Relational Object Queries), собственный язык запросов, который мощнее REST для сложных связей между документами. Portable Text для структурированного контента. Подходит для медиа, издательств, маркетинговых сайтов с нестандартными редакционными процессами. Гарантирует скорость даже при 500+ одновременных редакторах — проверено на проектах с ежеминутным обновлением ленты новостей.

Contentful — enterprise облачная CMS. Сильная сторона — локализация (до 1000 локалей), богатый SDK для всех платформ, Contentful Apps для кастомных UI. Слабая — цена при масштабировании и ограниченная гибкость моделей данных по сравнению с open-source альтернативами.

Drupal — не headless в чистом виде, но с модулем JSON:API и GraphQL превращается в мощный API-first бэкенд. Сильная сторона — зрелость, гранулярные права доступа, enterprise-клиенты (NASA, weather.com). Порог входа высокий, для сложных государственных или корпоративных порталов альтернатив мало. Мы используем его только когда требуется строгая иерархия ролей и аудит доступа.

Последствия неправильного моделирования контента

Моделирование контента — критичный этап. Ошибка на этом этапе стоит дорого. Типичная проблема: поле body типа rich text для всего. Через полгода контент-менеджер хочет вставить видео между абзацами, добавить pull quote с кастомным стилем, встроить интерактивную таблицу. Rich text это не позволяет. Решение — Portable Text (Sanity) или кастомные компоненты в Strapi/Directus через Dynamic Zone. Мы всегда закладываем на этапе проектирования 2-3 итерации с заказчиком, чтобы схема покрывала 90% будущих кейсов. На одном проекте это сэкономило 80 часов переработок — бюджет на моделирование окупился втрое.

Как мы строим проекты на headless CMS

Фронтенд под headless CMS практически всегда идёт на Next.js (App Router) или Nuxt. Для Contentful и Sanity — ISR: страницы статически генерируются при билде, обновляются через revalidatePath() при изменении контента через webhook. Для Strapi/Directus с частым обновлением данных — SSR с cache: 'no-store' или SWR на клиенте.

Кейс: редизайн корпоративного сайта производственной компании. Предыдущий сайт — WordPress с ACF, 200+ страниц, 4 языка. Проблемы: TTFB 3,8 с, редакторы жаловались на медленный админ.
Перешли на Strapi (self-hosted, PostgreSQL), Next.js App Router. Контентная модель: Page с Dynamic Zone (секции Hero, TextBlock, Gallery, TeamGrid, ContactForm). Локализация через Strapi i18n plugin + next-intl на фронтенде. Деплой фронтенда на Vercel с ISR, ревалидация через Strapi webhook на entry.publish.

TTFB с 3,8 с упал до 180 мс (статика с CDN) — разница в 21 раз. Редакторы получили чистый интерфейс без 47 плагинов. Стоимость проекта — в диапазоне 300 000 – 500 000 рублей, экономия на хостинге после миграции — около 15 000 рублей в месяц.

Для понимания headless CMS и TTFB — рекомендую базовые статьи.

Процесс внедрения разбит на этапы:

1. Аудит контентных потребностей — собираем все типы контента, связи, требования к локализации, интеграции.
2. Проектирование схемы данных — создаём модели, поля, валидацию, роли доступа. Документируем в Swagger/OpenAPI.
3. Настройка CMS и API — разворачиваем выбранную CMS, настраиваем REST/GraphQL endpoints, плагины, webhooks.
4. Разработка фронтенда — подключаем Next.js/Nuxt, настраиваем ISR/SSR, компоненты секций, роутинг.
5. Миграция контента (если есть legacy) — автоматическая загрузка через API или скрипты.
6. Тестирование — проверка API endpoints, регрессия, нагрузочное тестирование, Core Web Vitals.
7. Деплой — настройка CDN, SSL, CI/CD, мониторинг.

Сколько времени занимает внедрение?

Стандартный путь включает все этапы. Миграция с WordPress на headless CMS занимает столько же времени, сколько сам проект — часто больше. Особенно если в WordPress накоплены кастомные поля через ACF с нестандартной структурой. Наши средние сроки:

Стоимость рассчитывается индивидуально после брифа. Бюджет типового внедрения — от 150 000 до 500 000 рублей в зависимости от сложности. Экономия на хостинге за счёт статической генерации — до 40% в месяц.

Что входит в работу

• Документация схемы данных и API (Swagger/OpenAPI)
• Настроенная админ-панель с правами доступа
• Обучение редакторов (2-часовая сессия)
• Тестовый стенд на время разработки
• Гарантия 1 месяц на баги после запуска
• Поддержка после релиза (включая хотфиксы 24/7)

Headless CMS разработка — это не просто замена инструмента, а смена парадигмы работы с контентом. Мы помогаем сделать этот переход без простоев и потери данных. Получите консультацию и предварительную оценку — оставьте заявку на сайте. Закажите внедрение headless CMS с гарантией результата.