5

If we want to go with static website, we generate static html files of pages with names like contacts.html and we may add to our .htaccess file the lines like

RewriteEngine On
RewriteRule ^(([^/]+/)*[^.]+)$ /$1.html [L]

So if we follow by the link /contacts, we get the content of the public_html/contacts.html file in the browser.

But what if to save static files without the .html extension i.e. just with the name contacts? In other words, with the text/x-generic type. We don't need the .htaccess rule in such case, but is there some downside(s) of the approach from SEO or/and another side?

ps. I mean if I use shared hosting and don't have access to nginx

It's not a duplicate of the question Should I use a file extension or not? as I don't ask to use .html extension in the browser address bar or not.

  • Search engines do not care what file extension you use and do not care where the content comes from. – Rob Oct 18 '18 at 9:50
  • When you say you don't have access to nginx, is it actually a nginx web server run by your hosting company, as opposed to Apache? With Apache you could use .htaccess to set your default mime type, but nginx doesn't have any sort of directory specific configuration like Apache does as far as I know. – Stephen Ostermiller Oct 18 '18 at 15:20
  • @StephenOstermiller I meant that with nginx as I heard we also can do some configurations to serve static pages like described by the link stackoverflow.com/q/12638299/3208225 But in my shared hosting I don't have root permissions so I can't configure nginx as it's possible on VPS / VDS – stckvrw Oct 18 '18 at 17:56
  • No, but if your shared hosting is using Apache (likely), you have lots of options through .htaccess. Actually you say you already have a .htaccess file, so it must be Apache. – Stephen Ostermiller Oct 18 '18 at 18:12
  • @StephenOstermiller of course it's Apache and for me it's enough to use htaccess. I just mentioned nginx as some guys say it's better to use nginx to serve static pages instead of rules in htaccess – stckvrw Oct 18 '18 at 20:06
6

This isn't so much an SEO issue, as an issue as to whether your site would work at all. If it doesn't work in the browser then it's certainly going to hurt your SEO.

Your HTML pages still need to return the text/html mime-type in order to be interpreted as HTML by the browser. ie. You need to send a Content-Type: text/html HTTP response header somehow.

Ordinarily, Apache uses the file extension to determine the mime-type (using the AddType directive), from which it generates the Content-Type HTTP response header. If there is no file extension then it's going to return whatever default your server is set to return for unknown file types. (Bear in mind that this "default" could be nothing at all, ie. no Content-Type.)

In other words, with the text/x-generic type.

If the server sends a text/x-generic Content-Type then the browser is likely going to see the response as plain text and display it just as plain text. ie. the users see the raw HTML source.

Also, whilst your server might be configured to send a text/x-generic response as a default - that is by no means standard. Many servers will default to application/octet-stream, which will likely trigger the browser to download the file. ie. The user might see a "Save As..." dialog.

The intended default on Apache 2.4 is no Content-Type at all. So, it is left for the browser to interpret the response and decide for itself. However, this could naturally result in different responses from different browsers as I don't believe there is any "standard" here.

We don't need the .htaccess rule in such case

But you need something to "fix" the Content-Type header.

Workaround (well, kind of ...)

In comments, the possibility of setting the default mime-type in .htaccess is mentioned. However, this is only available on Apache 2.2 via the DefaultType directive. For example, the following will return a Content-Type: text/html header for resources where the mime-type cannot be otherwise deduced.

DefaultType text/html

However, DefaultType does not work on Apache 2.4. It is only available for backwards compatibility (ie. it doesn't break the server - but it doesn't actually do anything).

On Apache 2.4 it is recommended to use AddType - in other words, the recommendation is to base the mime-type on the underlying file extension, eg. .html. So, by removing the file extension you are kind of going against Apache's recommendation.

Alternatively, you can use ForceType - but this forces the mime-type on all resources (depending on where you put the directive) - so this must be set conditionally. But what do you base this condition on? You could perhaps check that the filename does not contain a dot (or only contains a limited set of permitted characters), ie. it does not look like it has a file extension:

<FilesMatch "^[^.]+$">
ForceType text/html
</FilesMatch>

However, there could potentially be other issues:

  • How is your server setting cache headers? This could be based on the file extension, although it is preferable to set this based on the mime-type.

  • If you want to open these files in an editor... how does your editor treat extensionless files?

Summary:

You could do this, but I wouldn't. Rewrite the URL instead.

Reference:

  • DefaultType on Apache 2.2 and Apache 2.4
  • ForceType on Apache 2.4
  • Mailing list archive that discusses DefaultType (reasons for dropping in Apache 2.4) and ForceType and other possible (non-working) methods of setting the Content-Type header using the Header directive (although this is non-trivial due to the nature of the Content-Type header). (Aside: Note that it has only been possible to set the Content-Type header at all - with the Header directive - since Apache 2.2.12):
    https://lists.gt.net/apache/users/443558
  • Answer on SO that shows an apparent method for setting the Content-Type header using the Header directive and expressions to conditionally set the Content-Type header only when it is not already set (references the above):
    https://stackoverflow.com/a/37529835/369434

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.