Perhaps it's an SEO metaguide: "How to duplicate software documentation and increase your pagerank with links from social news sites by changing the format to a numbered list."
You shouldn't use .htaccess files at all. You should put all configuration in the appropriate config file/virtualhost, so all the configuration for a tree of directories can be found in one place. Hunting for .htaccess files littered around a tree, overriding one another, is an anathema.
Really? We need advice on "Preventing Image Hot Linking with htaccess", and help with "Disabling Directory Browsing" — is everyone sure we don't need a tutorial on how to download and host Flash games and cool JS custom mouse cursor tricks while we're at it, too?
The hotlinking code appears to be a copy paste from a defunct blog, the post in 2004, called Jotsheet. The specific "humiliatingimage.gif" and the ordering of the image extensions is pretty good as a marker.
As much as seeing the letters SEO on Hacker News brightens my day, much of this is bad advice.
The provided code for preventing image hotlinking is going to break your own website when user agents are configured to suppress the referer header, which is a common setting (and sometimes enforced at the firewall) in some corporations.
I think there are broader strategic issues with this advice, too. Bandwidth is cheap. I'd much rather encourage people to hotlink and use Javascript to give them suggested HTML to do the linking -- for example, HTML which gave them the image they wanted and a link with appropriate anchor text to credit my site. See: http://www.polepositionmarketing.com/seo-sem/link-building-s...
I do something spiritually similar with PDF files on my site -- or at least I did, can't quite remember if I disabled it at some point. Users attempting to access my free PDFs from my site get PDF files, users attempting to access them from other places on the Internet without being cookied as having visited me get discretely redirected to the HTML page containing the PDF so that they get a full dose of branding and an opportunity to convert to my free trial prior to getting the PDF. (For example, if a teacher hotlinks my activities from her class home page. I want to encourage that, after all.)
Rewriting example.com/category/post-title to example.com/post-title makes sense only if you've already been using categories for a while and have a strong reason to abandon them. If you're just starting, configure your CMS properly (this takes about five seconds in the vanilla install of Wordpress) and you'll save wasted HTTP requests and minor juice leakage for the rest of your site's life. If you're already using category names, changing for the heck of it doesn't offer much in the way of concrete benefits.
The provided code for making the .htaccess file inaccessible will make the .htaccess file inaccessible. As well as, well, everything else in that directory and its subdirectories.
Cutting the categories is also a bad idea in general. Google results have been gradually (when possible) replacing displayed URLs with your sites category structure...Building your site's structure the way google wants is probably a good idea.
The description for #1 is technically wrong, since Apache will send 304 Not Modified headers whenever it serves a static file with the appropriate request headers. What the Expires header actually does is prevents the browser from sending the request at all (unless the page is manually refreshed).
#4, the Auth* lines aren't necessary, only the order, deny, and allow lines.
#6, why are we using browser matching and not the Accept-Encoding header?
15 comments
[ 4.5 ms ] story [ 39.2 ms ] threadhttp://httpd.apache.org/docs/2.2/howto/htaccess.html
I don't quite get why these things are SEO specific, they seem to be pretty general to me.
If you can avoid using them, also remember to tell Apache to stop looking for them using "AllowOverride None"
It's halfway because any service even remotely viable would at a minimum be hosted on a slicehost or something like that.
This particular one appears in a few other places, http://www.google.co.uk/search?q=humiliatingimage.gif+[L,NC]... but in particular it turns up a couple of months ago in http://blog.seoland.co.uk/10-htaccess-hacks-every-seo-should... which appears to be where makeitrank copied it from?
Removing the allow for the null-referrer ^$ fixes it for this, but breaks access for user agents that don't send Referer.
The provided code for preventing image hotlinking is going to break your own website when user agents are configured to suppress the referer header, which is a common setting (and sometimes enforced at the firewall) in some corporations.
I think there are broader strategic issues with this advice, too. Bandwidth is cheap. I'd much rather encourage people to hotlink and use Javascript to give them suggested HTML to do the linking -- for example, HTML which gave them the image they wanted and a link with appropriate anchor text to credit my site. See: http://www.polepositionmarketing.com/seo-sem/link-building-s...
I do something spiritually similar with PDF files on my site -- or at least I did, can't quite remember if I disabled it at some point. Users attempting to access my free PDFs from my site get PDF files, users attempting to access them from other places on the Internet without being cookied as having visited me get discretely redirected to the HTML page containing the PDF so that they get a full dose of branding and an opportunity to convert to my free trial prior to getting the PDF. (For example, if a teacher hotlinks my activities from her class home page. I want to encourage that, after all.)
Rewriting example.com/category/post-title to example.com/post-title makes sense only if you've already been using categories for a while and have a strong reason to abandon them. If you're just starting, configure your CMS properly (this takes about five seconds in the vanilla install of Wordpress) and you'll save wasted HTTP requests and minor juice leakage for the rest of your site's life. If you're already using category names, changing for the heck of it doesn't offer much in the way of concrete benefits.
The provided code for making the .htaccess file inaccessible will make the .htaccess file inaccessible. As well as, well, everything else in that directory and its subdirectories.
See http://googleblog.blogspot.com/2009/11/new-site-hierarchies-...
is wrong.
It does exactly the opposite of what you want.
#4, the Auth* lines aren't necessary, only the order, deny, and allow lines.
#6, why are we using browser matching and not the Accept-Encoding header?