What AJAX is #
AJAX stands for Asynchronous JavaScript and XML, though the XML part is historical: modern WordPress uses JSON as the data format, not XML. The concept is simpler than the acronym suggests. When you interact with a page and something happens without the page reloading, AJAX is almost certainly involved.
When you add a product to a WooCommerce cart and the cart icon updates without the page refreshing, that’s AJAX. When you fill out a Contact Form and see a “thank you” message without leaving the page, that’s AJAX. When the Gutenberg editor autosaves a draft in the background while you keep writing, that’s AJAX. WordPress uses AJAX constantly, in both the admin area and on the front end of sites.
How AJAX works #
When a user does something that triggers an Ajax Request (clicking “Add to Cart,” submitting a form), JavaScript sends a request to the WordPress server in the background. The server processes the request and sends back a response. JavaScript then updates the relevant part of the page with that response, without touching the rest of the page.
In WordPress, these background requests typically go to one of two endpoints: the legacy admin-ajax.php file (which many older plugins still use), or the REST API (the modern approach). Either way, the request happens behind the scenes while the user stays on the same page.
Why AJAX failures appear in Loupely captures #
When an Ajax Request fails, it usually fails silently from the user’s perspective. The cart button does nothing. The form appears to submit but no confirmation appears. The page builder won’t save. The underlying failure is a request that went out and either got an error response or got no response at all. Loupely’s browser-side capture records these failed network requests, including their status codes and the error responses. Combined with the PHP error data from the server, the correlation rules can often connect the failed Ajax Request to the specific server-side error that caused it.
When AJAX gets blocked #
Security plugins, server firewalls, and CDN configurations can block AJAX requests, treating them as suspicious automated traffic. When this happens, dynamic features stop working: carts don’t update, forms don’t submit, the Gutenberg editor can’t save. If a Loupely capture shows AJAX requests returning 403 responses, the most likely cause is a security layer treating the request as unauthorized. The fix is the same as for a blocked REST API: identify whether the block is from a security plugin, a server firewall, or a CDN, and whitelist the specific request paths that need to pass through.