- URL Rewriting: How to?
- Implementing the URL Rewriting on an AWP site
- Configuring the rules for rewriting a page
- Notes about the rewriting rules
- Tips if the HTTP 404 error (file not found) occurs when using the URL Rewriting
URL Rewriting is a technique used to improve SEO.
It is used to define the address of Web pages according to their name and to their parameters in order to make them easier to process by the search engines.
For example, a page used to display a list of products whose URL is:
can be presented to the Web users and to the search engines with the following URL:
Limitations and notes:
- URL Rewriting can only be applied to Active WEBDEV Pages.
- URL rewriting works on all WEB servers supported by WEBDEV.
- For the standard dynamic sites (with context), the addresses are simplified via the mechanism for short URLs.
Implementing the URL Rewriting on an AWP site
To configure the URL Rewriting of a site, on the "Page" tab, in the "SEO" group, click "URL Rewriting".
A configuration window gives an overall view of all rules for rewriting the project.
The characteristics of this window are as follows:
- The table (1) displays all the project pages and it allows you to choose the ones that will be processed by the mechanism for URL Rewriting.
To enable the URL Rewriting on a site page, check the corresponding box in the first column of the table.
- WEBDEV generates a rewriting URL by default. To configure the rules for a specific page, click (2) on the right of the table.
- The character used to separate the parameters during the rewriting can also be chosen (3).
- The border found at the bottom of window (4) is used to enhance the rules by running the engine test for URL rewriting. All you have to do is enter an address and the engine indicates whether it corresponds to a page and how the parameters will be extracted.
Configuring the rules for rewriting a page
The option window proposes the following information for each page whose URL must be rewritten:
The table presents the different components of the URL as it will be received by the WEBDEV application server. This table also explains how to rewrite the different components of the URL to make them correspond to a project page and to the parameters of this page.
The different columns of the table are as follows:
- The "Type" column (1) is used to choose whether the element of the URL is a fixed component or a parameter:
- A fixed component is an unchanging section of the URL. Fixed components can be multilingual (click the column to enter the values in the other languages of the project).
- A parameter is a section of the URL corresponding to a parameter of the page. This parameter can be explicitly declared in the "Global Declarations" event of the page (for more details, see Events associated with pages) or retrieved using PageParameter.
- The "Component" column (2) indicates the value of URL component for a fixed component or the parameter name.
- The "Format" (3) column is used to choose the type of a parameter (numeric, alphabetic, alphanumeric or other).
The buttons found on the right of the table (4) are used to move the different URL components.
If the Active WEBDEV Page contains a procedure declaration in the "Global declarations" event with declared parameters
, you can generate rewrite rules automatically with the button "Generate automatically" (5).
For example, a page declared as follows:
PROCEDURE PAGE_PageName( Param1 is string, Param2 is int)
will be automatically rewritten with three components:
- A fixed component: "PageName" (the "PAGE_" prefix from the code style is automatically removed).
- A first parameter corresponding to Param1.
- A second parameter corresponding to Param2.
An example is displayed at the bottom of window (6) when the rewriting rules are build.
Remark: Param1 and Param2 can be used in the code directly: in this case, the call to PageParameter
: You have the ability to ask to manually edit the regular expression corresponding to the rules for rewriting the page (7). In this case, the regular expression is used to validate the received URL and each section stored (via the brackets in the regular expression) is assigned to a table element. For more details on regular expressions, see MatchRegularExpression
Caution: The manual edit of regular expression is reserved to the process of specific rewriting cases. It should not be used in most cases.
Notes about the rewriting rules
- WEBDEV automatically checks whether the different rewriting rules defined in a project do not trigger any conflicts.
- The rewriting rules are defined for each site separately. If several sites are deployed on the same server, the rewriting rules will trigger no conflict between the sites.
Tips if the HTTP 404 error (file not found) occurs when using the URL Rewriting
Once the URL rewriting is configured, the Web server can return the HTTP 404 errors. This error indicates that the file corresponding to the requested URL was not found. Steps to follow to diagnostic and correct the problem:
- Check the URL rewriting parameters in WEBDEV. To do so, check the following aspects:
- The URL used must correspond to one of the regular expressions of URL rewriting for the site. To check whether the URL used corresponds to a rule for re-writing the site:
If the specified URL is correct, the real page URL is displayed below ; otherwise, a message indicates that no page corresponds to the specified URL.
- display the window for configuring the URL rewriting of project: on the "Page" tab, in the "SEO" group, click "URL Rewriting".
- type the name of the page that was re-written in the edit control named "Address to test: http://mysite/".
For example: pagerewriting-p1-p2-p3.awp. => pagerewriting(p1=p1,p2=p2) or => No site page corresponds to this URL.
If this does not correspond, check the "Advanced layout" option in the details of URL rewriting of page. In most cases, this option must be in "Automatic" mode and not in "Custom" mode (the "Custom" case is reserved to an advanced use).
- In order for the URL rewriting to operate, the Active WEBDEV Pages must not be stand-alone pages. Indeed, the re-writing rules are found in the library of the site (in the WDL). These rules cannot be found in the awp page because the purpose is to find the awp page.
- The rewriting information may not be updated in the project. In this case, we advise you to:
- repair the project in development: on the "Project" tab, in the "Project" group, expand "Recompile and synchronize" and select "Repair project",
- for the deployment, regenerate the library and redeploy it.
- The site must have been deployed at least one by a setup (physical media or FTP) in order for the WEBDEV Application server to have been configured.
- A ".WDConfig.awp" file must be found in the directory corresponding to the path of the re-written URL. This file contains an information about the name of the site. This information is such as: SITED * <SiteName>.
- Check the configuration of the Web server used. The URL rewriting will operate only if the Web server calls the WEBDEV Application Server properly.
Remark: These points are checked by the diagnostic of the WEBDEV application server by entering the name of the virtual server in the "Name/IP" edit control beside the "Diagnostic" button of the "Advanced" tab.
The following information must be checked:
- ".awp" must be associated with the WEBDEV 27 engine in the virtual site.
- In the Web server configuration, make sure that "Check the existence of the file" is NOT checked for AWP extensions.
- With IIS 6 (2003 Server): In the "Properties" window of Web site ("Home directory" tab, "Configuration" button), make sure that "Check the file existence" is not checked for the line with .awp.
- With IIS 7 (7/Vista): On the Web site, select "Handler mappings", "Home directory" tab, "Configuration" button, then select the line with ".awp". In "Restrictions of requests", "Mapping" tab, make sure that nothing is checked.
- If the URL contains some characters (such as +), some Web servers may consider that it is a double escape. An HTTP 404 error (or an HTTP 404.11 error) is triggered. In this case, the Web server must be configured to allow the double escape.
For example, with IIS 7 (7/Vista): On the Web site, select "Filtering the requests", then click the "Modify the function parameters..." link and check "Allow the double escape".