Arreglar fuentes bloqueadas por CORS en WordPress

Qué significa que una fuente esté bloqueada por CORS en WordPress

Una fuente bloqueada por CORS significa que el navegador ha rechazado cargar un archivo de tipografía, por ejemplo .woff2 o .woff, porque se solicita desde un origen distinto y la respuesta no autoriza ese acceso cruzado. Esto forma parte de la política Same-Origin del navegador.

En WordPress es frecuente verlo cuando las fuentes se sirven desde un subdominio como static.ejemplo.com, desde un cdn.ejemplo.com o desde una infraestructura externa distinta al dominio principal. Si el recurso no incluye una cabecera como Access-Control-Allow-Origin válida para ese caso, el navegador lo bloqueará aunque el archivo exista y responda con código 200.

Causas más habituales del error de fuentes bloqueadas por CORS

• La fuente se carga desde un subdominio distinto y el servidor que la entrega no envía cabeceras CORS.
• El CDN WordPress sirve los archivos estáticos, pero no aplica Access-Control-Allow-Origin a los tipos MIME de fuentes.
• Hay reglas en .htaccess o en nginx que solo afectan a imágenes o CSS, pero no a woff, woff2 o ttf.
• Un plugin de optimización o el constructor visual reescribe URLs y pasa la fuente a otro host sin replicar la configuración del origen.
• La caché del servidor, proxy o CDN mantiene cabeceras antiguas incluso después de haber corregido la regla.

Un ejemplo realista: la web carga CSS desde el dominio principal, pero las tipografías salen desde un subdominio técnico creado por el hosting. En ese escenario, el error cors fuentes no está en WordPress como aplicación, sino en la respuesta HTTP del host que entrega el archivo tipográfico.

Cómo revisar la URL de la fuente, el dominio y las cabeceras CORS

1. Abre la consola del navegador y localiza el mensaje de bloqueo. Normalmente indica la URL exacta de la fuente y el origen que intenta cargarla.
2. En la pestaña Network, filtra por font y revisa la petición del archivo. Comprueba si responde desde el dominio principal, un subdominio o un CDN.
3. Verifica si la respuesta incluye Access-Control-Allow-Origin y si su valor encaja con el origen de la página.
4. Confirma el tipo de archivo y el MIME. Algunas reglas solo se aplican a extensiones concretas y dejan fuera formatos modernos como woff2.

Si quieres una referencia oficial sobre el comportamiento general de CORS, Mozilla mantiene una documentación técnica útil para contraste: CORS en MDN.

Si la fuente se descarga desde un CDN y la cabecera no aparece, no sirve de mucho modificar solo WordPress. La corrección tendrá que aplicarse en la capa que realmente responde al archivo: servidor de origen, proxy inverso o configuración del propio CDN.

Cómo corregir CORS en Apache, .htaccess y Nginx sin romper otras cargas

La clave es aplicar la cabecera en el lugar correcto y solo para los recursos necesarios. No conviene asumir que una regla genérica resolverá todos los casos, porque depende de si Apache o Nginx sirve el archivo directamente, si interviene un CDN o si hay otra capa reescribiendo la respuesta.

Ejemplo prudente en Apache o .htaccess

<IfModule mod_headers.c>
  <FilesMatch "\.(woff|woff2|ttf|otf|eot)$">
    Header set Access-Control-Allow-Origin "*"
  </FilesMatch>
</IfModule>

Esta regla puede funcionar en algunos entornos, pero debe validarse según el hosting y el origen real de la fuente. Si necesitas restringir el acceso a un dominio concreto, el valor no debería abrirse sin revisar implicaciones técnicas. Además, en algunos servidores la directiva efectiva no se gestiona en .htaccess, sino en la configuración virtual del sitio.

Ejemplo prudente en Nginx

location ~* \.(woff|woff2|ttf|otf|eot)$ {
    add_header Access-Control-Allow-Origin "*";
}

En nginx cors, el matiz importante es que la ubicación, la herencia de cabeceras y la forma en que se sirven los estáticos pueden variar según la plantilla del servidor o el panel del hosting. Si la fuente sale del CDN, esta regla local puede no tener efecto visible.

Qué revisar si usas CDN, caché o plugins de optimización en WordPress

Cuando hay un CDN WordPress o un sistema de caché agresivo, la incidencia suele complicarse porque la cabecera que ves puede no proceder del servidor de origen. Revisa estos puntos:

• Si el CDN mantiene una versión antigua del recurso sin las nuevas cabeceras.
• Si el plugin de rendimiento mueve fuentes a un dominio estático diferente.
• Si la minificación o combinación de CSS reescribe rutas y hace que el navegador solicite la fuente desde otra ubicación.
• Si el proxy o firewall del proveedor normaliza o elimina cabeceras en ciertos tipos de archivo.

Un caso bastante común es corregir htaccess cors, recargar la web y seguir viendo el mismo error porque la caché de edge del CDN aún conserva la respuesta antigua. En ese escenario, además de ajustar la regla, conviene purgar caché en todas las capas relevantes y repetir la comprobación en modo incógnito o con la caché desactivada en herramientas de desarrollo.

Errores frecuentes y cuándo conviene pedir soporte técnico

• Añadir una cabecera en WordPress y asumir que afecta a un archivo servido por otro host.
• Aplicar reglas solo a woff y olvidar woff2, que hoy es muy habitual.
• Editar cabeceras sin comprobar antes qué capa responde realmente: origen, Nginx, Apache, CDN o proxy.
• Confundir un error CORS con un 404, 403 o problema de mixed content, que requieren otro enfoque.

Si después de revisar consola, red, origen de la fuente y caché sigues sin aislar la causa, suele ser más eficiente escalarlo. En instalaciones con CDN, balanceadores, hosting gestionado o plugins de optimización avanzados, tocar cabeceras sin mapa claro del flujo puede generar efectos secundarios en otros recursos estáticos.