Migracja WordPress bezpiecznie krok po kroku

Mariusz Szatkowski

Ostatnio zweryfikowano: 13 października 2026

24 min czytania

Poradnik

Full-stack developer

500+ projektów WP

Przenoszenie witryny WordPress może być zniechęcającym zadaniem, ale z odpowiednią wiedzą i przygotowaniem staje się procesem do zarządzania. Niezależnie od tego, czy zmieniasz domenę, ulepszasz hosting, czy restrukturyzujesz architekturę witryny, ten kompleksowy przewodnik przeprowadzi Cię przez każdy krok procesu migracji WordPress.

#Zrozumienie adresów URL witryny WordPress

Zanim zagłębimy się w techniki migracji, kluczowe jest zrozumienie dwóch fundamentalnych ustawień URL w WordPress:

Adres WordPress (URL): Tutaj znajdują się Twoje podstawowe pliki WordPress
Adres Witryny (URL): To adres, który odwiedzający wpisują w przeglądarce, aby dotrzeć do Twojej witryny

Oba ustawienia powinny zawierać część https:// i nie powinny mieć ukośnika / na końcu. Te ustawienia kontrolują, jak WordPress wyświetla adresy URL w całej Twojej witrynie, w tym w sekcji administracyjnej i frontendzie.

#Dlaczego migracja WordPress staje się konieczna

Kilka scenariuszy może wymagać migracji Twojej witryny WordPress:

Zmiany Domeny: Rebranding lub przejście na lepszą nazwę domeny
Migracja Hostingu: Przejście na lepszego dostawcę hostingu
Zmiany Serwera: Uaktualnienie infrastruktury serwera
Restrukturyzacja Witryny: Przeniesienie WordPress do podkatalogu lub katalogu głównego
Rozwój do Produkcji: Przeniesienie ze środowiska staging do produkcji
HTTP do HTTPS: Wdrożenie certyfikatów SSL

#Jak przygotować WordPress do migracji

#Co zabezpieczyć przed migracją WordPress

Zanim spróbujesz jakiejkolwiek migracji, stwórz kompleksowe kopie zapasowe:

Kopia Zapasowa Bazy Danych: Eksportuj bazę danych WordPress przez phpMyAdmin lub WP-CLI
Kopia Zapasowa Plików: Pobierz wszystkie pliki i katalogi WordPress
Kopia Zapasowa Konfiguracji: Zapisz plik wp-config.php osobno
Ustawienia Pluginów/Motywów: Dokumentuj niestandardowe konfiguracje

#Jak przetestować migrację na kopii stagingowej

Zawsze testuj migracje w środowisku staging przed przejściem na produkcję:

## Utwórz podkatalog testowy
mkdir /var/www/html/test-site
## Skopiuj pliki do lokalizacji testowej
cp -r /var/www/html/wordpress/* /var/www/html/test-site/

#Jak zmienić adres URL WordPress po przeniesieniu

#Metoda 1: WP_HOME i WP_SITEURL w wp-config.php

Dla tymczasowych zmian URL, dodaj te linie do swojego wp-config.php:

define('WP_HOME', 'https://example.com');
define('WP_SITEURL', 'https://example.com');

Zalety: Szybkie i natychmiastowe Wady: Wartości hardkodowane, nie można już edytować w admin WordPress

#Metoda 2: zmiana siteurl i home przez functions.php

Jeśli masz dostęp FTP, ale nie możesz uzyskać dostępu do admin WordPress:

Uzyskaj dostęp do pliku functions.php aktywnego motywu
Dodaj te linie po otwierającym tagu <?php:

update_option('siteurl', 'https://example.com');
update_option('home', 'https://example.com');

Prześlij plik i odwiedź swój panel administracyjny
Ważne: Usuń te linie po tym, jak witryna zacznie działać

#Metoda 3: stała RELOCATE w wp-config.php

WordPress zawiera automatyczną metodę relokacji:

Edytuj wp-config.php i dodaj przed “That’s all, stop editing!”:

define('RELOCATE', true);

Odwiedź https://yoursite.com/wp-login.php
Zaloguj się normalnie
Sprawdź Ustawienia > Ogólne, aby zweryfikować adresy URL
Usuń stałą RELOCATE po tym

Ostrzeżenie Bezpieczeństwa: Nigdy nie zostawiaj stałej RELOCATE w wp-config.php, ponieważ tworzy luki w zabezpieczeniach.

#Metoda 4: edycja siteurl i home w phpMyAdmin

Dla precyzyjnej kontroli, edytuj adresy URL bezpośrednio w bazie danych:

Uzyskaj dostęp do phpMyAdmin
Wybierz bazę danych WordPress
Znajdź tabelę wp_options (prefiks może się różnić)
Edytuj wiersze ‘siteurl’ i ‘home’
Zaktualizuj option_value do nowych adresów URL

Krytyczne: Zawsze twórz kopię zapasową bazy danych przed bezpośrednimi edycjami!

#Przeniesienie WordPress na inny serwer lub domenę

#Jak przenieść WordPress na nowy serwer

Podczas migracji na nowy serwer:

Stwórz Kopię Zapasową Wszystkiego: Kompletna kopia zapasowa witryny i bazy danych
Eksportuj Bazę Danych: Użyj phpMyAdmin lub WP-CLI
Przenieś Pliki: Użyj FTP, SFTP lub rsync
Importuj Bazę Danych: Utwórz nową bazę danych i importuj
Zaktualizuj wp-config.php: Zmień dane logowania do bazy danych
Zaktualizuj Adresy URL: Użyj jednej z powyższych metod
Przetestuj Dokładnie: Sprawdź wszystkie funkcjonalności

#Jak zmienić domenę WordPress przez WP-CLI

Zmiana domeny wymaga szczególnej uwagi na serializowane dane:

## Użycie WP-CLI (zalecane)
wp search-replace 'staradomena.com' 'nowadomena.com' --skip-columns=guid

## Lub użyj wyspecjalizowanych pluginów jak:
## - Better Search Replace

Ważne: Nigdy nie aktualizuj kolumny GUID w tabeli wp_posts. GUID oznacza Global Unique Identifier i nigdy nie powinien być zmieniany, aby utrzymać kompatybilność z czytnikami kanałów.

#Migracja z podkatalogu do głównego

Przenoszenie WordPress z podkatalogu do głównego:

Zaktualizuj Adresy URL w Admin WordPress: Ustawienia > Ogólne
Skopiuj Pliki: Przenieś pliki WordPress do nowej lokalizacji
Zaktualizuj .htaccess: Zmień reguły rewrite
Zaktualizuj Permalinki: Zapisz ponownie strukturę permanentnych linków
Sprawdź Wewnętrzne Linki: Zaktualizuj hardkodowane adresy URL

#Migracja multisite

WordPress Multisite wymaga dodatkowych uwag:

Kopia Zapasowa Sieci: Wszystkie witryny i bazy danych
Edytuj wp-config.php: Zaktualizuj stałe multisite
Zaktualizuj .htaccess: Zmień reguły rewrite multisite
Aktualizacje Bazy Danych: Zaktualizuj tabele wp_blogs i wp_site
Opcje Indywidualnych Witryn: Zaktualizuj tabele opcji każdej witryny

#Co sprawdzić po migracji WordPress

#Co przetestować zaraz po migracji

Przetestuj funkcjonalność frontend
Zweryfikuj dostęp admin
Sprawdź wszystkie formularze i zgłoszenia
Przetestuj funkcjonalność e-commerce
Zweryfikuj logowanie/rejestrację użytkowników

#Przekierowania 301 i mapa witryny po zmianie domeny

Wdroż przekierowania 301 ze starych adresów URL
Zaktualizuj sitemap.xml
Wyślij nową mapę witryny do wyszukiwarek
Zaktualizuj właściwość Google Analytics
Zweryfikuj Google Search Console

#Cache, baza danych i SSL po migracji

Wyczyść wszystkie pamięci podręczne
Optymalizuj tabele bazy danych
Sprawdź kompatybilność pluginów
Przetestuj prędkość witryny
Zweryfikuj certyfikat SSL

#Wspólne problemy migracji i rozwiązania

#Biały ekran śmierci po migracji

Zwykle spowodowany przez:

Wyczerpanie limitu pamięci
Konflikty pluginów
Niekompatybilność motywu

Rozwiązanie: Zwiększ limit pamięci w wp-config.php:

define('WP_MEMORY_LIMIT', '256M');

#Błędy połączenia z bazą danych

Sprawdź ustawienia wp-config.php:

define('DB_NAME', 'database_name');
define('DB_USER', 'username');
define('DB_PASSWORD', 'password');
define('DB_HOST', 'localhost');

#Problemy z mieszaną zawartością

Zasoby HTTP na stronach HTTPS powodują ostrzeżenia bezpieczeństwa:

## Znajdź mieszaną zawartość
grep -r "http://" wp-content/

#Problemy z linkami obrazów i mediów

Zaktualizuj adresy URL mediów w bazie danych:

UPDATE wp_posts SET post_content = REPLACE(post_content,'staradomena.com/wp-content/uploads','nowadomena.com/wp-content/uploads');

#Narzędzia i pluginy do migracji

#Polecane pluginy migracyjne

All-in-One WP Migration: Kompletne narzędzie migracji witryny
Duplicator: Łatwo twórz pakiety migracyjne
WP Migrate Lite (dawniej WP Migrate DB): eksport bazy z wyszukiwaniem i zamianą
Better Search Replace: wyszukiwanie i zamiana z kokpitu, z obsługą danych serializowanych (Velvet Blues Update URLs zamknięto w katalogu wtyczek 3 maja 2024)

#Komendy WP-CLI do eksportu, importu i search-replace

## Eksport bazy danych WP-CLI
wp db export backup.sql

## Import bazy danych WP-CLI
wp db import backup.sql

## Szukaj i zamień
wp search-replace 'stary-url' 'nowy-url' --dry-run

#Kwestie bezpieczeństwa podczas migracji

Używaj HTTPS: Upewnij się, że SSL jest skonfigurowany na nowym serwerze
Zaktualizuj Uprawnienia Plików: Zabezpiecz wp-config.php (600) i katalogi (755)
Usuń Skrypty Migracyjne: Usuń pliki tymczasowe i stałe
Zaktualizuj Klucze Bezpieczeństwa: Wygeneruj nowe klucze WordPress w wp-config.php
Monitoruj Logi: Obserwuj nietypową aktywność po migracji

#Jak przyspieszyć WordPress po migracji

#Optymalizacja tabel bazy przez OPTIMIZE TABLE

OPTIMIZE TABLE wp_posts;
OPTIMIZE TABLE wp_postmeta;
OPTIMIZE TABLE wp_options;

#Cache i CDN na nowym hostingu

Skonfiguruj pamięć podręczną stron
Skonfiguruj pamięć podręczną przeglądarki
Włącz integrację CDN
Optymalizuj pamięć podręczną bazy danych

#Testy funkcji i SEO po przeniesieniu strony

Nawigacja: Wszystkie elementy menu działają poprawnie
Formularze: Formularze kontaktowe i zgłoszenia działają
Wyszukiwanie: Wyszukiwanie witryny zwraca wyniki
Komentarze: System komentarzy działa
Media: Obrazy i filmy ładują się poprawnie

#Sprawdzenie meta tagów, canonicali i schema

Meta Tagi: Tytuły i opisy wyświetlają się poprawnie
Kanoniczne Adresy URL: Wskazują na nową domenę
Dane Strukturalne: Markowanie schema jest poprawne
Wewnętrzne Linki: Wszystkie linki działają i przekierowują poprawnie

#Monitoring WordPress po migracji

#Monitoring uptime, Search Console i błędów 404

Skonfiguruj monitorowanie uptime
Monitoruj Google Search Console pod kątem błędów
Śledź wzorce ruchu w analytics
Monitoruj błędy 404 w logach

#Bieżące utrzymanie po przeprowadzce

Regularna optymalizacja bazy danych
Optymalizacja i kompresja obrazów
Monitorowanie wydajności pluginów
Wdrożenie skanów bezpieczeństwa

#Przykłady migracji sklepu, multisite i HTTPS

#Studium przypadku 1: sklep z 50 000 produktów na nowej domenie

Scenariusz: Popularny sklep internetowy z 50 000+ produktów musiał przenieść się z sklep-stary.com na nowabrand.com, utrzymując jednocześnie rankingi SEO i zaufanie klientów.

Wyzwania Napotkane:

Ogromna baza danych produktów z złożonymi wariacjami
Aktywne sesje koszyka podczas migracji
Integracje bramek płatności stron trzecich
Kampanie emailowe klientów z linkami starej domeny

Strategia Migracji:

Przygotowanie przed migracją (2 tygodnie):
- Stworzono pełną kopię zapasową witryny, w tym dane klientów
- Skonfigurowano tymczasowe środowisko staging
- Przetestowano wszystkie integracje bramek płatności
- Przygotowano szablony email do powiadomień klientów
Implementacja techniczna (4 godziny):
- Użyto WP-CLI do zastąpienia URL w bazie danych
- Zaimplementowano niestandardowe reguły przekierowania 301
- Zaktualizowano wszystkie endpointy API stron trzecich
- Skonfigurowano certyfikat SSL dla nowej domeny
Optymalizacja po migracji (1 tydzień):
- Monitorowano Google Search Console pod kątem problemów z indeksowaniem
- Zaktualizowano wszystkie przepływy pracy w automatyzacji marketingowej
- Wdrożono ulepszone śledzenie wpływu migracji
- Przeprowadzono ankietę satysfakcji klientów

Wyniki:

Niemal wszystkie rankingi SEO utrzymane w ciągu 2 tygodni
Zero utraty danych podczas migracji
Skargi klientów wyraźnie zmniejszone dzięki odpowiedniej komunikacji
Wzrost prędkości witryny dzięki nowej infrastrukturze hostingu

Kluczowe Lekcje:

Komunikacja z klientami jest równie ważna jak wykonanie techniczne
Testowanie bramek płatności w środowisku staging zapobiega utracie przychodów
Posiadanie planu rollback daje pewność siebie podczas wykonania

#Studium przypadku 2: multisite z 200 witrynami w chmurze

Scenariusz: Instytucja edukacyjna z 200+ witryn subdomen musiała przenieść się z hostingu współdzielonego do dedykowanej infrastruktury chmurowej.

Złożoność Techniczna:

201 indywidualnych witryn WordPress
Niestandardowe role użytkowników i uprawnienia między witrynami
Współdzielona biblioteka mediów z 100GB+ zawartości
Złożone zależności pluginów między witrynami

Podejście do Migracji:

Faza Analizy Sieci:
- Zmapowano wszystkie współzależności witryn
- Zidentyfikowano niestandardowe konfiguracje pluginów
- Udokumentowano hierarchie ról użytkowników
- Przeanalizowano wzorce wykorzystania biblioteki mediów
Konfiguracja Środowiska Staging:
- Zreplikowano dokładną konfigurację serwera
- Stworzono zautomatyzowane skrypty testowe
- Wdrożono monitorowanie wydajności
- Skonfigurowano procedury rollback
Migracja Fazowa:
- Najpierw przeniesiono 10 witryn pilotażowych
- Udokumentowano i udoskonalono proces
- Przeniesiono pozostałe witryny partiami
- Ciągłe monitorowanie i optymalizacja

Rozwiązania Techniczne:

## Niestandardowy skrypt do migracji wsadowej multisite
#!/bin/bash
for site in $(wp site list --field=url); do
    echo "Migruję $site"
    wp search-replace 'stara-domena.com' 'nowa-domena.com' --url=$site
    wp cache flush --url=$site
done

Wyniki:

99.8% uptime podczas procesu migracji
40% poprawy czasu ładowania stron
Zero uszkodzeń danych we wszystkich witrynach
Uproszczona administracja dzięki centralnemu zarządzaniu

#Studium przypadku 3: blog na HTTPS i naprawa mixed content

Scenariusz: Blog bogaty w treści z 10 000+ postami i obszerną biblioteką mediów wymagał wdrożenia HTTPS.

Wyzwania Mixed Content:

Hardkodowane linki HTTP w treści postów
Zasoby zewnętrzne bez alternatyw HTTPS
Osadzone iframes z niebezpiecznych źródeł
Niestandardowy CSS z odniesieniami HTTP

Kompleksowe Rozwiązanie:

Audyt i Czyszczenie Treści:

-- Znajdź i zastąp odniesienia HTTP w postach
UPDATE wp_posts 
SET post_content = REPLACE(post_content, 'http://przykład.com', 'https://przykład.com')
WHERE post_content LIKE '%http://przykład.com%';

-- Kolumny guid nie ruszaj: dokumentacja WordPressa mówi, że nigdy się jej nie zmienia

Aktualizacje Konfiguracji Pluginów:

// Niestandardowe dodatki do functions.php do wymuszania HTTPS
add_action('template_redirect', function() {
    if (!is_ssl() && !is_admin()) {
        wp_redirect('https://' . $_SERVER['HTTP_HOST'] . $_SERVER['REQUEST_URI'], 301);
        exit;
    }
});

Zaawansowana Konfiguracja .htaccess:

## Wymuś HTTPS dla całego ruchu
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Wpływ na Wydajność:

Początkowy 5% spadek ruchu w pierwszym tygodniu
Pełne odzyskanie w ciągu 3 tygodni
10% poprawy rankingów wyszukiwania
Poprawa metryk zaufania i bezpieczeństwa użytkowników

#Migracja dużej bazy danych WordPress i skrypty

#Strategie optymalizacji migracji bazy danych

#Efektywne zarządzanie dużymi bazami danych

Dla baz danych przekraczających 1GB, standardowe metody eksportu/importu często zawodzą. Oto zaawansowane techniki:

Metoda 1: Eksport Fragmentowany z WP-CLI

## Eksportuj fragmentami dla dużych baz danych
wp db export fragment1.sql --tables=wp_posts,wp_postmeta --add-drop-table
wp db export fragment2.sql --tables=wp_options,wp_users,wp_usermeta --add-drop-table

## Połącz i importuj oddzielnie
mysql nowa_baza_danych < fragment1.sql
mysql nowa_baza_danych < fragment2.sql

Metoda 2: zrzut strumieniowany przez gzip zamiast własnego skryptu PHP

## Zrzut prosto do gzip, bez nieskompresowanego pliku na dysku
wp db export - --single-transaction --quick | gzip > db.sql.gz

## Import ze STDIN na serwerze docelowym
gunzip < db.sql.gz | wp db import -

#Obsługa danych serializowanych

WordPress przechowuje wiele ustawień jako serializowane dane PHP, które psują się, gdy zmieniają się długości URL:

Bezpieczna zamiana danych serializowanych przez WP-CLI:

## Najpierw podgląd, potem bez --dry-run
wp search-replace 'https://staradomena.com' 'https://nowadomena.com' --skip-columns=guid --precise --dry-run
wp search-replace 'https://staradomena.com' 'https://nowadomena.com' --skip-columns=guid --precise

#Skrypt bash automatyzujący migrację WordPress

#Framework automatyzacji migracji

Stwórz kompleksowy skrypt automatyzacji migracji:

#!/bin/bash
## Skrypt Automatyzacji Migracji WordPress

set -e  # Wyjdź przy każdym błędzie

## Konfiguracja
OLD_DOMAIN="stara-witryna.com"
NEW_DOMAIN="nowa-witryna.com"
BACKUP_DIR="/ścieżka/do/kopii"
STAGING_DIR="/ścieżka/do/staging"
LOG_FILE="$BACKUP_DIR/migracja_$(date +%Y%m%d_%H%M%S).log"

## Funkcja logowania
log() {
    echo "[$(date '+%Y-%m-%d %H:%M:%S')] $1" | tee -a "$LOG_FILE"
}

## Sprawdzenia przed migracją
pre_migration_checks() {
    log "Rozpocznij sprawdzenia przed migracją"
    
    # Sprawdź instalację WordPress
    if ! wp core is-installed --path=/var/www/html; then
        log "ERROR: Instalacja WordPress nie znaleziona"
        exit 1
    fi
    
    # Sprawdź połączenie z bazą danych
    if ! wp db check --path=/var/www/html; then
        log "ERROR: Połączenie z bazą danych nieudane"
        exit 1
    fi
    
    # Utwórz katalog kopii zapasowej
    mkdir -p "$BACKUP_DIR"
    mkdir -p "$STAGING_DIR"
    
    log "Sprawdzenia przed migracją zakończone"
}

## Tworzenie kopii zapasowych
create_backups() {
    log "Tworzenie kompleksowych kopii zapasowych"
    
    # Kopia zapasowa bazy danych
    wp db export "$BACKUP_DIR/database_$(date +%Y%m%d_%H%M%S).sql" --path=/var/www/html
    
    # Kopia zapasowa plików
    tar -czf "$BACKUP_DIR/files_$(date +%Y%m%d_%H%M%S).tar.gz" /var/www/html
    
    # Kopia zapasowa konfiguracji
    cp /var/www/html/wp-config.php "$BACKUP_DIR/wp-config_$(date +%Y%m%d_%H%M%S).php"
    
    log "Kopie zapasowe utworzone pomyślnie"
}

## Jak zastąpić URL podczas migracji WordPress?
replace_urls() {
    log "Rozpocznij proces zastępowania URL"
    
    # Główne URL WordPress
    wp search-replace "$OLD_DOMAIN" "$NEW_DOMAIN" --skip-columns=guid --path=/var/www/html
    
    log "Zastąpienie URL zakończone"
}

## Walidacja po migracji
post_migration_validation() {
    log "Rozpocznij walidację po migracji"
    
    # Przetestuj dostępność witryny
    if curl -f -s "https://$NEW_DOMAIN" > /dev/null; then
        log "Witryna jest dostępna"
    else
        log "ERROR: Witryna nie jest dostępna"
        exit 1
    fi
    
    # Przetestuj admin WordPress
    if curl -f -s "https://$NEW_DOMAIN/wp-admin/" > /dev/null; then
        log "Admin WordPress jest dostępny"
    else
        log "ERROR: Admin WordPress nie jest dostępny"
        exit 1
    fi
    
    # Sprawdź integralność bazy danych
    wp db check --path=/var/www/html
    
    log "Walidacja po migracji zakończona"
}

## Główne wykonanie
main() {
    log "Rozpocznij proces migracji WordPress"
    
    pre_migration_checks
    create_backups
    replace_urls
    post_migration_validation
    
    log "Migracja zakończona pomyślnie"
}

## Wykonaj główną funkcję
main

#Konfiguracja Nginx, PHP i MySQL po migracji

#Ustawienia Nginx i PHP po migracji

#Konfiguracja Nginx dla migrowanych witryn

server {
    listen 80;
    server_name nowa-witryna.com www.nowa-witryna.com;
    return 301 https://$server_name$request_uri;
}

server {
    listen 443 ssl http2;
    server_name nowa-witryna.com www.nowa-witryna.com;
    
    root /var/www/html;
    index index.php index.html;
    
    # Konfiguracja SSL
    ssl_certificate /ścieżka/do/ssl/cert.pem;
    ssl_certificate_key /ścieżka/do/ssl/private.key;
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers ECDHE-RSA-AES256-GCM-SHA512:DHE-RSA-AES256-GCM-SHA512;
    
    # Konfiguracja specyficzna dla WordPress
    location / {
        try_files $uri $uri/ /index.php?$args;
    }
    
    location ~ \.php$ {
        fastcgi_pass unix:/var/run/php/php8.1-fpm.sock;
        fastcgi_index index.php;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        include fastcgi_params;
        
        # Optymalizację wydajności
        fastcgi_buffer_size 128k;
        fastcgi_buffers 4 256k;
        fastcgi_busy_buffers_size 256k;
    }
    
    # Konfiguracja cache
    location ~* \.(js|css|png|jpg|jpeg|gif|ico|svg)$ {
        expires 1y;
        add_header Cache-Control "public, immutable";
    }
    
    # Nagłówki bezpieczeństwa
    add_header X-Frame-Options "SAMEORIGIN" always;
    add_header X-XSS-Protection "1; mode=block" always;
    add_header X-Content-Type-Options "nosniff" always;
    add_header Referrer-Policy "no-referrer-when-downgrade" always;
    add_header Content-Security-Policy "default-src 'self' http: https: data: blob: 'unsafe-inline'" always;
}

#Optymalizacja PHP dla wydajności migracji

; Konfiguracja PHP zoptymalizowana dla migracji WordPress
memory_limit = 512M
max_execution_time = 300
max_input_time = 300
upload_max_filesize = 64M
post_max_size = 64M
max_input_vars = 3000

; Konfiguracja OPcache dla lepszej wydajności
opcache.enable=1
opcache.memory_consumption=128
opcache.interned_strings_buffer=8
opcache.max_accelerated_files=4000
opcache.revalidate_freq=2
opcache.fast_shutdown=1

#Optymalizacja wydajności bazy danych

#Optymalizacja konfiguracji MySQL

-- Optymalizacja MySQL dla WordPress
SET GLOBAL innodb_buffer_pool_size = 1073741824; -- 1GB
SET GLOBAL innodb_log_file_size = 268435456; -- 256MB
SET GLOBAL innodb_flush_log_at_trx_commit = 2;
SET GLOBAL innodb_flush_method = O_DIRECT;

-- Konfiguracja cache zapytań
SET GLOBAL query_cache_type = ON;
SET GLOBAL query_cache_size = 67108864; -- 64MB

#Strategia indeksowania bazy danych

-- Dodaj indeksy dla lepszej wydajności
ALTER TABLE wp_posts ADD INDEX idx_post_type_status (post_type, post_status);
ALTER TABLE wp_postmeta ADD INDEX idx_meta_key_value (meta_key, meta_value(191));
ALTER TABLE wp_options ADD INDEX idx_autoload (autoload, option_name);

-- Optymalizuj duże tabele
OPTIMIZE TABLE wp_posts;
OPTIMIZE TABLE wp_postmeta;
OPTIMIZE TABLE wp_options;

#Dane serializowane, limit pamięci i wtyczki po migracji

#Błędy danych serializowanych, pamięci i wtyczek

#Problem 1: Uszkodzone dane serializowane

Problem: Po zastąpieniu URL, opcje motywu i ustawienia pluginów stają się uszkodzone.

Diagnoza:

<?php
// Wypisz opcje, których serializowanej wartości nie da się już odczytać (uruchom przez wp eval-file)
global $wpdb;
$rows = $wpdb->get_results( "SELECT option_name, option_value FROM {$wpdb->options}" );
foreach ( $rows as $row ) {
    $v = $row->option_value;
    if ( is_serialized( $v ) && 'b:0;' !== $v && false === @unserialize( $v ) ) {
        echo $row->option_name . "\n";
    }
}

Rozwiązanie:

## Przywróć zrzut sprzed zamiany i powtórz ją przez WP-CLI
wp db import backup-before-replace.sql
wp search-replace 'https://staradomena.com' 'https://nowadomena.com' --skip-columns=guid --precise

#Problem 2: Wyczerpanie pamięci podczas migracji dużej bazy danych

Problem: Limity pamięci PHP przekroczone podczas importu/eksportu bazy danych.

Rozwiązania:

Metoda 1: Przetwarzanie Fragmentami

<?php
// Przetwarzaj bazę danych fragmentami, aby uniknąć problemów z pamięcią
function process_database_in_chunks($table, $chunk_size = 1000) {
    global $wpdb;
    
    $offset = 0;
    do {
        $results = $wpdb->get_results("
            SELECT * FROM $table 
            LIMIT $offset, $chunk_size
        ");
        
        foreach ($results as $row) {
            // Przetwarzaj każdy wiersz
            process_row($row);
        }
        
        $offset += $chunk_size;
        
        // Zwolnij pamięć
        $wpdb->flush();
        
    } while (count($results) === $chunk_size);
}
?>

Metoda 2: Eksport Bazy Danych w Strumieniu

## Użyj mysqldump z kompresją dla dużych baz danych
mysqldump --single-transaction --quick --lock-tables=false \
  --host=localhost --user=username --password=password \
  nazwa_bazy_danych | gzip > backup.sql.gz

## Import ze strumieniowaniem
gunzip < backup.sql.gz | mysql -u username -p nazwa_bazy_danych

#Problem 3: Kompatybilność pluginów po migracji

Problem: Pluginy nie działają po zmianach URL z powodu hardkodowanych odniesień.

Systematyczne Rozwiązanie:

Stwórz Sprawdzacz Kompatybilności Pluginów:

<?php
// Sprawdzacz kompatybilności pluginów
function check_plugin_compatibility() {
    $plugins = get_option('active_plugins');
    $issues = [];
    
    foreach ($plugins as $plugin_path) {
        $plugin_data = get_plugin_data(WP_PLUGIN_DIR . '/' . $plugin_path);
        
        // Sprawdź hardkodowane URL w plikach pluginów
        $plugin_files = glob(WP_PLUGIN_DIR . '/' . dirname($plugin_path) . '/*.php');
        
        foreach ($plugin_files as $file) {
            $content = file_get_contents($file);
            
            // Szukaj potencjalnych hardkodowanych URL
            if (preg_match('/https?:\/\/[^\s"\'<]+/', $content, $matches)) {
                $issues[] = [
                    'plugin' => $plugin_data['Name'],
                    'file' => $file,
                    'hardcoded_urls' => $matches
                ];
            }
        }
    }
    
    return $issues;
}
?>

Zamiana adresów w ustawieniach wtyczek przez WP-CLI:

## Tylko wp_options, tryb PHP dla zagnieżdżonych wartości serializowanych
wp search-replace 'https://staradomena.com' 'https://nowadomena.com' wp_options --precise --dry-run

#Testy migracji WordPress w GitHub Actions

#Jak testować migrację w potoku CI

#Workflow GitHub Actions do automatycznych testów

name: Test Migracji WordPress

on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

jobs:
  migration-test:
    runs-on: ubuntu-latest
    
    services:
      mysql:
        image: mysql:8.0
        env:
          MYSQL_ROOT_PASSWORD: password
          MYSQL_DATABASE: wordpress_test
        options: >-
          --health-cmd="mysqladmin ping"
          --health-interval=10s
          --health-timeout=5s
          --health-retries=3
    
    steps:
    - uses: actions/checkout@v3
    
    - name: Skonfiguruj PHP
      uses: shivammathur/setup-php@v2
      with:
        php-version: '8.1'
        extensions: mysqli, gd, xml, mbstring
    
    - name: Zainstaluj WordPress
      run: |
        curl -O https://wordpress.org/latest.tar.gz
        tar -xzf latest.tar.gz
        cp -r wordpress/* /var/www/html/
        
    - name: Skonfiguruj WordPress
      run: |
        cp wp-config-sample.php wp-config.php
        sed -i "s/database_name_here/wordpress_test/" wp-config.php
        sed -i "s/username_here/root/" wp-config.php
        sed -i "s/password_here/password/" wp-config.php
        sed -i "s/localhost/127.0.0.1/" wp-config.php
        
    - name: Zainstaluj WP-CLI
      run: |
        curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
        chmod +x wp-cli.phar
        sudo mv wp-cli.phar /usr/local/bin/wp
        
    - name: Wykonaj Testy Migracji
      run: |
        wp core install --url=http://localhost --title="Test Site" --admin_user=admin --admin_password=password [email protected]
        wp plugin install all-in-one-wp-migration --activate
        # Dodaj skrypty testów migracji tutaj
        
    - name: Zweryfikuj Migrację
      run: |
        # Dodaj skrypty weryfikacji tutaj
        wp option get siteurl
        wp option get home

#Skrypt wdrożenia automatyzowanego

#!/bin/bash
## Automatyzowany Skrypt Wdrożenia WordPress

set -e

## Zmienne środowiskowe
ENVIRONMENT=${1:-staging}
BACKUP_DIR="/backups/wordpress"
DEPLOY_LOG="/var/log/deploy.log"

## Funkcja logowania
log() {
    echo "[$(date '+%Y-%m-%d %H:%M:%S')] [$ENVIRONMENT] $1" | tee -a "$DEPLOY_LOG"
}

## Sprawdzenia przed wdrożeniem
pre_deployment_checks() {
    log "Rozpocznij sprawdzenia przed wdrożeniem"
    
    # Sprawdź, czy WordPress jest zainstalowany
    if ! wp core is-installed --path=/var/www/html; then
        log "ERROR: WordPress nie jest poprawnie zainstalowany"
        exit 1
    fi
    
    # Sprawdź łączność z bazą danych
    if ! wp db check --path=/var/www/html; then
        log "ERROR: Połączenie z bazą danych nieudane"
        exit 1
    fi
    
    # Sprawdź wymagane pluginy aktywne
    if ! wp plugin is-active all-in-one-wp-migration --path=/var/www/html; then
        log "ERROR: Wymagany plugin migracji nie jest aktywny"
        exit 1
    fi
    
    log "Sprawdzenia przed wdrożeniem zakończone"
}

## Utwórz kopię zapasową wdrożenia
create_deployment_backup() {
    log "Tworzenie kopii zapasowej wdrożenia"
    
    local timestamp=$(date +%Y%m%d_%H%M%S)
    local backup_file="$BACKUP_DIR/pre_deploy_${ENVIRONMENT}_$timestamp.sql"
    
    wp db export "$backup_file" --path=/var/www/html
    
    # Zweryfikuj integralność kopii zapasowej
    if [ -s "$backup_file" ] && tail -n 1 "$backup_file" | grep -q "Dump completed"; then
        log "Kopia zapasowa utworzona i zweryfikowana: $backup_file"
    else
        log "ERROR: Tworzenie kopii zapasowej nieudane"
        exit 1
    fi
}

## Wykonaj migrację
execute_migration() {
    log "Wykonanie migracji WordPress"
    
    # Zaktualizuj URL witryny, jeśli to konieczne
    if [ "$ENVIRONMENT" = "production" ]; then
        wp search-replace "staging.przykład.com" "przykład.com" --skip-columns=guid --path=/var/www/html
    fi
    
    # Wyczyść wszystkie cache
    wp cache flush --path=/var/www/html
    
    # Zaktualizuj reguły rewrite
    wp rewrite flush --path=/var/www/html
    
    log "Migracja zakończona"
}

## Walidacja po wdrożeniu
post_deployment_validation() {
    log "Rozpocznij walidację po wdrożeniu"
    
    # Sprawdź dostępność witryny
    local site_url=$(wp option get siteurl --path=/var/www/html)
    
    if curl -f -s "$site_url" > /dev/null; then
        log "Witryna jest dostępna: $site_url"
    else
        log "ERROR: Witryna nie jest dostępna"
        exit 1
    fi
    
    # Sprawdź admin WordPress
    if curl -f -s "$site_url/wp-admin/" > /dev/null; then
        log "Admin WordPress jest dostępny"
    else
        log "ERROR: Admin WordPress nie jest dostępny"
        exit 1
    fi
    
    # Zweryfikuj integralność bazy danych
    if wp db check --path=/var/www/html; then
        log "Integralność bazy danych zweryfikowana"
    else
        log "ERROR: Sprawdzenie integralności bazy danych nieudane"
        exit 1
    fi
    
    # Sprawdź krytyczne pluginy
    local critical_plugins=("all-in-one-wp-migration" "wp-super-cache")
    
    for plugin in "${critical_plugins[@]}"; do
        if wp plugin is-active "$plugin" --path=/var/www/html; then
            log "Plugin $plugin jest aktywny"
        else
            log "WARNING: Plugin $plugin nie jest aktywny"
        fi
    done
    
    log "Walidacja po wdrożeniu zakończona"
}

## Główna funkcja wdrożenia
main() {
    log "Rozpocznij wdrożenie WordPress dla środowiska $ENVIRONMENT"
    
    pre_deployment_checks
    create_deployment_backup
    execute_migration
    post_deployment_validation
    
    log "Wdrożenie zakończone pomyślnie"
    
    # Wyślij powiadomienie (opcjonalnie)
    if command -v slack-cli &> /dev/null; then
        slack-cli send "Wdrożenie WordPress do $ENVIRONMENT zakończone pomyślnie"
    fi
}

## Wykonaj główną funkcję
main

#Migracja bez przestoju i obniżenie TTL w DNS

Resolver może trzymać rekord DNS w pamięci podręcznej tak długo, jak pozwala jego TTL (RFC 1035, sekcja 3.2.1). Z tego wynika kolejność kroków:

Obniż TTL z wyprzedzeniem. Ustaw rekordy A i AAAA na krótki TTL, na przykład 300 sekund, co najmniej jeden pełny stary TTL przed przełączeniem. Jeśli stara wartość wynosiła 86400 sekund, oznacza to dzień wcześniej, bo do tego czasu resolwery dalej podają stary adres IP.
Przetestuj nowy serwer przez plik hosts. Przypisz domenę do nowego IP w lokalnym pliku hosts i przejdź koszyk, logowanie i formularze na serwerze docelowym, zanim zmieni się publiczny rekord. Odwiedzający nadal trafiają na stary serwer.
Zamroź zapisy na czas ostatniego zrzutu. Zamówienia, komentarze i wpisy z formularzy, które trafią na stary serwer po ostatnim wp db export, nie przejdą na nowy. Na czas końcowego eksportu i importu włącz na starej stronie tryb konserwacji albo wstrzymaj publikację.

#Jak przenieść bibliotekę mediów WordPress przez rsync

FTP przy każdej próbie kopiuje każdy plik od nowa. rsync przez SSH porównuje źródło z celem i wysyła tylko różnice, więc drugi przebieg przenosi tylko to, co zmieniło się od pierwszego (dokumentacja rsync).

Uruchom go dwa razy. Pierwszy przebieg kopiuje wp-content/uploads, gdy stara strona jeszcze działa. Drugi, w czasie zamrożenia zapisów, dociąga pliki dodane w międzyczasie.
Adresy zamieniaj przez WP-CLI, nie przez SQL. WordPress zapisuje opcje i ustawienia widżetów jako zserializowane tablice PHP z zapisanymi długościami ciągów. wp search-replace przelicza te długości, zwykłe REPLACE() w SQL tego nie robi.
Odtwórz miniatury, jeśli zmienia się motyw. wp media regenerate tworzy na nowo miniatury dla rozmiarów obrazów zarejestrowanych w nowej instalacji, a --only-missing ogranicza to do obrazów, którym brakuje rozmiarów (WP-CLI: wp media regenerate).

#Audyt SEO, SSL i Core Web Vitals po migracji

Przeskanuj listę starych adresów. Każdy stary URL powinien odpowiadać przekierowaniem 301 na swój nowy odpowiednik, a żaden link wewnętrzny nie może zwracać 404. Google zaleca przy przenoszeniu witryny stałe przekierowania po stronie serwera ze starych adresów na nowe, a przy zmianie domeny zgłoszenie zmiany adresu w Search Console (Google Search Central: przenoszenie witryny ze zmianą adresów URL).
TLS i HSTS. Zainstaluj certyfikat na nowym serwerze przed przełączeniem. HTTP Strict Transport Security każe przeglądarkom łączyć się z domeną wyłącznie przez HTTPS przez cały okres max-age (RFC 6797), więc włącz go dopiero wtedy, gdy HTTPS działa na każdej objętej subdomenie.
Zmierz przed i po. Sprawdź w PageSpeed Insights te same szablony na starym i nowym serwerze. Cache stron, OPcache, cache obiektów i kompresja gzip lub Brotli na nowym hostingu widać w czasie odpowiedzi serwera.

#Aspekty prawne i zgodność z RODO podczas migracji infrastruktury

Dla strony firmy działającej w UE nowy hosting to także nowy podmiot przetwarzający dane osobowe:

Umowa powierzenia z nowym dostawcą. Art. 28 RODO wymaga umowy, która określa przedmiot, czas trwania, charakter i cel przetwarzania oraz zobowiązuje podmiot przetwarzający do środków bezpieczeństwa z art. 32 (RODO, rozporządzenie (UE) 2016/679).
Aktualizacja polityki prywatności. Jeśli przeprowadzka dodaje CDN, nowe miejsce przechowywania kopii albo nowego dostawcę hostingu, zmienia się razem z nią lista odbiorców danych w polityce prywatności.
Usunięcie danych u starego dostawcy. Zgodnie z art. 28 ust. 3 lit. g podmiot przetwarzający po zakończeniu usługi usuwa albo zwraca dane osobowe, zależnie od decyzji administratora. Gdy nowy serwer działa stabilnie, poproś starego dostawcę o potwierdzenie usunięcia plików, baz danych i kopii zapasowych.

#Wdrażanie WordPress przez CI/CD z rollbackiem

Wdrażaj z repozytorium. Workflow w GitHub Actions albo GitLab CI buduje assety motywu i wysyła kod przy każdym pushu do gałęzi głównej, więc na serwerze nie ma plików edytowanych ręcznie.
Zachowaj poprzednie wydanie. Każde wydanie trafia do osobnego katalogu, a symlink wskazuje aktywne. Wycofanie kodu to przestawienie symlinku na poprzednie wydanie. Przed każdym krokiem, który zmienia bazę, zrób wp db export, bo wycofanie kodu nie cofa zmian w tabelach ani w treści.
Te same wersje wszędzie. Wyrównaj wersje PHP oraz MySQL lub MariaDB między środowiskiem lokalnym, stagingiem i produkcją, żeby migracja przetestowana na stagingu zachowała się tak samo na produkcji.

#Jak wp search-replace obsługuje dane serializowane

Podręcznik WordPressa ostrzega, że hurtowe wyszukiwanie i zamiana w całej bazie może uszkodzić dane serializowane i że kolumny guid w wp_posts nie wolno zmieniać (Moving WordPress). wp search-replace powstało właśnie na ten przypadek: obsługuje zserializowane dane PHP i nie zmienia wartości kluczy głównych (WP-CLI: wp search-replace). Flagi, które mają znaczenie przy migracji:

--dry-run raportuje, co by się zmieniło, i niczego nie zapisuje.
--skip-columns=guid zostawia GUID-y wpisów bez zmian.
--precise wymusza przetwarzanie w PHP dla każdej kolumny. Jest wolniejsze i pewniejsze przy złożonych danych serializowanych.
--network obejmuje wszystkie tabele sieci multisite. Bez tej flagi przeszukiwane są tylko tabele bieżącej witryny.
--all-tables-with-prefix dodaje tabele, które wtyczki utworzyły z prefiksem WordPressa, ale ich nie zarejestrowały, a --all-tables bierze każdą tabelę w bazie.
--export=plik.sql zapisuje zmienione dane do pliku SQL zamiast do bazy, co pomaga, gdy baza docelowa stoi na innym serwerze.

Tabele bez klucza głównego są pomijane, więc tabela wtyczki bez takiego klucza wymaga osobnego sprawdzenia. Dla multisite podręcznik wymienia też, co sprawdzić ręcznie: tabele wp_blogs i wp_site oraz opcje home, siteurl i fileupload_url każdej witryny.

wp db export i wp db import zamykają ten zestaw. Eksport uruchamia mysqldump z danymi dostępowymi z wp-config.php i przyjmuje dowolną flagę mysqldump, a wp db export - pisze na STDOUT (WP-CLI: wp db export). Import nie tworzy bazy, tylko wykonuje SQL z pliku, a wp db import - czyta ze STDIN (WP-CLI: wp db import). Pustą bazę na serwerze docelowym trzeba więc założyć wcześniej.

#Podsumowanie

Migracja WordPress nie musi być przytłaczająca, gdy podejście jest systematyczne. Postępując zgodnie z tym kompleksowym przewodnikiem, przygotowując się starannie i testując dokładnie, możesz pomyślnie migrować swoją witrynę WordPress z minimalnym zakłóceniem dla użytkowników i wydajności SEO.

Pamiętaj, że przygotowanie jest kluczowe, nigdy nie próbuj migracji bez kompletnych kopii zapasowych i jasnego planu powrotu. Weź swój czas, testuj dokładnie i nie wahaj się szukać profesjonalnej pomocy dla złożonych migracji.

Z odpowiednim planowaniem i wykonaniem, Twoja migracja WordPress może być płynnym procesem, który przygotuje Twoją witrynę na przyszły wzrost i sukces.

Zobacz nasze projekty migracji WordPress, jeśli planujesz przebudowę albo przejście na Astro lub Next.js.