Skip to content

Knowledgebase

Making client-side routes work after a browser refresh

development

A client-side router can display a page after navigation even when the web server does not know how to serve that URL directly. Direct visits and refreshes test a different part of the deployment.

What you need before you begin

Identify whether the site is a browser-only app, a prerendered site or a server-rendered application. Confirm the actual build output and router mode.

01 Make client-side routes work after a browser refresh

  1. Open a nested route directly in a new browser tab and record the response. Compare it with navigation to the same route from the homepage.

  2. For a browser-only app that requires an HTML fallback, configure the server to serve the application entry page for suitable application routes.

  3. Keep existing assets, API endpoints and unrelated directories outside that fallback. Use the hosting platform’s supported rewrite mechanism rather than an Apache rule on a different server type.

  4. For a prerendered or server-rendered site, configure the generated route files or application server as intended instead of applying a generic single-page-app fallback.

  5. Test a real route, a genuinely missing page and a missing asset. Review how status codes affect monitoring and search indexing.

02 Example: allow two SPA routes without swallowing missing assets

For an Apache 2.4 browser-only application published in /app/, this narrowly scoped rule belongs in that directory’s existing .htaccess. It serves the app entry page for two deliberately supported routes. Merge it with reviewed rules rather than replacing the whole configuration.

Code or configuration example
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(?:dashboard|settings)/?$ index.html [END]

Test direct visits to /app/dashboard and /app/settings. The expression is a route allowlist for this example, not a universal router configuration. Add real application routes deliberately. Existing files and directories remain eligible for normal serving, while unrelated API and asset paths do not match the fallback.

Expected result: Refreshing an approved client route works. A request for /app/assets/missing.js returns a missing-file response rather than HTML advertised as JavaScript, and unrelated website routes remain outside this rule.

Confirm the expected result

Confirm bookmarks and refreshes load the intended page while invalid assets still fail correctly. Check that API calls return API responses rather than the frontend HTML.

Troubleshoot unexpected results

A JavaScript MIME error often means the server returned index.html for a missing script. Fix the asset path and fallback exclusions rather than changing the script MIME type.

A common question

Should every unknown URL return a 200 page?

Use the application’s intended routing and not-found behavior. Returning a successful homepage for all missing content can confuse users, crawlers and uptime checks.

Was this answer helpful?

Need a little more help?

Our support team can help you find the next step.

Contact support

Powered by WHMCompleteSolution