WooCommerce Endpoints Not Working

Endpoints are not pages. /my-account/orders/, /checkout/order-received/, /my-account/lost-password/ and the rest are rewrite rules that append a segment to one real page and tell WooCommerce which view to render. Nothing exists in the pages list for them, which is why "the page is missing" is the wrong mental model and leads people to create pages that make things worse.

Three layers can fail: the rewrite rules, the page the endpoint hangs off, and the content of that page.

Confirm which layer is broken

Test in this order, logged in, in a private window:

If pretty URLs are broken across the whole site and not only in WooCommerce, fix that first — WordPress permalinks not working is the general case, and everything below assumes the rest of the site is fine.

Flush the rewrite rules

The single most effective step, and the one to try first:

Settings → Permalinks → Save Changes. Change nothing; saving regenerates the rules.

Or with WP-CLI:

wp rewrite flush --hard
wp rewrite list --format=table | grep -i "my-account"

The rules for each endpoint should appear in that list. If they do not, WooCommerce is not registering them — a plugin conflict or a fatal error during initialisation, which debug mode will show.

If the endpoints work for a while and then 404 again, something is regenerating the rules or overwriting .htaccess: a security plugin, an optimisation plugin, or a deployment process that ships its own file. Find that before flushing a third time.

Check the page assignments

WooCommerce needs to know which page is which. Open WooCommerce → Settings → Advanced and confirm:

• Cart page, Checkout page, My account page and Terms each point at an existing, published page.
• The account endpoints and checkout endpoints slugs are what you expect, with no leading or trailing slashes.

Two failure modes here are easy to miss. A page that was deleted or moved to trash leaves the setting pointing at an ID that no longer resolves — the dropdown then looks empty rather than wrong. And a page duplicated during a redesign can leave the setting on the old copy, so edits appear to have no effect.

After changing any of these, flush permalinks again.

Slug collisions

An endpoint slug cannot be the same as a child page under the same parent. If a real page exists at /my-account/orders/, WordPress resolves the page and WooCommerce never sees the endpoint. Symptoms: one endpoint broken while the others work.

Check for pages whose slug matches an endpoint name — orders, downloads, edit-address, payment-methods, edit-account, customer-logout, order-received, order-pay, lost-password. Rename or delete the page, or rename the endpoint. Also check the trash: a trashed page still owns its path until the trash is emptied.

Blank endpoints rather than 404s

A 200 response with nothing in it is a different problem. The URL resolved; the content did not render.

• The page lost its shortcode or block. The account page needs [woocommerce_my_account], checkout needs [woocommerce_checkout], cart needs [woocommerce_cart] — or the equivalent blocks if the store uses the block cart and checkout. A page rebuilt in a page builder is the usual way these disappear; displaying products with shortcodes covers the shortcode side generally.
• Blocks and shortcodes are mixed. The block checkout and the shortcode checkout are different implementations. Pick one per page.
• A template override is stale. A theme copy of a WooCommerce template in woocommerce/ that was written for an older version can render nothing at all. Compare it against the current template before assuming the core is at fault.
• A page builder is wrapping the content and stripping the dynamic part. Test with a default theme and the builder disabled.

Caching, which breaks account pages specifically

Account, cart, checkout and order-received pages must never be served from a page cache. When they are, visitors see someone else's data or an endless "processing" state.

Confirm those pages are excluded in your caching plugin and at the host and CDN, then purge everything — the exclusion rules are set out in choosing a WordPress cache plugin, and the purge sequence in how to clear the WordPress cache.

The order-received endpoint deserves special attention: it carries an order key in the query string, and a cache that strips or ignores query strings will show every customer the same stored page.

Server rules and PHP limits

On Nginx there is no .htaccess, so a missing try_files directive breaks every endpoint at once while the home page loads normally. On Apache, a RewriteRule added by a security plugin above the WordPress block can swallow the request before it reaches index.php.

Two more server-side causes worth checking when the account page 404s intermittently rather than always:

• A max_input_vars limit hit during checkout processing, which truncates POST data and produces odd redirects rather than errors.
• A firewall rule blocking POST requests to admin-ajax.php or the store's REST routes, which breaks the actions on those pages while the pages themselves load. WooCommerce checkout not working covers that path in detail.

Verify the whole set

After any fix, walk the endpoints logged in as a customer with at least one completed order:

1. /my-account/ and each of its sub-pages, including logout.
2. /cart/ with an item in it.
3. /checkout/, then a full test order through to /checkout/order-received/.
4. /my-account/lost-password/ and the emailed reset link.
5. A downloadable product's download link, if you sell any.

Do it in a private window with the cache purged. Testing while logged in as an administrator, with caching bypassed, is how a broken customer account page survives a "fix" for weeks.