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