Imágenes rotas, botones que vuelven a staging y widgets con el dominio antiguo suelen indicar una sustitución incompleta o insegura. WordPress guarda URLs en entradas, metadatos, opciones y estructuras propias de plugins. La reparación debe respetarlas, no ejecutar un reemplazo ciego.
Identifica todas las formas de la URL antigua
Lista origen y destino exactos: HTTP y HTTPS, www y raíz, hostnames temporales, puertos, URLs escapadas y rutas. Busca en una exportación de solo lectura para saber dónde aparece cada variante.
No asumas que toda mención debe cambiar. Biografías, referencias externas, emails, licencias y registros multisite pueden ser intencionados.
Establece el destino canónico
Confirma primero DNS, certificado y política de redirecciones. Decide si home y siteurl usan raíz o www y verifica HTTPS en origen. Reemplazar antes de estabilizar el destino obliga a limpiar dos veces.
wp option get home
wp option get siteurlLas constantes de wp-config.php pueden sobrescribir la base; compara ambas fuentes.
Crea una copia restaurable
Exporta la base inmediatamente antes del cambio y registra prefijo, número de filas y hora. Guarda la copia fuera del directorio público. Solo es útil si existen credenciales y una ruta de importación probada.
Pausa la edición o prepara un delta final. Un rollback no debe descartar entradas, comentarios, usuarios o pedidos creados durante la reparación.
Usa una sustitución consciente de serialización
Las cadenas serializadas de PHP incluyen longitudes. Un REPLACE() SQL puede invalidarlas si cambia el tamaño de la URL y romper widgets o ajustes.
WP-CLI entiende la serialización. Simula primero:
wp search-replace 'https://staging.example.net' 'https://example.com'
--all-tables-with-prefix --precise --dry-runRevisa cantidades y elimina --dry-run solo si tienen sentido. Evita --all-tables si incluye aplicaciones ajenas.
Inspecciona widgets y constructores por separado
Los widgets clásicos aparecen en sidebars_widgets y opciones widget_*; los bloques, patrones reutilizables y navegación pueden ser entradas. Los constructores suelen guardar JSON o metadatos codificados y ofrecen su propia herramienta.
No edites blobs opacos manualmente. Usa el método compatible, regenera CSS y recursos y limpia solo las cachés afectadas.
En una instalación multilingüe, repite la inspección para las entidades en inglés, español y catalán. Una traducción puede guardar su propio bloque, plantilla o ajuste y no heredar la corrección de la versión base. Comprueba también selectores de idioma y enlaces personalizados de los menús.
Corrige medios y referencias generadas
Verifica adjuntos, destacadas, srcset, galerías, descargas, fondos CSS y Open Graph. Los archivos deben existir en rutas de uploads coherentes.
También puede quedar el dominio antiguo en CSS generado, minificados, ajustes de CDN o caché de página. Regenera recursos desechables después de corregir la base.
Comprueba redirects y contenido mixto
Solicita URLs antiguas representativas y confirma que llegan al nuevo destino sin bucles. Los enlaces internos deben usar directamente la URL canónica; depender de redirects desperdicia peticiones y esconde fallos.
Usa Consola y el código fuente para localizar recursos HTTP. No mantengas un plugin de reescritura de contenido mixto como sustituto de corregir el almacenamiento.
Valida funciones y señales SEO
Rastrea páginas, entradas, categorías, medios, widgets y landings. Revisa canonical, hreflang, sitemap, datos estructurados e imágenes sociales. Envía formularios y prueba la edición autenticada.
Compara coincidencias del dominio antiguo, pero clasifica manualmente las supervivientes. Cero resultados no es automáticamente correcto.
Evita la próxima reparación
Cuando sea posible, prueba la migración con el hostname real mediante hosts. Mantén una política de dominio canónico y un procedimiento de sustitución limitado.
El mantenimiento recurrente debe detectar dominios de staging en HTML público y validar enlaces de medios nuevos, para que un widget oculto no permanezca roto durante meses.