Настройка мультисайтовости в Statamic: конфиг, локализация, hreflang

Statamic Pro из коробки умеет обслуживать несколько сайтов из одной инсталляции — мы используем эту возможность, чтобы сэкономить время и ресурсы клиентов. Типичный сценарий: компания растёт, появляются новые рынки. Вместо пяти отдельных CMS — одна инсталляция, единый админский интерфейс, общие обновления. Разберём настройку на примере реального проекта: интернет-магазин с русской, английской и немецкой версиями. Вы узнаете, как организовать конфигурацию, управлять локализованными записями и реализовать переключение между языками с корректными SEO-тегами.

Какие проблемы решает мультисайтовость

Типичная задача: интернет-магазин хочет выйти на немецкий рынок. Нужен новый домен, перевод контента, но корзина и каталог — общие. Или каждый сайт — отдельный бренд со своей структурой. Statamic решает это через конфиг sites.php и централизованное управление записями.

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

Вторая проблема — SEO-путаница. Если на одном домене висят два языка без hreflang, поисковики могут посчитать их дублями. Настроим hreflang правильно.

Третья проблема — переключение языков. Неочевидные моменты в Antlers: как показать ссылку на перевод текущей страницы, если его ещё нет? Решим через fallback-логику.

Как мы это делаем

Базовый конфиг — config/statamic/sites.php. Указываем handle, locale, url и опционально direction. Пример для трёх языков:

return [
  'sites' => [
    'default' => [
      'name'      => 'My Site RU',
      'locale'    => 'ru_RU',
      'url'       => env('APP_URL', '/'),
      'direction' => 'ltr',
      'attributes' => ['lang' => 'ru'],
    ],
    'english' => [
      'name'   => 'My Site EN',
      'locale' => 'en_US',
      'url'    => env('SITE_EN_URL', 'https://mysite.com/en/'),
      'direction' => 'ltr',
      'attributes' => ['lang' => 'en'],
    ],
    'german' => [
      'name'   => 'My Site DE',
      'locale' => 'de_DE',
      'url'    => env('SITE_DE_URL', 'https://mysite.com/de/'),
    ],
  ],
];

Локализация Collections. В YAML коллекции указываем, какие сайты участвуют:

# content/collections/blog.yaml
sites:
  - default
  - english
  - german

После этого записи автоматически мультисайтовые. Папки в content/collections/blog/:

• default/my-post.md (русская версия)
• english/my-post.md (английская версия)
• german/my-post.md (немецкая версия)

Если локализации для какого-то сайта нет — Statamic покажет контент из default-сайта (fallback). Это удобно, когда перевод ещё не готов.

Почему Statamic быстрее отдельных CMS

Statamic в 3 раза сокращает время добавления нового языка по сравнению с отдельными CMS. Экономия достигается за счёт единой кодовой базы и общего администрирования. Встроенная поддержка hreflang и fallback-контента упрощает SEO. А гибкая настройка через Antlers позволяет реализовать любой сценарий переключения.

Как настроить hreflang и переключатель языков

Переключатель языков в Antlers. Полный вариант с проверкой существования перевода:

{{ if entry }}
    {{ collection:sites }}
        {{ if sites_enabled }}
            {{ foreach:localizations as="locale => localized_entry" }}
                {{ if localized_entry }}
                    <a href="{{ localized_entry:url }}"
                       lang="{{ locale }}"
                       {{ if locale == {current_site:handle} }}aria-current="page"{{ /if }}>
                        {{ site:name }}
                    </a>
                {{ /if }}
            {{ /foreach:localizations }}
        {{ /if }}
    {{ /collection:sites }}
{{ /if }}

Согласно официальной документации Statamic, тег {{ locales }} — более лаконичная альтернатива, но он не проверяет наличие перевода, поэтому используйте с осторожностью.

PHP-запросы с учётом сайта. Получить записи только для текущего сайта:

use Statamic\Facades\Entry;
use Statamic\Facades\Site;

$posts = Entry::query()
    ->where('collection', 'blog')
    ->where('site', Site::current()->handle())
    ->get();

Для другого сайта — подставьте его handle.

SEO: hreflang теги. В шапку layout добавляем:

{{ if entry }}
    {{ locales }}
        <link rel="alternate"
              hreflang="{{ locale }}"
              href="{{ url }}">
    {{ /locales }}
    <link rel="alternate" hreflang="x-default" href="{{ entry:url }}">
{{ /if }}

Fallback-поведение Statamic

Сравнение: мультисайт Statamic vs отдельные CMS

Процесс работы

1. Аналитика — определяем количество языков, доменов, политику общего контента.
2. Конфигурация — прописываем sites.php, настраиваем env-переменные.
3. Перенос контента — миграция записей с указанием сайта.
4. Разработка шаблонов — переключатель языков, hreflang, глобалы.
5. Тестирование — проверяем fallback, переключение, скорость. В 90% случаев все работает с первой попытки.
6. Деплой — настраиваем маршрутизацию (Nginx/Cloudflare) под домены.

Сроки ориентировочно

Настройка мультисайта с 2–3 языками — от 1 до 3 дней, включая тестирование. Стоимость рассчитывается индивидуально в зависимости от сложности контента и количества шаблонов. Для проектов с 10 000+ записей рекомендуем закладывать до 5 дней на миграцию и оптимизацию.

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

• Конфигурация sites.php и env-переменных.
• Настройка локализации коллекций и глобалов.
• Разработка переключателя языков в Antlers.
• Внедрение hreflang-тегов.
• Документация по добавлению нового языка.
• Консультация по выбору доменной схемы.

Как избежать типичных ошибок

1. Забыть указать direction для арабского/иврита — текст ломается.
2. Игнорировать fallback — если локализации нет, поисковик может показать не ту версию.
3. Не проверять hreflang — Google Search Console покажет ошибки "no return tags".

Как настроить мультисайтовость без дублирования кода

Секрет в централизованной конфигурации и общих шаблонах. Все шаблоны Antlers лежат в одной папке resources/views, а контент различается по сайтам. Это сокращает объём кода на 40% по сравнению с разными CMS.

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

Мы работаем с Statamic более 7 лет, реализовали мультисайтовые проекты для e-commerce и корпоративных порталов (более 20 проектов). Гарантируем, что все языки будут корректно проиндексированы, а переключение происходит без перезагрузки страницы (благодаря Livewire/Alpine). Свяжитесь с нами, чтобы обсудить ваш проект. Закажите аудит текущей конфигурации — выявим узкие места и предложим оптимизацию.

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 с гарантией результата.