Why does a Netlify single-page app rewrite return HTTP success?

Definition: As of 17 October 2026, Netlify documents a single-page app (SPA) rewrite as a rule that serves the app's index.html at the requested URL with HTTP status 200. The fallback can therefore return success for a path with no corresponding static file.

Key facts

• Netlify's redirect options documentation identifies 200 as the rewrite status; omitting the status defaults to 301, a permanent redirect.
• Netlify's rewrites documentation gives /* /index.html 200 as the SPA fallback and recommends placing it after other routing rules.
• Netlify's routing overview says the first matching rule applies, with _redirects rules processed before netlify.toml rules.
• As of 17 October 2026, Google's HTTP status documentation says a successful response containing an empty page or error message can produce a soft 404 report in Search Console. A soft 404 is an error inferred from content returned with a success status.

How is the success status configured?

A rewrite serves a destination's content while preserving the requested URL. Netlify's SPA example supports paths used by the browser's history pushState method, which the documentation associates with clean URLs.

The documented _redirects rule is:

/*  /index.html  200

The equivalent netlify.toml configuration is:

[[redirects]]
  from = "/*"
  to = "/index.html"
  status = 200

Netlify's routing overview requires _redirects to reach the publish directory, the folder of finished files deployed after the build. These are alternative ways to express the fallback. The explicit 200 selects rewrite behavior.

Which requests reach the fallback?

Netlify calls the default protection for existing files shadowing. Its rewrites documentation explains that an existing /partials/chat.html still serves its own contents under the SPA fallback. A path without a matching static file can instead receive index.html.

The same documentation shows 200! to force a rewrite even when a file matches. In netlify.toml, Netlify's redirect options express this override as force = true. Adding force broadens which requests receive the fallback.

Rule order also matters. The routing overview specifies top-to-bottom processing. A catch-all in _redirects can match before a more specific rule in netlify.toml, because the entire _redirects file is processed first.

How can missing paths return a missing-page status?

Netlify's redirect options support explicit 404 rules that serve error content while retaining the requested URL. The following combines its documented closed-store example with the SPA fallback:

/ecommerce  /store-closed  404
/*          /index.html   200

The specific rule precedes the fallback. The destination must contain the intended error content. The same documentation describes automatic handling of a deployed 404.html for failed paths; the SPA fallback already handles matching paths by serving index.html.

For a deployed app, a useful check compares the HTTP status and returned content for a valid app route and a deliberately nonexistent path. Google's status documentation explains why both matter: 200 passes the received content to further processing, and error-like content can lead to a soft 404 classification.

Related terms

• HTTP status codes
• Soft 404
• JavaScript rendering and AI crawlers
• How do I add redirects with Netlify's _redirects file?

FAQ

Why does a made-up path return the app?

If your request reaches the documented SPA fallback, Netlify serves index.html with 200. The wildcard rule covers paths beyond individual static files.

Does adding 404.html fix the fallback status?

Netlify's custom error handling uses 404.html for failed paths. If your catch-all already matches a request, review its scope and rule order so the intended missing-page response can apply.

Should I use force for every SPA route?

The same shadowing documentation preserves existing files by default. Use a forced rule only when you intend to serve the rewrite destination even for matching static files.

Sources

1. Netlify, "Redirect options", 17 September 2026
2. Netlify, "Rewrites and proxies", 14 July 2025
3. Netlify, "Redirects and rewrites", 14 July 2025
4. Google, "How HTTP status codes affect Google's crawlers", 4 February 2026

---

Check how a page reads to answer engines. Open the GEO score analyzer