Corregir CORS en WordPress sin romper nada

Qué significa un error CORS en WordPress y por qué aparece

Un error CORS indica que el navegador ha bloqueado una solicitud de origen cruzado porque la respuesta no incluye las cabeceras adecuadas o entra en conflicto con la política de mismo origen. En un sitio WordPress esto puede aparecer al usar la API REST, fuentes externas, imágenes servidas desde un subdominio, scripts desde una CDN o integraciones con servicios de terceros.

Por eso, aunque el problema se vea dentro de una web hecha con WordPress, no siempre nace en el core. Puede deberse al tema, a un plugin que modifica cabeceras, a Cloudflare, a reglas del hosting, a Apache o Nginx, o incluso al propio servicio externo que entrega el recurso.

Antes de tocar nada: qué debes revisar en el navegador y en la solicitud

Antes de aplicar cambios, conviene revisar cuatro puntos: qué recurso falla, desde qué origen se solicita, qué cabecera falta o entra en conflicto y en qué capa se gestiona la respuesta. Este diagnóstico evita añadir parches globales que luego rompen otras funciones.

• Abre DevTools del navegador y revisa la consola para ver el dominio exacto afectado.
• En la pestaña Network, localiza la solicitud bloqueada y comprueba la URL, el código de estado y las cabeceras de respuesta.
• Si existe una preflight OPTIONS, verifica si falla antes de la solicitud principal.
• Confirma si el recurso sale del mismo dominio, de un subdominio, de una CDN o de un servicio externo.

Muchas veces el mensaje menciona Access-Control-Allow-Origin, pero eso no significa automáticamente que debas añadir esa cabecera en cualquier sitio. Depende de dónde se entregue el recurso y de qué capa esté respondiendo realmente.

Dónde suele estar el problema: WordPress, servidor, CDN o recurso externo

En un entorno WordPress habitual en hosting compartido, el conflicto puede aparecer en varias capas a la vez. Un plugin puede inyectar cabeceras, pero la respuesta final seguir sirviéndose desde caché del servidor o desde Cloudflare. También es frecuente que una fuente, un script o una imagen se carguen desde otro origen con políticas distintas.

Si el error afecta a la API REST de WordPress, conviene revisar si hay reglas de seguridad, plugins de hardening o snippets que alteran la respuesta. Si el fallo aparece solo en archivos estáticos, como fuentes o imágenes, suele ser más probable que la cabecera deba gestionarse donde esos archivos se sirven: servidor web, CDN o subdominio de medios.

Cómo corregir CORS en WordPress sin romper otras funciones

La forma prudente de actuar es ajustar solo la capa implicada y validar el resultado después de cada cambio.

Ajustes en servidor o hosting

Si el recurso bloqueado se entrega desde Apache, Nginx o una CDN, conviene revisar ahí las cabeceras de respuesta. En algunos hostings esto se gestiona desde el panel, en otros mediante reglas específicas. No es recomendable aplicar comodines amplios ni duplicar cabeceras sin verificar antes qué está devolviendo ya el servidor.

Casos vinculados a la API REST

Si el problema afecta a peticiones hacia /wp-json/, revisa si un plugin, un firewall o un snippet está modificando autenticación, métodos permitidos o respuesta preflight. WordPress tiene comportamiento propio para la REST API, por lo que conviene apoyarse en la documentación oficial de la REST API si necesitas confirmar cómo debería responder el sistema base.

Recursos cargados desde subdominios o terceros

Cuando el recurso viene de un subdominio, una biblioteca externa, una fuente web o una CDN ajena, el ajuste debe hacerse en ese origen si tienes control sobre él. Si no lo tienes, quizá debas cambiar la forma de cargar el recurso o usar una alternativa compatible, porque WordPress no puede corregir desde su lado una respuesta remota mal configurada.

Plugins o snippets que añaden cabeceras duplicadas

También conviene revisar si hay varios plugins, funciones en functions.php o reglas del hosting añadiendo cabeceras CORS a la vez. Las duplicidades o valores incompatibles pueden generar respuestas ambiguas y provocar bloqueos aunque aparentemente la cabecera exista.

Después de cualquier cambio, purga la caché del plugin, del servidor, de la CDN y del navegador. Si no lo haces, puedes estar comprobando una respuesta antigua y sacar una conclusión equivocada.

Errores frecuentes al aplicar cabeceras CORS

• Añadir Access-Control-Allow-Origin: * sin valorar riesgos ni compatibilidad con credenciales.
• Modificar WordPress cuando el recurso real lo sirve otra capa distinta.
• Olvidar la solicitud preflight y revisar solo la petición final.
• Mantener activas reglas en plugin, .htaccess, Nginx y CDN al mismo tiempo.
• Confundir un error CORS con un 403, un bloqueo WAF o un problema de autenticación.

Qué hacer si el error continúa después de los cambios

Si el error persiste, lo más útil es comparar la respuesta antes y después de cada ajuste y aislar la capa que sigue devolviendo cabeceras incorrectas. Desactiva temporalmente solo lo imprescindible para probar, como un plugin de seguridad o un sistema de caché, y vuelve a medir en DevTools. Si hay Cloudflare, proxy inverso o reglas del hosting, conviene confirmar qué respuesta llega realmente al navegador.

En resumen, el criterio correcto para corregir CORS en WordPress es diagnosticar antes de cambiar cabeceras. Aplicar parches globales puede ocultar el origen real del conflicto y romper APIs, fuentes, caché o integraciones externas. Si no está claro qué capa responde mal, el siguiente paso razonable es una revisión técnica del origen del conflicto para corregirlo con precisión y sin efectos colaterales.