Migracja WordPress do Next.js: SEO i przekierowania 301

Migracja WordPress do Next.js: zakres projektu i ryzyka SEO

Migracja z WordPressa na Next.js jest pojęciem bardzo szerokim, za którym kryją się zupełnie odmienne podejścia do przebudowy serwisu. W pierwszym wariancie WordPress zostaje całkowicie porzucony na rzecz plików MDX lub innego systemu zarządzania treścią. W drugim zachowujemy go w roli headless CMS, wymieniając jedynie warstwę widoku. Trzecia ścieżka to natomiast gruntowna rewolucja, podczas której obok samej technologii zmienia się domena, struktura adresów URL oraz całkowity wygląd serwisu. Jak widać, mówiąc o migracji, możemy mieć na myśli różny zakres zadań.

Te scenariusze mają inne ryzyko:

1. Ta sama domena i te same adresy. Publiczne adresy nadal zwracają 200, więc nie potrzebują przekierowań. Najważniejsze są zgodność treści, metadanych, statusów HTTP i moment przełączenia hostingu.
2. Ta sama domena, ale nowe ścieżki. Każdy zmieniony adres wymaga decyzji w mapie migracyjnej i zwykle stałego przekierowania do odpowiadającej mu treści.
3. Nowa domena. Oprócz mapowania i przekierowań dochodzi weryfikacja obu domen oraz narzędzie Zmiana adresu w Google Search Console.
4. Headless WordPress. Odpada import do nowego CMS-a, ale pozostają integracja API, podgląd szkiców, pamięć podręczna, webhooki i odtworzenie funkcji motywu oraz wtyczek. Trzeba też zapobiec indeksowaniu dawnej warstwy prezentacji WordPressa pod techniczną domeną lub adresem serwera źródłowego, aby nie utworzyć drugiej publicznej wersji treści.

Ten sam URL oznacza zgodność całego publicznego adresu, a nie tylko samej ścieżki. Przed wdrożeniem sprawdź protokół, nazwę hosta (www lub bez www), wielkość liter, końcowy ukośnik, kodowanie znaków, paginację oraz parametry, które zmieniają treść. Jedną wersję wybierz jako kanoniczną, a pozostałe warianty sprowadź do niej spójnymi przekierowaniami.

W sytuacji, kiedy wersja testowa jest dostępna publicznie, zabezpiecz ją uwierzytelnianiem lub ograniczeniem sieciowym. robots.txt steruje skanowaniem, ale nie jest kontrolą dostępu; zablokowany robot nie zobaczy również znacznika noindex. Nie polegaj na samym robots.txt, gdy środowisko testowe zawiera poufne dane albo kopię produkcyjnej treści.

Migracja WordPress do Next.js bez utraty SEO: co trzeba zachować?

Next.js daje dużą kontrolę nad renderowaniem, pamięcią podręczną i kodem warstwy widoku, ale nie gwarantuje automatycznie lepszych Core Web Vitals, bezpieczeństwa ani pozycji. Trzeba pamiętać, że prawidłowo zoptymalizowany WordPress może być szybszy od nieprawidłowo zbudowanej aplikacji w Next.js, ponieważ o wszystkim decyduje implementacja, infrastruktura oraz zachowanie tego, co użytkownik i wyszukiwarka otrzymywali przed migracją.

Same przekierowania to za mało, aby uchronić serwis przed problemami – nie uratują strony, z której nagle zniknęła połowa treści, poprawny link wewnętrzny czy właściwy status indeksacji. Kompleksowa i bezpieczna migracja chroni jednocześnie:

• Znaczenie i kompletność głównej treści
• Publiczne URL-e i linki prowadzące do serwisu

• Tytuły, opisy, linki kanoniczne, robots i hreflang

• Dane strukturalne, autorów i daty publikacji
• Linkowanie wewnętrzne oraz nawigację

• Obrazy, pliki do pobrania, kanały RSS lub Atom i inne zasoby

• Analitykę, formularze i ścieżki konwersji

Google może potrzebować kilku tygodni na przetworzenie średniego serwisu, a w dużych witrynach proces może potrwać kilka miesięcy. Celem nie jest obietnica całkowicie niewidocznej migracji, tylko ograniczenie zmian niezwiązanych z technologią i szybkie wykrywanie odstępstw.

Audyt SEO przed migracją WordPressa: stan wyjściowy i cele

Zanim rozpoczniesz eksport, zapisz stan, z którym porównasz nową stronę. Sam ogólny wykres ruchu nie wystarczy, ponieważ sezonowość, kampanie i aktualizacje Google mogą zaciemnić obraz.

Stan wyjściowy powinien obejmować:

• Organiczne kliknięcia, wyświetlenia i najważniejsze strony wejścia

• Konwersje z ruchu organicznego, a nie tylko liczbę sesji

• Najważniejsze frazy i grupy podstron
• Liczbę URL-i indeksowanych oraz przyczyny wykluczeń

• Błędy 404, 5xx, przekierowania i statusy linków kanonicznych

• Próbki wyrenderowanego HTML-a, danych strukturalnych i zrzutów kluczowych szablonów

• Wyniki Core Web Vitals i wydajność kluczowych szablonów

• Działanie formularzy, wyszukiwarki, koszyka i innych funkcji biznesowych.

Przed wdrożeniem warto spisać jasne warunki akceptacji, takie jak brak nieplanowanych błędów 404, pełna zgodność kluczowych treści na najważniejszych adresach oraz poprawne rejestrowanie konwersji. Określenie precyzyjnych progów dla błędów 5xx, dopuszczalnego czasu odpowiedzi oraz dopuszczalnych wahań w liczbie stron sprawi, że decyzja o publikacji lub ewentualnym wycofaniu zmian będzie oparta na twardych danych.

Inwentaryzacja URL-i WordPressa przed migracją do Next.js

Raport Skuteczność w Search Console nie jest pełną bazą zaindeksowanych stron; pokazuje adresy obecne w dostępnych danych wyszukiwania, a eksport z interfejsu ma limit wierszy. Mapa witryny również nie wystarczy, bo może nie zawierać starych, osieroconych lub już usuniętych adresów, do których nadal prowadzą linki.

Połącz co najmniej:

• Eksport publicznych treści i bezpośrednich odnośników z WordPressa

• Wszystkie mapy witryny
• Wyniki pełnego skanowania serwisu

• Raporty Skuteczność, Indeksowanie stron i Linki w Google Search Console

• Organiczne strony wejścia z analityki
• Logi serwera z odpowiednio długiego okresu
• Adresy z linkami zewnętrznymi

• Istniejące przekierowania w WordPressie, wtyczkach, CDN i konfiguracji serwera

Uwzględnij nie tylko wpisy i strony, ponieważ musisz też sprawdzić własne typy treści, kategorie, tagi, autorów, paginację, strony załączników, kanały RSS lub Atom, obrazy, PDF-y, warianty językowe i istotne parametry zapytań. Weź też pod uwagę, że w serwisie sezonowym logi z ostatniego miesiąca mogą nie pokazać URL-i odwiedzanych tylko w określonej części roku.

Przed połączeniem źródeł znormalizuj nazwę hosta, protokół i sposób zapisu ścieżek, ale zachowaj również surowy adres wejściowy, aby nie zgubić wariantów wymagających przekierowania ani nie policzyć kilka razy tej samej strony. Osobno oznacz parametry śledzące, parametry zmieniające treść oraz adresy wygenerowane przez błędne linki.

Arkusz migracyjny powinien zawierać przynajmniej: stary URL, planowany nowy URL, obecną odpowiedź HTTP, decyzję migracyjną, typ treści, ruch, linki zewnętrzne, link kanoniczny, status indeksacji, właściciela oraz wynik testu przed i po wdrożeniu. Mapa adresów jest artefaktem wdrożeniowym, dlatego wersjonuj ją razem z kodem lub konfiguracją infrastruktury.

Mapa przekierowań 301: co zrobić z każdym starym URL-em?

Najbezpieczniej zachować dotychczasową strukturę URL-i, a w sytuacji, kiedy nie jest to możliwe, nie stosuj jednej reguły do całego serwisu:

Jeszcze jedna uwaga: nie kieruj wszystkich usuniętych wpisów na stronę główną ani luźno powiązaną kategorię, ponieważ takie przekierowanie nie tylko nie pomaga użytkownikowi, ale może też zostać potraktowane przez Google jako miękki błąd 404 (soft 404).

Przekierowania 301 i 308 w Next.js: konfiguracja

W Next.js ustawienie permanent: true generuje odpowiedź z kodem 308 zamiast klasycznego 301. Dla robotów Google oba te statusy oznaczają przekierowanie stałe i same w sobie nie powodują utraty PageRanku, jednak różnią się na poziomie protokołu HTTP – kluczową zmianą jest zachowanie metody żądania, którą 308 gwarantuje w sposób jawny. Jeśli specyfika integracji wymaga tradycyjnego kodu 301, możesz go wymusić za pomocą parametru statusCode: 301, pamiętając jednak, aby stosować go rozłącznie i nigdy nie łączyć z flagą permanent.

// next.config.ts
import type { NextConfig } from 'next'
 
const nextConfig: NextConfig = {
  async redirects() {
    return [
      {
        source: '/2024/01/stary-adres',
        destination: '/blog/nowy-adres',
        permanent: true, // Next.js zwróci kod 308, czyli stałe przekierowanie
      },
    ]
  },
}
 
export default nextConfig

Stosuj reguły wzorcowe wyłącznie w sytuacjach, gdy struktura adresów jest w pełni regularna. WordPress potrafi w tym względzie zaskoczyć, wykorzystując własną bazę kategorii, daty w bezpośrednich odnośnikach, końcowe ukośniki, wielojęzyczność czy historycznie zmieniane końcówki adresów. Jedna zbyt szeroka reguła może skierować poprawne adresy URL do nieistniejących celów, a stała odpowiedź zostać zapamiętana przez przeglądarkę lub CDN.

Przy setkach indywidualnych adresów traktuj przekierowania jako wersjonowane dane powiązane z arkuszem migracyjnym i testami. W Next.js 16 dawne middleware.ts nazywa się teraz proxy.ts, ale nie każda mapa powinna trafiać do Proxy. Najpierw użyj prostych reguł redirects(), natomiast większe lub często zmieniane zbiory rozważ w CDN, konfiguracji hostingu albo szybkim magazynie klucz–wartość. Zwróć też uwagę na limity samej platformy wdrożeniowej – na Vercel funkcja redirects() pozwala na zdefiniowanie maksymalnie 1024 reguł. Pamiętaj również, że w trybie eksportu statycznego Next.js nie obsługuje dynamicznych przekierowań w kodzie, więc musi je zapewnić serwer lub platforma hostingowa, która serwuje gotowe pliki.

Sprawdź również zachowanie wariantów z końcowym ukośnikiem, basePath, prefiksami językowymi i parametrami zapytania. Next.js domyślnie przekazuje parametry ze starego adresu do celu reguły, co bywa pożądane dla UTM-ów, ale może niepotrzebnie przenieść parametry techniczne WordPressa. Ustawienia trailingSlash oraz automatyczna normalizacja adresów mogą natomiast utworzyć dodatkowy skok przed właściwym przekierowaniem. Przetestuj rzeczywiste URL-e wejściowe, a nie tylko uproszczone ścieżki z mapy.

Automatyczny test mapy przekierowań

Tę samą mapę wykorzystaj w automatycznych testach, zamiast sprawdzać adresy ręcznie po wdrożeniu. Test powinien zatrzymać automatyczne podążanie za przekierowaniem, aby osobno ocenić pierwszy status i nagłówek Location:

import { describe, expect, it } from 'vitest'
import redirects from './redirects.json'
 
const baseUrl = process.env.TEST_BASE_URL ?? 'http://localhost:3000'
 
describe.each(redirects)('$source', ({ source, destination }) => {
  it('prowadzi bezpośrednio do właściwego celu', async () => {
    const response = await fetch(new URL(source, baseUrl), {
      redirect: 'manual',
    })
 
    expect([301, 308]).toContain(response.status)
 
    const location = response.headers.get('location')
    expect(location).not.toBeNull()
 
    const actualUrl = new URL(location!, baseUrl)
    const expectedUrl = new URL(destination, baseUrl)
 
    // Kontrolujemy także protokół, nazwę hosta, parametry zapytania i fragment,
    // co jest istotne przy zmianie domeny oraz migracji parametrów.
    expect(actualUrl.href).toBe(expectedUrl.href)
  })
})

Po sprawdzeniu pierwszego skoku wykonaj drugi test, który przechodzi kolejne odpowiedzi ręcznie, z ustalonym limitem liczby kroków. Dzięki temu wykryjesz pętlę lub dodatkowe przekierowanie, czego pojedyncze wywołanie fetch z automatycznym podążaniem nie pokaże. Końcowa strona powinna zwrócić 200, właściwy adres kanoniczny i oczekiwany fragment treści. Proces opisuję szerzej w artykule o kontroli jakości technicznego SEO.

Migracja treści z WordPressa do Next.js: wpisy, metadane i CMS

Eksport post_content obejmuje jedynie fragment danych WordPressa, a pełny zakres zależy od serwisu, ale zwykle zawiera wpisy, strony, własne typy treści, taksonomie, autorów, daty, komentarze, menu, pola niestandardowe i metadane wtyczek SEO. W przypadku WooCommerce dochodzą jeszcze produkty, warianty, kategorie, konta, zamówienia i integracje, co w zasadzie jest osobnym projektem migracyjnym.

Przy korzystaniu z REST API kontroluj liczbę rekordów za pomocą dedykowanych nagłówków X-WP-Total oraz X-WP-TotalPages. WordPress ogranicza parametr per_page do 100 rekordów, więc eksport musi poprawnie obsługiwać paginację. Pamiętaj, że błąd sieciowy, status 429 (zbyt wiele żądań) lub 500 (błąd serwera) nie mogą być zinterpretowane jako poprawny koniec procesu eksportu. Dodaj ponowienia z opóźnieniem, zapisuj identyfikatory pobranych rekordów i po zakończeniu porównaj ich liczbę w podziale na typy.

Jeżeli redakcja publikuje podczas migracji, sam jednorazowy eksport nie daje spójnego obrazu danych. Ustal moment odcięcia, wykonaj eksport przyrostowy po polu modified albo czasowo zamroź publikację. Po imporcie wykonaj uzgodnienie danych: policz rekordy źródłowe i docelowe, wykryj duplikaty, brakujące relacje, niedostępne media oraz elementy odrzucone przez transformację.

Automatyczna konwersja kodu HTML do formatu Markdown lub MDX stanowi użyteczny punkt wyjścia, jednak nie zapewnia wiernego odwzorowania zawartości z edytora Gutenberg. Shortcode'y, formularze, galerie, elementy osadzone, bloki dynamiczne, pola ACF, Elementor i nietypowy kod HTML wymagają dedykowanych reguł transformacji albo ręcznych decyzji. Oprócz technicznej walidacji składni potrzebny jest też wizualny i merytoryczny audyt reprezentatywnych szablonów oraz najważniejszych podstron generujących największy ruch.

Jeżeli treść trafia do MDX, ustal też nowy proces redakcyjny: kto publikuje, jak działa podgląd, planowanie publikacji, korekta, role i historia zmian. Next.js jest frameworkiem, a nie zamiennikiem panelu WordPressa.

Migracja mediów WordPressa: obrazy, pliki i next/image

Komponent next/image optymalizuje sposób dostarczania grafik, jednak sam w sobie nie jest magazynem plików. Pliki multimedialne mogą pozostać na stabilnym CDN lub dawnej domenie WordPressa, skąd będą obsługiwane jako zdalne źródła. Wtedy trzeba jawnie skonfigurować dozwolone remotePatterns. Alternatywnie można przenieść je do nowego magazynu albo zachować dotychczasową strukturę ścieżek /wp-content/uploads/.

Niezależnie od wariantu:

• Korzystaj z rzeczywistego adresu pliku, a nie pola WordPress guid

• Zachowaj lub zmapuj strukturę katalogów bez kolizji nazw

• Przenieś wymiary, alt, podpis, kredyt i powiązanie z treścią

• Uwzględnij PDF-y, wideo i inne pliki do pobrania
• Sprawdź warianty rozmiarów używane wcześniej w srcset

• Przekieruj stare URL-e plików tylko wtedy, gdy ich publiczne adresy naprawdę się zmieniły

Samo pobranie oryginalnych plików nie wystarczy, jeśli HTML nadal odwołuje się do miniaturek WordPressa albo nowa ścieżka różni się od celu przekierowania.

Techniczne SEO przed wdrożeniem Next.js: lista kontrolna

W App Routerze ustal jedno źródło prawdy dla metadanych. Skonfiguruj metadataBase w głównym układzie (layout), a dla dynamicznych wpisów generuj tytuł, opis, adres kanoniczny i alternatywne wersje językowe przez generateMetadata. Mapę witryny i reguły dla robotów możesz wystawić przez sitemap.ts oraz robots.ts. Sprawdź wynik w HTML-u odpowiedzi, ponieważ metadane dodawane dopiero przez efekt w komponencie klienckim nie powinny być podstawą technicznego SEO.

• Każdy URL z inwentaryzacji ma oczekiwany status: 200, 301/308, 404 albo 410

• Przekierowania prowadzą do trafnych, końcowych celów bez pętli i łańcuchów

• Nowa mapa witryny zawiera wyłącznie kanoniczne, indeksowalne URL-e zwracające 200

• Linki wewnętrzne prowadzą bezpośrednio do nowych URL-i, a nie przez przekierowania

• Tytuł strony, opis meta, link kanoniczny, dyrektywy robots, Open Graph i hreflang są poprawne

• Główna treść, nagłówki, autorzy i daty odpowiadają zaakceptowanej migracji

• Dane uporządkowane Schema.org w formacie JSON-LD są zgodne z widoczną treścią i przechodzą testy.

• Obrazy, PDF-y, kanały RSS lub Atom i pozostałe zasoby są dostępne.

• Formularze, wyszukiwarka, analityka, zgody i konwersje działają.

• Produkcyjny robots.txt i reguły noindex nie blokują ważnych ścieżek.

• Google Search Console pozostanie zweryfikowane po zmianie hostingu.

• Odpowiedź serwera zawiera właściwą treść i metadane bez oczekiwania na kod uruchamiany wyłącznie w przeglądarce.

Testuj zarówno priorytetowe strony, jak i próbki z każdego szablonu. Kontrola samych kodów HTTP nie wykryje pustego HTML-a, brakującej treści po renderowaniu, błędnego linku kanonicznego czy formularza, który przestał wysyłać zgłoszenia. Porównuj zarówno źródłowy HTML odpowiedzi, jak i DOM po wykonaniu JavaScriptu; to pozwala wykryć rozbieżności w renderowaniu, hydracji i metadanych.

Przełączenie hostingu i domeny: DNS, przekierowania i plan wycofania

Przełączenie domeny na inny hosting nie jest przekierowaniem. DNS zaczyna kierować ruch do nowej infrastruktury, a dopiero aplikacja, CDN lub serwer odpowiada właściwym statusem HTTP.

Przed wdrożeniem:

1. Obniż TTL rekordów DNS z wyprzedzeniem, jeśli zmieniasz hosting.
2. Ustal krótkie zamrożenie publikacji albo sposób synchronizacji zmian powstałych po eksporcie.
3. Przygotuj kopię zapasową, właściciela decyzji, instrukcję wycofania oraz konkretne progi, które je uruchamiają.
4. Włącz przekierowania najpóźniej w momencie skierowania ruchu na nową wersję.
5. Usuń produkcyjne noindex i blokady używane w środowisku testowym.
6. Sprawdź dostępność z zewnątrz, CDN, firewall, pamięć podręczną i wydajność serwera.
7. Pozostaw dostęp do starej infrastruktury i logów do czasu potwierdzenia poprawnego przełączenia.

Stałe przekierowania mogą zostać zapamiętane przez przeglądarkę lub CDN, dlatego plan wycofania musisz przetestować przed uruchomieniem ich na produkcji. Na środowisku testowym możesz najpierw zweryfikować mapę kodem tymczasowym, ale w momencie właściwej migracji adresów włącz przekierowania stałe. Wycofanie aplikacji i wycofanie mapy adresów to dwie osobne operacje i musisz określić, czy stara wersja potrafi obsłużyć nowe ścieżki i co stanie się z treściami opublikowanymi po przełączeniu.

Jeżeli zmienia się domena, stara domena musi nadal działać, utrzymywać ważny certyfikat TLS i obsługiwać przekierowania. Dopiero wtedy użyj narzędzia Zmiana adresu w Search Console. Zweryfikuj wszystkie warianty starej i nowej domeny, a dla każdego zweryfikowanego wariantu starego hosta i każdej subdomeny wyślij osobne zgłoszenie — także wtedy, gdy dany wariant nie był aktywnie używany. Narzędzia nie stosuje się do samej zmiany ścieżek, migracji HTTP do HTTPS, przejścia między www i wersją bez www w tej samej domenie ani zmiany hostingu przy zachowanych URL-ach.

Monitorowanie SEO po migracji: Search Console, logi i konwersje

Pierwsza kontrola powinna nastąpić bezpośrednio po wdrożeniu, wtedy sprawdź kluczowe URL-e, logowanie analityki, konwersje i błędy serwera. Potem, w kolejnych dniach, monitoruj nowe 404, 5xx, pętle przekierowań, zachowanie Googlebota oraz różnice w treści.

W Search Console przede wszystkim obserwuj:

• Indeksowanie stron i przyczyny wykluczeń,
• Statystyki indeksowania,
• Mapy witryn,
• Skuteczność z podziałem na strony i typy wyszukiwania,
• Sprawdzanie adresu URL dla reprezentatywnych przypadków,
• dane dla starej i nowej domeny, jeżeli domena się zmieniła.

Przy migracji zmieniającej adresy przygotuj dwie zamrożone listy: starą z adresami sprzed migracji i nową z kanonicznymi celami. Starą zachowaj jako dane do testów i monitorowania, natomiast w Search Console zgłoś nową mapę witryny zawierającą wyłącznie kanoniczne adresy zwracające 200. Po rozpoczęciu migracji starą mapę witryny można usunąć z Search Console; stan dawnych URL-i kontroluj za pomocą arkusza migracyjnego, raportów indeksowania, inspekcji adresów i logów serwera.

Ruch oceniaj w podziale na konkretne grupy stron oraz konwersje, zestawiając analogiczne okresy i uwzględniając sezonowość. Jeden zbiorczy wykres może zamaskować poważny problem dotyczący tylko wybranego szablonu podstron. Oznacz w analityce dokładny moment wdrożenia i zapisuj wszystkie późniejsze poprawki, aby odróżnić efekt migracji od kolejnych zmian.

Stałe przekierowania utrzymuj co najmniej rok, a jeśli stare linki nadal generują ruch, najlepiej bezterminowo. Intensywne monitorowanie może trwać kilka tygodni, ale kontrola mapy przekierowań i starych linków zewnętrznych powinna pozostać stałym elementem kontroli jakości.

Po przełączeniu zaktualizuj także najważniejsze linki, nad którymi masz kontrolę: profile firmy, wizytówki, kampanie reklamowe, newslettery i integracje partnerskie. W przypadku wartościowych linków zewnętrznych generujących dużo wejść warto, jeśli to możliwe, poprosić wydawcę o zmianę celu. Przekierowanie pozostaje zabezpieczeniem, ale bezpośredni link skraca ścieżkę użytkownika i zmniejsza obciążenie starej infrastruktury.

Błędy SEO przy migracji WordPress do Next.js

1. Zgubione dane Yoast lub RankMath. Tytuł, opis meta, dyrektywy robots i dane uporządkowane mogą znajdować się poza post_content.
2. Zbyt szerokie reguły wzorcowe. Historyczne końcówki adresów, języki, parametry i końcowe ukośniki mogą trafić do błędnego celu mimo pozornie regularnej struktury.
3. Kilka niespójnych warstw przekierowań. Reguły pozostawione jednocześnie w WordPressie, CDN, hostingu i Next.js łatwo tworzą pętle albo łańcuchy niewidoczne w jednej konfiguracji.
4. Zablokowana produkcja. Reguły noindex, robots.txt, firewall albo ochrona środowiska testowego pozostają aktywne po przełączeniu.
5. Brak kontroli funkcji biznesowych. Ruch może wyglądać poprawnie, mimo że formularze lub pomiar konwersji nie działają.
6. Testowanie wyłącznie w przeglądarce. Poprawny DOM po wykonaniu JavaScriptu może ukrywać pusty HTML, błędny status HTTP albo metadane niewidoczne w odpowiedzi serwera.

Migracja z WordPressa do Next.js ma sens przy projektach z dużą interaktywnością, niestandardowym interfejsem lub integracjami, które uzasadniają koszt nowej architektury. W wypadku blogów i stron opartych o treść, gdzie celem jest głównie szybkość i niski koszt utrzymania, podobne zasady SEO stosuje się przy przejściu na Astro, co opisuję w artykule o migracji bloga z WordPressa na Astro.