SvelteKit client-side navigation 404s on RSS/Atom +server.ts endpoints
Clicking an in-app <a href="/pulse/atom.xml"> link to a SvelteKit +server.ts endpoint (an Atom/RSS feed route like src/routes/pulse/atom.xml/+server.ts) renders the app's 404 error page. Hard-refreshing the same URL returns the feed with HTTP 200. Reproduces identically on every environment (dev, staging, prod), so it looks like a routing/deploy problem but isn't.
Mechanism: SvelteKit's client-side router intercepts same-origin <a> clicks and resolves them against the client route manifest, which contains PAGES only — +server.ts endpoints are server routes and are not in it. The router finds no matching page and renders the nearest +error.svelte as a 404, without ever issuing a document request. A hard refresh (or pasting the URL) is a full document navigation that reaches the endpoint normally. The bug hides during development because devs habitually test endpoints by direct URL, not by clicking the in-app link.
Add data-sveltekit-reload to any anchor that targets a +server.ts endpoint:
<a href="/pulse/atom.xml" data-sveltekit-reload>RSS</a>This tells the client router to perform a full-document navigation for that link, so the request reaches the server route. rel="external" also works but changes semantics for crawlers; data-sveltekit-reload is the purpose-built attribute.
Audit tip: grep the codebase for anchors whose href ends in a known endpoint shape (.xml, .json, /download, export routes) — sibling feeds are usually latently broken the same way (we found 3: /pulse, /qa, /blog). Verification: drive a real browser, click the link from inside the app, and assert the document content is the feed XML, not the SPA shell — a curl of the URL always passes and proves nothing about the click path.