Migraste tu sitio a un hosting nuevo. Copiaste los archivos, exportaste la base de datos, la importaste en el destino y corriste algo como esto para actualizar las URLs:
UPDATE wp_options
SET option_value = REPLACE(option_value, 'https://dominio-viejo.com', 'https://dominio-nuevo.com')
WHERE option_name = 'home' OR option_name = 'siteurl';
UPDATE wp_posts
SET post_content = REPLACE(post_content, 'https://dominio-viejo.com', 'https://dominio-nuevo.com');
Le das enter, todo corre sin errores, entras al sitio y... página en blanco, o un 404 total, o el editor de WordPress se congela. No hay mensaje de error claro. No hay logs evidentes. Solo el sitio, roto.
Esto le pasa a mucha más gente de la que admite, y casi siempre es la misma causa raíz: datos serializados.
El problema que nadie ve venir
WordPress no guarda toda su configuración como texto plano. Muchos valores —widgets, ajustes de tema, configuración de plugins, metadatos de Elementor, opciones de menús— se guardan como arrays de PHP serializados. Un array serializado se ve así:
a:2:{s:4:"home";s:19:"https://dominio-viejo.com";s:8:"siteurl";s:19:"https://dominio-viejo.com";}
Fíjate en el s:19: antes de cada URL. Ese número no es decorativo: le dice a PHP exactamente cuántos caracteres tiene el string que sigue. Es la longitud exacta, contada por PHP, no algo que tú puedas editar a mano sin consecuencias.
Ahora corre un REPLACE() de SQL sobre eso, cambiando una URL corta por una más larga:
a:2:{s:4:"home";s:19:"https://dominio-nuevo-y-mas-largo.com";...
El texto cambió, pero el número 19 se quedó igual. PHP llega a ese punto, cuenta 19 caracteres, corta ahí, y el resto del array queda ilegible. Cuando unserialize() no puede leer la estructura, silenciosamente devuelve false o un array vacío. Ese widget, esa configuración, ese ajuste de tema — desaparece. Multiplica eso por cada fila de wp_options y wp_postmeta que tenía datos serializados, y entiendes por qué el sitio completo puede quedar en blanco: a veces la opción rota es literalmente la que le dice a WordPress qué theme cargar o cómo armar las rewrite rules.
Lo más traicionero: UPDATE con REPLACE() no da ningún error. SQL no sabe nada de serialización de PHP, para SQL es solo texto. El daño es completamente silencioso hasta que cargas la página.
Cómo se ve el síntoma según qué se rompió
- Página en blanco (pantalla blanca de la muerte): normalmente un fatal error de PHP al intentar deserializar algo crítico, silenciado porque
display_errorsestá apagado en producción. - 404 en todo el sitio menos el home: casi siempre las rewrite rules o
sidebars_widgetsquedaron corruptas. - wp-admin carga pero el editor visual falla: metadatos de constructor de páginas (Elementor, Divi, etc.) con JSON o arrays serializados dañados en
wp_postmeta. - El sitio "casi" funciona pero widgets/menús desaparecieron: exactamente el mismo problema, en una escala más contenida.
La forma correcta de hacerlo
La regla es simple: nunca uses REPLACE() de SQL directo sobre una base de datos de WordPress para cambiar URLs. Necesitas una herramienta que entienda serialización y recalcule las longitudes automáticamente.
Opción 1 — WP-CLI (si tienes acceso SSH):
wp search-replace 'https://dominio-viejo.com' 'https://dominio-nuevo.com' --all-tables --precise
Opción 2 — Plugin Better Search Replace (sin necesidad de terminal):
Se sube manualmente si el sitio ya no carga, se corre primero en modo dry run para ver cuántas filas se van a tocar, y luego el reemplazo real sobre todas las tablas.
Ambas herramientas deserializan cada valor, hacen el reemplazo dentro de la estructura, y vuelven a serializar recalculando las longitudes correctas. Es la diferencia entre una migración limpia y una tarde entera tratando de averiguar qué widget desapareció.
Si ya corriste el UPDATE y el sitio está roto
No hay mucho que reparar campo por campo — es más rápido:
- Restaura el backup de la base de datos de antes del
UPDATE. - Vuelve a importarlo en el destino.
- Corre el reemplazo con WP-CLI o Better Search Replace, no con SQL manual.
- Entra a Ajustes → Enlaces permanentes y guarda sin cambiar nada, para regenerar las rewrite rules.
Si no tienes ese backup limpio, toca revisar fila por fila en wp_options y wp_postmeta buscando registros donde la longitud declarada (s:N:) no coincida con el largo real del string — tedioso, pero recuperable.
¿Estás por migrar un sitio o ya se te rompió a media migración? En ariapsa.com/sm/ revisamos tu caso y evitamos que un cambio de dominio se convierta en una base de datos corrupta. n