WordPress Multisite: сеть сайтов на одной установке

Когда у бизнеса появляется не один, а пять, десять или пятьдесят сайтов — корпоративный портал, сеть филиалов, языковые версии — вести каждый отдельно становится дорого и медленно. WordPress Multisite предлагает решение: одна установка, общая база, единая админка, но при этом каждый сайт работает как самостоятельный.

01Что такое WordPress Multisite

Это нативный режим WordPress (включается одной директивой в wp-config.php и парой строк в .htaccess), при котором одна установка превращается в сеть сайтов. Появляется новая роль — Super Admin: он управляет сетью целиком, ставит плагины, обновляет ядро. Локальный администратор управляет только своим сайтом — контентом, меню, виджетами.

Каждый сайт сети может жить на:

• Поддомене: moscow.brand.ru, spb.brand.ru.
• Подпапке: brand.ru/moscow/, brand.ru/spb/.
• Отдельном домене (через mapping): brand-spb.ru технически входит в ту же сеть.

Сайты делят одну базу (с префиксами таблиц для каждого), общие плагины и темы, но имеют независимый контент, пользователей, настройки и SEO.

02Типовые сценарии, где Multisite оправдан

Multisite — нишевый инструмент. Он окупается, когда сайтов реально много или они похожи по структуре.

Сеть филиалов и франшиза

У вас 20 городов или 50 франчайзи — каждый ведёт свой сайт-визитку с локальным контентом. Дизайн и функционал одинаковы. Super Admin раз ставит обновление — оно прокатывается на всю сеть. Это альтернатива копированию темы по 20 раз.

Языковые версии

Если переводов 3–4 и важна полная независимость контента — Multisite позволяет вести их как отдельные сайты, не плодя костыли в плагинах. Альтернативы — Polylang/WPML внутри одной установки — проще, но имеют ограничения по производительности и сложным языкам.

Корпоративный портал из подразделений

Холдинг с разными брендами или несколькими направлениями: каждое получает свой сайт с собственным стилем, но IT-инфраструктура одна.

Сервис-«белый ярлык»

Платформы, которые дают клиентам сайты под собственным брендом (агентства недвижимости, фитнес-сети, школы) — типовой кейс Multisite.

03Когда Multisite не нужен

Гораздо чаще можно обойтись без сетевого режима. Признаки:

• Сайтов меньше 3–4, и они принципиально разные по дизайну/функционалу — проще держать отдельные установки.
• Нужна максимальная независимость по доступам, бэкапам и SLA (например, разные юридические лица) — в Multisite всё связано.
• Один из сайтов планирует жить отдельно и его потом будут продавать или передавать — выделить сайт из сети технически возможно, но трудоёмко.
• Команда не привыкла работать в схеме «Super Admin / Site Admin» — будут постоянные путаницы в правах.

04Плюсы и реальные преимущества

• Одна точка обновления. Поставил обновление ядра или темы — оно применилось ко всем сайтам сети.
• Общие пользователи. Сотрудник может иметь доступ сразу к нескольким сайтам без отдельных учёток.
• Единая инфраструктура. Один сервер, одна база, один сертификат (wildcard), одна система резервных копий.
• Скорость развёртывания. Новый сайт в сети поднимается за минуту: создал, выбрал тему, дал доступ местному админу.
• Экономия на лицензиях платных плагинов и тем — многие из них в multisite активируются на всю сеть.

05Подводные камни, о которых редко предупреждают

Multisite — это всегда повышенная связанность. Реальные грабли:

• Единая точка отказа. Падает сервер — падает вся сеть. Сбой обновления — у всех сайтов. Поэтому бэкапы и staging-окружение становятся обязательны, не «по желанию».
• Плагины несовместимы. Часть плагинов (особенно WooCommerce-расширения, кэш-плагины, мультиязычные) либо не поддерживают multisite, либо работают с ограничениями. Перед стартом проверьте совместимость каждого из плагинов вашей сборки.
• Производительность. Сотни сайтов с десятками плагинов на одной установке без серьёзного кэширования (Object Cache, Redis) и нормального хостинга начинают тормозить.
• Сложность бэкапов и миграций. Восстановить отдельный сайт из сети сложнее, чем самостоятельную установку. Многие плагины бэкапа этого не умеют.
• Конфликты ролей. Локальные администраторы не могут ставить плагины — это иногда воспринимают как баг, хотя это by design.
• Темы. Если каждому сайту нужна сильно своя тема — преимущества «общего ядра» теряются.

06SEO в сети сайтов

Multisite сам по себе не даёт SEO-бонусов, но и не штрафует. Главное — правильно выбрать архитектуру:

• Поддомены Яндекс рассматривает как отдельные сайты. Подходит, когда у каждого региона/филиала своя выдача и Карты. Подробнее — в материале о поддоменах для регионов.
• Подпапки делят авторитет одного домена, но требуют чёткой структуры и риска каннибализации ключей. Это в большей степени про SEO для нескольких офисов внутри одного сайта.
• Отдельные домены через mapping ведут себя как полностью самостоятельные сайты — для SEO в Яндексе важно тогда регистрировать каждый в Вебмастере отдельно.

На стороне ядра каждый сайт сети имеет свои robots.txt, sitemap, метатеги и настройки SEO-плагина — изолировать всё это не сложнее, чем в обычной установке.

07Что учесть на старте

1. Выбор архитектуры (поддомены/папки/отдельные домены) — менять позже трудно, фиксируйте на старте.
2. Проверка плагинов на совместимость с multisite — особенно WooCommerce, форм и кэша.
3. Wildcard-SSL для поддоменов — заранее закажите у хостинга.
4. Хостинг и серверные ресурсы. На обычном shared часто не хватает памяти для десятков сайтов — выбирайте VPS/выделенный сервер.
5. Регламент обновлений и бэкапов. Сначала staging, потом продакшен — без исключений.
6. Чёткое разграничение ролей Super Admin и Site Admin с записанной инструкцией для команды.

Multisite экономит время, когда сайтов много и они похожи. Когда их 2–3 и они разные — экономии нет, а сложности растут.

Официальная документация по теме — Справка Яндекс.Вебмастера.