Path to .js and .json incorrect when using country redirects

Apologies - I can’t share my repo as it’s a project that can’t be made public until later this month. Our client would kill me!

The TLDR is that we’re having a problem (404) with the location of the sites package .js and .json files when we are viewing country based sites and the catch all redirect is on.

The catch all redirects look like:
/*. /es/:splat. 302! Country=ES

I’ve looked through the docs and I can’t find any information on it, but I’d like to know if we can redirect based on file extension?

So, something like this would ensure the .json, no matter where it is called in the directory structure is always called from the root.

/*.json. /:splat.json 200

I’ve tried all sorts of combos but I don’t know if this is legit redirects code (it doesn’t throw an error in the playground but it doesn’t work in practice). Should I be using :TAGS ?!?

Some more info:

  • Our site is built using Gatsby. All the latest and up-to-date versions.
  • We’re using a netlify _redirects to direct visitors to a ES, FR, IT, DE and ZH versions of the site. The paths for those are like “” and “” etc etc.
  • If the catch all redirects are NOT IN place then the site plays like it should do (no broken paths) :white_check_mark:
  • If the catch all redirects are IN place then the site breaks when on one of those sub domains :no_entry_sign:
  • I have tried using the tag in the html to no avail! :cry:
  • The site also breaks even if the nf_country is not set (we don’t drop it by default, we only use it when toggling between countries)

There is another article that is very similar to this on the forum (Gatsby assets getting fetched from wrong path on localized pages), but while it helps confirm the problem (it’s the same problem) their solution was basically to add lots of redirect rules for each page (which is going to be impossible for us as we have many many pages, like “”.

Any help would be much appreciated!!


Hey @richythings,

Could you share the URL of the site or the page so we can see the issue? If this is what I’m guessing it is (based on your description), you could solve it using a <base> tag in HTML. But again, it’s just a guess, which can only be confirmed by seeing what exactly is happening.