Когда Multisite оправдан для SEO
WordPress Multisite удобен когда одна команда держит много сайтов с общей инфраструктурой. Для SEO это не «магия масштаба», а отдельный класс рисков canonical между сайтами, общие плагины с разными SEO-настройками, сломанный hreflang и sitemap которые подмешивают чужие URL.
Официальная документация WordPress Multisite network описывает создание сети. SEO-решения начинаются раньше выбора subdomain или subdirectory вы определяете сайты это языки одного бренда, регионы, франшизы или отдельные продукты.
- Языки одного бренда чаще требуют жёсткого hreflang и общего контент-процесса.
- Франшизы / города риск thin-дублей и почти одинаковых шаблонов.
- Отдельные продукты лучше держать как независимые SEO-сущности с собственным GSC.
Структура сети и подводные камни
Subdirectory (`example.com/ua/`) упрощает авторитет домена но усложняет разделение команд и cookies. Subdomain (`ua.example.com`) чётче делит сайты но Google может трактовать их более независимо. Domain mapping (`brand.pl`) даёт локальный сигнал и требует отдельной политики редиректов и SSL.
- Не смешивайте «язык в path» и «язык как отдельный mapped domain» без карты соответствий.
- Запретите индексацию staging-сайтов сети на уровне хоста и robots а не только «в плагине».
- Отдельные SEO-плагины на каждом сайте часто разъезжаются по версиям и шаблонам title.
- Общая медиатека может давать одинаковые URL изображений между сайтами проверяйте alt и контекст.
Хак на заметку. Сделайте инвентарь «сайт сети → primary domain → GSC property → sitemap URL → SEO plugin config owner». Если owner пустой это P0.
hreflang между сайтами сети
Google описывает локализованные версии как взаимные аннотации. В Multisite самая частая поломка каждый сайт генерирует hreflang из своего «локального» списка и пропускает self-reference или x-default.
- Ведите центральный реестр URL-пар (или ID постов) для всех языков/регионов.
- Генерируйте hreflang из одного источника правды (кастомный endpoint или проверенный WPML/Polylang-процесс).
- Проверяйте выборку в Rich Results / URL Inspection после деплоя шаблона.
- Не ставьте hreflang на noindex или на страницы с другим canonical.
Индексация sitemap и GSC
Каждый публичный сайт сети должен иметь собственную property в Search Console и собственный sitemap index. Типичные сбои
- Sitemap главного сайта включает URL дочерних блогов.
- robots.txt сети одинаковый для всех хотя политики индексации разные.
- Canonical указывает на «главный» сайт сети для локализованных страниц.
- Кросс-постинг контента без canonical/rewrites создаёт дубли между сайтами.
| Риск | Симптом | Что сделать |
|---|---|---|
| Смешанные структуры | Часть языков в path, часть на доменах | Зафиксировать одну политику + карту редиректов |
| Broken hreflang | Нет взаимности / x-default | Центральный реестр URL и тесты выборки |
| Sitemap leak | Чужие хосты в sitemap | Отдельный sitemap index на сайт |
| Thin franchise | Почти одинаковые городские лендинги | Уникальные блоки + локальные данные или consolidation |
Быстрый чек-лист Multisite SEO
Чек-лист на заметку (15–20 минут). Сделайте сейчас
- Список всех публичных сайтов сети и их primary URL.
- Проверка robots.txt и meta robots на каждом хосте.
- Sitemap index содержит только свой хост.
- Выборка 10 URL с hreflang взаимность и self.
- Canonical не «сливает» локали на главный сайт без причины.
- Отдельные GSC property и проверка Coverage/Pages.
- Staging/dev сайты сети закрыты от индекса.
Типичные ошибки
- Включать Multisite «для удобства» когда нужен один сайт с WPML.
- Копировать контент между сайтами сети 1-в-1 без уникальной ценности.
- Обновлять SEO-плагин только на главном сайте.
- Игнорировать domain mapping cookies и смешанный HTTP/HTTPS в старой сети.
- Не иметь владельца SEO-конфигурации на каждый сайт.
Заключение
Multisite SEO работает когда структура сети, hreflang и индексация управляются как продукт а не как побочный эффект админки. Иначе сеть масштабирует ошибки быстрее контента.
Нужен аудит сети сайтов команда SEO-Studio поможет в рамках SEO-услуг.