Ver texto como é en vez de é suele significar que unos bytes UTF-8 se interpretaron o volvieron a codificar con el juego equivocado. Cambiar el charset mostrado por WordPress puede ocultar un síntoma mientras las nuevas escrituras siguen dañándose.
Conserva las bases original y migrada. Determina los bytes realmente guardados antes de realizar sustituciones.
Clasifica el daño
Guarda ejemplos de entradas, títulos, opciones, nombres de archivo y tablas de plugins. Averigua si afecta a todo, solo a filas antiguas o únicamente al contenido nuevo.
Patrones:
base correcta y cabecera de página incorrecta
charset de conexión equivocado al importar
declaración latin1 alrededor de bytes UTF-8
UTF-8 doblemente codificado
emoji o caracteres suplementarios no admitidosUsa muestras no sensibles y conserva los bytes o valores hexadecimales exactos.
Compara origen y destino
Revisa charset y collation de tablas y columnas en ambos servidores. Comprueba en la cabecera del volcado SET NAMES, juego de caracteres del cliente y declaraciones de collation.
SHOW CREATE TABLE wp_posts;
SHOW VARIABLES LIKE 'character_set%';
SHOW VARIABLES LIKE 'collation%';Ejecuta consultas de solo lectura con el prefijo real. Los valores predeterminados del servidor no describen todas las columnas existentes.
Inspecciona los bytes guardados
Compara una cadena conocida con HEX() en origen y destino. Si los bytes coinciden pero se muestran distintos, falla la conexión o la decodificación de página. Si difieren, la importación transformó los datos.
No envíes contenido de clientes a herramientas públicas. Trabaja en staging con identificadores exactos.
La comparación visual no distingue una codificación simple de una doble.
Revisa las constantes de WordPress
Comprueba DB_CHARSET y DB_COLLATE en wp-config.php. WordPress moderno suele usar utf8mb4 y una collation vacía salvo requisitos del hosting.
No cambies estas constantes a la ligera en una base existente: influyen en conexiones y operaciones de esquema, pero no convierten de forma segura cada valor guardado.
Revisa aparte la cabecera HTTP y <meta charset> de presentación.
Vuelve a importar con ajustes explícitos
Si es posible reconstruir el destino, la reparación más limpia suele ser una nueva exportación e importación que conserve bytes y declare correctamente el charset de conexión.
Ensaya en otra base y compara filas y muestras hexadecimales antes de conectar WordPress. Impide escrituras nuevas durante la ventana o concierta su incorporación posterior.
No importes repetidamente sobre tablas ya transformadas parcialmente.
Repara la doble codificación con cuidado
Los datos doblemente codificados pueden necesitar una conversión reversible, pero la expresión correcta depende de los bytes actuales y del texto esperado. Prueba filas concretas y conserva originales.
Evita una sustitución global de secuencias visibles como Ã: podrías dañar texto legítimo y otros patrones.
Prepara una lista acotada de columnas y filas y valida acentos, punto medio catalán, puntuación española, emoji y ejemplos no latinos.
Convierte el esquema cuando proceda
Utiliza una conversión a utf8mb4 compatible con la aplicación o el administrador, revisando longitud de índices y versión MySQL. Un ALTER TABLE grande bloquea escrituras y necesita disco libre.
Haz copia y programa mantenimiento. No conviertas tablas de producción sin estimar tiempo y reversión.
Incluye deliberadamente tablas de plugins y código propio, no solo el núcleo.
Revisa URLs, slugs y nombres de archivo
La codificación dañada puede cambiar URLs codificadas y slugs aunque el título visible se repare. Compara canónicas, menús, adjuntos y redirecciones con el origen.
No regeneres todos los slugs: romperías URLs indexadas y enlaces entrantes. Repara un mapa limitado y crea redirecciones intencionadas. En archivos, distingue la codificación del sistema de la metadata del adjunto.
Verifica contenido antiguo y nuevo
Prueba web pública, editor, guardado, búsqueda, URLs, correo y exportaciones. Guardar una fila antigua que se ve correcta no debe volver a corromperla.
Compara muestras entre bases y ensaya una nueva copia y restauración. La integridad se demuestra mediante bytes y escrituras de ida y vuelta, no porque una sola página parezca correcta.