Jak sklonować stronę WordPress lokalnie

Kiedy zaczynasz na poważnie grzebać przy stronie — w WordPressie albo w jakimkolwiek innym systemie — przed startem musisz wbić sobie do głowy jedną podstawową zasadę: nie eksperymentuj na produkcji.

Z kilku powodów:

1. Bo skutki mogą być katastrofalne, jeśli nie wiesz dokładnie, czego dotykasz, albo nie masz backupu.
2. Bo przez to, a potem podczas przywracania wszystkiego, możesz zaliczyć bardzo niepotrzebny skok stresu.
3. I dlatego, że postawienie lokalnej kopii zajmie ci tylko pół godziny, a będziesz sobie za to wiecznie wdzięczny.

Powtórzę:

Najpierw stawiasz lokalną kopię. Potem grzebiesz. Nie odwrotnie.

W ostatnich dniach, kiedy mocno przebudowuję swoją stronę, musiałem to zrobić, więc skorzystałem z okazji i przygotowałem ten poradnik.

Moja strona miała kilka lat treści, 250 wpisów, obrazy zbierane od 2013 roku i taki rozmiar, że Duplicator utknął w połowie dwa razy, zanim w końcu zadziałał.

To też tu jest. Błędy — i ich rozwiązania — w pakiecie.

Po co mieć lokalny klon WordPressa

Lokalna kopia pozwala pracować na komputerze bez dotykania prawdziwej strony.

Przydaje się do: testowania wtyczek, zmiany motywu, przeglądania bazy danych, przygotowania migracji, audytu technicznego, instalacji Polylang, modyfikacji CSS albo psucia rzeczy bez tego, żeby Google, użytkownicy czy klient cokolwiek zauważyli.

W moim przypadku cel był podwójny:

1. Całkowicie zmienić projekt, przechodząc ze strony nastawionej na pozyskiwanie leadów na magazyn cyfrowy.
2. Przygotować stronę do tłumaczenia wspomaganego przez AI. Własne rozwiązanie z pewnym poziomem ryzyka, bo oznacza ruszanie kilku rzeczy naraz.

W każdym razie proces jest taki sam, jeśli chcesz automatycznie zmienić kategorie, zmienić motyw, dodać dużą wtyczkę typu WooCommerce albo po prostu mieć środowisko testowe, zanim dotkniesz czegoś poważnego.

Narzędzia, których użyłem

• LocalWP: do utworzenia lokalnego środowiska WordPress.
• Duplicator: do eksportu strony produkcyjnej.
• cPanel: panel administracyjny hostingu użyty do ręcznego pobrania folderu z obrazami.
• WP-CLI: dołączony do LocalWP, żeby poprawić wewnętrzne opcje WordPressa.

Wszystko za darmo.

Przewodnik krok po kroku: jak sklonować WordPress lokalnie

Skoro znasz już narzędzia, przejdźmy do kroków, których jest trochę więcej niż zwykle.

Tak czy inaczej, żebyś miał punkt odniesienia, w około 30 minut będziesz mieć wszystko gotowe, zależnie od problemów, które się pojawią. Jeśli twoja strona jest mała i nie wyskoczy żaden błąd, możliwe, że zajmie ci to mniej niż dziesięć minut.

Mało która inwestycja zwraca się lepiej.

Krok 1: zainstaluj LocalWP

LocalWP tworzy lokalne instalacje WordPressa bez ręcznego konfigurowania Apache, MySQL i PHP. Nie potrzebujesz XAMPP, WAMP ani LAMP.

Instalujesz go, tworzysz nową stronę i po dwóch minutach masz czystego WordPressa działającego na swoim komputerze.

W moim przypadku nazwałem ją yg, więc LocalWP przypisał jej lokalną domenę https://yg.local z takim środowiskiem:

Pole	Wartość
Serwer	nginx
PHP	8.2
Baza danych	MySQL
WordPress	Czysta instalacja

To wystarczy, żeby zacząć.

Krok 2: sprawdź, czy lokalny WordPress się otwiera

Zanim cokolwiek zaimportujesz, otwórz lokalną stronę i wejdź do panelu:

• https://yg.local
• https://yg.local/wp-admin

Jeśli się ładuje i możesz wejść, środowisko jest gotowe. Niczego jeszcze nie instaluj. Nie ruszaj ustawień. Po prostu sprawdź, czy działa.

Krok 3: zainstaluj Duplicator na prawdziwej stronie

Wejdź do produkcyjnego WordPressa (nie lokalnego) i zainstaluj Duplicator:

Wtyczki > Dodaj nową > Duplicator

Zainstaluj go i aktywuj.

Ważne: Duplicator instaluje się na produkcji. Chodzi o to, żeby wygenerować pakiet prawdziwej strony, a potem zaimportować go do LocalWP.

Krok 4: utwórz kopię za pomocą Duplicator

Z panelu produkcyjnego przejdź do:

Duplicator > Packages

Utwórz nowy pakiet z nazwą, po której będzie wiadomo, do czego służy. Ja użyłem:

yagogonzalez-copia-local-fase0

Wstępny skan ostrzegł, że strona jest duża. Nic dziwnego przy stronach z latami treści.

Problem pojawił się podczas budowania pakietu:

Couldn't close zip archive

Serwer nie zdołał zamknąć pliku ZIP.

To nie znaczy, że strona się zepsuła. To znaczy, że hosting nie był w stanie dokończyć operacji, prawdopodobnie przez rozmiar, czas wykonania albo limity pamięci.

Pierwszy problem do rozwiązania.

Krok 5: wypróbuj DupArchive, jeśli ZIP zawodzi

Duplicator oferuje alternatywę, gdy ZIP zawodzi: DupArchive.

Do tego trzeba zmienić silnik archiwum z ZIP na DupArchive. Pakiet generuje się wtedy jako .daf zamiast .zip.

Zmienia się to tutaj:

Duplicator > Ustawienia > Kopie zapasowe > Archiwum

Tam znajdź Archive Engine i zmień ZipArchive na DupArchive.

Potem zapisz zmiany.

Wszystko gotowe?

No nie. Nowy błąd:

Łączny rozmiar plików i bazy danych przekracza limit 500 MB

Kopia ważyła około 1,33 GB. Sama zmiana tego ustawienia też nic nie dawała.

Rozwiązanie: nie wkładać wszystkiego do pakietu.

Krok 6: utwórz pakiet bez folderu uploads

Folder, który najbardziej podbija wagę każdego WordPressa z kilkuletnią historią, to wp-content/uploads/. 

Tam są obrazy, PDF-y, miniatury, WebP i wszystko, co zostało przesłane od pierwszego dnia.

Żeby zmniejszyć pakiet do pobrania, w Duplicator włączyłem filtry plików i wykluczyłem:

• wp-content/uploads/
• wp-content/cache/
• wp-content/upgrade/
• wp-content/backups-dup-lite/
• wp-content/plugins/duplicator/backups/

Dzięki temu pakiet zawiera to, co ważne do odtworzenia strony: bazę danych, WordPress, motyw, wtyczki, konfigurację, wpisy, strony, taksonomie, ACF, Yoast i ustawienia wewnętrzne.

Obrazy pobierzemy osobno. W kroku 8 wyjaśniam, jak.

Krok 7: pobierz pliki Duplicator

Po wygenerowaniu pakietu Duplicator tworzy dwa pliki:

• installer.php
• plik .zip albo .daf

Pobierz oba.  

To one pozwalają odtworzyć stronę lokalnie. Instalator zajmuje się wypakowaniem pakietu, importem bazy danych, podmianą adresów URL i dostosowaniem ścieżek.

Krok 8: pobierz folder uploads

Ponieważ uploads nie był w pakiecie, trzeba pobrać go ręcznie z hostingu.

Typowa ścieżka w WordPressie:

/public_html/tudominio.com/wp-content/uploads/

Jeśli masz normalny hosting, możesz pobrać go z opcji menedżera plików w cPanelu. Tak zrobiłem ja.

Jeśli nie możesz zrobić tego tą drogą, trzeba będzie zrobić to po staremu, pobierając go przez FTP albo SFTP bezpośrednio na komputer za pomocą FileZilla albo podobnego programu.

Rada: nie kompresuj folderu na serwerze. To znowu obciążyłoby hosting i mogłoby zawieść tak samo jak Duplicator. Bezpośrednie pobieranie jest wolniejsze, ale bezpieczniejsze.

Krok 9: przygotuj LocalWP do importu kopii

Po pobraniu dwóch plików Duplicator wróć do LocalWP:

1. Dla lokalnej strony: kliknij Stop site.
2. Otwórz folder strony: kliknij Site folder.
3. Wejdź do app > public.
4. Usuń zawartość public (czystego WordPressa utworzonego przez LocalWP).
5. Skopiuj tam oba pliki Duplicator.

Ważne: trzeba usunąć zawartość public, a nie folder public.

Folder musi istnieć, a w środku powinny być tylko dwa pobrane pliki:

• installer.php
• copia-local.daf

Potem uruchom stronę: kliknij Start site.

Krok 10: uruchom lokalnie instalator Duplicator

Otwórz instalator w przeglądarce:

https://yg.local/installer.php

Instalator wykrywa pakiet i rozpoczyna proces.

Do połączenia z lokalną bazą danych użyj danych z LocalWP:

Pole	Wartość
Database Host	localhost
Database Name	local
User	root
Password	root

Ponieważ była to pusta lokalna instalacja (ta, którą program tworzy domyślnie na początku), zaznacz, że akceptujesz usunięcie poprzedniej bazy danych przez Duplicator. 

Nic się nie dzieje: usuwał tylko czystego WordPressa z LocalWP, nie prawdziwą stronę.

Potem Duplicator podmienia adresy URL:

• Old URL: https://yagogonzalez.com
• New URL: https://yg.local

Po zakończeniu możesz już wejść do lokalnego WordPressa.

Ważne: po imporcie bazy danych użytkownik i hasło są tymi z prawdziwej strony, a nie tymi utworzonymi początkowo w LocalWP.

Krok 11: wyczyść pliki instalacyjne

Duplicator zwykle usuwa pliki instalatora po zakończeniu:

• installer.php
• plik .daf
• folder dup-installer
• logi instalacji

Na produkcji jest to ważne ze względów bezpieczeństwa. Lokalnie jest mniej krytyczne, ale warto zostawić porządek.

Przed przejściem dalej sprawdź, czy po instalacji już ich nie ma.

Krok 12: skopiuj uploads do lokalnego WordPressa

Przy zatrzymanej stronie (Stop site) w LocalWP wejdź do app > public > wp-content i skopiuj tam folder uploads który pobrałeś.

Prawidłowa struktura:

<em>wp-content/</em>
├── plugins/

├── themes/

└── uploads/

    ├── 2013/

    ├── 2014/

    ...

    └── 2026/

Co nie powinno się zdarzyć:

wp-content/uploads/uploads/2026/

To podwójne uploads/uploads to klasyczny błąd po spakowaniu do ZIP-a przed pobraniem i psuje wszystkie ścieżki obrazów.

Krok 13: napraw problem z uszkodzonymi obrazami

W moim przypadku tutaj pojawił się największy problem (bo niespodziewany): strona się ładowała, ale obrazów nie było widać. I nie chodziło o ścieżkę z podwójnym upload.

Problem był w URL-u, który WordPress generował dla obrazów:

https://yg.local/C:/Users/pcadmin/Local Sites/yg/app/public/wp-content/uploads/2026/06/imagen.webp

Wszystko zaznaczone pogrubieniem było zbędne. Prawidłowy URL powinien wyglądać tak:

https://yg.local/wp-content/uploads/2026/06/imagen.webp

WordPress miał zapisaną w opcji upload_path bezwzględną ścieżkę Windows:

C:/Users/pcadmin/Local Sites/yg/app/public/wp-content/uploads

Żeby to poprawić, otwórz Site shell w LocalWP i uruchom te trzy komendy jedna po drugiej:

wp --url=https://yg.local option delete upload_path

wp --url=https://yg.local option delete upload_url_path 

wp --url=https://yg.local cache flush

Po wykonaniu tych poleceń i odświeżeniu strony obrazy już się pojawiały.

Problem w tym, że pojawiło się też kilka Warnings (ostrzeżeń).

Krok 14: popraw widoczne warnings

Jak mówiłem, na lokalnej stronie pojawiał się ten warning:

Constant WP_POST_REVISIONS already defined

Tutaj posiłkowałem się ChatGPT, bo nie miałem pojęcia, jak to rozwiązać.

Problem pochodził z functions.php motywu, który definiował WP_POST_REVISIONS bez sprawdzenia, czy nie była już zdefiniowana gdzieś indziej.

Poprawka:

<em>if ( ! defined( 'WP_POST_REVISIONS' ) ) {</em>
<em>    define( 'WP_POST_REVISIONS', false );</em>
<em>}</em>

Jeśli w twoim przypadku wartość jest inna, po prostu zachowaj swoją:

<em>if ( ! defined( 'WP_POST_REVISIONS' ) ) {</em>
<em>    define( 'WP_POST_REVISIONS', <strong>5</strong> );</em>
<em>}</em>

Zmieniłem to z menedżera plików motywu WordPressa (Wygląd > Edytor plików motywu), zapisałem plik i gotowe.

Krok 15: posprzątaj produkcję

Kiedy lokalna kopia działa, wróć do prawdziwej strony i usuń ślady po Duplicator:

1. Duplicator > Packages:  usuń utworzone pakiety.
2. Wtyczki > Zainstalowane wtyczki: odinstaluj Duplicator.

To nie wpływa na lokalną kopię. Po prostu nie zostawiasz na produkcji ciężkich pakietów i zbędnych instalatorów.

Nie jest to obowiązkowe, ale zdecydowanie zalecane.

Krok 16: przetestuj lokalny klon

Sprawdź kilka adresów URL zanim pójdziesz dalej.  

W moim przypadku sprawdziłem:

• Stronę główną.
• Wpis.
• Kategorię.
• Podkategorię.
• Tag.

Zrobiłem tak, bo każda z nich używa innego szablonu:

• https://yg.local
• https://yg.local/ruta-de-escape
• https://yg.local/tecnologia
• https://yg.local/ocio/series
• https://yg.local/negocio

Cztery rzeczy do sprawdzenia:

1. Strona się ładuje.
2. Obrazy są widoczne.
3. Wygląd jest taki sam jak na produkcji.
4. Linki wewnętrzne wskazują na yg.local, a nie na yagogonzalez.com.

Ten ostatni punkt jest kluczowy. Jeśli klikasz artykuł i przenosi cię na produkcję, nadal masz źle podmienione adresy URL.

Krok 17: utwórz punkt przywracania przed dalszą pracą

Ten krok znowu jest opcjonalny, ale zalecany.

Zanim zaczniesz wprowadzać potrzebne zmiany lokalnie albo ruszać cokolwiek poważnego, utwórz punkt przywracania.

W LocalWP możesz sklonować stronę:

Clone site

W moim przypadku utworzyłem kopię o nazwie yg-pre-polylang.

Logika jest prosta:

• yg = lokalna strona robocza.
• yg-pre-polylang = czysta kopia przed dotykaniem czegokolwiek.

Jeśli coś padnie, nie trzeba powtarzać całej migracji z produkcji od zera, tylko biorę tę czystą kopię i pracuję na niej. Oczywiście wcześniej znowu ją klonując, jasne.

Typowe problemy w tym procesie

Lokalne migracje prawie nigdy nie wychodzą idealnie za pierwszym razem. Zbieram tutaj te, które pojawiły się w tym przypadku.

ZIP Duplicator się wysypał

Błąd: Couldn't close zip archive

Przyczyna: limity serwera (rozmiar, czas wykonania, pamięć).

Rozwiązanie: wypróbować DupArchive albo wykluczyć ciężkie foldery z pakietu.

DupArchive miał limit rozmiaru

Błąd: pakiet przekraczał 500 MB.

Rozwiązanie: wykluczyć wp-content/uploads/ i pobrać ten folder osobno.

Obrazy się nie ładowały

Przyczyna: WordPress używał bezwzględnej ścieżki Windows tak, jakby była publicznym URL-em.

Rozwiązanie:

wp option delete upload_path

wp option delete upload_url_path

Warning PHP z powodu już zdefiniowanej stałej

Przyczyna: WP_POST_REVISIONS zdefiniowana dwa razy w functions.php.

Rozwiązanie: owinąć definicję w if ( ! defined(…) ).

Podsumowanie

Jeśli twoja strona waży mało, Duplicator robi wszystko sam. Ale jeśli ma lata treści i nazbierane obrazy, zwykle trzeba podzielić proces na dwie części:

• Duplicator = baza danych + WordPress + motyw + wtyczki
• FTP/SFTP = folder uploads

A potem sprawdzić ścieżki, obrazy, warnings i linki wewnętrzne, zanim dotkniesz czegokolwiek poważnego.

Lokalna kopia jest nic niewarta, jeśli naprawdę nie działa.

A jeśli zamierzasz ruszać coś delikatnego — wielojęzyczność, redesign, duże wtyczki, migracje SEO — robienie tego bezpośrednio na produkcji to podejmowanie niepotrzebnego ryzyka.

Masz narzędzia. Są darmowe. A proces, choć nie jest automatyczny, da się zrobić w pół godziny.

Pamiętaj:

Najpierw lokalnie. Potem testy. Dopiero potem produkcja. W tej kolejności.

Jak Bale i golf, tylko zastosowane do WordPressa.

Swoją drogą, tutaj zostawiam ci kontynuację tego artykułu: jak zoptymalizować szybkość WPLocal.