Remplacer le domaine dans la base WordPress après une migration de site
Générateur de scripts pour changer l'adresse du site dans la base de données : WP-CLI ou SQL brut pour phpMyAdmin. Indiquez le préfixe des tables, l'ancien et le nouveau domaine — l'outil fait le reste. Tout est produit dans votre navigateur : les adresses saisies ne sont envoyées nulle part.
wp-config.php : $table_prefix. Par défaut wp_
Renseignez l'ancien et le nouveau domaine pour voir le script.
Le script est produit dans votre navigateur — les domaines saisis ne sont envoyés nulle part ni enregistrés.
Чому «просто REPLACE по всій базі» ламає сайт
WordPress зберігає частину налаштувань у PHP-серіалізованому вигляді, де довжина кожного рядка записана окремим числом: a:1:{s:4:"logo";s:26:"http://old.com/logo.png";} Число 26 — це довжина адреси у байтах. Звичайний REPLACE змінить саму адресу, але не чіпне число. Після цього unserialize() повертає false, і значення читається як порожнє. Найчастіше так втрачаються віджети, налаштування теми (theme_mods), поля ACF та дані Elementor — тобто саме те, що складніше за все відновити. Тому режим «WP-CLI» стоїть за замовчуванням: wp search-replace розпаковує серіалізовані структури і перераховує довжини коректно.
Одна адреса — п’ять різних записів у базі
Друга причина, чому після переносу «половина посилань лишилась старими»: той самий домен лежить у базі в кількох формах одночасно. http://old.com — звичайний вигляд https://old.com — інша схема, якщо сайт переїхав на SSL уже після наповнення //old.com — protocol-relative у старих темах http:\/\/old.com — екрановані слеші всередині JSON: так адреси зберігають блоки Gutenberg і поле _elementor_data http%3A%2F%2Fold.com — urlencoded у redirect-плагінах та кеші oEmbed Інструмент генерує заміну для кожної увімкненої форми окремо, у правильному порядку: protocol-relative йде останнім, бо є підрядком повної адреси.