Los caracteres extraños en WordPress (esos ñ, ¿, o signos de interrogación que reemplazan las tildes y la ñ) son casi siempre un problema de codificación: WordPress, la base de datos o el servidor están usando charsets incompatibles, y cuando el texto viaja entre capas, se corrompe.
En 30 segundos
- Los caracteres extraños en WordPress aparecen cuando la base de datos, PHP o el servidor usan codificaciones distintas (típicamente UTF-8 vs. ISO-8859-1).
- La causa más frecuente en 2026 es una migración de servidor hecha sin verificar el charset del motor MySQL de destino.
- La solución pasa por forzar
utf8mb4enwp-config.phpy, si los datos ya están corruptos, convertir las tablas existentes. - Antes de tocar la base de datos, hacé un backup completo. Sin excepción.
- Si el problema persiste después de los pasos técnicos, el conflicto probablemente viene de un plugin o tema heredado que ignora UTF-8.
Qué son los caracteres extraños en WordPress y cuándo aparecen
Los caracteres extraños en WordPress son símbolos que aparecen donde debería haber letras normales: la ñ se convierte en ñ, los signos de apertura de pregunta o exclamación desaparecen, las tildes se transforman en  seguido de otra letra. El problema siempre es el mismo: una parte del sistema interpreta el texto con un charset distinto al que se usó para guardarlo.
Esto pasa puntualmente en cuatro situaciones. Migraciones de servidor (la más común). Actualizaciones de PHP de 7.x a 8.x cuando el hosting no reconfiguró los defaults. Copiar y pegar contenido desde Word o Google Docs sin limpiar formato. Y en sitios viejos que originalmente se armaron con ISO-8859-1 y nunca se migraron a UTF-8.
La definición técnica es sencilla: WordPress está diseñado para funcionar con UTF-8 (o su variante extendida utf8mb4, que agrega soporte para emojis y scripts asiáticos). Si cualquier punto de la cadena (base de datos, conexión PHP-MySQL, cabeceras HTTP, o el propio editor) usa otra codificación, el texto se «rompe» en tránsito.
Causas raíz: UTF-8 vs. ISO-8859-1
ISO-8859-1, también llamado Latin-1, fue el charset estándar de la web hasta mediados de los 2000. Soporta las letras del español pero no los emojis, los caracteres chinos, ni muchos símbolos técnicos. UTF-8 los engloba todos usando entre 1 y 4 bytes por carácter.
El problema ocurre cuando un texto guardado en UTF-8 se lee como si fuera ISO-8859-1 (o viceversa). La ñ en UTF-8 son dos bytes: 0xC3 0xB1. Si esos bytes se interpretan como ISO-8859-1, el resultado es ñ. Eso es exactamente lo que ves en pantalla cuando el charset está mal configurado.
En WordPress hay cuatro puntos donde la codificación tiene que estar sincronizada:
- wp-config.php: define el charset y la collation que WordPress usa para crear y leer tablas.
- Motor de base de datos: MySQL/MariaDB tiene su propio charset, que puede diferir del que WordPress espera.
- Conexión PHP-MySQL: si PHP no especifica UTF-8 al conectarse, MySQL puede interpretar mal los datos.
- Cabeceras HTTP y meta charset: el servidor debe enviar
Content-Type: text/html; charset=UTF-8para que el navegador no haga suposiciones.
Basta que uno solo de estos puntos no esté alineado para que aparezcan los símbolos raros.
Paso 1: Verificar la configuración UTF-8 en WordPress
Antes de tocar archivos, confirmá el charset que está reportando tu sitio. Abrí el navegador, hacé clic derecho en cualquier página del sitio y elegí «Ver código fuente». Buscá la línea que dice: Complementá con desarrollo de plugins personalizados.
<meta charset="UTF-8">
Si ves charset="iso-8859-1" o directamente no encontrás esa línea, ahí tenés una pista. También podés revisar las cabeceras HTTP con las DevTools del navegador (pestaña Network, cualquier respuesta HTML, columna Content-Type).
Desde el panel de WordPress, andate a Ajustes > Opciones de lectura (o en algunas instalaciones Ajustes > General). En WordPress moderno ya no hay un campo visible de «charset» porque el valor viene directo del código, pero si tenés una instalación antigua con ese campo, asegurate de que diga UTF-8.
Paso 2: Editar wp-config.php para forzar UTF-8
Abrí el archivo wp-config.php en la raíz de tu instalación WordPress. Buscá estas dos constantes:
define( 'DB_CHARSET', 'utf8mb4' );define( 'DB_COLLATE', 'utf8mb4_unicode_ci' );
Si no están, agregalas antes de la línea que dice /* That's all, stop editing! */. Si están con el valor utf8 (sin la parte mb4), cambialo.
¿Cuál es la diferencia entre utf8 y utf8mb4? Técnicamente, el utf8 de MySQL es una implementación incompleta que solo soporta caracteres de hasta 3 bytes (lo que cubre el español perfectamente, pero excluye emojis y algunos caracteres especiales). utf8mb4 soporta el rango completo de Unicode. WordPress recomienda utf8mb4 desde la versión 4.2 (allá por 2015), así que si tu sitio es medianamente reciente, ya debería estar con ese valor.
Eso sí: cambiar las constantes en wp-config.php solo afecta las tablas nuevas que WordPress cree a partir de ese momento. Si el problema viene de datos ya guardados con la codificación incorrecta, el paso 3 es el que te resuelve.
Paso 3: Convertir la base de datos existente a UTF-8
Este es el paso que la gente evita porque da miedo. Tiene sentido tenerle respeto, pero con el backup en mano no hay drama.
Hacé el backup antes. Desde phpMyAdmin: seleccioná tu base de datos, pestaña Exportar, formato SQL, botón Ejecutar. Guardá ese archivo en un lugar seguro fuera del servidor. Te puede servir nuestra cobertura de seguridad en formularios de WordPress.
Una vez que tenés el respaldo, podés usar el plugin WP Migrate DB o el más específico Fix Character Encoding (disponible en el repositorio oficial de WordPress), que convierte las tablas con un proceso relativamente seguro. La otra opción es hacerlo manualmente desde phpMyAdmin con una consulta SQL por tabla:
ALTER TABLE wp_posts CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
Repetís eso para wp_comments, wp_postmeta, wp_options y las demás tablas del sitio. No es glamoroso, pero funciona.
¿Qué pasa con el contenido ya guardado con caracteres corruptos? La conversión del charset de la tabla no «arregla» automáticamente el texto que ya estaba mal. Para eso, el proceso es más artesanal: exportar el SQL, hacer un find & replace de las secuencias corruptas conocidas (ñ → ñ, á → á, etc.) con un editor como Notepad++ configurado en UTF-8 sin BOM, y volver a importar. Tedioso pero efectivo.
Conflictos de plugins y temas: cómo identificarlos
Ponele que ya hiciste todo lo anterior y el problema sigue. El sospechoso siguiente son los plugins o el tema activo.
Hay plugins, sobre todo los que tienen más de ocho o diez años sin actualizaciones mayores, que fuerzan cabeceras HTTP propias o que hacen operaciones de texto asumiendo ISO-8859-1. El método de diagnóstico es el clásico de siempre: desactivación progresiva.
Desactivá todos los plugins a la vez (podés hacerlo en masa desde el listado de plugins del panel). Si el problema desaparece, reactivá de a uno hasta que reaparezca. Cuando identificás el culpable, tenés tres opciones: buscar una actualización del plugin, reemplazarlo por un equivalente moderno, o contactar al autor.
Con los temas el proceso es parecido: activá temporalmente un tema por defecto de WordPress (Twenty Twenty-Four o Twenty Twenty-Five) y fijate si el problema persiste. Si desaparece, el problema está en tu tema.
Migración de servidor: la causa más común en 2026
Si migraste tu sitio recientemente y ahora tenés caracteres extraños en WordPress, las probabilidades apuntan al charset del servidor de destino. Esto se conecta con lo que analizamos en automatizar procesos en tu sitio.
El flujo típico de una migración problemática: exportás la base de datos del servidor viejo (correctamente configurado en UTF-8), la importás en el servidor nuevo, y el servidor nuevo tiene MySQL configurado con un charset distinto como default. El import funciona, WordPress arranca, pero el texto sale corrupto.
El checklist que debería revisarse antes de cualquier migración:
- Verificar charset y collation del servidor de destino desde phpMyAdmin o con
SHOW VARIABLES LIKE 'character_set%'; - Confirmar que la versión de MySQL en destino soporta
utf8mb4(requiere MySQL 5.5.3+ o MariaDB 5.5+) - Exportar el SQL con la opción «Forzar charset UTF-8» marcada en phpMyAdmin
- Verificar que el
wp-config.phpmigrado tiene las constantes correctas - Pedir al hosting que confirme el
default-character-setdel servidor MySQL
Si tu hosting es donweb.com, los servidores están configurados con utf8mb4 por defecto en los planes actuales. Pero si estás en un plan antiguo o migraste vos mismo el archivo de configuración, vale la pena confirmarlo con soporte.
Tabla de síntomas y causas más frecuentes
| Síntoma visible | Causa probable | Dónde buscar |
|---|---|---|
| ñ en lugar de ñ, á en lugar de á | Datos guardados en UTF-8 pero leídos como Latin-1 | Charset de tablas MySQL |
| ? en lugar de cualquier carácter especial | Charset incompatible en la conexión PHP-MySQL | Constante DB_CHARSET en wp-config.php |
| Cuadrados o signos de interrogación en el navegador | Cabecera HTTP devuelve charset incorrecto | Configuración de Apache/PHP en el hosting |
| Solo algunos posts tienen el problema | Contenido copiado desde Word o editor externo | Limpiar HTML del post en el editor de bloques |
| El problema aparece después de actualizar un plugin | Plugin modifica cabeceras o hace operaciones de texto | Desactivar plugins progresivamente |
Soluciones rápidas si nada funciona
Si ya hiciste todo lo anterior y el problema persiste, hay algunas cosas más que podés probar antes de escalar al soporte del hosting.
Primero, limpiá la caché del navegador completamente (Ctrl+Shift+Del). Parece obvio pero más de una vez el problema «estaba resuelto» y seguía apareciendo por caché. Probá también con un navegador distinto o en modo incógnito.
Si usás LiteSpeed Cache, W3 Total Cache o cualquier plugin de caché, vacialo desde el panel. Los cachers a veces guardan el HTML ya corrupto y lo siguen sirviendo aunque hayas corregido la fuente.
¿Alguien verificó la configuración de PHP en el servidor? Pedile al soporte del hosting que confirme que default_charset = "UTF-8" está en el php.ini. Desde PHP 5.6 ese es el valor default, pero instalaciones viejas pueden tenerlo en blanco o con otro valor.
Otra cosa que a veces pasa inadvertida: si editás archivos PHP del tema o de plugins con Windows Notepad y los guardás, Notepad puede agregar un BOM (Byte Order Mark) al principio del archivo. Eso rompe las cabeceras HTTP de WordPress. Editá siempre con Notepad++ o VS Code, configurados en «UTF-8 sin BOM».
Errores comunes
Cambiar el charset en wp-config.php sin convertir las tablas existentes
Cambiar DB_CHARSET a utf8mb4 solo define cómo WordPress crea tablas nuevas. Los datos viejos siguen con la collation anterior. Si esos datos ya estaban mal codificados, el problema continúa. El cambio en wp-config.php es necesario pero no suficiente.
Hacer la conversión SQL sin backup
El ALTER TABLE de conversión de charset puede fallar a mitad si hay un error de conexión, un timeout, o datos que no se pueden convertir. Si no tenés backup, el resultado puede ser una base de datos parcialmente convertida e irrecuperable. No hay forma de justificar saltarse este paso.
Si querés saber más, tenemos un artículo sobre Wierd WP issue...
Esto está directamente relacionado con Wierd WP issue.., donde profundizamos el tema.
Eso se conecta con lo que analizamos en Wierd WP issue...
Esto está cubierto en detalle en Wierd WP issue...
Confundir utf8 y utf8mb4 en MySQL como equivalentes
En MySQL, utf8 es un charset de 3 bytes que no cubre el rango completo de Unicode. utf8mb4 es el charset correcto para Unicode completo. Si migrás a utf8 creyendo que es suficiente, vas a tener problemas con cualquier contenido que use emojis o caracteres de idiomas no europeos. Usá utf8mb4 siempre. Cubrimos ese tema en detalle en plugins feature de distribución gratuita.
Ignorar el charset de la collation al hacer el ALTER TABLE
No alcanza con especificar CHARACTER SET utf8mb4 en el ALTER TABLE. También hay que especificar la COLLATE. La collation utf8mb4_unicode_ci es la más recomendada para sitios en español porque hace comparaciones insensibles a mayúsculas/minúsculas y maneja la ñ correctamente.
Preguntas Frecuentes
¿Por qué aparecen caracteres extraños en mi sitio WordPress?
El origen casi siempre es una incompatibilidad de charset entre WordPress, la base de datos y el servidor. WordPress usa UTF-8; si alguna parte de la cadena está en ISO-8859-1 u otro charset, los caracteres especiales del español (tildes, ñ, signos de apertura) se convierten en secuencias de símbolos ilegibles. Las causas más frecuentes son migraciones de servidor sin verificar charset y bases de datos heredadas que nunca se actualizaron.
¿Cómo arreglar acentos y ñ que no se ven en WordPress?
El proceso tiene tres pasos. Primero, verificar y corregir las constantes DB_CHARSET y DB_COLLATE en wp-config.php para que usen utf8mb4 y utf8mb4_unicode_ci. Segundo, convertir las tablas existentes de la base de datos al mismo charset con un ALTER TABLE ... CONVERT TO CHARACTER SET utf8mb4. Tercero, limpiar la caché del sitio y del navegador. Antes de hacer cualquier cambio en la base de datos, respaldala.
¿Qué causa los símbolos raros después de una actualización de WordPress o del hosting?
Las actualizaciones de PHP (especialmente de 7.x a 8.x) o los cambios de versión de MySQL en el hosting a veces resetean configuraciones de charset. Si el problema apareció justo después de una actualización, lo primero que hay que verificar es el default_charset de PHP (php.ini) y el charset de conexión del motor de base de datos. También puede ocurrir que la actualización activó un módulo nuevo que agrega cabeceras HTTP con charset incorrecto.
¿Cómo configurar UTF-8 en WordPress correctamente desde cero?
En una instalación nueva, WordPress ya configura UTF-8 automáticamente si el servidor lo soporta. Para verificar que todo está bien: wp-config.php debe tener DB_CHARSET = 'utf8mb4' y DB_COLLATE = 'utf8mb4_unicode_ci'; el servidor debe devolver Content-Type: text/html; charset=UTF-8 en las cabeceras; y phpMyAdmin debe mostrar las tablas de WordPress con collation utf8mb4_unicode_ci.
¿Hay un plugin para solucionar problemas de codificación en WordPress?
Sí, aunque con matices. El plugin Fix Character Encoding, disponible en el repositorio oficial de WordPress, ayuda a convertir tablas existentes. WP Migrate DB incluye opciones para forzar charset durante exportaciones e importaciones. Dicho esto, estos plugins son herramientas de diagnóstico y conversión, no soluciones permanentes: si el problema de configuración subyacente no se corrige en wp-config.php y en el servidor, el problema puede reaparecer.
Conclusión
Los caracteres extraños en WordPress tienen solución directa en la gran mayoría de los casos: alinear el charset entre WordPress, la base de datos y el servidor en utf8mb4. El proceso no es complicado, pero requiere orden: primero backup, después diagnóstico, después cambios en wp-config.php, y si los datos ya están corruptos, conversión de tablas.
El escenario que genera más problemas en 2026 sigue siendo la migración de servidor sin checklist de charset. Si sabés que viene una migración, revisá los puntos de configuración antes de mover los datos, no después. Es mucho más fácil configurar bien el destino que reparar una base de datos ya importada con codificación incorrecta.
Si el problema persiste después de todos los pasos técnicos, la causa probable es un plugin o tema heredado. El método de desactivación progresiva lo identifica rápido y sin daño.