W regionie DACH (Niemcy, Austria, Szwajcaria) TYPO3 nigdy nie był przypadkowym wyborem. Urzędy, uczelnie, firmy przemysłowe z wieloma domenami i duże związki branżowe wybierały go od początku lat dwutysięcznych, bo rozwiązywał dokładnie to, czego klasyczny WordPress długo nie potrafił: porządną wielojęzyczność, szczegółowe uprawnienia, multi-site i wiele drzew stron od razu po instalacji. W 2026 roku rynek wygląda inaczej. Ten tekst to uczciwe spojrzenie na to, kiedy migracja z TYPO3 do WordPressa ma sens ekonomiczny i redakcyjny, a kiedy nie. Nie jest neutralny. Jest polemiczny w dobrym sensie: z wyraźnym stanowiskiem i faktami, które da się sprawdzić.
W skrócie
- TYPO3 12 LTS jest dostępny od 4 października 2023 roku, TYPO3 13 to aktywna linia rozwojowa, projekt żyje.
- WordPress 6.7 i nowsze to punkt odniesienia na 2026 rok i według W3Techs napędza około 43 procent wszystkich stron na świecie.
- Edytor blokowy istnieje od WordPressa 5.0 z grudnia 2018 roku, REST API od WordPressa 4.7 z grudnia 2016 roku.
- Multi-site, wiele domen i wielojęzyczność to w TYPO3 funkcje rdzenia, a w WordPressie kwestia Multisite oraz Polylang lub WPML.
- Migracja nie opłaca się zawsze. Opłaca się wtedy, gdy dostępność specjalistów, wygoda redakcji i szybkość frontendu ważą więcej niż techniczny profil TYPO3.
W czym TYPO3 jest lepsze od WordPressa?
TYPO3 urósł w Niemczech, Austrii i Szwajcarii z trzech powodów. Po pierwsze, wcześnie dostarczył model wielojęzyczności, który nie potrzebował wtyczki. Jedna strona, kilka wersji językowych, jasne powiązania tłumaczeń: w 2010 roku w WordPressie było to nierealne. Po drugie, TYPO3 obsługuje multi-site i wiele domen w rdzeniu. Jedna instalacja, kilka drzew stron, kilka domen, oddzielne redakcje z oddzielnymi uprawnieniami. Po trzecie, system ról i uprawnień jest na tyle szczegółowy, że odwzorowuje wewnętrzne procesy akceptacji w urzędach, na uczelniach i w koncernach przemysłowych, łącznie z obszarami roboczymi (workspaces) dla nieopublikowanych wersji.
Właśnie w tych segmentach TYPO3 stał się w DACH duży. Uczelnie z wydziałami, samorządy z portalami dla mieszkańców, koncerny z portalem grupy i spółkami zależnymi, niemieckie kraje związkowe z ministerstwami. Stowarzyszenie TYPO3 Association z siedzibą w Szwajcarii skupia ten rynek od 2004 roku i daje stabilność, która ma znaczenie dla zamawiających publicznych. Kto w 2010 roku cyfryzował niemieckie starostwo powiatowe, trudno omijał TYPO3.
Ta historyczna przewaga jest prawdziwa i żadna uczciwa dyskusja jej nie pomija. Nie jest jednak całą historią na 2026 rok.
Jak zmienił się WordPress od czasu Gutenberga i REST API?
W grudniu 2018 roku ukazał się WordPress 5.0 z edytorem blokowym, wewnętrznie nazywanym Gutenbergiem. To nie była kosmetyka, tylko przesunięcie modelu redakcyjnego. Od tamtej pory strony składa się z bloków, wzorce bloków pozwalają na wielokrotnie używane układy, a pełna edycja witryny, dostępna od WordPressa 5.9 ze stycznia 2022 roku, rozszerza tę ideę na szablony, nagłówki i stopki. Efekt da się zmierzyć: zespoły redakcyjne bez zaplecza programistycznego publikują dziś same nawet złożone układy.
Dwa lata wcześniej, w grudniu 2016 roku, WordPress 4.7 włączył REST API do rdzenia. Od tego momentu WordPress jest pełnoprawnym CMS-em headless. Frontendy w Astro, aplikacje w Next.js i natywne aplikacje mobilne pobierają treści przez to samo API. TYPO3 ma podobną historię w postaci Headless TYPO3, ale ekosystem frameworków frontendowych, które od ręki rozmawiają z WordPressem, jest o rzędy wielkości szerszy.
Równolegle udział w rynku dalej przesuwał się na korzyść WordPressa. Często cytowane około 43 procent wszystkich stron na świecie pochodzi z W3Techs i potwierdza je Automattic w oficjalnych materiałach. Ta liczba to nie tylko statystyka, ale też wskaźnik dostępności ludzi. W Berlinie, Monachium, Wiedniu, Zurychu, Hamburgu i Kolonii na każde ogłoszenie dla programisty TYPO3 przypada kilku kandydatów z WordPressa. Kto w 2026 roku szuka seniora TYPO3, musi szukać dłużej, płacić więcej i godzić się na dłuższe okresy wypowiedzenia niż przy WordPressie. To nie ocena jakości, tylko kwestia dostępności na rynku.
Do tego dochodzi tempo, w jakim ekosystem WordPressa reaguje na nowe standardy. WCAG 2.2, BFSG, NIS2, DORA, Core Web Vitals: w ostatnich latach wszystko to dało wtyczki, motywy i gotowe wzorce dobrych praktyk, które w TYPO3 co prawda istnieją, ale rzadko są równie dojrzałe. Przykładem jest popularność motywów gotowych na WCAG 2.2 albo głębokość integracji z Cloudflare Workers. Dokładniej o warstwie edge piszemy w artykule o Cloudflare Workers dla WordPressa i WooCommerce.
Kiedy migracja z TYPO3 do WordPressa się opłaca
Migracja z TYPO3 do WordPressa nie powinna wynikać z mody, tylko z reguły decyzyjnej. W WPPoland stosujemy pięć kryteriów. Jeśli spełnione są co najmniej trzy, migracja jest rozsądną ekonomicznie odpowiedzią.
Po pierwsze, zespół redakcyjny nie jest blisko programistów. Jeśli treści trafiają dziś do agencji jako zgłoszenia, bo potrzebne są zmiany w TypoScripcie, kosztuje to czas i pieniądze. WordPress z edytorem blokowym i dobrze skonfigurowanymi wzorcami bloków wyraźnie tę zależność zmniejsza.
Po drugie, serwis żyje z content marketingu. Blog, baza wiedzy, white papery, webinary, studia przypadków: WordPress pozwala to wszystko publikować częściej. Kto publikuje więcej niż dwa porządne materiały tygodniowo, odczuje korzyść z WordPressa w codziennej pracy.
Po trzecie, wydajność frontendu jest pod presją. Core Web Vitals to czynnik rankingowy, a ekosystem WordPressa zbudował największy zestaw rozwiązań edge, cache i build. Kto celuje w 100 na 100, znajdzie w świecie WordPressa więcej gotowych elementów niż w TYPO3.
Po czwarte, dostępność specjalistów ogranicza projekt. Jeśli szukanie seniorów TYPO3 trwa kilka miesięcy, a stawki godzinowe są wyraźnie powyżej średniej dla WordPressa, to sygnał ekonomiczny. Uczciwe spojrzenie na standardy nearshore w projektach dla DACH znajdziesz w naszym tekście o seniorach IT z Polski.
Po piąte, docelowa architektura jest headless. Kto i tak przechodzi na nowoczesny frontend w Astro albo Next.js, w ekosystemie WordPressa ma więcej i dojrzalszych mostów. Nasz artykuł filarowy o headless WordPressie jako usłudze opisuje ten model szczegółowo.
Kiedy lepiej zostać przy TYPO3?
Polemika bez kontrargumentów to marketing, a nie doradztwo. Są cztery jasne przypadki, w których TYPO3 pozostaje właściwym wyborem, a projekt migracji byłby nieproporcjonalny.
Po pierwsze, serwis został określony w zamówieniu publicznym, które wprost wymaga TYPO3, na przykład w umowach ramowych niemieckich krajów związkowych. Żądanie migracji wbrew umowie jest nieuczciwe biznesowo.
Po drugie, wewnętrzny zespół jest głęboko wyszkolony w TYPO3, na stałe panuje nad obszarami roboczymi, procesami i wieloma drzewami stron i pracuje dzięki temu w dobrym tempie. Wtedy migracja spala wewnętrzną wiedzę w zamian za niejasną wartość dodaną.
Po trzecie, wielojęzyczność jest bardzo złożona, na przykład osiem lub więcej języków, treści wspólne dla kilku języków, warianty regionalne i układ wielodzierżawczy rozpięty na wiele domen. WordPress poradzi sobie z tym przez Polylang albo WPML, ale złożoność nie zniknie, tylko się przeniesie.
Po czwarte, własna logika Extbase jest mocno spleciona z procesami merytorycznymi, na przykład w portalach uczelni z katalogami modułów albo w systemach urzędowych do obsługi spraw. Odbudowa tej logiki w WordPressie może kosztować więcej niż dalsze utrzymanie TYPO3.
Jeśli żaden z tych przypadków nie zachodzi, a przeważają kryteria migracji, pozostaje pytanie o ścieżkę.
Jak przeprowadzić migrację z TYPO3 do WordPressa w czterech etapach
Migracje z TYPO3 do WordPressa dzielimy na cztery etapy. Zajmują różną ilość czasu, ale każdy musi się odbyć, inaczej pojawiają się błędy opisane w następnej sekcji.
Etap pierwszy to audyt. Tu w całości mapujemy obecny stan TYPO3. Jakie drzewa stron, jakie domeny, jakie wersje językowe, jakie rozszerzenia, jakie konfiguracje TypoScript, jakie procesy, jakie role, jakie zewnętrzne integracje. Audyt daje inwentarz z adresami URL, metadanymi, powiązaniami językowymi i własnymi modelami danych. Bez tego inwentarza wszystko, co dzieje się później, jest zgadywaniem.
Etap drugi to mapowanie modelu treści. WordPress myśli wpisami, stronami, własnymi typami wpisów i taksonomiami. TYPO3 myśli drzewami stron, elementami treści i rekordami. Mapowanie decyduje, które elementy treści TYPO3 staną się blokami Gutenberga, które blokami wielokrotnego użytku i wzorcami bloków, które polami ACF, a które własnymi typami wpisów. Typowe mapowanie w projektach dla DACH obejmuje aktualności, komunikaty prasowe, oferty pracy, lokalizacje, wydarzenia i pracowników. To etap najbardziej wymagający intelektualnie, bo porządkuje na nowo sposób myślenia redakcji.
Etap trzeci to właściwa migracja techniczna. Tu działają skrypty, które czytają bazy danych TYPO3, przekształcają treści i zapisują je w strukturach WordPressa. Zwykle łączymy bezpośredni dostęp do bazy przez repliki tylko do odczytu z importerami WP-CLI. Obrazy przenosimy razem z ich wariantami (renditions), a wielojęzyczność budujemy na Polylang albo WPML, zależnie od profilu docelowego. Skrypty są idempotentne, czyli można je uruchamiać wielokrotnie bez tworzenia duplikatów.
Etap czwarty to SEO i strategia przekierowań. Tu pilnujemy, żeby każdy stary adres URL zwracał odpowiedź 301 prowadzącą do odpowiadającego mu nowego adresu. Dane strukturalne budujemy od nowa, tagi hreflang mapujemy w całości, a mapy strony XML generujemy ponownie. Ten etap nie jest opcjonalny ani dokładany na końcu: przygotowujemy go równolegle z etapem trzecim. Głębiej o wzorcach SEO w architekturze headless piszemy w artykule o SEO w headless WordPressie.
Najczęstsze błędy przy migracji z TYPO3
W ostatnich latach widzieliśmy wystarczająco dużo projektów przejścia z TYPO3 na WordPressa, żeby nazwać pięć najczęstszych błędów. Wszystkich da się uniknąć, jeśli audyt jest uczciwy.
Po pierwsze, niedoszacowanie zachowania adresów URL. TYPO3 generuje adresy ze ścieżek drzewa stron, często z niemieckimi znakami diakrytycznymi i długimi hierarchiami. Kto przy zmianie spłaszczy strukturę URL bez mapy przekierowań, traci pozycje na miesiące. Rozwiązaniem jest kompletna lista adresów przed przełączeniem, z jednoznacznym źródłem i celem dla każdej pozycji, wdrożona przez konfigurację serwera WWW albo Cloudflare Page Rules.
Po drugie, zbyt naiwne mapowanie wielu drzew stron na kategorie. Drzewo stron w TYPO3 to nie to samo co kategoria w WordPressie. Drzewa stron zawierają hierarchie, uprawnienia, warianty językowe i elementy treści. Kategoria to taksonomia. Kto mapuje jedno na drugie jeden do jednego, traci informacje. Czyste rozwiązanie to połączenie własnych typów wpisów, taksonomii i stron z relacjami rodzic-dziecko.
Po trzecie, zapominanie o wielojęzycznych fragmentach. TYPO3 pozwala nakładać tłumaczenia na pojedyncze elementy treści bez duplikowania całej strony. Lokalizacja w WordPressie przez Polylang albo WPML domyślnie duplikuje stronę. Jeśli mapowanie nie uwzględni tej różnicy, nagle brakuje tłumaczeń nagłówka, stopki albo bloków zajawek, bo w TYPO3 były utrzymywane jako globalne fragmenty.
Po czwarte, zbyt późne przekładanie własnych modeli danych Extbase. Kto zbudował w TYPO3 własne rozszerzenie, powiedzmy do wydarzeń z logiką wczesnych zapisów, limitem miejsc i listami rezerwowymi, nie przeciągnie go przez ogólny importer. Logikę trzeba przełożyć na własny typ wpisu z endpointami REST, najlepiej z własnymi regułami walidacji. Kto odkryje to w ostatnich dwóch tygodniach przed przełączeniem, przesuwa termin.
Po piąte, zapominanie o wariantach obrazów. TYPO3 generuje warianty w różnych rozmiarach i kadrach przez swoją warstwę File Abstraction Layer. WordPress ma własny system rozmiarów. Jeśli migracja przenosi tylko oryginały, a warianty powstają w locie przy pierwszym wywołaniu, serwis po przełączeniu przez kilka dni wygląda na wolny. Rozwiązaniem jest wygenerowanie rozmiarów z góry przez WP-CLI zaraz po imporcie.
Agencja do migracji z TYPO3 do WordPressa
Od lat wspieramy firmy i instytucje publiczne z regionu DACH w migracjach z TYPO3 do WordPressa, ze szczególnym naciskiem na architektury headless. Nasz model oddziela pracę redakcyjną od dostarczania frontendu. WordPress zostaje redakcją, a frontend działa na Astro albo Next.js i jest serwowany przez Cloudflare Workers. Urzędy i firmy średniej wielkości dostają dzięki temu szybkość potrzebną do Core Web Vitals bez rezygnacji z wygody redakcji w WordPressie.
W zespołach projektowych mówimy po niemiecku, polsku i angielsku, dokumentujemy architekturę tak, żeby zespoły ds. zgodności mogły ją sprawdzić, i dostarczamy szablony gotowe na WCAG 2.2 i BFSG. Konkretne ceny zależą od profilu projektu, od inwentarza po nakład pracy przy multi-site. Jak działa nasz model usług, pokazuje strona o headless WordPressie jako usłudze, skąd można też od razu skontaktować się z zespołem.
Meetupy WordPress i TYPO3 w regionie DACH
Publiczne katalogi społeczności i linki do meetupów. Nie prowadzimy własnych stron wydarzeń ani spotkań offline: te listy odsyłają do istniejących społeczności w DACH.
Społeczności i katalogi WordPressa
Zewnętrzne linki społecznościowe (Meetup, WordCamp, organizacje krajowe). Żadnych własnych stron wydarzeń ani spotkań offline WPPoland.
- DACH Meetup-Verzeichnis (de.wordpress.org)
- WordPress Meetup Pro (global)
- WordCamp Central
- WP Switzerland
- WordPress Meetup Berlin
- WordPress Meetup München
- WordPress Meetup Hamburg
- WordPress Meetup Köln
- WordPress Meetup Leipzig
- WordPress Meetup Dortmund
- Düsseldorf WooCommerce Meetup
- Vienna WordPress Meetup
- WordPress Zurich
- WordPress Bern
Społeczności i katalogi TYPO3
Oficjalne kalendarze TYPO3, grupy użytkowników i barcampy w regionie DACH, również wyłącznie źródła zewnętrzne.
- TYPO3 Events Calendar
- TUG Directory (User Groups)
- TYPO3camp München
- TYPO3camp RheinRuhr
- TYPO3camp Berlin
- TYPO3camp Mitteldeutschland
- TYPO3camp Stuttgart
- TYPO3camp Vienna
- TYPO3camp Schweiz
- TUGA (Austria)
- TUG München (T3MUC)
- TUG Berlin (T3B)
- TUG Schweiz
Więcej o migracji WordPressa i headless
Ten artykuł nie jest osobnym tekstem, tylko częścią cyklu o migracjach WordPressa i wydajności w regionie DACH. Jeśli zaczynasz tutaj, kolejne części znajdziesz w poniższych tekstach.
Metodyczne studium przypadku z mapą przekierowań i listami kontrolnymi modelu treści jest pod adresem poufna migracja z TYPO3 do WordPressa. Tam też można pobrać oba szablony CSV. Filarem dla architektury po migracji jest headless WordPress jako usługa. O technicznym dostarczaniu przez warstwę edge piszemy w tekście Cloudflare Workers dla WordPressa i WooCommerce. Przy wymaganiach sektora publicznego ważny pozostaje tekst o WCAG, BFSG i EAA. Kontekst nearshore przy pytaniach o ludzi daje nasz artykuł o seniorach IT z Polski.
Pogłębienie dla CTO i kierowników technicznych znajdziesz w tekstach Headless WordPress: Next.js czy Astro oraz SEO w headless WordPressie. Osobiste stanowisko autora w sprawie strategii WordPressa w DACH przedstawia profil Mariusza Szatkowskiego.
TYPO3 ma swój dom w DACH, to fakt. WordPress ma w 2026 roku większy zasięg, większą pulę specjalistów i szerszy ekosystem, to też fakt. Migracja nie jest wyznaniem wiary. To rachunek z pięcioma zmiennymi. Kto liczy uczciwie, dostaje jasną odpowiedź.
Jak przenieść tt_content z TYPO3 do bloków Gutenberga
Migracja złożonej, korporacyjnej instancji TYPO3 do WordPressa wymaga dobrego zrozumienia obu modeli danych:
- Rozbiór TypoScriptu i elementów treści: W TYPO3 treści są często drobno podzielone w zagnieżdżonych tabelach
tt_content. Zamiana ich na semantyczne bloki Gutenberga wymaga własnych skryptów migracyjnych (WP-CLI), które oczyszczają strukturę HTML i porządnie przypisują modułowe komponenty. - Wielojęzyczność i hierarchie zastępcze: TYPO3 zarządza językami przez złożone drzewa lokalizacji z logiką dziedziczenia. Przy przejściu na rozwiązania WordPressa, takie jak Polylang Pro czy WPML, trzeba precyzyjnie przenieść identyfikatory języków, hierarchie menu i powiązania relacyjne, żeby uniknąć duplikatów i konfliktów routingu.
- Zabezpieczenie zasobów i ścieżek mediów: Ścieżki przechowywania w TYPO3 (
fileadmin/) zasadniczo różnią się od biblioteki mediów WordPressa. Solidny proces importu aktualizuje odwołania do obrazów, generuje responsywne obrazy WebP i zapobiega martwym linkom do grafik. - Kompletna strategia przekierowań 301: Ponieważ serwisy na TYPO3 często działają w sieci od dekad, pełne zmapowanie starych struktur URL przez reguły rewrite w Nginx jest niezbędne, żeby utrzymać pozycje w wynikach organicznych.
Testy i szkolenie redakcji po relaunchu na WordPressie
Udane zamknięcie projektu migracji wymaga uporządkowanego przekazania:
- Rozbudowane automatyczne testy regresji: Przed ostatecznym przełączeniem DNS automatyczne testy sprawdzają zgodność wszystkich treści, działanie formularzy kontaktowych i dostępność według WCAG 2.2.
- Szkolenie redakcji z ekosystemu Gutenberga: Redaktorzy, którzy latami pracowali w interfejsie TYPO3, doceniają intuicyjną obsługę nowoczesnych motywów blokowych WordPressa. Celowane warsztaty i modułowe biblioteki wzorców bloków wyraźnie przyspieszają pracę redakcji.
- Monitorowanie błędów indeksowania w Google Search Console: W pierwszych miesiącach po relaunchu trzeba codziennie sprawdzać odsetek błędów 404 i raporty indeksowania, żeby szybko wyłapywać błędne adresy celowanymi przekierowaniami 301. Starannie zaplanowane przejście z TYPO3 na WordPressa zabezpiecza cyfrową przyszłość firmy i wyraźnie obniża długoterminowe koszty utrzymania.
Jakie zalety ma WordPress w porównaniu z TYPO3 dla firm?
Strategiczne przejście na WordPressa daje wyraźne korzyści biznesowe:
- Większa dostępność programistów i swobodniejszy wybór partnerów: Specjalistów od przestarzałych wersji TYPO3 jest na rynku mało i są bardzo drodzy, a globalny ekosystem WordPressa daje dostęp do tysięcy wykwalifikowanych programistów i agencji na całym świecie.
- Szybsze wprowadzanie nowych kampanii marketingowych: Dzięki modułowemu edytorowi Gutenberg zespoły marketingowe same tworzą i od razu publikują nowe landing page i treści nastawione na konwersję, bez wsparcia zewnętrznych programistów.
- Podsumowanie: Modernizacja infrastruktury CMS usuwa techniczny balast, odczuwalnie obniża bieżące koszty i przygotowuje cyfrowy model biznesowy na wymagania najbliższych lat.
Profesjonalne i przemyślane prowadzenie migracji CMS zapewnia płynne przejście bez utraty widoczności w Google i daje firmie trwałą przewagę na dynamicznym rynku online. Jakość zawsze się na rynku obroni.
