# Jak wyeksportować posty z WordPressa bez błędów bazy danych?

> Posty z WordPressa wyeksportujesz bez błędów bazy danych, nie zrzucając całej bazy naraz, lecz pobierając treść w częściach: najlepiej przez API REST albo wbudowany eksport, a gdy backend nie odpowiada, czytając publiczne strony. Błędy bazy przy eksporcie biorą się z robienia wszystkiego w jednym ciężkim kroku: duży zrzut SQL przekracza limit pamięci albo czasu i kończy się błędem, a uszkodzony rekord potrafi przerwać cały eksport. Rozwiązaniem jest rozbicie pracy: API REST zwraca posty stronami jako JSON, wbudowany eksport WordPressa robi plik WXR, a oba można podzielić na partie. Tak unikasz jednego procesu, który pada. Posty wyjdą jako czyste dane, gotowe do headless albo statycznej strony. WPBuildAI skanuje stronę i zwraca posty jako czysty Markdown, bez obciążania bazy.

Source: https://wpbuildai.com/pl/eksport-postow-wordpress/
By lawrence-arya · 2026-06-05

---
Posty z WordPressa wyeksportujesz bez błędów bazy danych, nie zrzucając całej bazy naraz, lecz pobierając treść w częściach: najlepiej przez API REST albo wbudowany eksport, a gdy backend nie odpowiada, czytając publiczne strony. Sedno jest w tym, skąd biorą się błędy. Powstają, gdy próbujesz zrobić wszystko w jednym ciężkim kroku: duży zrzut SQL przekracza limit pamięci albo czasu serwera i kończy się błędem, a pojedynczy uszkodzony rekord potrafi przerwać cały eksport. Rozwiązaniem jest rozbicie pracy na części: API REST zwraca posty stronami jako JSON, wbudowany eksport WordPressa robi plik WXR, a oba da się podzielić na partie. Tak unikasz jednego procesu, który pada. Posty wyjdą jako czyste dane, gotowe do strony headless albo statycznej. WPBuildAI skanuje stronę i zwraca posty jako czysty Markdown, bez obciążania bazy.

## Skąd biorą się błędy bazy przy eksporcie

Warto zrozumieć przyczynę, bo wskazuje rozwiązanie. Eksport przez zrzut całej bazy to jedna wielka operacja: serwer musi spakować wszystkie posty, pola i powiązania w jeden plik, co zużywa dużo pamięci i czasu. Gdy baza jest duża, serwer przerywa po przekroczeniu limitu i dostajesz błąd pamięci albo timeout. Do tego jeden uszkodzony albo nietypowy rekord potrafi wywrócić cały zrzut. Web Almanac 2024 ([HTTP Archive](https://almanac.httparchive.org/en/2024/)) przypomina, ile WordPress robi przy każdym żądaniu, a pełny zrzut piętrzy to w jednym kroku. Rozwiązaniem nie jest mocniejszy serwer, lecz mniejsze kroki.

## Sposób 1: API REST stronami

Najczystszy sposób z dostępem to [WordPress REST API](https://developer.wordpress.org/rest-api/), które zwraca posty jako JSON, stronami. Zamiast jednego wielkiego zrzutu pobierasz na przykład po 20 postów na raz, strona po stronie, więc żadne pojedyncze żądanie nie jest ciężkie. Jeśli jedna partia ma problem, widzisz dokładnie którą, zamiast tracić cały eksport. Dane wychodzą strukturalnie: tytuł, treść, slug, data, gotowe do zamiany na Markdown dla strony headless albo statycznej. To podejście omija właśnie ten ciężki krok, który wywraca zrzut bazy, i daje kontrolę nad tym, co już masz, a co jeszcze nie.

## Sposób 2: wbudowany eksport WordPressa (WXR)

Drugi sposób to wbudowany eksport WordPressa, w Narzędzia, Eksport, który tworzy plik WXR, czyli XML ze wszystkimi postami. Jest lżejszy od pełnego zrzutu SQL, bo eksportuje treść, a nie całą bazę z ustawieniami i tabelami systemowymi. Co ważne, pozwala wybrać zakres, na przykład tylko wpisy albo tylko jeden okres, więc duży blog możesz wyeksportować w kilku plikach WXR zamiast jednego ogromnego. To dobre rozwiązanie, gdy chcesz prostoty i nie potrzebujesz JSON-a, podobnie jak przy [eksporcie całej strony do HTML](/pl/jak-wyeksportowac-cala-strone-wordpress-html). Każdy plik WXR jest mniejszym, bezpieczniejszym krokiem niż zrzut bazy.

## Sposób 3: bez dostępu, ze stron publicznych

Jeśli backend w ogóle nie odpowiada, na przykład przez te same błędy bazy, posty pobierzesz, czytając publiczne strony. Crawler obchodzi blog, otwiera każdy wpis i zapisuje treść, obrazy i metadane jako pliki. Ta droga w ogóle nie dotyka bazy ani panelu, więc błędy bazy jej nie dotyczą, podobnie jak przy [przenoszeniu sklepu, gdy wtyczka pada z timeoutu](/pl/jak-przeniesc-sklep-woocommerce-serwer-bez-wtyczek-timeout). Ograniczeniem jest to, że pobierzesz tylko opublikowane, widoczne wpisy, nie szkice ani treści ukryte. Ale gdy baza odmawia współpracy, jest to często jedyny sposób, żeby odzyskać posty, i daje je jako czyste dane.

## Rozbij pracę na partie

Wspólny mianownik trzech sposobów to ten sam ruch: rozbić pracę na partie. Niezależnie od metody, mniejsze kroki nie przekraczają limitów serwera i nie wywracają się na jednym rekordzie. Jeśli coś pójdzie nie tak, tracisz jedną partię, nie cały eksport, i wiesz, gdzie wznowić. To jest różnica między eksportem, który pada na dużym blogu, a takim, który spokojnie przechodzi. Zasada jest ogólna: nie pakuj wszystkiego w jeden proces, który albo się uda, albo straci wszystko. Partia po partii eksport jest przewidywalny, nawet gdy bloga są tysiące wpisów.

## Zachowaj adresy i metadane

Eksport to nie tylko sam tekst, liczą się też adresy i metadane. Zachowaj slug każdego posta, bo to on tworzy adres URL, oraz tytuły i opisy, czyli sygnały SEO budowane latami. Jeśli posty trafią na nową stronę headless albo statyczną pod tymi samymi adresami, nic nie tracisz; jeśli adresy się zmienią, ustaw przekierowania 301, zgodnie z poradnikiem o [przeniesieniu witryny](https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes). To treść i adresy decydują o pozycjach, jak pokazuje [analiza Backlinko](https://backlinko.com/search-engine-ranking), więc eksportuj je razem z tekstem, a nie tylko goły tekst, jak przy [zmianie CMS bez utraty pozycji](/pl/jak-zmienic-cms-bez-utraty-pozycji-google).

## Krok po kroku

1. **Nie zrzucaj całej bazy** naraz, jeśli blog jest duży.
2. **Wybierz metodę:** API REST, eksport WXR, albo strony publiczne.
3. **Pobieraj w partiach**, stronami lub w kilku plikach.
4. **Zachowaj slugi i metadane** razem z treścią.
5. **Sprawdź liczbę postów** względem oryginału.
6. **Przy zmianie adresów** ustaw przekierowania 301.

## Przykład: eksport dużego bloga bez błędów

Weźmy blog z 3000 wpisów, którego pełny zrzut SQL za każdym razem kończy się timeoutem. Zamiast go zmuszać, posty pobiera się przez API REST stronami, po 50 na raz, więc żadne żądanie nie jest ciężkie i widać postęp partia po partii. Każdy post wychodzi jako czyste dane: tytuł, treść w Markdown, slug, data. Jedna partia trafia na nietypowy rekord i zostaje ponowiona osobno, bez utraty reszty. Liczba pobranych postów zgadza się z oryginałem. Slugi zostają zachowane jako adresy na nowej stronie statycznej, a nieliczne zmienione dostają 301. Eksport, który w wersji „zrzuć wszystko" padał, przeszedł spokojnie, bo praca została rozbita na partie.

## Częste błędy

- Zrzucanie całej bazy naraz na dużym blogu, co pada z limitu.
- Traktowanie jednego uszkodzonego rekordu jako powodu utraty całego eksportu.
- Eksport samego tekstu bez slugów i metadanych.
- Niesprawdzenie liczby postów i przeoczenie brakujących.
- Zmiana adresów postów bez przekierowań 301.

## Co warto zapamiętać

Posty z WordPressa wyeksportujesz bez błędów bazy danych, nie zrzucając całej bazy naraz, lecz pobierając treść w częściach: przez API REST stronami, wbudowanym eksportem WXR w kilku plikach, albo ze stron publicznych, gdy backend nie odpowiada. Błędy biorą się z jednego ciężkiego kroku, który przekracza limit pamięci lub czasu, więc rozbij pracę na partie, żeby tracić najwyżej jedną, nie całość. Zachowaj slugi i metadane razem z treścią, sprawdź liczbę postów i ustaw 301 przy zmianie adresów. Posty wyjdą jako czyste dane, gotowe do headless albo statycznej strony. WPBuildAI skanuje stronę i zwraca posty jako czysty Markdown, bez obciążania bazy. Wyślij adres swojej strony, żeby otrzymać bezpłatną analizę.

Bez powiązania z WordPress, Lovable, Webflow, Shopify, Wix ani Squarespace.