WordPress
Ejecutar una búsqueda y reemplazo en su base de datos WordPress
WordPress stores absolute URLs in dozens of database tables, so a domain change or an SSL move leaves old addresses scattered through posts, options and plugin settings: a search and replace is how…
Ejecutar una búsqueda y reemplazo en tu base de datos de WordPress
WordPress almacena URLs absolutas en docenas de tablas de base de datos, por lo que un cambio de dominio o una migración SSL deja direcciones antiguas dispersas por posts, opciones y configuraciones de plugins: una búsqueda y reemplazo es cómo las limpias de forma segura. Esta guía cubre las dos formas compatibles de hacerlo en KPanel, por qué un método común de terceros corrompe datos, y cómo verificar el resultado.
Cuándo necesitas una
- Migrar de
http://ahttps://después de habilitar SSL. - Cambiar de dominio, por ejemplo de
old-brand.co.nzanew-brand.co.nz. - Después de pasar staging a producción, cuando el nombre de host de staging aún está incrustado en la base de datos.
- Retirar un antiguo servidor de assets y redirigir cada URL de imagen de una vez.
- Corregir un error masivo en muchos posts, como un número de teléfono antiguo o un nombre de producto descontinuado.
Una búsqueda y reemplazo reescribe filas en todas las tablas a la vez y no hay deshacer por fila. Haz una copia de seguridad antes de empezar, cada vez, incluso para un cambio que parece trivial. KPanel crea una automáticamente cuando usas las herramientas integradas descritas a continuación, pero si ejecutas el comando tú mismo eres responsable de ella. Consulta Hacer una copia de seguridad.
Por qué no puedes simplemente ejecutar un REPLACE de SQL
Este es el error más dañino en el trabajo con bases de datos de WordPress, así que vale la pena entenderlo antes de elegir un método.
WordPress almacena configuraciones de plugins, opciones de temas y datos de widgets como strings serializados de PHP. Una string serializada registra la longitud de cada valor dentro de ella, así:
a:1:{s:3:"url";s:26:"http://old-domain.co.nz/x";}
Ese s:26 dice que la URL tiene 26 caracteres de largo. Reemplaza http:// con https:// usando un REPLACE de SQL simple REPLACE() y el texto se convierte en 27 caracteres mientras la longitud almacenada aún afirma 26. PHP entonces se niega a deserializar toda la opción, y la configuración silenciosamente revierte a vacío. Las configuraciones del personalizador de temas desaparecen, los sliders pierden sus diapositivas, las licencias de plugins se desregistran.
El search-replace de WP-CLI que ejecuta KPanel deserializa cada valor, reemplaza dentro de él, y reserializa con longitudes corregidas. Por eso es el único método documentado aquí.
Nunca ejecutes UPDATE wp_options SET option_value = REPLACE(...) o el equivalente en phpMyAdmin contra una base de datos de WordPress. Parece que funcionó, reporta filas afectadas, y silenciosamente destruye cada configuración serializada que tocó. No hay reparación que no sea restaurar una copia de seguridad.
Método 1: La tarjeta de búsqueda y reemplazo
Esta es la opción correcta para casi todos. Está disponible en cada plan de WordPress.
- Inicia sesión en KPanel y haz clic en Websites en la barra lateral izquierda.
- Haz clic en el sitio.
- Abre la pestaña WordPress, luego la sección Quick Actions.
- Encuentra la tarjeta Search & Replace y haz clic en Configure.
- Ingresa el texto existente en Find (old value).
- Ingresa el nuevo texto en Replace with.
- Deja Dry run (preview only, no changes) marcado y haz clic en Preview.
El dry run reporta cuántos reemplazos se harían y desglosa el conteo por tabla y columna, para que puedas ver exactamente dónde aterrizaría el cambio antes de comprometerte.
Cuando el preview se ve bien:
- Desmarca Dry run.
- Haz clic en Run.
- Confirma el diálogo.
Una copia de seguridad completa se toma automáticamente antes de que comience el reemplazo, y la ejecución cubre todas las tablas incluidas las creadas por plugins.
Busca la string más específica que puedas. Reemplazar old-domain.co.nz también reescribe mail.old-domain.co.nz y staging.old-domain.co.nz, lo que rara vez es lo que quieres. Incluir el esquema, como en https://old-domain.co.nz, mantiene la coincidencia ajustada.
Método 2: WP-CLI desde la consola
La consola te da el mismo motor con más control sobre flags. Es una de las secciones que aparecen en planes managed; en otros planes la tira de pestañas muestra un enlace +8 on Managed en su lugar.
Abre el sitio, luego WordPress, luego Console. El prompt ya comienza con wp, así que escribe solo el resto del comando.
Primero obtén una vista previa:
search-replace 'http://old-domain.co.nz' 'https://old-domain.co.nz' --all-tables --dry-run
Luego ejecútalo de verdad:
search-replace 'http://old-domain.co.nz' 'https://old-domain.co.nz' --all-tables
La consola no hace una copia de seguridad para ti. La copia de seguridad automática previa solo ocurre cuando usas la tarjeta Search & Replace en el Método 1. Si ejecutas el comando aquí, haz una copia de seguridad tú mismo primero desde la pestaña Backups del sitio.
Flags útiles:
| Flag | Qué hace |
|---|---|
--all-tables | Incluye tablas personalizadas creadas por plugins, no solo las de WordPress core |
--dry-run | Reporta qué cambiaría y no escribe nada |
--precise | Usa PHP en lugar de SQL para el reemplazo. Más lento, pero maneja estructuras serializadas complicadas |
--skip-columns=guid | Deja solos los GUIDs de posts (ver abajo) |
--report-changed-only | Reduce la salida a tablas que realmente cambiaron |
Una nota sobre GUIDs
Cada post de WordPress tiene una columna guid. A pesar de parecer una URL es un identificador, no un enlace, y los lectores de feeds lo usan para saber si ya han visto un elemento. Reescribirlo puede hacer que cada post en tu feed reaparezca como nuevo.
Reescribe GUIDs cuando estés cambiando de dominio permanentemente y comenzando de nuevo. Omítelos con --skip-columns=guid cuando solo estés pasando de HTTP a HTTPS en el mismo dominio.
Cambiar de dominio: usa en su lugar la tarjeta de cambio de URL del sitio
Si todo el punto es mover el sitio a un nuevo dominio, no comiences con búsqueda y reemplazo. La tarjeta Change Site URL, en la misma sección Quick Actions, actualiza las opciones siteurl e home y ejecuta el reemplazo en todas las tablas en una operación, en el orden correcto. Hacerlo de otra forma puede dejar a WordPress incapaz de cargar su propio admin.
Después del reemplazo
Trabaja en esta lista antes de considerarlo hecho.
- Vacía el caché. En la sección Quick Actions, ejecuta Flush Cache. Si el sitio usa el caché de página completa, púrgalo desde WordPress, luego Caching.
- Vacía las reglas de reescritura. Ejecuta Flush Rewrites en la misma sección, o abre Settings, luego Permalinks en wp-admin y haz clic en Save Changes sin cambiar nada.
- Purga el CDN si el sitio está en él, desde Performance, luego Kapsule CDN. Consulta Purgar el caché de CDN.
- Carga el sitio en una ventana privada para que el caché de tu navegador no pueda engañarte.
- Verifica el candado. Un candado faltante o de advertencia después de un movimiento SSL significa que las URLs fueron dejadas atrás: Corregir avisos de contenido mixto.
- Haz clic en las páginas complicadas. Sliders de la página de inicio, el logo del encabezado, cualquier página construida con un page builder, y el checkout en una tienda. Estos contienen las URLs que viven en opciones serializadas.
- Limpia cualquier plugin de caché desde su propia pantalla de configuración.
Solución de problemas
El dry run reporta cero reemplazos. La string no está en la base de datos en esa forma exacta. Verifica una barra diagonal final, un prefijo www., o el esquema. Intenta buscar solo el nombre de host desnudo primero para confirmar que esté ahí en todo.
Las imágenes se rompen después de un cambio de dominio. Las URLs de medios viven en wp_posts e wp_postmeta y son recogidas por --all-tables, pero un CDN o un plugin de optimización de imágenes puede cachear sus propias copias reescritas. Purga el CDN y el caché del plugin, luego recarga.
Las configuraciones desaparecieron después del reemplazo. Ese es el problema de serialización, y significa que el cambio se hizo con SQL crudo en lugar de con las herramientas aquí. Restaura la copia de seguridad tomada antes de la ejecución: Restaurar desde una copia de seguridad.
Las URLs de staging siguen reapareciendo. Algo las está repoblando, usualmente un push programado o una opción en caché. Verifica el flujo de trabajo en Usar Staging: Empujar y tirar y asegúrate de que Rewrite URLs esté marcado cuando hagas push.