Коли 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-послуг.