Zarządzasz kilkoma markami, oddziałami, domenami, rynkami zagranicznymi lub dużą liczbą landing pages?
Zamiast rozwijać każdą stronę jako osobny, niezależny projekt, w odpowiednich przypadkach można zbudować sieć serwisów WordPress Multisite zarządzaną w ramach jednej architektury.
W Webtom.pl projektujemy i wdrażamy WordPress Multisite dla firm i organizacji, które potrzebują uporządkować większą liczbę stron, zachować wspólne standardy technologiczne i jednocześnie umożliwić poszczególnym zespołom zarządzanie własnymi treściami.
Możemy odpowiadać za cały proces:
Nie zakładamy z góry, że Multisite będzie najlepszą odpowiedzią. Najpierw analizujemy sposób działania organizacji i dopiero na tej podstawie rekomendujemy architekturę.
Opowiedz nam, ile serwisów obsługujesz, jakimi domenami zarządzasz i w jaki sposób poszczególne zespoły powinny pracować z treścią.
Multisite rozważamy przede wszystkim wtedy, gdy wiele stron ma funkcjonować jako część jednego większego ekosystemu.
Może dotyczyć między innymi:
Kluczowym pytaniem nie jest jednak wyłącznie liczba stron.
Znacznie ważniejsze jest to, ile elementów serwisy powinny współdzielić, a które muszą pozostać niezależne.
Przed uruchomieniem środowiska ustalamy między innymi:
Dzięki temu Multisite nie powstaje jako przypadkowo skonfigurowana instalacja WordPress, ale jako architektura zaprojektowana pod rzeczywisty model organizacji.
Przygotowujemy środowisko techniczne i konfigurujemy sieć zgodnie z przyjętą architekturą.
Zakres może obejmować między innymi:
WordPress posiada centralny panel Network Admin, z którego superadministrator może zarządzać witrynami, użytkownikami, motywami, wtyczkami i aktualizacjami całej sieci.
W przypadku firmowych sieci Multisite szczególnie ważne jest zaplanowanie wspólnej warstwy technologicznej.
Możemy przygotować:
Dzięki temu kolejne serwisy nie muszą być za każdym razem budowane od początku.
Jednocześnie zakres swobody można dostosować do organizacji – część komponentów może być ściśle kontrolowana centralnie, a inne mogą pozostawać konfigurowalne przez lokalnych redaktorów.
Jeżeli projekt wymaga bardziej zaawansowanych funkcji, możemy realizować również dedykowane programowanie WordPress.
Jednym z najważniejszych elementów projektu Multisite jest odpowiedź na pytanie: kto powinien móc zmieniać co?
Centrala może odpowiadać za:
Lokalny zespół może natomiast otrzymać dostęp wyłącznie do przypisanej mu witryny i zarządzać np.:
Nie każda organizacja potrzebuje takiego samego modelu uprawnień.
Dlatego role i odpowiedzialności projektujemy przed wdrożeniem, zamiast ustalać je dopiero wtedy, gdy w systemie pracuje kilkudziesięciu redaktorów.
WordPress Multisite może być szczególnie użyteczny wtedy, gdy wiele stron powinno zachować wspólną tożsamość marki lub określone standardy wizualne.
Możemy przygotować jeden system komponentów wykorzystywany przez:
Przykładowo centrala może zdefiniować:
a lokalne serwisy wykorzystują je w swoich treściach.
Nie oznacza to, że wszystkie witryny muszą wyglądać identycznie.
Architektura może przewidywać:
przy zachowaniu wspólnego fundamentu technicznego.
Sieć nie musi oznaczać wyłącznie adresów typu:
albo:
Poszczególne witryny mogą również działać pod niezależnymi domenami, np.:
WordPress Multisite posiada natywne mechanizmy mapowania witryn sieci na osobne domeny. Samo wdrożenie wymaga jednak poprawnej konfiguracji WordPressa, DNS, serwera i certyfikatów SSL.
Dlatego strukturę domen ustalamy już na etapie projektowania architektury.
Multisite może być wykorzystany w projektach międzynarodowych, szczególnie wtedy, gdy poszczególne rynki mają:
Nie należy jednak utożsamiać Multisite automatycznie z systemem tłumaczeń.
W jednym projekcie właściwym rozwiązaniem może być:
Decyzja zależy od tego, czy poszczególne rynki są przede wszystkim wersjami językowymi tej samej strony, czy faktycznie osobnymi serwisami posiadającymi własną strukturę i proces zarządzania.
Firma może posiadać kilka lub kilkanaście stron WordPress rozwijanych przez lata jako osobne instalacje.
Z czasem pojawiają się wtedy problemy:
W odpowiednich projektach część takich serwisów można połączyć w jedną sieć Multisite.
Nie jest to jednak zwykłe „scalenie baz danych”.
Przed migracją analizujemy między innymi:
Nie każdy element z niezależnej instalacji można lub warto odwzorować 1:1.
Możemy przeanalizować, czy połączenie ich w Multisite rzeczywiście uprości zarządzanie, czy lepszym rozwiązaniem będzie pozostawienie osobnych instalacji.
Dobrze zaprojektowana architektura powinna uwzględniać nie tylko dzisiejszą liczbę stron.
Jeżeli firma planuje kolejne:
warto zaplanować powtarzalny proces ich uruchamiania.
Nowa witryna może wykorzystywać:
Nie oznacza to automatycznie, że uruchomienie każdej kolejnej strony będzie identycznym i całkowicie automatycznym procesem.
Jeżeli nowy rynek lub marka wymaga innych funkcji, projektu UX/UI czy integracji, zakres będzie odpowiednio większy.
Najważniejsze jest jednak to, że kolejny serwis powstaje na zaplanowanym fundamencie, a nie jako następna przypadkowa instalacja WordPressa.
Sieć stron często jest tylko jednym elementem większego środowiska IT.
Możemy integrować Multisite między innymi z:
Już na etapie architektury trzeba ustalić, czy dana integracja:
To szczególnie ważne w projektach, w których np. formularze z różnych krajów powinny trafiać do innych zespołów sprzedażowych lub oddziałów CRM.
WooCommerce może działać w środowisku Multisite, ale sposób wykorzystania go powinien wynikać z modelu biznesowego.
Przykładowo poszczególne witryny mogą posiadać własne sklepy i konfiguracje.
Jeżeli natomiast firma oczekuje:
nie należy zakładać, że Multisite zapewni takie mechanizmy automatycznie.
Takie wymagania mogą wymagać dodatkowej architektury, synchronizacji albo dedykowanej integracji.
Dlatego projekty Multisite + WooCommerce analizujemy jako system e-commerce, a nie wyłącznie konfigurację WordPressa.
W większej sieci stron trzeba zaplanować również sposób zbierania danych.
W zależności od organizacji mogą być potrzebne:
Architekturę analityczną warto ustalić razem ze strukturą witryn.
Dzięki temu kolejny serwis nie powstaje z przypadkowym zestawem tagów i konfiguracji, którego później nie da się łatwo porównać z pozostałymi rynkami.
Każda witryna działająca w sieci nadal powinna posiadać właściwie przygotowaną strukturę SEO.
Dotyczy to między innymi:
Centralna administracja WordPress nie oznacza, że wszystkie witryny powinny mieć identyczną strategię SEO.
W przypadku osobnych marek lub rynków każda strona może wymagać innej:
Dlatego architekturę techniczną budujemy tak, aby nie ograniczała późniejszego rozwoju widoczności poszczególnych serwisów.
W Multisite wiele stron współdzieli wspólną instalację.
Oznacza to, że aktualizacja:
może oddziaływać na większą część środowiska niż w pojedynczej stronie.
Dlatego przy rozbudowanej sieci szczególnie ważny jest uporządkowany proces zmian.
W ramach dalszej opieki możemy zapewnić:
Po uruchomieniu możemy przejąć również wsparcie techniczne WordPress dla całego środowiska.
Rozmawiamy o:
Na tym etapie weryfikujemy również, czy Multisite rzeczywiście jest właściwą architekturą.
Ustalamy:
Jeżeli projekt powstaje od początku, możemy przygotować wspólny system projektowy dla całej sieci.
Jeżeli strony już istnieją, analizujemy możliwość wykorzystania obecnego designu lub jego modernizacji.
Konfigurujemy sieć, domeny, środowisko techniczne, podstawowe role oraz strukturę poszczególnych witryn.
Budujemy wspólną warstwę technologiczną i komponenty zgodnie z ustaloną architekturą.
Podłączamy systemy zewnętrzne, formularze, analitykę i inne elementy wymagane w projekcie.
Jeżeli projekt zastępuje istniejące strony, przenosimy uzgodniony zakres danych i treści.
Ustawiamy między innymi:
Sprawdzamy:
Uruchamiamy sieć lub kolejne witryny zgodnie z uzgodnionym harmonogramem.
Po publikacji możemy rozwijać całą sieć i dodawać kolejne serwisy, komponenty oraz integracje.
WordPress Multisite wykorzystaliśmy między innymi w projekcie dla OKNO-POL. W ramach realizacji przygotowaliśmy jeden główny motyw WordPress, który stał się podstawą dla ponad 50 dedykowanych landing pages zarządzanych z jednego środowiska Multisite.
Treści wdrożyliśmy dla 9 wersji językowych, obejmujących m.in. język polski, angielski, niemiecki, francuski, włoski, niderlandzki, norweski, szwedzki i czeski. Projekt obejmował również autorski moduł Consent Mode V2 przygotowany dla środowiska Multisite.
To przykład sytuacji, w której wspólna architektura pozwala rozwijać dużą liczbę serwisów kampanijnych bez tworzenia kilkudziesięciu całkowicie niezależnych instalacji.
Nie zawsze.
Jeżeli kilka stron:
osobne instalacje mogą być rozwiązaniem prostszym i bezpieczniejszym organizacyjnie.
Dlatego przed rozpoczęciem projektu porównujemy: Multisite ↔ osobne instalacje WordPress pod kątem rzeczywistego modelu działania firmy.
Nie rekomendujemy Multisite tylko dlatego, że organizacja ma więcej niż jedną stronę.
Multisite przestaje być prostym projektem CMS, gdy pojawiają się integracje, migracje, role, wiele domen i procesy biznesowe.
Dlatego możemy przejąć projekt zarówno jako wyspecjalizowany zespół WordPress, jak i software house odpowiedzialny za bardziej rozbudowaną architekturę i integracje.
Projektujemy rozwiązanie pod strukturę organizacji.
Jeżeli potrzebny jest wspólny komponent, integracja lub dodatkowa funkcja, możemy przygotować ją jako element całego systemu.
Możemy zarówno wdrożyć gotowy design, jak i zaprojektować wspólny system interfejsu dla całej sieci.
Nie opieramy oferty wyłącznie na teoretycznej znajomości funkcji WordPressa.
Wdrożyliśmy środowisko obejmujące ponad 50 landing pages i 9 wersji językowych zarządzanych z wykorzystaniem Multisite.
Po uruchomieniu nie zostajesz z architekturą bez zespołu, który ją zna.
Możemy rozwijać:
Koszt wdrożenia nie zależy wyłącznie od liczby witryn działających w sieci.
Na zakres prac wpływają między innymi:
Przykładowo sieć 20 landing pages korzystających z jednego spójnego motywu może być prostsza niż 5 serwisów posiadających zupełnie inne funkcje i integracje.
Dlatego przed wyceną analizujemy przede wszystkim architekturę i stopień współdzielenia elementów pomiędzy witrynami.
Podeślij nam informacje o obecnych stronach, domenach, rynkach i sposobie zarządzania treścią. Sprawdzimy, czy Multisite będzie właściwym rozwiązaniem i które elementy trzeba uwzględnić w projekcie architektury.
Tak, jeżeli ich architektura i sposób działania pozwalają na sensowne połączenie. Przed migracją analizujemy motywy, wtyczki, treści, użytkowników, domeny, integracje i dedykowany kod. Nie zakładamy, że każdą istniejącą instalację można przenieść 1:1.
Tak. WordPress Multisite pozwala mapować poszczególne witryny na osobne domeny. Wymaga to odpowiedniej konfiguracji WordPressa, DNS, hostingu i certyfikatów SSL.
Tak. Role można zorganizować tak, aby użytkownik zarządzał przypisaną witryną bez dostępu do administracji całej sieci. Uprawnienia centralne pozostają po stronie administratora sieci.
Nie. Mogą korzystać ze wspólnego motywu i komponentów, ale jednocześnie posiadać różne treści, kolory, logotypy lub elementy przeznaczone dla konkretnego rynku albo marki.
Tak. Jedną z podstawowych funkcji administracji sieci jest możliwość dodawania kolejnych witryn.
Może być dobrym rozwiązaniem, szczególnie gdy poszczególne rynki mają własne domeny, treści, zespoły lub zakresy oferty. Nie w każdym projekcie Multisite jest jednak lepszy od klasycznej wielojęzyczności WordPress.
Tak, ale sposób organizacji sklepów i danych trzeba zaplanować indywidualnie. WooCommerce działający na poszczególnych witrynach nie oznacza automatycznie wspólnego katalogu, klientów czy zamówień dla całej sieci.
Tak. Zakres zależy od API systemów zewnętrznych i wymagań biznesowych. Integracja może działać centralnie albo różnić się pomiędzy poszczególnymi witrynami.
Jeżeli witryny korzystają z tego samego motywu lub komponentu, jego aktualizacja może wpływać na wiele stron jednocześnie. Dlatego zmiany powinny być wcześniej testowane i wdrażane w kontrolowany sposób.
Tak. Poszczególne witryny w sieci mogą posiadać własne treści. Zakres współdzielenia danych lub komponentów zależy od zaprojektowanej architektury.
Nie zawsze. Wybór zależy od tego, jak dużo elementów serwisy współdzielą, kto nimi zarządza, jak wyglądają integracje oraz czy wymagają niezależnych cykli rozwoju.
Tak. Możemy odpowiadać za aktualizacje, monitoring, backupy, środowisko testowe, naprawy, rozwój motywu, nowe komponenty i wdrażanie kolejnych witryn.
Termin zależy od liczby witryn, zakresu wspólnych komponentów, migracji, integracji, UX/UI oraz wymagań infrastrukturalnych. Wiarygodny harmonogram przygotowujemy po analizie architektury projektu.
Koszt zależy przede wszystkim od architektury, liczby typów witryn, zakresu wspólnych funkcji, migracji, integracji i sposobu zarządzania siecią. Sama liczba stron nie jest wystarczającą podstawą do wyceny.
Porozmawiajmy o Twoim projekcie!
Sławomir Woźniak
New Business | PL
Zobacz czym jest WordPress Multisite i kiedy warto go wdrożyć? Sprawdź, jak działa.
Czym jest staging WordPress i środowisko testowe? Sprawdź, jak bezpiecznie testować aktualizacje, WooCommerce, migracje i zmiany na stronie.
