Forum Replies Created

Viewing 2 replies - 1 through 2 (of 2 total)
  • Thread Starter sebastiansantamariacea

    (@sebastiansantamariacea)

    Hola Yasin,

    Gracias por la respuesta. Actualizo el estado: ya no es necesario probar la desactivación de 10Web Booster, porque encontramos y confirmamos la causa raíz por otra vía.

    El problema real era el plugin WPS Hide Login, que estaba interceptando las peticiones sin sesión iniciada a /wp-admin/ y devolviendo un 404, lo cual impedía que Google verificara la conexión. No era el caché/optimización de 10Web Booster.

    Al desactivar WPS Hide Login, la verificación de Google Merchant Center se resolvió y el feed de productos volvió a sincronizar correctamente.

    Gracias de todos modos por la ayuda y por confirmar que esas rutas ya estaban excluidas por defecto en Booster, eso ayudó a descartar esa hipótesis. Dejo esto documentado por si le sirve a alguien más con el mismo síntoma.

    Saludos,

    Sebastián

    Thread Starter sebastiansantamariacea

    (@sebastiansantamariacea)

    Hi @shahzeenfarooq, thank you for the detailed guidance!

    I contacted my hosting provider and they confirmed and fixed the /xmlrpc.php redirect loop issue – it now returns a valid 200 response with proper XML-RPC output.

    However, wpcom_rest_api_status is still returning “error” and Sync All Products still fails with “Google Merchant Center no se ha configurado correctamente.”

    I dug further and found the actual root cause: GET https://www.mammluu.cl/wp-admin/ WITHOUT an active session redirects to a 404 page at https://www.mammluu.cl/404/?v=161747ec4dc9 instead of showing the WordPress login screen.

    The response headers on that 404 include: server: cloudflare, x-two-optimize: 1, x-two-optimize-reason: “HTTP status code is: 404”, x-two-cache-date, x-two-page-is-optimized. These x-two- headers indicate this is being served by the 10Web Booster plugin Cloudflare-based optimization/caching layer, not by the origin server or a WordPress redirect. This is very likely why wpcom_rest_api_status stays in error state, since Google servers cannot reach the verification endpoint when unauthenticated.

    I’ve posted the full System Status Report plus this additional diagnostic info here: https://pastebin.com/M6vtq5kG

    Before I run the disconnect/reconnect flow you suggested, could you confirm whether excluding /wp-admin/* from the 10Web Booster cache/optimization layer would resolve this, so I know what to ask my hosting provider for? I want to avoid disconnecting and losing time if the underlying cache issue would just cause the same failure again on reconnect. Thank you!

Viewing 2 replies - 1 through 2 (of 2 total)