# Migracja WordPress → Astro

Przeniesienie istniejącej strony z WordPressa na Astro i CMS dopasowany do firmy — treść, media i adresy zostają, przekierowania rozpisane, ryzyko SEO ograniczone.

**Canonical:** https://spoko.space/pl/migracja-wordpress-astro/  
**Language:** pl  
**Updated:** 2026-09-21

---

## Twoja strona nie musi stać na WordPressie.

*WordPress → Astro*

Przenoszę stronę, którą już masz, na Astro i CMS zbudowany pod twoją firmę. Treść, adresy i lata pracy nad SEO jadą razem z nią.

Migracja z planem SEO · Treść zostaje · Własny CMS · Szybka z założenia

[Sprawdź moją stronę](#audyt) · [Zobacz, jak to działa](#jak-to-dziala)

## WordPress działa. Do momentu, w którym strona staje się osobnym projektem. {#wordpress-działa-do-momentu-w-którym-strona-staje-się-osobnym-projektem}

*Problem*

To nie jest zarzut wobec WordPressa. To opis tego, w co zamienia się konkretna instalacja po kilku latach dokładania do niej kolejnych rzeczy.

- **Wtyczka na każdą decyzję** — Każda rozwiązywała realny problem w dniu instalacji. Razem są tym, co dziś aktualizujesz, testujesz i przy czym trzymasz kciuki.
- **Front, który ładuje wszystko** — Motyw, page builder i ich biblioteki ładują się na każdej podstronie — niezależnie od tego, czy ta podstrona ich używa.
- **Utrzymanie w cudzym rytmie** — Aktualizacje core’a, motywu i wtyczek przychodzą, kiedy przychodzą, a każda jest drobnym ryzykiem, które ktoś musi wziąć na siebie.
- **Panel pisany pod wszystkie strony naraz** — Kokpit obsługuje wszystko, czym może być internet. Dlatego rzadko pasuje do tych kilku rzeczy, które twój zespół faktycznie robi.

## Migracja, a nie kolejne pisanie strony od zera. {#migracja-a-nie-kolejne-pisanie-strony-od-zera}

*Obietnica*

Droga wersja wyjścia z WordPressa to ta, w której wszystko zaczyna się od pustego ekranu: teksty pisane od nowa, zdjęcia wgrywane po raz drugi, adresy zmienione, a strona przez pół roku odrabia pozycję, którą już miała.

**Zaczynam od strony, którą już masz.** Podstrony, wpisy, zdjęcia i adresy są materiałem wejściowym, a nie czymś do odtworzenia później. Zmienia się to, co jest pod spodem.

**Zostaje to, co ma wartość. Wylatuje to, co jej nie ma.** Treść, struktura i adresy zostają. Stos wtyczek, page builder i motyw — nie. Złożoności nie przenoszę: jeżeli coś buduję od nowa, to dlatego, że na to zasługuje.

## Ta sama strona. Inny fundament. {#ta-sama-strona-inny-fundament}

*Przed / po*

To, co czyta odwiedzający, zostaje bez zmian. To, co pobiera przeglądarka i co ty utrzymujesz — nie.

### Dziś, na WordPressie {#dziś-na-wordpressie}

Stos, w którym każda warstwa zależy od tej pod spodem.

- Core WordPressa — albo aktualizowany, albo ryzykowny
- Wtyczki do formularzy, SEO, cache’u, galerii i zgód
- Page builder, który decyduje o tym, jak zapisana jest treść
- Motyw, którego układ strony nie przeżyje
- Utrzymanie jako stały punkt w miesiącu

### Po migracji {#po-migracji}

Statyczny front i model treści, który należy do ciebie.

- Astro, generujące podstrony z wyprzedzeniem
- Treść zapisana jako dane, nie jako kod strony
- Minimum JavaScriptu w przeglądarce — tylko tam, gdzie jest potrzebny
- CMS zbudowany pod te kilka rzeczy, które faktycznie edytujecie
- Publikacja zautomatyzowana, więc wydanie zmian nie jest wydarzeniem

## Co dokładnie przechodzi na nową stronę? {#co-dokładnie-przechodzi-na-nową-stronę}

*Zakres*

Treść zostaje. Adresy rozpisane. Funkcje zbudowane od nowa.

- **Treść** — Podstrony, wpisy, kategorie i tagi razem ze strukturą — nagłówkami, listami, tabelami i osadzeniami.
- **Media** — Biblioteka zdjęć, przekodowana do nowoczesnych formatów i przyciętych rozmiarów pod układy, które jej używają.
- **SEO** — Tytuły, opisy, canonicale, dane strukturalne i sitemapa, a do tego przekierowanie na każdy adres, który się zmienia.
- **Funkcje** — Formularze, wyszukiwarka, filtry, galerie i strefy dla zalogowanych — jako część strony, a nie doklejony dodatek.
- **Analityka** — Analytics, tag manager i zgody podpięte na nowo i sprawdzone na zdarzeniach, które już raportujesz.
- **Integracje** — Newsletter, CRM, rezerwacje, płatności — z czym strona rozmawia dziś, z tym rozmawia dalej.

## A co z Google? {#a-co-z-google}

*SEO*

Nikt uczciwie nie obieca migracji bez ruchu na pozycjach, a kto obiecuje, ten coś sprzedaje. Da się natomiast usunąć powody, dla których migracja zwykle kosztuje pozycje — prawie zawsze te same i wszystkie do uniknięcia planem zrobionym, zanim cokolwiek ruszy.

Mapa adresów powstaje jako pierwsza, jest sprawdzana na żywej stronie i weryfikowana po starcie w Search Console oraz w logach serwera.

- **Mapa adresów** — Każdy adres z obecnej strony trafia na listę i dostaje swój odpowiednik, zanim zacznie się budowa.
- **Przekierowania 301** — Co się przenosi, dostaje przekierowanie stałe, żeby linki i pozycje poszły razem z adresem.
- **Metadane** — Tytuły i opisy przechodzą w takiej formie, w jakiej są — chyba że akurat przepisuję daną podstronę.
- **Canonicale** — Jeden adres kanoniczny na podstronę, żeby dwie wersje serwisu nie konkurowały ze sobą w trakcie przełączania.
- **Sitemapa i robots.txt** — Generowane od nowa z nowej strony i zgłaszane, zamiast przepisywane ręcznie.
- **Dane strukturalne** — Artykuły, okruszki, produkty i FAQ budowane z samej treści.
- **Linkowanie wewnętrzne** — Przepisane na nowe adresy, żeby po migracji strona nie linkowała do własnych przekierowań.
- **Indeksowanie** — Staging zamknięty dla robotów, produkcja otwarta w dniu startu — sprawdzone, nie założone.

## CMS ma pasować do firmy, a nie firma do CMS-a. {#cms-ma-pasować-do-firmy-a-nie-firma-do-cms-a}

*Własny CMS*

Uniwersalny panel musi być gotowy na każdą stronę, jaka kiedykolwiek powstała. Twój ma być dobry w tych pięciu rzeczach, które zespół robi co tydzień: opublikować wpis, podmienić zdjęcie, zmienić cenę, dodać realizację, zaktualizować podstronę w dwóch językach.

To nie jest makieta produktu, którego nie ma: na zrzutach jest CMS, który zbudowałem i prowadzę pod strony klientów — z kreatorem stron z bloków, tłumaczeniami, mediami i wdrożeniami w jednym miejscu. [Zobacz, jak jest zbudowany](https://spoko.space/pl/autorski-cms-z-ai/).

- **Tylko to, czego potrzebujesz** — Pola, które twoja treść naprawdę ma, i zero zakładek z ustawieniami, które trzeba omijać.
- **Treść jako dane** — Zapisana strukturalnie, nie jako kod strony — więc da się jej użyć ponownie, przetłumaczyć i wyświetlić gdziekolwiek.
- **Pod wasz sposób pracy** — Role, akceptacja i publikacja ułożone tak, jak już pracujecie, a nie odwrotnie.
- **Gotowy na AI, jeśli chcesz** — Ta sama treść dostępna dla narzędzi AI przez MCP, na tych samych uprawnieniach co panel.

## Trzy sposoby na przeprowadzkę {#trzy-sposoby-na-przeprowadzkę}

*Warianty*

Który pasuje, zależy od tego, ile z obecnej strony chcesz zachować. Każdy wyceniam po ocenie migracji.

### Migracja 1:1 — Wariant 1 {#migracja-11}

Ta sama strona na nowym fundamencie. Projekt graficzny zostaje, zmienia się wszystko pod nim.

- Obecny projekt odtworzony bez zmian
- Treść, media i adresy przeniesione
- Przekierowania tam, gdzie adres się zmienia
- CMS na te części, które edytujecie
- Najszybsze wyjście z obecnego stosu

### Migracja z redesignem — Wariant 2 {#migracja-z-redesignem}

Przeprowadzka i odkładany od dawna nowy projekt — w jednym podejściu zamiast w dwóch wdrożeniach.

- Nowy projekt zbudowany na istniejącej treści
- Architektura informacji przemyślana od nowa
- Treść redagowana tam, gdzie tego wymaga
- Ta sama dyscyplina mapowania SEO
- Jedna budowa, jeden start, jedno zamieszanie

### Migracja custom — Wariant 3 {#migracja-custom}

Dla stron, które wykonują realną pracę: sklepy, strefy dla zalogowanych, wielojęzyczność, integracje.

- Funkcje budowane od nowa, nie przepisywane wtyczka po wtyczce
- Wielojęzyczność razem ze strukturą adresów
- Integracje z systemami, których już używacie
- Model treści zaprojektowany pod branżę
- Zakres rozpisany szczegółowo przed wyceną

## Jak wygląda migracja {#jak-wygląda-migracja}

*Proces*

Nic się nie rusza, zanim nie powstanie mapa, i nic nie startuje, zanim nowa strona nie zostanie sprawdzona wobec starej.

- **Audyt** — Z czego składa się strona: podstrony i ich adresy, wtyczki i to, za co każda odpowiada, struktura treści, integracje, ruch.
- **Plan** — Mapa adresów, model treści, lista tego, co buduję od nowa i co wylatuje — spisane i uzgodnione, zanim powstanie kod.
- **Budowa** — Nowy front w Astro i CMS wokół twojego modelu treści, na domenie testowej zamkniętej dla robotów.
- **Migracja i weryfikacja** — Treść i media przeniesione, przekierowania na miejscu, a potem nowa strona sprawdzona podstrona po podstronie wobec starej.
- **Start** — Przełączenie DNS, zgłoszenie sitemapy, obserwacja przekierowań i indeksowania w Search Console przez kolejne tygodnie.

## Nie wiesz, czy migracja ma sens? {#nie-wiesz-czy-migracja-ma-sens}

*Zacznij tutaj*

Wyślij mi adres strony. Obejrzę obecną instalację WordPressa i powiem, co realnie oznaczałoby przejście na Astro — łącznie z sytuacją, w której uczciwa odpowiedź brzmi: jeszcze nie warto.

*Bez prezentacji sprzedażowej. Bez generycznego audytu. Konkretne spojrzenie na twoją stronę.*

- **Wydajność** — Co strona ładuje dzisiaj i jaka część tego to stos technologiczny, a nie treść.
- **Wtyczki i zależności** — Co jest zainstalowane, co jest naprawdę potrzebne i co trzeba byłoby zbudować od nowa.
- **Struktura treści** — Jak treść jest dziś zapisana i jak wyglądałaby jako dane strukturalne.
- **SEO** — Adresy, metadane i dane strukturalne — co trzeba rozpisać, zanim cokolwiek ruszy.
- **Funkcje** — Formularze, wyszukiwarka, sklep, logowanie, integracje: co strona robi poza publikowaniem podstron.
- **Zakres migracji** — Który z trzech wariantów pasuje, ile mniej więcej zajmie i ile kosztuje.

## Zamów ocenę migracji {#zamów-ocenę-migracji}

Adres strony to jedyne, czego naprawdę potrzebuję — resztę wyczytam z samej strony.

Odpowiadam w 1–2 godziny w dni robocze — tym, co znalazłem, a nie linkiem do kalendarza.

## WordPress, który został CMS-em {#wordpress-który-został-cms-em}

*Case study*

[polo.blue](https://polo.blue/) to warsztatowy serwis o VW Polo: kilkaset długich, naszpikowanych zdjęciami artykułów. WordPress jest tam CMS-em od początku i jest nim nadal. Zmieniał się front, dwa razy — najpierw aplikacja we Vue 2, potem, w **marcu 2023**, obecna strona w Astro.

Obie przebudowy zostawiły treść w spokoju i o to chodzi: artykuły, biblioteka mediów i adresy nigdy nie siedziały w motywie, więc wymiana tego, co je wyświetla, była robotą na froncie, a nie przenoszeniem istoty serwisu. Panel autora za każdym razem został ten sam.

Audytorium mniej więcej się podwoiło w ciągu ostatnich dwóch lat — **58 027 aktywnych użytkowników** w pierwszym pełnym roku na Astro wobec **118 324** w ostatnich dwunastu miesiącach, dwie trzecie z wyszukiwarki. Przez trzy lata przybyło też sporo artykułów, więc czytaj to jako to, co zrobił serwis, a nie co zrobiło mu Astro: porównania „przed i po" tu nie ma, bo stary front nigdy nie był mierzony.

Miejsce, w którym statyczna strona teoretycznie przegrywa, to komentarze. Tutaj nie są budowane z wyprzedzeniem — przeglądarka czyta je z REST API WordPressa, a nowe wysyła własnym endpointem, więc komentarz pojawia się bez przebudowywania strony. Statycznie tam, gdzie to się opłaca, dynamicznie tam, gdzie trzeba.

- **Trzy i pół roku w produkcji** — Działa od marca 2023 — to nie pilotaż ani przebudowa, którą trzeba było powtórzyć.
- **Astro 2 → 7, bez przepisywania** — Pięć głównych wersji frameworka, przechodzonych zwykłymi aktualizacjami, a nie kolejną przebudową.
- **Panel się nie zmienił** — WordPress nadal jest CMS-em, a osoba pisząca artykuły pracuje dokładnie tak jak wcześniej.
- **Treść przeżyła dwa fronty** — Vue 2, potem Astro. Artykuły zostały na miejscu, bo mieszkają w CMS-ie, a nie w szablonie.
- **Komentarze bez przebudowy** — Czytane w przeglądarce z REST API WordPressa, wysyłane przez własny endpoint strony.
- **57 KB HTML na artykuł** — Zmierzone na żywej stronie: 57 KB po kompresji plus ~53 KB JavaScriptu współdzielonego z całym serwisem.

## Mniej kodu w przeglądarce. Więcej miejsca na to, co się liczy. {#mniej-kodu-w-przeglądarce-więcej-miejsca-na-to-co-się-liczy}

*Wydajność*

Różnica jest architektoniczna, a nie kwestią dostrajania.

**WordPress renderujący stronę** składa ją przy każdym żądaniu: uruchamia się PHP, odpytywana jest baza, motyw buduje HTML. Wtyczki cache istnieją po to, żeby tego nie robić — co samo mówi, ile to kosztuje. **Aplikacja jednostronicowa** — taki front we Vue 2 miało kiedyś polo.blue — przenosi ten koszt do przeglądarki: odwiedzający pobiera aplikację, aplikacja pyta API o artykuł i dopiero wtedy jest co czytać. **Strona statyczna nie robi ani jednego, ani drugiego.** HTML powstaje przy publikacji, serwer oddaje gotowy plik, więc tekst jest w pierwszej odpowiedzi.

Jak to wygląda dziś na polo.blue, według danych z prawdziwych przeglądarek, a nie z laboratorium: **na komputerze przechodzi Core Web Vitals** — LCP 1,2 s, INP 94 ms, CLS 0,03. **Na telefonie nie przechodzi**, i to na jednej metryce: przesunięcia układu 0,17 przy progu 0,1, podczas gdy LCP (1,6 s) i INP (169 ms) mieszczą się w swoich.

Warto powiedzieć, skąd bierze się to przesunięcie, bo to jest najbardziej użyteczna część: nie z kodu strony. Każde ze 165 zdjęć w tym artykule ma podane wymiary, a pomiar laboratoryjny tej samej strony nie wykazuje przesunięcia w ogóle. Ono pojawia się u prawdziwych użytkowników, kiedy doładowują się bloki reklamowe i menedżer tagów, i rozpychają układ. To jest uczciwy podział ról — statyczne renderowanie zabiera czekanie, nad którym panuje, a reszta to, co dokładasz na wierzch.

*I to jest jednocześnie lista rzeczy do zrobienia na tym serwisie: skrypty reklam i tagów na telefonie oraz biblioteka mediów, w której 144 ze 165 zdjęć w najdłuższym artykule to nadal JPEG, a nie AVIF czy WebP — czyli punkt „Media" z zakresu powyżej.*

## Pytania, które padają przed przeprowadzką {#pytania-które-padają-przed-przeprowadzką}

### Czy żeby zrobić migrację, trzeba przy okazji zrobić redesign? {#faq-czy-żeby-zrobić-migrację-trzeba-przy-okazji-zrobić-redesign}

Nie. Wariant 1:1 odtwarza obecny projekt, więc dla odwiedzających nic się nie zmienia — strona po prostu przestaje stać na WordPressie. Redesign warto dorzucić wtedy, gdy i tak był w planach: razem wychodzi taniej niż rok po roku.

### Co dzieje się z moją obecną treścią? {#faq-co-dzieje-się-z-moją-obecną-treścią}

Przechodzi. Podstrony, wpisy, kategorie, tagi i biblioteka mediów są eksportowane z WordPressa i wgrywane do nowego modelu treści razem ze strukturą. Nic nie jest przepisywane ręcznie i nic nie zależy od tego, czy ktoś skopiuje to na piechotę.

### A co z wtyczkami? {#faq-a-co-z-wtyczkami}

Każda przechodzi przez audyt i trafia do jednego z trzech koszyków: budowana od nowa jako część strony (formularze, wyszukiwarka, galerie), zastąpiona tym, co platforma robi sama (cache, optymalizacja zdjęć, sitemapa), albo usunięta, bo nic na stronie już z niej nie korzysta. Złożoności nie przenoszę.

### Czy dalej będę edytować stronę samodzielnie? {#faq-czy-dalej-będę-edytować-stronę-samodzielnie}

Tak, po to jest CMS. Różnica polega na tym, że zawiera dokładnie to, co twoja strona ma, więc edycja podstrony to wypełnienie pól, a nie walka z page builderem. Jeśli zespół dobrze czuje się w panelu WordPressa, można też zostawić WordPressa jako headless CMS.

### Czy migracja zaszkodzi mojemu SEO? {#faq-czy-migracja-zaszkodzi-mojemu-seo}

Każda migracja niesie ryzyko i nikt uczciwie nie obieca, że pozycje się nie ruszą. Da się natomiast usunąć typowe przyczyny: każdy adres rozpisany przed budową, przekierowania 301 na wszystko, co się przenosi, metadane i dane strukturalne przeniesione, sitemapa zgłoszona i Search Console obserwowana po starcie, żeby wyłapać spadek w dni, a nie w miesiące.

### Czy to zadziała przy stronie wielojęzycznej? {#faq-czy-to-zadziała-przy-stronie-wielojęzycznej}

Tak. Języki są częścią modelu treści, a nie wtyczką, więc każdy ma własne adresy, własne wpisy w sitemapie i tagi hreflang spinające wersje. Ta strona działa dokładnie tak — po polsku i po angielsku.

### Czy mogę zostawić WordPressa jako CMS? {#faq-czy-mogę-zostawić-wordpressa-jako-cms}

Możesz. W wariancie headless zespół zostaje przy znanym panelu WordPressa, a front jest pisany od nowa w Astro i pobiera treść przez REST API. To mniejsza zmiana i dobry wybór, kiedy problemem nie jest panel, tylko front. Ten wariant opisuję na stronie naprawy WordPressa.

### Ile trwa migracja? {#faq-ile-trwa-migracja}

To zależy od tego, ile strona robi — i właśnie to ustala ocena migracji. Wizytówka na kilkadziesiąt podstron to inny projekt niż sklep z kontami klientów, i wolę powiedzieć, który z nich masz, zanim umówimy się na termin.

### Co dzieje się w dniu startu? {#faq-co-dzieje-się-w-dniu-startu}

Zanim ten dzień nadejdzie, nowa strona stoi już na domenie testowej i jest sprawdzona podstrona po podstronie. Start to przełączenie DNS, zgłoszenie sitemapy i weryfikacja przekierowań na żywym serwisie. Gdyby coś było nie tak, stara strona nadal stoi i można się na nią cofnąć.

## Twoja następna strona nie musi zaczynać się od pustego ekranu. {#twoja-następna-strona-nie-musi-zaczynać-się-od-pustego-ekranu}

Wyślij adres strony, którą masz. Powiem ci, co oznaczałoby jej przeniesienie.

[Sprawdź moją stronę](#audyt)