Prove this is a client-side page route
A static app's deep link needs an origin fallback to its entry page while real missing assets must still return 404.
A client-routed page can work after in-app navigation while its direct URL still receives an origin 404. Record one working home URL and one failing page route. The History API can change the visible URL without fetching a new document during in-app navigation; a later direct browser request asks the server for that path. Confirm the framework deliberately owns that route and that the application entry page renders it when loaded correctly.
Check a real asset URL such as a JavaScript module or stylesheet separately. If the asset is missing, fix the build output or path first. A fallback that turns missing asset requests into the entry HTML can hide the underlying error and create a MIME failure.
Scope the fallback to application page routes
The application owner should list the page-route prefixes that need the entry page and the asset, API, download and well-known paths that must keep their normal response. Ask whether the purchased hosting account provides an account-level route or rewrite control for this static delivery model. Apache’s FallbackResource illustrates a front-controller fallback, but it handles every otherwise-unmatched request in its scope, including a missing asset, unless that asset path is excluded by a separate rule or narrower directory scope. Its documentation does not prove the active Novasean web stack or account permission.
Keep a copy of the previous account rule. If the only available rule cannot preserve genuine missing-asset 404 responses and unrelated application paths, stop and ask the application owner or operator for a safer supported deployment arrangement.
Make one reviewed account-scoped change
Have the authorised application owner or contracted operator apply the smallest supported rule that serves the application entry page for recognised page routes. Do not edit global virtual-host files on shared hosting. Ensure existing files are served as files and API requests are not rewritten to HTML. A custom 404 document is not always equivalent: it may retain a 404 status when the application expects a successful page response.
Test deep links, assets and rollback
Open and refresh two representative deep links directly in a fresh session. Confirm the application renders the correct route and the response status matches the intended page behaviour. Then request a deliberately absent file under the actual asset prefix and confirm it still returns HTTP 404, rather than HTML with status 200. Also test an existing module and the homepage. If the fallback masks the missing file or breaks another application, restore the previous rule and have the owner revise the route scope before trying again.
For example, /account/settings should load directly while a missing /assets/app.js stays 404. If the app genuinely serves assets under that path, test an existing asset too before approving the fallback.
Frequently asked questions
Why does clicking a link work but refreshing fail? In-app navigation can be handled by JavaScript, while refresh sends the route to the server.
Can I rewrite every unknown path to index.html? Only if the deployment design safely excludes assets and other paths. A blanket rule can conceal missing files.
Sources and technical references
Related guides
Was this guide helpful?
If you accepted optional analytics, your Yes/No answer and this guide’s page address are sent to Google Analytics. No written feedback is collected. Read our privacy statement or change your choice in .
Need help with your service?
Open your client area or contact Novasean. Describe the symptom and checks you have performed. Keep passwords, recovery codes and private keys out of your message.