.htaccess Error In Wordpress ? Here .htaccess Greats SEO For Wordpress

The .htaccess code in this post is designed to work when placed in the web-accessible root .htaccess file of your domain. Before making any changes to this file, make a good backup and keep it on hand just in case. Working with .htaccess is nothing to be afraid of, but it’s critical to not make any mistakes in syntax, spelling, or anything that’s not a comment (#). If you forget a dot working with CSS, your design might look messed up. If you forget a dot working with .htaccess your server will return a 500 – Internal Server Error. If this happens, don’t panic, just upload your backup and everything will be fine.

1. Canonical robots.txt .htaccess

Help bots and visitors find your robots.txt file no matter what. Given that the robots.txt file should always be located in the root directory, you would think that this wouldn’t be an issue. Unfortunately, bad bots and malicious scripts like to scan for robots.txt files everywhere. Fortunately, this .htaccess snippet eliminates the nonsense by directing any request for “robots.txt” to the actual file in your root directory. If you’re sick of seeing endless requests for nonexistent robots files, this code’s for you:

# CANONICAL ROBOTS.TXT
<IfModule mod_rewrite.c>
 RewriteBase /
 RewriteCond %{REQUEST_URI} !^/robots.txt$ [NC]
 RewriteCond %{REQUEST_URI} robots\.txt [NC]
 RewriteRule .* http://example.com/robots.txt [R=301,L]
</IfModule>

To use this code, replace example.com with your own domain and include in your web-accessible root directory. These directives collectively redirect all requests for any “robots.txt” file, with the exception of the actual, root robots.txt file. If you need to whitelist a similarly named file, just include the following line beneath the first RewriteCond, replacing the path and file name with your own:
RewriteCond %{REQUEST_URI} !/wordpress/robots.txt$ [NC]
Alternate Method: Instead of using Apache’s rewrite module, we can do the same thing with less code using mod_alias:

RedirectMatch 301 ^/(.*)/robots\.txt http://example.com/robots.txt

Either method is effective, but mod_alias is optimal for typical sites with only one robots.txt file. If you have multiple robots.txt files, the mod_rewrite method will enable complete granular control from the root .htaccess file.

 2. Canonical Favicons .htaccess

 Avatars, gravatars, and favicons are a big hit with malicious scanners. Evil scripts like to traverse your directory structure with requests for commonly used images such as the ubiquitous favicon.ico. So just as with robots.txt, we can stop the madness and redirect any request for “favicon.ico” to the actual file in your root directory.

# CANONICAL FAVICONS
<IfModule mod_rewrite.c>
 RewriteEngine On
 RewriteBase /
 RewriteCond %{REQUEST_URI} !^/favicon.ico$ [NC]
 RewriteCond %{REQUEST_URI} /favicon(s)?\.?(gif|ico|jpe?g?|png)?$ [NC]
 RewriteRule (.*) http://example.com/favicon.ico [R=301,L]
</IfModule>

To use this code, replace example.com with your own domain and include in your web-accessible root directory. These directives collectively redirect all requests for any “favicon” or “favicons” with a .png, .gif, .ico, or .jpg extension. To prevent an infinite request loop, the code includes an exception for the actual, root “favicon.ico” file. If you need to whitelist a similarly named file, just include the following line beneath the first RewriteCond, replacing the path and file name with your own:
RewriteCond %{REQUEST_URI} !/images/favicons.png$ [NC]

3. Canonical Sitemaps .htaccess

Just as idiotic bots can’t seem to find your robots and favicon files, so too are they clueless when it comes to finding your sitemap, even when declared in the robots.txt file. Nefarious bots will ignore your robots suggestions and hammer your site with ill-requests for nonexistent sitemaps. This malicious behavior chews up system resources and wastes bandwidth. To eliminate the waste while helping stupid bots find your sitemap, slip this into your root .htaccess:

# CANONICAL SITEMAPS
<IfModule mod_alias.c>
 RedirectMatch 301 /sitemap\.xml$ http://example.com/sitemap.xml
 RedirectMatch 301 /sitemap\.xml\.gz$ http://example.com/sitemap.xml.gz
</IfModule>

To use this code, edit each rule with your own domains and file paths. The first rule redirects all requests for your regular, uncompressed sitemap, and the second rule redirects all requests for your compressed (gzipped) sitemap. These rules are independent of each other, so feel free to remove either to suit your needs.

4. Canonical Category, Tag, and Search URLs .htaccess

Out of the box, WordPress returns a 404 – Not Found for the following URLs:

• http://your-domain.tld/blog/tag/
• http://your-domain.tld/blog/search/
• http://your-domain.tld/blog/category/

These are commonly requested URLs that may be leaking valuable page rank. As explained previously, you can use the following slice of .htaccess to redirect these URLs to your home page (or anywhere else):

# CANONICAL URLs
<IfModule mod_alias.c>
 RedirectMatch 301 ^/tag/$      http://example.com/
 RedirectMatch 301 ^/search/$   http://example.com/
 RedirectMatch 301 ^/category/$ http://example.com/
</IfModule>

To use, place the previous code into your root .htaccess file and replace each example.com with the desired redirect location. Alternately, if WordPress is installed in a subdirectory, use this code instead:

# CANONICAL URLs
<IfModule mod_alias.c>
 RedirectMatch 301 ^/blog/tag/$      http://example.com/
 RedirectMatch 301 ^/blog/search/$   http://example.com/
 RedirectMatch 301 ^/blog/category/$ http://example.com/
</IfModule>

Again, edit the examples with your actual URLs. A good place to redirect any juice or traffic from these three URLs is the home page. Hopefully future versions of WordPress will handle these redirects internally, but until then, this bit of .htaccess is a simple and effective solution.

5. Canonical Feeds .htaccess

WordPress generates many different feeds for your site. The default feed configuration works great, but it’s worth including in this post a couple of useful .htaccess tricks:

• Set up canonical feed types (e.g., deliver only RSS2 feeds and redirect other formats)
• Setup FeedBurner feeds and redirect associated feed requests

Each of these techniques are easily achieved with a little .htaccess. Better grab a beverage..

Set up canonical feeds

WordPress provides feeds in four different formats: Atom, RDF, RSS, and RSS2. This variety was useful in the past to accommodate different apps and devices, but these days I think it’s safe to say that most readers and devices can handle any format you throw at it. So instead of having 4x the feeds, you can consolidate your feeds into a single format:

# CANONICAL FEEDS
<IfModule mod_alias.c>
 RedirectMatch 301 /feed/(atom|rdf|rss|rss2)/?$ http://example.com/feed/
 RedirectMatch 301 /comments/feed/(atom|rdf|rss|rss2)/?$ http://example.com/comments/feed/
</IfModule>

This code will redirect requests for alternate feed formats to your canonical choice for both main-content feed and all-comments feed. To use this code, replace both of the target URLs with your own and place in the web-accessible root directory.

Redirect feeds to FeedBurner

Redirecting feeds to FeedBurner is another useful .htaccess snippet to have in your tool belt. Here are two snippets to do the job – one for main-content and another for all-comments feeds:

# REDIRECT to FEEDBURNER
<IfModule mod_rewrite.c>
 RewriteCond %{REQUEST_URI} ^/feed/ [NC]
 RewriteCond %{HTTP_USER_AGENT} !(FeedBurner|FeedValidator) [NC]
 RewriteRule .* http://feeds.feedburner.com/mainContentFeed [L,R=302]

 RewriteCond %{REQUEST_URI} ^/comments/feed/ [NC]
 RewriteCond %{HTTP_USER_AGENT} !(FeedBurner|FeedValidator) [NC]
 RewriteRule .* http://feeds.feedburner.com/allCommentsFeed [L,R=302]
</IfModule>

The first block redirects all requests for your main-content feed, and the second block handles your all-comments feed. So to use, just replace the mainContentFeed and allCommentsFeed with the URLs of your associated FeedBurner feeds. You may also redirect special category feeds by replicating the pattern with another block of code:

 RewriteCond %{REQUEST_URI} ^/category/wordpress/feed/ [NC]
 RewriteCond %{HTTP_USER_AGENT} !(FeedBurner|FeedValidator) [NC]
 RewriteRule .* http://feeds.feedburner.com/specialCategoryFeed [L,R=302]

As before, just replace the URL of your FeedBurner feed in the RewriteRule and test accordingly.

6. Simpler Login URL .htaccess

Lastly, a cool .htaccess trick for a better user-login experience. A single line of code placed in your root .htaccess file is all it takes:

RewriteRule ^login$ http://example.com/wp-login.php [NC,L]

Edit the example.com with the domain/path of your WordPress installation. Now instead of typing “wp-login.php”, we just type “login” and whoop, there it is.
You could also use RedirectMatch to enable a login URL switch:

RedirectMatch 301 \@admin http://example.com/wp-admin

The @ prevents the rule from bothering anything else, and RedirectMatch picks up on the switch from anywhere in the site, so regardless of what page you’re on, you just append “@admin” to the URL and you’re there. I use this trick at perishable.biz if you want to see it work. Check the comments of Chris’ original post for good discussion and some more great ideas.

Ok please Comment.. Thanks to SEO