Por qué una landing estática (o hecha con IA) puede romperte el pago de WooCommerce

Si tienes una tienda con WooCommerce y de repente la página de pago se queda cargando y cargando, con esa ruedecita que no para nunca, ¿a que lo primero que harías sería empezar a desactivar plugins o culpar a una actualización reciente?

Pues no, resulta que lo más probable es que algo que NO es WordPress esté respondiendo a la petición del pago y le esté devolviendo el HTML de una página normal donde el navegador esperaba datos, así que se queda colgado sin dar la cara.

Casi seguro que ni es tu pasarela de pago, ni es el tema, ni nada que hayas tocado tú.

Lo sé porque me pasó hace nada en una de mis propias webs, la de mantenimiento, y lo más desesperante es que no salía ni un triste error en la consola del navegador.

Cero pistas justo por el sitio donde todo el mundo mira primero. Vamos a verlo con calma, porque una vez sabes dónde mirar esto se diagnostica en dos minutos.

El pago de WooCommerce se queda cargando y la consola no dice nada ¿qué pasa?

Es una triste historia, la página de finalizar compra ha cargado bien, ves tus campos y tu resumen del pedido, pero el bloque del resumen y la zona de pago se quedan con la ruedecita girando y un velo gris por encima, y el botón de pagar no responde.

No es una pantalla en blanco, no es un error 500, simplemente esa parte no termina de actualizarse nunca.

Aquí va la primera pista, y es importante, y es que la página sí carga, lo que no termina nunca es la actualización de ese resumen en el pago.

Y eso pasa porque WooCommerce refresca esa parte por detrás con una llamada AJAX (una petición que el navegador hace en segundo plano, sin recargar la página) que se llama update_order_review.

Cada vez que cambias un dato del pedido, WooCommerce lanza esa llamada para recalcular totales, impuestos y métodos de pago, y si esa llamada no vuelve como debe, esa parte se queda atascada para los restos, y nadie puede hacer compras en tu web, un marronazo tremendo.

Total, que la avería no está en la página que ves, está en una petición interna que no ves. ¿Desentrañamos el misterio?

La consola de desarrollo del navegador al rescate

No hay que ir muy lejos, solo tienes que abrir las herramientas de desarrollo de tu navegador, normalmente con F12 (Windows) o Opción+Comando+I (Mac), o haciendo clic en cualquier parte de la página y luego en «Inspeccionar elemento», da igual el qué.

Normalmente iríamos a la pestaña llamada Consola a buscar el error en rojo, pero no, en esta avería concreta ahí no hay nada de nada, vuelta a buscar culpables en los plugins o una actualización del tema ¿no?

Pues no, simplemente estás mirando en el lugar equivocado, las respuestas las vas a encontrar en la pestaña llamada Red (o Network si lo tienes en inglés).

En esta pestaña es donde se ven todas las peticiones que hace el navegador, una a una, con su estado y su respuesta:

• Abre las herramientas de desarrollo y haz clic en la pestaña Red.
• Recarga la página de pago o vuelve a tocar un campo para que WooCommerce lance la llamada.
• En el filtro escribe wc-ajax, o busca directamente la petición update_order_review.
• Haz clic en esa petición y mírate dos cosas: el estado (Status) y la respuesta (Response).

Con eso ya tienes delante lo que de verdad está pasando, sin adivinanzas. Y según lo que veas, la cosa va por uno de tres caminos, lo vemos ya.

Las tres caras de un pago que no carga

Esa petición update_order_review te puede salir de tres maneras, y cada una apunta a un problema distinto:

• Se queda en Pending (pendiente) y no termina nunca: Eso es que el servidor se ha quedado pillado procesando algo por dentro, normalmente una consulta lenta o una llamada externa que no responde. Es más un tema de rendimiento, y tiene su propia historia. Si lo tuyo es que el carrito va lento, no que devuelve cosas raras, échale un ojo a mi guía sobre la carga lenta por culpa de wc-ajax=get_refreshed_fragments, que va justo de eso.
• Devuelve un 500: Ahí hay un error grave de PHP, que no estás viendo porque en producción los errores suelen ir ocultos. Toca mirar el registro de errores de tu hosting.
• Devuelve un 200: O sea, todo correcto en teoría, pero cuando abres la pestaña Respuesta, en lugar de un montón de datos te encuentras… HTML, una página web enterita. Esta es la avería que queremos arreglar hoy.

Y es que esta tercera es la más traicionera de todas, porque el navegador recibe un 200, todo bien y por eso no salta ninguna alarma por ningún lado. Aquí está el quid de por qué la consola no mostraba errores.

La explicación es que WooCommerce espera que esa petición le devuelva los datos en formato JSON (el formato en el que viajan los datos entre tu web y el navegador, una especie de lista ordenada que el JavaScript sabe leer), pero lo que le llega una página web en HTML.

El JavaScript del pago de WooCommerce intenta leer esos datos, se encuentra con una página entera, y no sabe qué hacer con semejante cosa y se queda plantado, con la ruedecita dando vueltas.

Ni se queja, ni avisa, ni nada. Te doy la bienvenida al club de los que han pasado media tarde mirando donde no era, porque sí, a mi me ha pasado, como casi todo lo que cuento en este blog.

JSON o HTML, esa es la cuestión … my friend

Aquí está la pregunta que lo resuelve casi todo, porque si WooCommerce pidió datos y lo que vuelve es una página, ¿qué te está colando esa página web en vez de dejar que conteste WordPress?

Porque si te devuelve la portada de tu propia web, algo se está comiendo la petición antes de que llegue siquiera a WordPress ¿qué puñetas está pasando, no era WordPress dinámico, inteligente, cojonudo?

Los sospechosos habituales son estos:

• Una página estática (un archivo index.html) en la raíz de tu web. La más típica, y la que me tocó a mí, así que la desarrollo abajo entera.
• Una caché o CDN que ha guardado una página HTML para esa dirección y la sirve en vez de la respuesta de verdad. Purga la caché y prueba otra vez.
• Un plugin de próximamente o modo mantenimiento que intercepta y le enseña su pantalla a todo el que pasa, peticiones AJAX incluidas. Desactívalo un momento y prueba.
• Un cortafuegos o WAF, a nivel de servidor o de un plugin de seguridad, que bloquea o redirige las peticiones wc-ajax. Revisa sus reglas.
• Una redirección mal puesta que manda esa dirección a otro sitio.

Lo dejo en cinco a propósito, que esto no es un listado infinito. En la inmensa mayoría de los casos es el primero, y es el que viví yo, así que vamos con él.

Esas bonitas y ligeras páginas hechas con HTML (o con IA) delante de tu WordPress

Cada vez más gente se monta una página de inicio bonita por su cuenta, a mano o, ahora, generada con IA en un rato, y la sube como index.html a la raíz de su hosting, encima del WordPress que ya tenía funcionando ahí debajo.

Pues casi siempre esta sencilla acción, lógica a prueba de toda duda, es casualmente la que provoca casi siempre este problema con el pago de WooCommerce.

Cuando alguien entra a la raíz de tu web el servidor tiene que decidir qué archivo enseña. Y si encuentra un index.html, casi siempre lo sirve antes que el index.php de WordPress, porque ese es el orden por defecto en la mayoría de servidores. Tú querías que tu portada fuese esa página estática, perfecto, hasta ahí todo bien.

El problema es que WooCommerce hace sus llamadas AJAX a esa misma raíz, con un parámetro detrás, algo así como tudominio.com/?wc-ajax=update_order_review.

Para el servidor eso sigue siendo «la raíz», porque el parámetro de detrás le da igual a la hora de elegir qué archivo enseñar.

Así que le planta el index.html como es normal, y tú querías que pasase, el problema es que WordPress ni se entera de que ha habido una petición.

Es como si pones un cartel de bienvenida en la puerta de tu tienda, a los clientes que pasan a leerlo, estupendo.

Pero resulta el repartidor que viene a dejarte un paquete (que es WooCommerce pidiendo sus datos) se planta en la puerta, el portero le da el cartel, lo despacha, y el pobre vuelve con el cartel en la mano en lugar de con el paquete.

Y aquí viene lo que más despista de todo, y es que las páginas normales (tu /finalizar-compra/, tu /carrito/, las fichas de producto) sí funcionan, porque esas no son la raíz pelada y WordPress sí las gestiona con sus reglas de siempre.

Por eso la avería te deja tó picueto, porque la web va bien, la página de finalizar compra incluso carga, y solo se atasca esa actualización del resumen que viaja por la raíz.

De paso también te revienta el carrito, porque el contador y el añadir al carro por AJAX usan exactamente la misma puerta, así que si notas que el carrito tampoco se actualiza, ya sabes por dónde van los tiros.

¡Pues si no era tan difícil!

La idea es de lo más sencilla en realidad, se trata de conseguir que esas peticiones wc-ajax vayan directas a index.php, que es un archivo que el servidor ejecuta sin dudarlo, en vez de a la raíz pelada donde le gana la partida el HTML.

Tienes dos formas de hacerlo y con una te vale.

Opción A: regla en el .htaccess

Añade el siguiente bloque a tu archivo .htaccess, pero es importante que lo pongas fuera del bloque por defecto ese de # BEGIN WordPress / # END WordPress, justo antes por ejemplo

# Desbloquear WooCommerce AJAX si hay un index en html (visto en ayudawp.com)
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{QUERY_STRING} (^|&)wc-ajax= [NC]
RewriteRule ^$ index.php [L]
</IfModule>

Lo que hace es que cualquier petición a la raíz que lleve wc-ajax= se manda a index.php (con su parámetro intacto) antes de que el servidor sirva el index.html.

Así la recoge WordPress y devuelve sus datos como es de esperar.

Opción B: función como mu-plugin

Si prefieres no tocar nada del servidor, este mu-plugin hace lo mismo desde WordPress, es solo una línea de filtro que cuela index.php en la dirección del endpoint AJAX:

/* Desbloquear WooCommerce AJAX si hay un index en html (visto en ayudawp.com) */
add_filter( 'woocommerce_ajax_get_endpoint', 'ayudawp_wc_ajax_index_php', 99 );
function ayudawp_wc_ajax_index_php( $url ) {
    // Envía el endpoint de WooCommerce AJAX al index.php
    return str_replace( '/?wc-ajax=', '/index.php?wc-ajax=', $url );
}

Lo guardas como un archivo .php dentro de wp-content/mu-plugins/ (si no tienes esa carpeta, la creas) y se activa solo, sin más.

Cualquiera de las dos opciones arregla también el carrito, porque tira de la misma puerta, así que verás que el contador del carrito vuelve a actualizarse a la primera.

Comprobar que va y no volver a caer en la trampa

Para confirmar que está resuelto, abre directamente en el navegador la dirección tudominio.com/?wc-ajax=update_order_review.

Antes te salía la portada de la web, ahora debe salirte un 0 pelado o una respuesta de WooCommerce, no la página. Después prueba el pago de principio a fin y comprueba que el carrito suma bien.

Para que esto no te vuelva a pasar dentro de unos meses, si lo que quieres es tener esa página de inicio estática o hecha con IA como portada, lo limpio no es soltar el index.html suelto en la raíz a pelearse con WordPress.

Lo mejor sería servir ese diseño como página de inicio del propio WordPress, subiendo la maqueta a una plantilla de página y la pones como portada en los ajustes de lectura.

Te ahorras este problema y todos los derivados que tiene, porque cualquier cosa que WordPress sirva desde la raíz con un parámetro detrás puede caer en la misma trampa.

¿Lo hago ya?

Si te está pasando, pues claro, ya tardas, te lo resumo:

• Abre las herramientas de desarrollo del navegador, ve a la pestaña Red, vuelve a tocar el pago o recarga y busca la petición update_order_review.
• Mira su estado y su respuesta. Si es un 200 con HTML dentro, es esto que te he contado.
• Averigua qué responde a tu raíz, que casi seguro es un index.html, pero podría ser una caché o un plugin de «próximamente».
• Manda el wc-ajax a index.php con la regla del .htaccess o con el mu-plugin, y vacía la caché (por asegurar) para comprobar que ya funciona.

Dudas razonables que (supongo) hemos resuelto

¿Por qué mi pago de WooCommerce se queda cargando y no pasa nada?

Lo más habitual es que la llamada que actualiza el resumen del pedido (update_order_review) no esté recibiendo los datos que espera.

Si devuelve un 200 con una página HTML en vez de datos, hay algo respondiendo por la raíz de tu web antes que WordPress, normalmente una página estática, una caché o un plugin de mantenimiento.

¿Por qué no veo ningún error en la consola del navegador?

Porque la respuesta llega con un código 200, que significa «todo correcto». El navegador no la considera un error, simplemente el JavaScript del pago no sabe leer una página web donde esperaba datos y se queda parado en silencio.

La pista no está en la consola, está en la pestaña Red.

El wc-ajax me devuelve HTML, ¿qué significa?

Que la petición no está llegando a WordPress. Algo que está delante (un archivo index.html en la raíz, una caché, un cortafuegos o un plugin de «próximamente») responde por su cuenta con una página y nunca deja que WooCommerce conteste con sus datos.

¿Esto me afecta también al carrito?

Sí. El contador del carrito y el añadir al carro por AJAX usan el mismo endpoint en la raíz, así que se rompen igual. En cuanto aplicas el arreglo, vuelven a funcionar los dos.

Tengo una landing hecha con IA en la portada, ¿es seguro?

La página en sí no tiene nada de malo, el problema podría ser dejarla como index.html suelto en la misma carpeta que tu WordPress, porque se pelean por la raíz. Si la sirves como página de inicio del propio WordPress no hay conflicto.

Por cierto, para diagnosticar este tipo de cosas yo uso un pequeño mu-plugin que registra qué responde de verdad a tu pago de WooCommerce y cuánto tarda, y te lo puedes descargar aquí. Lo metes, reproduces el fallo, lees el registro y lo borras cuando termines.

Si te ha pasado algo parecido, o se te resiste por otro motivo, me tienes ahí abajo en los comentarios. Tú cuéntamelo, que para eso estamos.

¿Te gustó este artículo? ¡Ni te imaginas lo que te estás perdiendo en YouTube!