404 at origin for specific sub-paths despite files confirmed in published deploy (cache purge confirmed — not a caching issue)

Support
1

Netlify site name: silver-madeleine-43fa72.netlify.app
Custom domain: fairwaygca.golf
Error: 404 on specific sub-paths only (/panel, /reservas, /evento) — root domain loads fine
Tried Ask Netlify first: Yes — it repeatedly suggested SPA redirect rules and cache issues, both of which I’ve ruled out below (site is plain static HTML, no framework/router; cache purge confirmed via API but 404 persists)

I have a static HTML site (no framework, no SPA, no build step — manual deploys). The root domain (fairwaygca.golf/) loads correctly and serves the latest published content. However, three specific sub-paths return a 404: /panel, /reservas, and /evento.

What I’ve already confirmed:

  • The published deploy’s Deploy File Explorer shows index.html (exact lowercase filename, confirmed by opening the folder) correctly present inside panel/, reservas/, and evento/ folders.
  • Tested the exact full path directly (/panel/index.html) — still 404.
  • Tested on the raw .netlify.app subdomain directly (bypassing the custom domain) — still 404, ruling out a custom domain/DNS issue.
  • No _redirects file, no netlify.toml, no Edge Functions configured.
  • Visitor Access is disabled (confirmed no password protection or access restriction).
  • No Git repository linked (confirmed “Not linked” under Continuous deployment) — so there’s no publish directory mismatch to check either.
  • Re-deployed cleanly from within the existing project’s own Deploys tab (not Netlify Drop) — same result.

The key evidence — this is not a caching issue:
I purged the site cache via the API (POST /api/v1/purge), confirmed with an HTTP/2 202 response. Re-testing /panel/index.htmlimmediately after, the response headers now show:

cache-status: "Netlify Edge"; fwd=miss; fwd-status=404; stored

This means the request reached origin cleanly (cache miss) and origin itself returned the 404 — not a stale cached response. Before the purge, the same path showed cache-status: hit; ttl=31535969 (~365 days), which is itself unusual for an error page, but the post-purge result rules out caching as the root cause entirely.

Could someone from the team take a look at why origin is failing to serve these specific sub-paths when the files are confirmed present in the published deploy? Happy to share the x-nf-request-id values from any of these requests if useful for tracing on your end.