How to use IIRF URL rewrite with WordPress on IIS to make it SEO friendly.

There are generally two things you need to do to make your WordPress site running on Microsoft IIS servers SEO (Search Engine Optimization) friendly.  They both deal with URL rewriting.  URL rewriting is a way to make the web address look more like English then a bunch of alpha-numeric characters.  By doing this, search engines like Google can read your site easier and you'll have a better chance of getting a higher rank on their search site.  Below are the two main examples of URL rewriting.  The first is modifying your IIRF.ini  and the second is using WordPress permalink editing.

Keep in mind that this is a solution for your WordPress site running on Microsoft IIS servers.  When running on Apache web servers WordPress will be utilizing the built in .htaccess file to mange permalinks.

IIRF rewriter


When setting up WordPress and running through the install process, it's better to make the following changes to your iirf.ini file before creating a bunch of pages.  You can use the sames example below even if you host multiple websites.  You will need to edit your iirf.ini file and put the below code in:  THESE ARE EXAMPLES ONLY, you will need to put your site information in there.

# SpecialConditions.ini
#
# shows how to use the special RewriteCond conditions: -f, -d
#
# If you are using IIRF V2.0, remember to rename this file to IIRF.ini ,
# or copy this content to a file named IIRF.ini before using it.
#
# If you are using IIRF v1.2, the filename is IsapiRewrite4.ini. 
#
#
# Mon, 24 Aug 2009  04:23
#
 

RewriteLog  c:\temp\iirfLog.out
RewriteLogLevel 3
StatusUrl iirfStatus

# A simple rule. 
# Tests APPL_PHYSICAL_PATH - the physical path of the IIS application
# for the given URL request.  If the physical path does not exist, then 
# This rule rewrites the request to a 404 page.
RewriteCond %{APPL_PHYSICAL_PATH}   !-d                                    
RewriteRule ^.*$                    /winisp/404.aspx                      [U,I,L]

# Another simple rule. 
# Tests REQUEST_FILENAME for existence.  If it does not exist, then 
# Rewrites to a 404 page.  Because this one follows the above, it will
# be effective only when an IIS vdir exists. 
RewriteCond %{REQUEST_FILENAME}     !-f
RewriteRule ^.*$                    /winisp/404file.aspx                      [U,I,L]

 

# PhpBlog.ini
#
#
# This example shows how one user employed IIRF twith a
# PHP-powered blog engine.

# Remember to rename this file to IsapiRewrite4.ini ,
# or copy this content to a file named IsapiRewrite4.ini
# before using it!
#
# Note: The example here was contributed by someone who uses IIRF.
# I haven't tested this ini file, and I don't make any guarantees that 
# it works as advertised  or expected or desired.  It's an example. 
# Good luck! -Cheeso
#
# Fri, 11 May 2007  12:46
#

RewriteLog  c:\temp\iirfLog.out
RewriteLogLevel 3

# MaxMatchCount
#
# Specifies the maximum number of sub-expression matches to
# capture for a single pattern. This specifies the size of the
# array in the C module.  If you have a pattern with more than
# the default number of matches, set this number.
#
# The default is 10.

MaxMatchCount 10


# /content/blogcategory/0/33/

# should translate to

# /index.php?option=com_content&task=blogcategory&id=0&Itemid=33

RewriteRule ^/([^/]+)/([^/]+)/([^/]+)/([^/]+)/$  /index.php?option=com_$1&task=$2&id=$3&item=$4


# DetectFilesAndDirectories.ini

# Shows how to use the "special patterns" for RewriteCond - 
# for detection of files and directories.
#
# remember to rename this file to IsapiRewrite4.ini ,
# or copy this content to a file named IsapiRewrite4.ini
# before using it!
#
# Thu, 13 Jul 2006  15:11
#

RewriteLog  c:\temp\iirfLog.out
RewriteLogLevel 5

# ============================================
# This rule shows chaining of RewriteCond's.  
#
# The first RewriteCond checks the HTTP_URL.  if it ends in
# .foo, .htm, .php or .html, then it evaluates to TRUE.
#
# As per the description in the IIRF doc, successive RewriteCond
# statements are chained with a logical AND.
#
# Therefore, if the first RewriteCond evaluates to TRUE, then
# the 2nd will also be evaluated. The second statement tests
# whether the REWUEST_FILENAME is a file - actually in english
# the logical statement is "is the REQUEST_FILENAME NOT a file?" 
#
# And the 3rd RewriteCond asks "Is the REQUEST_FILENAME NOT a
# directory?" 
#
# In summary, then, the chain of RewriteCond directives
# evaluates to TRUE when, the URL includes the given suffix, and
# the REQUEST_FILENAME is neither a file nor a directory (file
# or directory does not exist). In that case, the RewriteRule is
# applied. 
#
# ============================================

RewriteCond %{HTTP_URL}             (/|\.foo|\.htm|\.php|\.html|/[^.]*)$   [I]
RewriteCond %{REQUEST_FILENAME}     !-f                                    
RewriteCond %{REQUEST_FILENAME}     !-d                                    
RewriteRule ^.*$                    /index.php                             [U,I,L]

 

# ============================================
# This one detects if the physical path of the app exists. 
# If not it redirects to default.aspx.
#
RewriteCond %{APPL_PHYSICAL_PATH}   !-d                                    
RewriteRule ^.*$                    /default.aspx                          [U,I,L]

# This 
RewriteCond %{HTTP_USER_AGENT}   !-d                                    
RewriteRule ^.*$                    /winisp/info.aspx                      [U,I,L]


# CheckHttpHost.ini

# rewrite based on the HTTP_HOST used in the request.
#
# remember to rename this file to IsapiRewrite4.ini ,
# or copy this content to a file named IsapiRewrite4.ini
# before using it!
#
# Mon, 25 Sep 2006  15:42
#

RewriteLog  c:\temp\iirfLog.out
RewriteLogLevel 5

#=====================================================
# Demonstrates RewriteCond with HTTP_HOST.
#
#=====================================================
RewriteCond %{HTTP_HOST}            ^(?!www\.myhost\.org).*$             [I]
RewriteRule ^.*$                    /redirected.htm                    [U,L]


# ChainedRewriteCond.ini
#
# shows how to chain RewriteCond statements
#
# If you are using IIRF V2.0, remember to rename this file to IIRF.ini ,
# or copy this content to a file named IIRF.ini before using it.
#
# If you are using IIRF v1.2, the filename is IsapiRewrite4.ini. 
#
#
# Mon, 24 Aug 2009  04:23
#
 

RewriteLog  c:\temp\iirfLog.out
RewriteLogLevel 3
StatusUrl iirfStatus

# The following three conditions are chained together with boolean AND. 
# Together, they mean, if the URL ends in .foo, .htm, .php, or .htm, AND
# if there is no file by that name AND
# there is no directory by that name THEN
# the RewriteRule will be evaluated. 
# The RewriteRule is in effect only if the pattern on the rule matches
# the incoming URL. In this case though, the pattern is ".*" which 
# always matches.  So the RewriteRule will be applied. 
RewriteCond %{HTTP_URL}             (/|\.foo|\.htm|\.php|\.html|/[^.]*)$   [I]
RewriteCond %{REQUEST_FILENAME}     !-f                                    
RewriteCond %{REQUEST_FILENAME}     !-d                                    
RewriteRule ^.*$                    /winisp/info.aspx                      [U,I,L]

 

# Blacklist-on-UserAgent.ini
#
# shows how to blacklist based on user-agent, using a RewriteCond statement.
#
# If you are using IIRF V2.0, remember to rename this file to IIRF.ini ,
# or copy this content to a file named IIRF.ini before using it.
#
# If you are using IIRF v1.2, the filename is IsapiRewrite4.ini. 
#
#
# Mon, 24 Aug 2009  04:23
#
 

RewriteLog  c:\temp\iirfLog.out
RewriteLogLevel 3
StatusUrl iirfStatus

# You can blacklist requests based on user agent via RewriteCond.  In this
# case all requests coming from a user agent that contains the word
# "java" will get a 410 (gone) response.  In this case the replacement
# string in the RewriteRule is meaningless.  We use - here, but it could
# be anything.  The important bit is the [G] modifer, which is "Gone".
RewriteCond %{HTTP_USER_AGENT}      java              [I]
RewriteRule ^.*$                    -                 [G]

# You can also do rewrites based on the user agent:
RewriteCond %{HTTP_USER_AGENT}      ^Mozilla.*$
RewriteRule ^.*$                    /winisp/Mozilla.aspx                      [U,I,L]

 

RewriteCond %{HTTP_HOST} ^(yourdomainname.com).*$ [I]

RedirectRule ^/(.*)$ http://www.yourdomainname.com/$1 [I,R=301]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^/(.*)$ /index.php/$1 [L]


Permalinks Settings

Begin Process

By default WordPress URL Structure looks a bit more robotic because it is not user friendly at all let alone not being SEO friendly.

http://wpbeginner.com/?p=25

Above is an example of what a default WordPress URL structure looks like. The goal of making the URL structure more friendly is that your users should know before reading the article what it is about by just looking at the URL. The same goal is to be accomplished for Search Engines as well.

Step 1: Open the Permalink Option Page

First you need to open the Permalink Option Page which you can find in your WordPress Admin Panel if you click on the Setting Tabs and then go to Permalink. There you should see something which looks familiar to the image above.

You would need to click on the fifth option which says Custom Structure.

Step 2: Pick Your Structure from Documentation

There are many ways a URL can be organized. WordPress gives a few options which you can see at two, three, and four. But those are not the best option in our opinion.

We recommend the URL Structure of

/%category%/%postname%/

or if someone wants a completely static looking site, then they can use the version below.

/%category%/%postname%.html

By using that documentation your URL structure will be keyword rich as it will contain the keyword of the category and the title. Like the one below:

http://www.wpbeginner.com/wp-tutorials/how-to-install-WordPress-on-your-site/

Now while we recommend the options above there are multiple other ways you can organize your URLs. We have seen many different options in use. To know the possible URL Structure combination, you will need to learn a few documentation tags.

%year% – The year of the post, four digits, for example 2004

%monthnum% – Month of the year, for example 05

%day% – Day of the month, for example 28

%hour% – Hour of the day, for example 15

%minute% – Minute of the hour, for example 43

%second% – Second of the minute, for example 33

%postname% – A sanitized version of the title of the post (post slug field on Edit Post/Page panel). So This Is A Great Post! becomes this-is-a-great-post in the URL.

%post_id% – The unique ID # of the post, for example 423

%category% – A sanitized version of the category name (category slug field on New/Edit Category panel). Nested sub-categories appear as nested directories in the URI.

%author% – A sanitized version of the author name.

More information about the tags can be found in WordPress Codex for Permalinks.


Once you have selected the combination, paste it in the field and click “Save Changes”

Your .htaccess file will automatically be updated, and your URL will be changed. We suggest that you do this towards the start of your website, so you don’t have to go through the process of re-indexing in a search engine.

Good luck with ranking high in search engines.


Was this article helpful?

mood_bad Dislike 0
mood Like 0
visibility Views: 8754