Trouble with redirects


I have a single page app built with polymer and lit element, and I want to create static versions of each page so that bots will be able to pick up meta data from the HTML when they’re navigated to directly. As an example:

And of course I would like pretty URLs, without the .html extension.

This works locally–when the static version of the file is available and I navigate to localhost/detail/zombie-the-original/, /detail/zombie-the-original/index.html acts as the entry point to the application, and when I view source, I see the correct metadata (in this example, the tag reads “Rum for Your Lives! | Zombie (the Original)”. If the file does not exist, index.html is served and acts as the entry point (and I see its title, which is just “Rum for Your Lives!”). In either case, client-side routing takes over and the appropriate view is displayed.

In production, when I navigate to, I see the title for the regular index.html file. Only when I hit directly do I see the correct metadata.

I thought that, according to the docs the default behavior in production would be the same. But when that failed to work, I attempted to create rewrite rules to facilitate it. I tried variations on the following in my _redirects file (each commented block below was a separate attempt):

# original _redirects file
/*    /index.html   200

# Attempting to use :splat with .html appended (not sure text following :splat is supported, but deploy details indicated the rule was processed without error):
/detail/*    /detail/:splat/index.html    200
/*    /index.html   200

# Attempting to use an individual rewrite rule specifically for this page:
/detail/zombie-the-original/    /detail/zombie-the-original/index.html    200
/*    /index.html   200

I tried swapping the order of the two rules, getting rid of the index.html rewrite, and getting rid of all rewrites. None of this seemed to make any difference. I also tried with Pretty URLs off/on, and it didn’t seem to matter either (though I’d prefer to do without since I noticed a slight performance improvement in disabling asset optimization entirely).

I downloaded a zip of my deploy and confirmed that the _redirects file is at the root, and that the rest of the files are as expected.

Is there something simple I’m missing?

I think my netlify instance name is but I’m not certain.

Thanks for any insight you can provide. This is one of the only things left for me to figure out before I consider the site launched and turn on the netlify analytics.

Joe Morgan

Hey Joe,

I’m also not sure that the text following :splat is going to work the way you want - we generally recommed that being at the end of the string.

Could you link to a deploy (e.g. its logs in our UI) that had the redirects you mention testing in place? We’d want to look at them in situ, and you don’t currently have any of them configured. Could you also give a bit more detail around how you were looking? E.g. via a social service like facebook or a slack unfurl, vs in the browser, and either way what exactly you mean by “metadata”, so we can try to get you the best advice?

Thanks in advance for your help!


I’m not entirely certain which link to use, but here is an example deploy:

This particular attempt looked like this:

/detail/zombie-the-original/*    /detail/zombie-the-original/index.html    200!
/*    /index.html   200  

My primary interest is in updating and other such tags, but I’m testing by simply viewing the source and looking for differences in the element.

  • Joe

I do see that those redirect rules look to both be working. However, I’m not sure what you mean by ‘updating and other such tags’. Could you explain? Also you did not clarify what you mean by ‘metadata’. If you could do both, that would help.

Sorry, I entered <meta name="twitter:image"> without the pre-formatted markup, and it didn’t come through. I’m trying to use static HTML so that bots will recognize twitter card data, page titles, descriptions, and keywords for all of my pages, even though it’s a single page application.

Hi. In testing this again today, I realized that the HTML is being cached by the service worker. Netlify rewrites are working as expected. My apologies for the confusion.

Thank you for sharing the root cause and solution for this issue. This topic will hopefully be useful for someone in a similar situation in the future and searching for a solution.

It is extra effort to loop back here with an update and we want you know we appreciate it. :+1: