|Administrator Help - RC v3.3|
Chapter - 8.5 URLs Rewrite
Please read the following chapters to the end before changing rewrite configurations available at Rapid Classified.
The purpose of URL rewriting is to make URL links at your site both – Search Engine and User friendly. In addition, having relevant to the page content keywords in URL helps to achieve a better ranking while SE performs indexing. Generally, dynamically driven web sites (such as Rapid Classified) present content on pages, which pulled from database. In Rapid Classified for instance, the same physical page viewad.asp (a full ad view page) presents content for thousands of ads posted by clients. Each ad view page distinguished in this case by an ad ID (ad identification in database). Therefore, the URLs for different ads might appear as:
While Meta Keywords and Description tags for this page built from the ad subject making the page SE friendly, further SE optimization could be achieved by including an ad subject into the URL. For instance:
Although ad keywords are now present in URL, the link still appears dynamic. A full URL rewrite helps to convert this URL into static one, which is more SE and user friendly and would probably be considered for higher ranking by SE:
Rapid Classified have a few options to make most dynamic URLs at the site both – keyword rich and SE/User friendly.
Note: Rapid Classified is URL Rewrite Ready. For complete URL rewrite, ISAPI configuration module (where rewrite rules could be specified) must be present on web server. Following chapters consider two different rewrite modules:
For Web Server rewrite capability, consult web hosting support or documentation.
8.5.2 Pages affected by rewrite rules
URL links to the following dynamic pages would be affected when rewrite engine turned on:
Pages above are the only dynamic pages visible to Search Engines. While there are many other dynamic pages at Rapid Classified, they are either not important from SEO standpoint or simply invisible to Search Engines (pages, which are only visible to logged in to the account visitors or administrative page visible to admin only).
Note: Service URL links to pages above would still have generic IDs as page arguments. Service URL links considered to be links, related to site administration and management by admin or site visitors. For example, when you, as administrator use "Move" link at the full ad view page, then after the move, browser would return you to the viewad.asp page with only ID as page argument (even if URL rewrite turned ON). There is no need to rewrite URL in this case, because "Move" or any other Service operations at the site are not visible to Search Engines.
Carefully consider URL rewrite rules and links appearance. With the change of URL addresses, you may loose page ranks and wait a long time for the next update by Search Engines.
8.5.3 URL Rewrite Configurations (Allow Keywords in URL)
URL rewrite configuration settings stored in config/rewrite_config.asp configuration file. There is an online interface for changing this configuration file and it is available at the "Miscellaneous Configs" admin page.
There are five configurations available:
For now let us only consider the first two leaving remaining three for later.
By default both - Enable URL Rewrite and Allow Keywords in URL checked off. This means all URL links to dynamic pages at Rapid Classified generated only with IDs as page arguments:
At this point, you may only switch Allow Keywords in URL on without having ISAPI rewrite module on web server. After switching Allow Keywords in URL on, all dynamic pages at the site would have relevant keywords in URL as page arguments as following:
viewad.asp, view_print.asp – Ad subject in URL
viewscat.asp, viewlist.asp, viewsublist.asp – Category names in URL
8.5.4 Names/Keywords in URL
All names in URL normalized. There is a strict rule set by respective RFC in relation to which characters allowed in URI (URL). In RC, only English alphanumeric characters would be inserted into URL (words separated with a dash [-]). All special characters would be stripes off. For languages other than English (specifically non-Latin based languages), URLs would be encoded with the respective encoding set in config/codepage.asp.
Important: It is strongly recommended to configure classified with UTF-8 for all non-Latin languages. If the encoding at the non-Latin site set to something other than the UTF-8 (windows-1251 for instance), then you most likely need to switch Allow Keywords in URL off. Reason – All Search Engines index pages run under UTF-8. Any non UTF-8 encoded URL with names would not be readable by SE and would not influence site ranking.
For non-Latin languages with UTF-8 encoding the following would occur:
Names in URL would be UTF-8 encoded. Although they might not be readable by humans, they would be perfectly readable by SE and properly presented at SE index pages.
Example with Russian words in URL.
In some browsers clients might see the URL to viewad.asp page for instance as:
However, Google for instance would present this URL on an index page and would consider Russian keywords [продается-дом] (translated as [house for sale]) while someone makes a search for those keywords as following:
Whether to turn Allow Keywords in URL on, for the case of non-Latin language is entirely up to your. As per example above, you noted that even in UTF-8, URLs not humanly readable (although SE has no problem).
Recommendation: For non-Latin languages enforce UTF-8 for your site, switch Allow Keywords in URL [off], but switch Use keywords in URLs [on] at the Site Maps generator admin page. This way your visitors would not see encoded names in URL while navigating through the Rapid Classified site. However, the links submitted to SE inside of Sitemaps for indexing, would contain keywords, which properly interpreted by Search Engines. More information about sitemaps in chapter 8.4.
8.5.5 URL Rewrite Configurations (Enable URL Rewrite)
This is the most important section of this chapter. Going further would require ISAPI rewrite module on web server and option to create rewrite rules. This chapter provides rewrite rules for
Note: Any other ISAPI rewrite modules supported, but might require rewrite rules specific to the rewrite engine syntax.
To enable URL rewrite switch the Enable URL Rewrite [on] at the "Miscellaneous Configs" admin page.
Immediately after that and given that Allow Keywords in URL switched [on], most URL links to dynamic pages visible to SE, rewritten as in the following examples.
Full ad view page and print friendly format (viewad.asp, view_print.asp):
Categories List pages (viewscat.asp, viewlist.asp, viewsublist.asp):
The above URL links generated by the internal Rapid Classified engine and inserted to most of the <a> tags throughout classified.
As you may see, links point to fictional, non-existed .html pages at the classified. It is a job of the ISAPI rewrite module with properly configured rewrite rules to translate internally those URLs into valid links with proper page arguments for the right content display.
Rewrite rules for ISAPI rewrite module v3.0 from Helicon (Apache mod_rewrite compatible)
Full rewrite module configuration is out of the context of this manual. Only specific rules necessary for proper Rapid Classified operation with URL Rewrite [on] would be provided.
For the case, when Allow Keywords in URL is [on] following rules required:
RewriteRule ^(.*?view(?:ad|_print|scat))~([^/]*)\.(\d*)\.html$ $1.asp?id=$3 [NC]
RewriteRule ^(.*?viewlist)~([^/]+)\.(\d+)\.(\d)\.(\d+)\.html$ $1.asp?sid=$3&sa=$4&page=$5 [NC]
RewriteRule ^(.*?viewsublist)~([^/]+)\.(\d+)\.(\d+)\.html$ $1.asp?\3id=$3&page=$4 [NC]
For the case, when Allow Keywords in URL is [off] following rules required:
RewriteRule ^(.*?view(?:ad|_print|scat))~(\d*)\.html$ $1.asp?id=$2 [NC]
RewriteRule ^(.*?viewlist)~(\d+)\.(\d)\.(\d+)\.html$ $1.asp?sid=$2&sa=$3&page=$3 [NC]
RewriteRule ^(.*?viewsublist)~(\d+)\.(\d+)\.html$ $1.asp?\3id=$2&page=$3 [NC]
In general, all 6 rules could be specified in Helicon configuration file - httpd.conf
This way you may freely switch Allow Keywords in URL on/off without affecting navigation from rewritten URL links. This is convenient for the case considered in chapter 8.5.4, where you switch Allow Keywords in URL [off] but set the Use keywords in URLs [on] for Sitemaps generator.
How does it work? (Read on if you are interested)
Let us analyze URL rewriting based on a sample link generated for viewscat.asp page (list of subcategories for a given main category).
In reality, ISAPI module intercepts a URL by applying pattern-matching rule.
URL (points to friendly but non-existing .html page):
RewriteRule ^(.*?view(?:ad|_print|scat))~([^/]*)\.(\d*)\.html$ $1.asp?id=$3 [NC]
Based on a rule above, module commands web server to load an existed Rapid Classified page with parameters identifying respective category:
Without going deep into "Regular Expressions" pattern matching syntax, quickly review the rewrite rule above.
It tells to match the URL, based on this: ^(.*?view(?:ad|_print|scat))~([^/]*)\.(\d*)\.html$
But load this instead: $1.asp?id=$3
Outer brackets signify that the matched string inside should be stored by the rule. This particular rule identifies either [viewad], [view_print] or [viewscat] from the beginning (signified by ^) of the URL (after domain name) and stores in $1 property.
So far matched viewscat~
This pattern matches anything (but the /) or nothing before the dot. In our case it matches – [computers.] and stores computers in $2 property.
So far matched viewscat~computers.
Finally, this pattern matches any number of consecutive digits, followed by a dot and ending by html. Only digits stored. In out case 10000 stored in $3 property.
Matching complete and viewscat~computers.10000.html have been matched.
It is time now for the rewrite rule to see what to load:
So far rule stored:
$1 = viewscat
We ignored $2 in the rule but use $1 and $3. Substituting them with stored values, the rule commands web server to load:
[NC] flag at the end means Case Insensitive.
This is a valid Rapid Classified page, which displays the list of subcategories under the main category - Computers.
Rewrite rules for URL Rewrite module v2.0 for IIS 7.0
If URL rewrite Module v2.0 for IIS 7.0 installed on web server, then depending on web hosting provider you may need to insert rewrite rules into the web.config configuration file or use GUI from the hosting control panel to configure rewrite rules.
When Allow Keywords in URL is [on] or [off], six rules required.
Set of rules, which goes into web.config ASP.NET configuration file (normally stored at the root of the site). The set placed between <system.webServer></system.webServer> tags inside configuration file and web.config might look like the following (actual set of rules painted in blue):
If you directed to GUI for rewrite rules configuration, then use the following:
8.5.6 URL Rewrite Configurations (remaining configurations)
There are three more configurations available at the "Miscellaneous Configs" admin page:
All 3 configurations directly tide with URL rewrite rules.
Note: if any of the three settings changed, then ALL rules for ISAPI rewrite modules in previous chapter MUST be respectfully amended.
Default value is [~] (tilde). This character used to separate a page name and keyword/ID of URLs. For instance:
The only other character, which recommended as separator, is a slash [/].
The URLs in such case would look like:
There is a catch however. If you set a slash [/] as a separator, then you must specify a base url tag in <head></head> section of the site with full URL path to the RC installation. Tag should be set inside head_meta template in Content Management.
On the other hand, if RC located in some folder:
If you do not indicate <base> tag, rewrite rule would not work and ALL relative links would be directed to the 404 – "page not found".
In addition, all instances of [~] in rewrite rules MUST be replaced with [/]
Tilde however considered safer and changes to URL Separator not generally recommended.
Default value is [.] (dot). This character used to separate keywords and numeric identifies in URLs. For instance:
Although this configuration is available for amendments, it should only be amended if you are an experienced developer and wish to change static URLs’ builder routine in libraries.asp.
Default value is .html This is page extension used for static links generated by RC.
If you decide to change it, then all instances of [.html] in rewrite rules MUST be replaced with new page extension.
8.5.7 Creating Custom Search Links
When you have a significant number of ads posted to classified, it is possible to create custom search links with most common keywords and place them anywhere at the site or submit them to SE with Sitemaps. With URL rewriting, links would be short, attractive and SE friendly.
Consider the link:
This link would display a list of ads with keyword [home] in subject or body at the Advanced Search page. It is the same as if you typed [home] into the search box and hit "Search" button.
As is, this URL is long and unattractive. Here are Rewrite rules to make it SE and user friendly
RewriteRule ^(.*?)search~([^/]+)$ $1advsearch.asp?AST1=$2&dosearch=dosearch&ASD5=3&ASD2=1&ASD4=1 [NC]
For MS Module for IIS7.0
Once rule implemented classified ads could be searched with simple URL link:
Replace [home] with any keywords, which bare match within ads at your classified to create series of quick search links. Place them at the main page for visitors and submit to SE with Sitemaps (use custom links window at Sitemaps generator).
At the same time, you may change the URL for ad body keywords (if you specified at least one keyword). For details about configuration of ad body keywords see chapter 1.2.
The URL Link for located keywords for the particular URL rewrite rule above would be:
|©2003-2010 Rapid Classified v3.3 GA Soft|