Redirect non-existing routes to index.html for Generated Static Sites

Currently if a glitch project is a Generated Static Site it can not use a standard browser history based routeing scheme, it must use a hash based url scheme (e.g. If you want to just a standard scheme (like you’re out of luck. Once your project has gone to sleep and glitch serves the statically compiled site, if you try to load a route that doesn’t map to an actual file then it will just throw a 404. Which is frustrating since most modern static sites don’t work this way. Most statically generated sites with multiple routes have the web server setup such that any non-existing routes get redirected to index.html. Then it’s up to your app to decide if it’s a valid url that it should render a page for or return a 404.

I’m suggesting that for new projects glitch should start redirect non-valid urls to index.html for generated static sites and leave it up to the app to decide if it’s a route or not (or at least provide the option to make a glitch project behave this way).

To demonstrate this behavior I’ve remixed the react generated static site and simply removed the hash router leaving the standard routing behavior. This causes the about page to become immediately inaccessible as soon as the project switches to static mode: (accessible if the project code has been accessed in the last 5 minutes, otherwise not)

The project code:


This is a fantastic suggestion - in fact in the early days of generated static sites this was the behaviour by default. IMO that was a lot better, plus the react starter used proper routing back then iirc.
You absolutely have my vote (if I can free one up :pensive:)

Edit: I think originally they did something slightly different, for instance the 11ty starter gave a 404 error similar to the default on the old express project, and the react one was empty but with css or smth - but it was very similar to this.


Thanks for writing this up, I’m going to see if it’s possible for us to make it happen soon!


Great! Thanks for that :blush:

1 Like

I hate to be that “+1!” person, but this would make generated_static immensely useful for me. I normally do full pre-rendering that avoids the need for a 200.html solution (serve the contents of a given HTML file as a 200 response instead of producing 404’s). However, for dynamic routes this doesn’t work. I’m using querystring parameters for dynamic data in the interim, but I’d love to be able to have true support for pushState / History API in Glitch generated_static projects.

This feature is provided by most static hosting platforms:

Netlify: (docs) can be configured via _redirects file to serve an HTML file instead of 404’ing:

/*    /index.html   200 (docs) will serve a 200.html found in nearest parent directory instead of 404’ing

GitHub Pages: supports 404.html but not 200.html. Some folks are using <meta refresh> to hack around this.

Nuxt and a few other frameworks also generate 200.html by default.

It might also be a nice way to avoid folks creating projects that circumvent the static app serving restrictions (search this forum for “how would i switch not found page on static site”) or fronting a Glitch site with Cloudflare.


+1 from me too.

Hi @jenn, I noticed the behavior here has changed. Now instead of throwing a 404 if you visit a url which doesn’t correspond to a file in the file system when in static mode, it will return a 302 and redirect you to the home page.

Screen Shot 2021-12-15 at AEDT - 8.38.25 am

While it’s good that Glitch is now serving the index.html at the root if there isn’t a corresponding file unfortunately doing this redirect on the client side via a 302 means that it’s still not possible to use standard pathed URLs. Do you have any idea if this is still being worked on or is the change to a 302 redirect a sign that this isn’t likely to be resolved? Cheers, Cal :slight_smile:

If you can describe what further change should occur, I can pass it on to the folks who made the latest update and see what options there are!

1 Like

Great, thanks for that! How’s this?

This issue relates to “generated static site” glitch projects that are being served statically when a request occurs for a URL which doesn’t map to a file on disk.

The current behavior is to issue a 302 response causing the client to redirect to “/”. This breaks links to Single-Page Apps which use standard browser history for navigation. e.g. attempting to load this page will instead result in being redirected to the home page (click on the “about” link on the home page to actually load the page).

Changing the behavior to instead do an “internal redirect” (silently redirecting to the root index.html on the server-side) would solve this.

It would be cool if this behavior could be configurable for advanced users so if desired such redirects could be turned off and a 404 issued instead, or which file to redirect to could be specified. (Although I understand that offering config for advanced users isn’t really Glitch’s focus.)


Just wanted to +1 this again. To go into a little more detail, a normal SPA or PWA would still render everything with index.html, but have all routes redirected to this. Per what Callumgare et al have been saying, because the apps now 302, something always renders, but without client-side access to the referrer details, the apps can’t know about where the request came from.

If instead, a request came in from /about, and was still redirected to /index.html but preserved the browser path, then the app can pick that up and instead render the about page. With a server-side app, this type of setup is very straight-forward to do. Client-side apps can do this on a number of different hosts as well. As things stand now, for a generated_static site you have to render it with hash-based paths (e.g. /#/about), whereas what we’re talking about is an app that would support something like HTML5 history mode. Vue Router’s discussion on sample server configs is a good example of this type of support.


@jenn Any update on this? Ta :slight_smile:

Hi! I don’t have an update on this as it’s going to take some more resources to look into the best way to do this that helps everyone (we have gotten requests to do this in varying ways both on the forum and in the support queue). I’ll be sure to post in here when we do have an update - thank you all for the feedback and patience!


No worries! Thanks very much for the response :heart:

1 Like