
Migracja Joomla do Joomla 6 nie powinna być traktowana jak zwykła aktualizacja oprogramowania. W przypadku kilkuletniej strony firmowej, portalu lub sklepu mamy do czynienia z całym ekosystemem: szablonem, rozszerzeniami, własnymi modyfikacjami, strukturą menu, adresami URL, metadanymi i stronami, które przez lata zdobywały widoczność w Google. Można więc przeprowadzić aktualizację poprawnie od strony technicznej, a jednocześnie stracić część efektów wcześniejszego pozycjonowania. Dobra migracja Joomla powinna zachować nie tylko treść i funkcjonalność witryny, ale również jej historię zapisaną w adresach URL, linkowaniu i indeksie wyszukiwarki.
Aktualizacja Joomla czy migracja strony?
Na początku warto rozróżnić dwa pojęcia, które często są używane zamiennie. Aktualizacja Joomla oznacza przede wszystkim zmianę wersji systemu przy zachowaniu obecnej strony, jej struktury i funkcjonalności. Migracja jest pojęciem szerszym. Może obejmować zmianę głównej wersji CMS, przebudowę szablonu, wymianę rozszerzeń, zmianę serwera, uporządkowanie bazy danych, modyfikację struktury menu, a czasem również zmianę adresów URL.
To rozróżnienie ma duże znaczenie dla SEO. Jeżeli po przejściu na Joomla 6 podstrona dostępna wcześniej pod adresem:
example.pl/oferta/tworzenie-stron.html
pozostaje dokładnie pod tym samym adresem, wyszukiwarka nie musi poznawać jej od nowa. Jeżeli jednak po modernizacji otrzymuje adres:
example.pl/tworzenie-stron
dla Google są to dwa różne URL-e. W takim przypadku sam fakt, że na nowej stronie znajduje się identyczna treść, nie rozwiązuje problemu. Stary adres musi zostać prawidłowo powiązany z nowym.
Najbezpieczniejsza migracja to taka, podczas której nie zmienia się bez potrzeby elementów już działających poprawnie. Jeśli dotychczasowe adresy są logiczne, zaindeksowane i posiadają linki zewnętrzne, nie ma powodu zmieniać ich tylko dlatego, że nowa wersja Joomla umożliwia stworzenie krótszej struktury.
Co trzeba sprawdzić przed migracją Joomla?
Profesjonalna migracja zaczyna się przed wykonaniem pierwszej aktualizacji. Najpierw należy poznać istniejącą stronę. W przypadku prostego serwisu firmowego może to zająć niewiele czasu, ale wieloletnia Joomla potrafi zawierać pozostałości po rozszerzeniach instalowanych kilka lat wcześniej, nadpisania szablonu, niestandardowe moduły i kod, którego obecny właściciel strony nie jest nawet świadomy.
Przed rozpoczęciem prac warto zinwentaryzować między innymi:
- aktualną wersję Joomla,
- wersję PHP i rodzaj bazy danych,
- zainstalowane komponenty, moduły i pluginy,
- używany szablon i jego nadpisania,
- własne modyfikacje kodu,
- strukturę menu i kategorie artykułów,
- konta użytkowników oraz poziomy dostępu,
- formularze, wyszukiwarkę, system komentarzy i inne funkcje dodatkowe,
- adresy URL znajdujące się w indeksie Google,
- podstrony generujące ruch organiczny,
- strony posiadające wartościowe linki zewnętrzne,
- obecne przekierowania,
- pliki robots.txt i .htaccess,
- mapę witryny, dane strukturalne i znaczniki canonical.
Taka lista pozwala odpowiedzieć na znacznie ważniejsze pytanie niż "czy Joomla da się zaktualizować?". Trzeba ustalić, co podczas aktualizacji może przestać działać i co musi zostać zachowane.
Znaczenie wersji wyjściowej Joomla
Sposób przejścia do Joomla 6 zależy przede wszystkim od tego, na jakiej wersji działa obecna witryna. Inaczej wygląda modernizacja stosunkowo świeżej Joomla 5.4, a inaczej serwisu zbudowanego wiele lat temu na Joomla 3.
| Wersja wyjściowa | Charakter prac | Główne ryzyko |
|---|---|---|
| Joomla 5.4 | Bezpośrednie przygotowanie do Joomla 6 | Niezgodne rozszerzenia i własny kod |
| Joomla 5.x | Najpierw aktualizacja bieżącej linii 5.x | Stare rozszerzenia i zależności PHP |
| Joomla 4 | Migracja etapowa przez Joomla 5 | Szablon, nadpisania i rozszerzenia |
| Joomla 3 | Wieloetapowa modernizacja | Duża liczba niekompatybilnych elementów |
W starszych serwisach nie należy traktować Joomla 6 jako pojedynczego pakietu, który po prostu zastąpi dawną wersję. Kolejne generacje systemu wprowadzały zmiany w API, obsłudze rozszerzeń, wymaganiach PHP i sposobie działania szablonów. Dlatego modernizacja Joomla 3 może w praktyce oznaczać kilka osobnych etapów wraz z testami po każdym z nich.
Czasami bardziej racjonalne okazuje się przeniesienie danych i funkcjonalności do przygotowanej od nowa instalacji niż próba zachowania każdego elementu starego systemu. Nie oznacza to jednak budowania serwisu "od zera" z punktu widzenia SEO. Adresy, treści i dotychczasowe sygnały wyszukiwarki nadal powinny zostać uwzględnione w planie migracji.
Wymagania techniczne Joomla 6
Przed modernizacją trzeba sprawdzić nie tylko sam CMS, ale również środowisko serwera. Joomla 6.x wymaga PHP co najmniej w wersji 8.3. Oficjalna dokumentacja jako wersję rekomendowaną wskazuje PHP 8.4. Dla MySQL minimalna obsługiwana wersja to 8.0.13, a w przypadku MariaDB jako wspierana wskazywana jest wersja 10.6 lub nowsza. Zalecany limit pamięci PHP wynosi przynajmniej 256 MB.
| Element | Joomla 6.x |
|---|---|
| PHP | minimum 8.3, rekomendowane 8.4 |
| MySQL | minimum 8.0.13 |
| MariaDB | wspierane od 10.6 |
| PostgreSQL | wspierane od 14.0 |
| PHP memory_limit | zalecane przynajmniej 256 MB |
Wymagania CMS to jednak dopiero pierwszy poziom kontroli. Trzeba również zweryfikować, czy z wybraną wersją PHP współpracują wszystkie rozszerzenia. Strona może spełniać wymagania Joomla, a mimo to przestać działać z powodu jednego starego komponentu, pluginu lub fragmentu własnego kodu.
Pluginy zgodności przy przejściu z Joomla 5.4
Szczególnej uwagi wymaga migracja Joomla 5.4 do Joomla 6. W Joomla 5.4 dostępny jest plugin "Behaviour - Backward Compatibility 6", którego zadaniem jest ułatwienie przejścia do Joomla 6. Przed wykonaniem aktualizacji powinien być zainstalowany i włączony.
Jednocześnie starszy plugin "Behaviour - Backward Compatibility", służący zgodności Joomla 5 ze starszym kodem Joomla 4, powinien zostać przed migracją do Joomla 6 wyłączony. Jest to jednocześnie bardzo dobry test. Jeżeli po jego wyłączeniu Joomla 5.4 przestaje działać, oznacza to, że któryś element serwisu nadal korzysta ze starego mechanizmu zgodności. Problem najlepiej znaleźć i usunąć jeszcze przed przejściem na Joomla 6.
Rozszerzenia, szablon i własne modyfikacje
Sam rdzeń Joomla jest zwykle najbardziej przewidywalnym elementem całej operacji. Problemy zaczynają się w otoczeniu CMS. Wieloletnia strona może zawierać kilkadziesiąt dodatkowych rozszerzeń, z których część jest aktywnie używana, część działa tylko w określonych miejscach, a część pozostała po dawnych wersjach witryny.
Przed migracją każde rozszerzenie warto przypisać do jednej z czterech grup:
- pozostaje - jest potrzebne i posiada wersję zgodną z Joomla 6,
- aktualizujemy - jest potrzebne, ale wymaga nowszej wersji,
- zastępujemy - funkcja pozostaje potrzebna, ale dotychczasowe rozszerzenie nie jest już rozwijane,
- usuwamy - element jest zbędny i nie powinien być przenoszony do nowego systemu.
To dobry moment na techniczne porządki. Migracja nie powinna polegać na automatycznym przeniesieniu wszystkich dodatków tylko dlatego, że znajdują się w starej instalacji.
Szablon może być większym problemem niż Joomla
W przypadku starszych witryn największą przeszkodą bywa szablon. Dotyczy to szczególnie konstrukcji opartych na dawnych frameworkach szablonowych albo zawierających dużą liczbę override'ów, czyli własnych wersji widoków komponentów i modułów.
Jeżeli szablon nie jest zgodny z nową Joomla, trzeba zdecydować, czy zostanie zaktualizowany, przebudowany czy zastąpiony. Przy okazji warto zweryfikować, czy dawne nadpisania są jeszcze potrzebne. Kod dodany kilka lat wcześniej w celu rozwiązania konkretnego ograniczenia Joomla może być obecnie zbędny, ponieważ nowszy CMS obsługuje daną funkcję natywnie.
Dlaczego migrację wykonuje się na kopii strony?
Aktualizowanie rozbudowanej strony produkcyjnej bezpośrednio "na żywo" jest niepotrzebnym ryzykiem. Prawidłowa procedura zakłada wykonanie pełnej kopii plików i bazy danych, a następnie uruchomienie środowiska testowego.
Kopia testowa pozwala sprawdzić migrację bez presji czasu. Można zmieniać PHP, usuwać niezgodne rozszerzenia, modyfikować szablon, analizować błędy i powtarzać proces bez wpływu na działającą witrynę.
Środowisko testowe powinno być jednocześnie zabezpieczone przed przypadkową indeksacją. Robocza kopia strony dostępna publicznie pod subdomeną może zostać znaleziona przez wyszukiwarkę. Powstają wtedy duplikaty artykułów i podstron ofertowych. Sam plik robots.txt nie zawsze jest wystarczającym sposobem ochrony środowiska developerskiego. Znacznie pewniejszym rozwiązaniem jest ograniczenie dostępu do strony, na przykład autoryzacją na poziomie serwera.
Adresy URL - najważniejszy element migracji SEO
Jeżeli celem jest zachowanie widoczności w Google, przed uruchomieniem nowej wersji trzeba stworzyć listę dotychczasowych adresów URL. Szczególną wartość mają strony, które:
- są zaindeksowane w Google,
- generują ruch organiczny,
- zajmują wysokie pozycje na istotne frazy,
- mają linki prowadzące z innych serwisów,
- znajdują się w menu lub linkowaniu wewnętrznym,
- od wielu lat funkcjonują pod jednym adresem.
Najprostszym rozwiązaniem jest zachowanie dotychczasowych URL-i. Nie zawsze jest to jednak możliwe. Zmiana routera komponentu, struktury menu, kategorii albo sposobu generowania aliasów może spowodować zmianę adresu mimo zachowania tego samego artykułu.
Dlatego przed migracją przydatna jest mapa starych i nowych adresów.
| Stary URL | Nowy URL | Działanie |
|---|---|---|
| /uslugi.html | /uslugi.html | bez zmian |
| /oferta/strony-www.html | /tworzenie-stron | 301 |
| /stara-usluga.html | brak odpowiednika | 404 lub 410 |
Tak przygotowana tabela staje się jednym z najważniejszych dokumentów całej migracji. Pozwala przetestować stronę automatycznie i wykryć URL-e, które po zmianie CMS zwracają błąd 404 albo prowadzą w niewłaściwe miejsce.
Kiedy potrzebne są przekierowania 301?
Jeżeli adres podstrony zmienia się trwale, stary URL powinien zostać przekierowany na najbardziej odpowiadający mu nowy adres. Do trwałych zmian Google rekomenduje przekierowania wykonywane po stronie serwera, między innymi kodem 301.
Nie wystarczy przekierować wszystkich nieistniejących podstron na stronę główną. Jeżeli dawny artykuł o projektowaniu sklepów internetowych ma nowy odpowiednik, powinien prowadzić właśnie do niego. Przekierowanie powinno zachować znaczenie starej strony.
Najlepsza relacja wygląda tak:
stary konkretny URL - 301 - nowy konkretny URL
Należy również unikać łańcuchów przekierowań:
adres A - 301 - adres B - 301 - adres C
Jeżeli ostatecznym adresem jest C, optymalnym rozwiązaniem jest bezpośrednie przekierowanie A do C. Zmniejsza to liczbę zapytań i upraszcza interpretację struktury zarówno przeglądarce, jak i robotom wyszukiwarki.
Canonical, robots.txt i mapa strony
Migracja Joomla nie kończy się na tym, że podstrony "otwierają się". Po zmianie CMS trzeba zweryfikować również elementy znajdujące się w kodzie oraz konfiguracji serwera.
Canonical
Każda ważna podstrona powinna wskazywać właściwy adres kanoniczny. Szczególnie niebezpieczna jest sytuacja, w której po przeniesieniu witryny nowa podstrona nadal posiada canonical prowadzący do starego URL-u, domeny testowej albo innego wariantu adresu.
Robots.txt i noindex
Jednym z najbardziej kosztownych błędów jest pozostawienie po wdrożeniu zabezpieczeń używanych na środowisku testowym. Nowa strona może działać perfekcyjnie dla użytkownika, a jednocześnie zawierać dyrektywę noindex albo blokadę istotnych zasobów w robots.txt.
Mapa witryny
Po migracji sitemap powinna zawierać aktualne, kanoniczne URL-e zwracające kod 200. Nie powinno się pozostawiać w niej adresów przekierowanych, stron błędów ani URL-i należących do wersji testowej.
Jeżeli podczas modernizacji URL-e uległy zmianie, nową mapę warto przesłać w Google Search Console. Ułatwia to wyszukiwarce poznanie aktualnej struktury serwisu.
Treść, title i description po migracji
Nowy szablon często zachęca do jednoczesnej przebudowy całej zawartości serwisu. Z punktu widzenia marketingowego może mieć to sens, ale z punktu widzenia migracji SEO warto zachować ostrożność.
Jeżeli podstrona zajmuje wysoką pozycję, zmienianie jednocześnie CMS, URL-u, tekstu, tytułu, nagłówków i linkowania utrudnia późniejszą ocenę przyczyn ewentualnego spadku. Google w swoich zaleceniach dotyczących migracji serwisów wskazuje, aby w miarę możliwości rozdzielać duże zmiany i nie wykonywać wszystkiego jednocześnie.
Przy podstronach o dobrej widoczności warto więc zachować przynajmniej:
- główny temat strony,
- najważniejszą zawartość tekstową,
- title, jeśli działa skutecznie,
- hierarchię głównych nagłówków,
- ważne linki wewnętrzne,
- adres URL albo odpowiednie przekierowanie.
Rozbudowę treści można wykonać również po ustabilizowaniu migracji. Dzięki temu łatwiej rozdzielić efekty zmiany technologicznej od efektów zmian redakcyjnych.
Wydajność nowej Joomla
Migracja do Joomla 6 jest dobrą okazją do poprawienia wydajności serwisu, ale nowa wersja CMS sama w sobie nie gwarantuje szybkiej strony. Na czas ładowania nadal wpływają serwer, szablon, rozszerzenia, obrazy, fonty, liczba skryptów JavaScript, arkusze CSS, zewnętrzne usługi i konfiguracja cache.
Po migracji warto porównać stronę starą i nową. Szczególną uwagę należy zwrócić na:
- czas odpowiedzi serwera,
- wielkość dokumentu i zasobów,
- liczbę zapytań HTTP,
- obrazy wyświetlane powyżej pierwszego ekranu,
- ładowanie fontów,
- nieużywany CSS i JavaScript,
- działanie cache,
- Core Web Vitals.
Nowoczesny CMS pracujący na aktualnym PHP daje dobre podstawy techniczne, ale końcowy wynik zależy od sposobu wykonania całej strony.
Co sprawdzić w dniu uruchomienia nowej strony?
Po zakończeniu testów przychodzi moment przełączenia witryny produkcyjnej. Nawet jeżeli środowisko testowe działa poprawnie, konieczna jest jeszcze kontrola nowego serwisu już pod właściwą domeną.
Bezpośrednio po wdrożeniu warto sprawdzić między innymi:
- stronę główną i najważniejsze podstrony,
- menu główne i menu mobilne,
- formularze kontaktowe,
- logowanie i funkcje użytkowników,
- wyszukiwarkę wewnętrzną,
- adresy obrazów i plików do pobrania,
- certyfikat SSL,
- przekierowanie HTTP do HTTPS,
- wariant www lub bez www,
- kody odpowiedzi 200, 301 i 404,
- canonical,
- robots.txt,
- meta robots,
- sitemap,
- kod Google Analytics lub innego systemu analitycznego,
- weryfikację Google Search Console,
- dane strukturalne, jeśli były wykorzystywane wcześniej.
W przypadku większej witryny ręczne otwarcie kilku podstron nie wystarcza. Po wdrożeniu warto wykonać pełne crawlowanie serwisu i porównać wyniki z wcześniej zapisaną listą URL-i.
Co kontrolować po migracji?
Pierwsze uruchomienie strony nie kończy migracji. Przez kolejne dni i tygodnie należy obserwować, jak nową wersję serwisu interpretuje Google. Przy większych zmianach przejściowe wahania widoczności mogą być naturalne, ponieważ wyszukiwarka musi ponownie odwiedzić i przetworzyć strony.
Do najważniejszych elementów kontroli należą:
- błędy indeksowania w Google Search Console,
- adresy 404 pojawiające się po migracji,
- poprawność przekierowań,
- liczba zaindeksowanych stron,
- wybrane przez Google adresy kanoniczne,
- ruch organiczny,
- wyświetlenia i kliknięcia ważnych podstron,
- logi serwera,
- wydajność witryny,
- błędy PHP i problemy generowane przez rozszerzenia.
Jeżeli adresy zostały zmienione, przekierowań nie należy usuwać po kilku tygodniach. Google zaleca utrzymywanie przekierowań związanych z migracją przez możliwie długi czas, generalnie przynajmniej przez rok. W praktyce, jeśli nie istnieje techniczny powód ich usunięcia, wartościowe stare URL-e można przekierowywać bezterminowo.
Najczęstsze błędy przy migracji Joomla
1. Aktualizacja bez pełnej kopii
Kopia wykonana kilka tygodni wcześniej nie jest kopią migracyjną. Bezpośrednio przed rozpoczęciem prac powinny zostać zabezpieczone zarówno pliki, jak i aktualna baza danych.
2. Sprawdzanie tylko zgodności Joomla
To, że serwer spełnia wymagania Joomla 6, nie oznacza jeszcze, że wszystkie komponenty i pluginy są gotowe na Joomla 6 oraz wybraną wersję PHP.
3. Jednoczesna zmiana wszystkich adresów
Krótszy URL nie jest automatycznie lepszy od starego adresu. Jeśli istniejący URL ma historię, linki i wysoką pozycję, jego zmiana powinna mieć konkretny powód.
4. Przekierowanie wszystkich błędów na stronę główną
Każda stara podstrona powinna prowadzić do swojego rzeczywistego następcy. Jeżeli odpowiednika nie ma, prawidłowy kod 404 lub 410 może być lepszym rozwiązaniem niż sztuczne przekierowanie do strony głównej.
5. Pozostawienie noindex po testach
Jest to jeden z tych błędów, których użytkownik może długo nie zauważyć. Strona działa, można ją odwiedzać, ale robot otrzymuje informację, że nie powinna znajdować się w indeksie.
6. Usunięcie starych artykułów tylko dlatego, że wyglądają na nieaktualne
Przed usunięciem podstrony trzeba sprawdzić jej ruch, widoczność i linki. Tekst, który z punktu widzenia właściciela serwisu jest mało istotny, może być jedną z najlepiej widocznych stron całej domeny.
7. Brak testu wersji mobilnej
Migracja połączona z wymianą szablonu może powodować błędy niewidoczne na komputerze: przesunięte menu, niewłaściwe szerokości tabel, elementy wychodzące poza ekran czy problemy z formularzami.
8. Założenie, że brak błędu oznacza sukces
Strona może zwracać kod 200 i wyglądać poprawnie, a jednocześnie mieć zmienione canonicale, brakujące metadane, błędne przekierowania albo kilkaset nowych adresów tworzonych przez niewłaściwą konfigurację menu. Dlatego migrację trzeba oceniać na kilku poziomach jednocześnie.
Checklista migracji Joomla do Joomla 6
| Etap | Co sprawdzić? |
|---|---|
| 1. Audyt | Joomla, PHP, baza, rozszerzenia, szablon, własny kod |
| 2. SEO przed migracją | URL-e, ruch, pozycje, linki, canonicale, sitemap |
| 3. Backup | Pełna kopia plików i bazy danych |
| 4. Środowisko testowe | Ochrona przed indeksacją i test aktualizacji |
| 5. Kompatybilność | Komponenty, moduły, pluginy, szablon i override'y |
| 6. Migracja | Aktualizacja systemu i test wszystkich funkcji |
| 7. URL-e | Porównanie starej i nowej struktury |
| 8. Przekierowania | 301 dla wszystkich istotnych zmienionych adresów |
| 9. Indeksowanie | robots.txt, noindex, canonical i sitemap |
| 10. Kontrola | Crawl, Search Console, logi, ruch i błędy 404 |
Migracja Joomla do Joomla 6 jest więc czymś więcej niż wymianą plików CMS. W dobrze utrzymanej stronie trzeba zachować ciągłość działania systemu, funkcjonalności dla użytkowników i sygnałów, które przez lata zgromadziła domena. Im starszy i bardziej rozbudowany serwis, tym większe znaczenie ma etap przygotowania.
Najlepszym rezultatem migracji jest sytuacja, w której użytkownik widzi szybszą i nowocześniejszą stronę, administrator otrzymuje aktualny i bezpieczniejszy system, a wyszukiwarka nadal rozpoznaje serwis, jego treści i najważniejsze adresy. Dopiero wtedy można mówić o rzeczywistej modernizacji, a nie tylko o zmianie numeru wersji Joomla.

Komentarze