Migrating site with static shtml files - what should I do?

I was not aware that netlify will not serve .shtml files before I signed up.

I have hundreds of pages that end in .shtml which only displays static html content. I can rename these to html extension, but then I’m going to lose my SEO traffic on the shtml extensions I’ve built up over the years.

Can’t I do something so that netlify still serves these shtml pages as static html? Can someone advise what I should do, thanks.

You can try using a proxy redirect, but I’m no sure if it will work. You can try creating a _redirects file like :/*.html /:splat.shtml 200!. More on this here: Redirects and rewrites | Netlify Docs

yeah, I don’t know about redirects. I’m paranoid about messing with anything like that when it comes to SEO.

Unfortunately, looks like I’m going to have to use Vercel. I just tried their service and shtml extensions work fine. Wish Netlify would do the same as I really wanted to stay here.

Hiya!

Would something like this work for you?

$ cat public/_redirects 
/ /index.shtml 200

$ cat public/_headers 
/
  content-type: text/html; charset=UTF-8

/*.shtml
  content-type: text/html; charset=UTF-8

Example setup:

And a test site:
https://603b30fee4f02806462dd212--netlify-help-custom-file-extension.netlify.app

The only “bothersome” part of this setup is if you have lots of index.shtml files with links pointing to things like /foo or /foo/ (where /foo/index.shtml is implied) where you might end up with loads of rules in _headers. Let us know if this might get you on the right track at least!

@greggf Welcome to the Netlify community.

Short answer, no.

Long answer, if you’re willing to do a little work now to future-proof your website, yes.

If you post a file – say, index.shtml – to Netlify and attempt to visit it, Netlify will offer you the option of downloading that file but will not display it. Therefore you need to convert from SHTML to HTML.

The easiest way to do this is to visit your SHTML site with httrack or Sitesucker or somesuch, which will create an HTML version of your site and its internal links. This works well for simple SSIs that contain no calculations or other fancy stuff, which will be the case if you are using SSI for DRY. Anything fancy will have to be replicated (to the extent it is possible) with JavaScript.

(It wouldn’t be a bad idea at this point to have canonical tags in the heads of each of your HTML files.)

Once you have the HTML version of your entire site, then you need to generate a list of every SHTML filename (including the path) and its corresponding HTML filename (including the path), and construct a _redirects file to tell bots and other visitors how to get to the new HTML version from URLs that point to the old SHTML version.

(It wouldn’t be a bad idea at this point to create either a sitemap.xml file, a sitemap.txt file, or both and register them with Google, Bing, etc., so everyone knows about the new filenames.)

With each file using its new HTML extension and your _redirects file pointing visitors to the HTML content that corresponds with the old SHTML files, you should be golden.

For more information about redirects, see the documentation.