Evaluación inicial sin contraseñas Presupuesto antes de intervenir Especialista responsable de principio a fin

Errores y diagnóstico

Un error CORS bloquea recursos, API o checkout: origen, cabeceras y caché

Respuesta directa: Un error CORS bloquea recursos, API o checkout: origen, cabeceras y caché debe resolverse como una decisión operativa, no como una…

Un error CORS es una decisión del navegador sobre una petición cross-origin concreta, no un fallo genérico de conectividad. Empieza por origin, URL destino, método y modo de credenciales exactos; después inspecciona los headers de la respuesta real, incluidas variantes de CDN/caché.

Captura la petición que falla

Registra Origin, destino, método, status, mensaje de consola y si envía cookies/Authorization. “Blocked by CORS” no basta para elegir solución.

Revisa el preflight cuando exista

OPTIONS debe llegar a la ruta correcta y devolver método/headers permitidos. Un 301, 403 o HTML cacheado puede fallar antes de la petición real.

Define un origen permitido preciso

Con credenciales, wildcard no es válido. Devuelve scheme+host esperado y habilita credenciales solo donde sean necesarias.

Localiza qué capa controla los headers

Aplicación, nginx, CDN, gateway y plugin pueden añadir o eliminar CORS. Valores duplicados o contradictorios rompen igual que su ausencia.

Haz segura la variación de caché

Si la respuesta cambia por Origin, la caché debe respetarlo. El edge no puede reutilizar un Allow-Origin de otra web. Revisa también `Vary: Origin` cuando la respuesta dependa del origen solicitado.

Prueba la ruta real en navegador

curl muestra headers pero no aplica la política CORS del navegador. Repite con mismo origin, método y credenciales del checkout o frontend.

Si el endpoint hace timeout en vez de responder CORS, pasa al diagnóstico 504; si responde el backend equivocado, verifica DNS tras migración.

ANTES DE ENVIAR LA SOLICITUD

Preguntas frecuentes.

¿Pedís contraseñas en el formulario?+

No. El formulario público nunca solicita accesos. Los datos seguros se piden únicamente después de aprobar el alcance y el presupuesto.

¿Quién revisa la incidencia?+

La solicitud llega a Jordi Ensenyat, fundador de Code Barcelona y especialista WordPress con más de 15 años de experiencia.

¿Se cambia algo antes del presupuesto?+

No. Primero se revisan los síntomas visibles y se define el alcance. La intervención empieza tras la aprobación y con una vía de vuelta preparada.

¿Trabajáis con webs en inglés y fuera de España?+

Sí. WP Repair atiende incidencias WordPress y WooCommerce en inglés y español, con servicio remoto.

Evaluar mi incidencia↗