In this section we will present the various methods of redirection supported by the SEO-G module. Each section includes a detailed figure to illustrate the functionality and logic of the SEO-G for URL redirects and friendly links conversion.

In a nutshell SEO-G deploys 4 different redirect mechanisms: the Original Converter, the Proximity Redirect, the External Redirect and the Custom Redirection.

1. Original URL to SEO-G URL Redirection
The first method converts the original osCommerce link, of supported SEO-G entities, to a friendly URL. The server generates a 301 response to service this transition. In this case, SEO-G retrieves the original URL from the SEO_URL database table, comparing it against the requested URI. If the entries match, SEO-G retrieves the friendly URL and performs a 301 redirect.

The purpose of this redirect mechanism, is to expose to visitors and search engines the new links structure, when SEO-G is initially deployed. Without it, visitors and search engines will keep visiting pages using the original URLs.

Figure-1 Original osCommerce to SEO-G friendly URL Converter

Figure-1 shows the basic logic behind the SEO-G Original URL Converter. The URI is compared against the SEO_URL database table for an exact match. When a link record is found, the SEO-G will initiate a 301 redirect to the corresponding friendly URL. If no match is found, regular PHP script processing is resumed.

You should note, that the asynchronous URL builder of SEO-G, along with the automatic update mechanism, alter the SEO_URL table often in order to maintain and synchronize links. This method is used to assist exposure of the new URLs, during initial SEO-G deployment, as visitors and search engines are not aware of the newly implemented URL structure.

2. SEO-G Proximity Redirect
The proximity redirect, is an intelligent search facility that scans the SEO_URL table for matches against the requested URI and always initiates a 301 permanent redirect conveying existing web traffic from one page to another with minimum loss of ranking.

The proximity redirect mechanism, is triggered when the incoming URI matches the SEO-G supported URL link extensions, but do not match the URL body (namely the query and path components of the URL).

A threshold configuration setting, is available for the proximity redirect, via the Administration Panel - > SEO-G -> Configuration. The threshold switch indicates how many continuous characters SEO-G must match, against the incoming URI, before taking a redirect decision. If the proximity threshold is less than the number of matched characters, SEO-G will initiate the 301 redirection routine. In this case, the landing page will be the first one retrieved from the SEO_URL table.

Figure-2 Proximity Redirect by SEO-G Logic and Functionality Diagram.

The proximity redirect mechanism is also utilized by the external SEO-G redirection script. The SEO-G proximity redirect, is a multiple purpose redirection mechanism. It covers cases where a visitor, types in an incorrect URL. It also covers cases where the store owner reassigns names for products, categories, manufacturers, text pages and any entity SEO-G handles, where the old links are already exposed to visitors and search engines.

A fully automated database update method, can also be deployed that rectifies links, because this SEO module can associate the web page content with the recorded URLs. Mismatch errors of the recorded URLs against the stored page content are reported and can be corrected instantly.

SEO-G proximity redirect, is also used for site migration from one domain to another. Stores that are ported from another web engine to the osCommerce cart, with or without the I-Metrics layer, may benefit from this approach as the proximity redirect, forces visitors and search engines to use the closest valid URLs available. Proximity redirect is extremely efficient for store relocation as a single script performs an automated and dynamic mapping of old to new links.

The proximity threshold switch can adjust the sensitivity of the redirection using a character closest match method. Higher numbers lead to a lower sensitivity bringing better results for the destination page, at the expense of not always locating a page. A lower number of characters for the proximity threshold, increases the chances of locating a matched link in the database but could lead to a poor decision making, conveying web traffic and page ranking to the wrong page. At the moment the threshold switch is a global setting, but there are plans to modify this behavior, so a separate threshold can be assigned at the URL level, with newer versions of SEO-G subject to the number of keywords a friendly link consists of.

3. SEO-G External redirect
The SEO-G external redirect mechanism, collaborates with the proximity redirect. In a nutshell it forwards URIs, for which the server would otherwise return a 403 or 404 response, to the main SEO-G module for further processing, offering a chance to funnel incorrect URLs of any kind, posted externally or internally.

This approach generates two different 301 redirects for pages. The first 301 redirect is forwarded to the SEO-G root by filtering the URI allowing only basic characters.

The second 301 redirect is the proximity redirect and is almost certain to be generated in this case as the external redirect script performs a basic filtering to the URI thus it is unlikely to match an existing friendly URL.

An alternative method can be deployed where the database records of stored URLs are scanned during the first page request. Custom implementation include filtering of URL extensions to increase the chances for a match with the first 301 redirection.

Figure-3 External Redirect Logic and Functionality of SEO-G

The purpose for the SEO-G External redirection code, is to allow an easy transition from one web engine to another. Typically used from migration from a non-osCommerce engine, to and osCommerce or I-Metrics platforms.

Another purpose of this redirection type, is to improve the security of the store and scripts. When the 403 filter is deployed via the .htaccess, the SEO-G converts the otherwise plain 403 forbidden responses, to 301 redirects, forwarding the request to the main SEO-G module. This in turn, attempts to match the URL to a valid link. This method can hide sensitive folders or scripts, that otherwise could been exploited by an attacker. Other types of 4xx responses can also be hooked in the .htaccess and subsequently forwarded to the SEO-G functions for processing.

The external redirect of SEO-G is implemented at the PHP application level, instead of the .htaccess, because of the PHP flexibiltiy and functionality. The decision making of the external redirect, is able to connect to the database like every other normal catalog script of the I-Metrics layer and osCommerce engine.

4. Individual Redirect and Redirection Table - Custom Redirects
SEO-G deploys a custom redirection table. This mechanism is in place from the v1.00 of SEO-G. The individual redirection is a custom table where the e-shop owner can enter links of his choice to be redirected. The Individual or Custom Redirection mechanism has undergone certain upgrades. Among them, the ability for the SEO-G module to process URLs with different extensions.

In order for the individual redirection to take place, the incoming URI must be forwarded via the SEO-G root script. Earlier versions, would only process URLs of the same extension. In earlier versions if the original friendly URL had an .html extension, the custom redirection table had to consist of URLs with .html extensions. The older approach made a store's URLs transition harder to streamline and utilize.

Figure - 4 Custom Redirection Table.

The custom redirection table editing facility is available from the Administration panel SEO-G redirects.

The Proximity, External and Original Converter redirection methods are available with the SEO-G Renegade edition only. Older SEO-G versions have only the Custom Redirection method in place.