Searchengineoptimizationseo 130820015428 Phpapp02

Search engine optimization (SEO)
1 of 16
http://pic.dhe.ibm.com/infocenter/wchelp/v7r0m0/advanced/print.jsp?top...

Contents
1. SEO for Version 7 Feature Pack 3 or later
1.1. Task flow: Setting up WebSphere Commerce SEO on a starter store (Feature Pack 3)
1.1.1. Shortening a store URL by changing the context root
1.1.2. Testing SEO-friendly URLs in the storefront
1.2. Constructing SEO-friendly URLs by using pattern files
1.3. SEO-friendly URL deconstruction overview
1.4. SEO-friendly URL construction overview
1.4.1. SEO-friendly URL construction with a default catalog
1.5. Search engine optimization (SEO) title and meta description (TMD) data for store web pages
1.6. Enabling SEO with sales catalogs and extended sites
1.7. URL redirects for SEO
1.8. Retrieving SEO substitution parameters for populating the Management Center UI
1.9. Customizing the SEO component configuration properties
1.10. SEO with Rich Snippets
2. Search engine optimization (SEO) for WebSphere Commerce Version 7 to Feature Pack 2
2.1. Optimizing your site for search engines
2.2. Updating page content
3. WebSphere Commerce integration with sitemaps
3.1. Customizing site maps integration
3.1.1. Site map integration template

Depending on the feature pack level of your store, you can use one of the following solutions to optimize your store for search engine results.
SEO for Version 7 Feature Pack 3 or later

Search engines, such as Google, are one of the most important channels for customers to reach your store. Using search engine optimization (SEO) to improve page
ranking can result in increased traffic and revenue. The SEO functionality for WebSphere Commerce Version 7 Feature pack 3 or later improves online search page ranking
for your store by creating shorter SEO-friendly URLs with meaningful keywords. This version includes enhanced Management Center tools that business users can use to
influence page ranking by changing the URL and metadata information, an improved Sitemap generator that indexes all the SEO-friendly URLs, and 301 URL redirect rules.
Search engine optimization for WebSphere Commerce provides the following functionality:
Creating simple, static URLs for store pages that shoppers and search robots can easily understand
Optimizing page metadata to improve search engine page rank
Creating 301 URL redirection when a web page is moved
Generating site maps to submit to search engine providers
Simplifying URLs
Use the following methods to simplify store URLs.
The standard context root of the store URL is long and contains identifiers that are irrelevant to shoppers. Shortening the length of the context root it to a single word
such as store or shop shortens the URL:
Context root URL
Full
http://localhost/webapp/wcs/stores/servlet/Product2_10001_10001_10029_-1_10007_10001_10001_ProductDisplayErrorView
Short
http://localhost/shop/Product2_10001_10001_10029_-1_10007_10001_10001_ProductDisplayErrorView
For more information, see Shortening the context root of a store URL.
Use keywords for categories and products to create a URL that is easy for shoppers and search robots to read and understand:
Original URL: URL with full context root and old query string
http:/mystore
/shop/Product2_10001_10001_10029_-1_10007_10001_10001_ProductDisplayErrorView
Rewritten URL: Final SEO-friendly URL with shortened context

root and shorter, easier to understand keyword-based ending
http://mystore/shop/side-tables/two-drawer-side-table
For more information about SEO-friendly URL construction, see SEO-friendly URL construction overview.
Optimizing page metadata to improve search engine indexing

Search engines use the page title and metadescription of a page to influence search results. Indexing allows a shopper to use a search engine to search for a red leather
couch, and view search results with links to red leather couches for sale. The SEO feature creates unique information for title and metadescription tags for each web page to
describe the product or page contents. Every product in a store is assigned unique metadata to ensure that the product is found by a search engine. The title tag indicates
to users and search engines what the topic of a particular page is, and displays in the first line of a search result. The metadescription tag of a page provides search engines
with a summary of the page contents, which appear on search engine results pages.
For more information, see Search engine optimization (SEO) title and meta description (TMD) data for store web pages.
Creating 301 URL redirects for moved store pages

If a URL is changed by either WebSphere Commerce or a business user, a 301 redirect is automatically generated between the old URL and the new URL.
For more information about URL redirects, see URL redirects for SEO Overview.
Generating site maps to submit to search engine providers

A site map is a full list of all the pages in your store. This site map is submitted to search engines so that they know what to crawl and index. The Sitemap Generator is
enhanced in Feature Pack 3 to index the new friendly website addresses and search landing pages.
For more information about site maps, see WebSphere Commerce integration with sitemaps.
Limitations of Search Engine Optimization

SEO-friendly URLs are not supported in the IBM Gift Center for the Madisons starter store.
Search engine optimization is not supported with content versioning.
Task flow: Setting up WebSphere Commerce SEO on a starter store (Feature Pack 3)
7/8/2013 11:59 AM
2 of 16
You can set up a Madisons or Elite starter store in the development environment to try out WebSphere Commerce search engine optimization (SEO) features. When you
complete this task flow, you can view SEO-friendly URLs in the storefront. In Management Center, you can use SEO features for catalog and marketing managers, including
adjusting the page title, using URL keywords, and adding meta description for your URLs.
Before you begin
Ensure that you have completed the following installation and enablement tasks:
Install WebSphere Commerce Version 7 Feature Pack 3. This feature pack installs all software required to add WebSphere Commerce SEO features to your store.
Enable starter store enhancements. Use the script to enable the software assets for the new SEO features.
About this task
For an overview of the features included in WebSphere Commerce SEO feature packs, see SEO for Version 7 Feature Pack 3 or later.
Procedure
Shortening the context root of a store URL

Shortening the context root of a store's URL makes it easier for shoppers to remember a link and also improves visibility in search engine results.
About this task
You can shorten the URL for your store by modifying the context root. You can change the default site URL from http://hostname/webapp/wcs/stores/servlet
/StoreName/index.jsp to something shorter, such as: http://hostname/shop/StoreName/index.jsp. In this example, shop is used to replace the context root, but any
name can be used in its place.
Procedure
To modify the context root:
If you are running an IIS web server:
1. Install the URL Rewrite module from: http://www.iis.net/download/URLRewrite
2. Correcting the load order of IIS modules:
a. Navigate to C:\Windows\System32\inetsrv\config.
b. Open applicationHost.config
c. Search for RewriteModule in the globalModules list.
d. Move the line to above the IsapiFilterModule module in that list.
e. Save the file.
3. In the IIS Manager, select the server node and click Restart from the Actions list on the right side of the window.
4. Restart the IIS Admin Service.
5. Return to the server view in the IIS Manager.
6. Double-click URL Rewrite.
7. Create a rewrite rule to map the SEO URL to the original URL:
a. Select Blank rule.
b. Enter the following information into the form. In this example, shop is used to replace the context root. Any name can be used for the pattern:
Name
Enter a descriptive name, such as [SEORewriteRule]
Pattern
shop/(.*)$
Ignore case
checked
Action type
Rewrite
Rewrite URL
webapp/wcs/stores/servlet/{R:1}
Append query string:
checked
Stop processing of subsequent rules: checked

c. Click Apply.
If you are running an IBM HTTP Server:
1. Navigate to WC_installdir/instances/demo/httpconf, where demo is your instance name
2. Open httpd.conf
3. Ensure that the following line is uncommented:
LoadModule rewrite_module modules/mod_rewrite.so
4. Locate the virtualhost object: <VirtualHost servername:80>
5. Insert the following code inside the <VirtualHost servername:80> object before the ending </VirtualHost> tag.
RewriteEngine on
RewriteRule ^/shop/(.*) /webapp/wcs/stores/servlet/$1 [PT,L]
6. Locate the virtualhost object: <VirtualHost servername:443>
7. Insert the following code inside the <VirtualHost servername:443> object before the ending </VirtualHost> tag.
RewriteEngine on
RewriteRule ^/shop/(.*) /webapp/wcs/stores/servlet/$1 [PT,L]
8. Save the file.
9. Restart the IBM HTTP server.
If you are running a Sun web server:
1. Navigate to the config directory where you installed your Sun web server. For example: /opt/webserver7/https-hostname/config
2. Open the obj.conf file.
3. Add the following entry inside the default Object tag:
7/8/2013 11:59 AM
3 of 16
<If $uri =~ '^/shop/(.*)'>

NameTrans fn="restart" uri="/webapp/wcs/stores/servlet/$1"
</If>
4. Restart the web server.
5. Optional: If you want to support having query parameters in your URL with the shortened context root, repeat steps 3 and 4 replacing the <If> block with the
following code:
<If $uri =~ '^/shop/(.*)' and not defined $query>
NameTrans fn="restart" uri="/webapp/wcs/stores/servlet/$1"
</If>
<If $uri =~ '^/shop/(.*)' and defined $query>
NameTrans fn="restart" uri="/webapp/wcs/stores/servlet/$1?$query"
</If>
What to do next
Once
1.
2.
3.
the rewrite rule is updated in the web server, update the WebSphere Commerce server configuration file to provide the context root rewrite rule value:
Open the WebSphere Commerce configuration file.
Search for the SEOConfiguration section.
Within the SEOConfiguration section, enter the following code:
<context-root-rewrite value="/shop" />
For example:
<SEOConfiguration defaultUrl="" dynamicUrl="true" enable="true">
<context-root-rewrite value="/shop" />
</SEOConfiguration>
4. Save the file.

5. Propagate the changes to the WebSphere Commerce configuration file.
Testing SEO-friendly URLs in the storefront

In this lesson, you test the SEO-friendly URLs as a shopper in the Madisons store.
About this task
To ensure that the SEO features were implemented correctly, navigate to a product page and check the URL.
Procedure
1. To view the Madisons store, in a new web browser type http://host_name/webapp/wcs/stores/servlet/StoreView?storeId=storeId.
Where:
storeId
The store entity ID as defined in the STORE_ID column of the STORE table.
host_name
The fully qualified host name of your WebSphere Commerce Server (for example, wcserver.mydomain.ibm.com is fully qualified).
2. Click any featured product to be directed to that page.
3. Check the URL to ensure that it uses the SEO-friendly conventions including the shortened context root and readable keywords.
Results
You successfully configured and tested SEO-friendly URLs.
Constructing SEO-friendly URLs by using pattern files

Pattern files are used in the construction and deconstruction of SEO-friendly URLs. Because each page type requires the construction of different data, a pattern file
contains a URL template. For example, there are pattern files for the Category page, Contact Us page, and Product page.
Pattern definitions
The following is a sample pattern definition for a privacy policy page URL:

a <seourl:seoUrlPatternDef name="PrivacyRegistrationURL">
b <seourl:seoUrlPattern viewName="PrivacyView">/LanguageToken/StoreToken:CatalogToken/PrivacyRegistrationToken</seourl:seoUrlPattern>
c <seourl:urlToParamMapping>
<seourl:mapping name="langId" value="?LanguageToken?"/>
<seourl:mapping name="storeId" value="?StoreToken?"/>
<seourl:mapping name="catalogId" value="?CatalogToken?"/>
<seourl:mapping name="fromPage" value="registration"/>
</seourl:urlToParamMapping>
d <seourl:paramToUrlMapping>
<seourl:mapping name="LanguageToken" value="?langId?" defaultValue="-1"/>
<seourl:mapping name="StoreToken" value="?storeId?"/>
<seourl:mapping name="CatalogToken" value="?catalogId?"/>
<seourl:mapping name="PrivacyRegistrationToken" value="Privacy-Policy-Registration"/>
</seourl:paramToUrlMapping>
e <seourl:usageDef>
<seourl:usage device="browser">
<seourl:target>Privacy</seourl:target>
</seourl:usage>
</seourl:usageDef>
</seourl:seoUrlPatternDef>
a. SEO URL pattern definition name
The name of the pattern. This is the name that is used while constructing the SEO URLs in JSP pages by using wcf:url tag library.
b. Struts to pattern mapping
Defines the pattern of the URL. The viewName attribute defines the struts action mapping which will be used when the SEO URL is deconstructed. After the SEO
7/8/2013 11:59 AM
4 of 16
URL is deconstructed and matched against the pattern, the request is forwarded to the corresponding viewName attribute.
c. SEO URL to parameter mapping
Used during deconstruction of the SEO URL. After the URL is matched against the pattern, the values associated with the keywords in the URL are attached to the
corresponding parameter names defined in this mapping, based on the mapping between the tokenName and the keyword.
For example, if en/madisons/Privacy-Policy-Registration is matched against the above pattern /LanguageToken/StoreToken:CatalogToken
/PrivacyRegistrationToken, the value of keyword "en" is associated with parameter langId. The Madisons keyword is associated with StoreToken:CatalogToken and
its value (for example: 10001:10002) is assigned to storeID and catalogId (storeId = 10001 and catalgoId = 10002) after splitting.
d. SEO URL parameter to URL mapping
Used during construction of the SEO URL in JSP pages by using the wcf:url tag library. Based on the token name and tokenValue, the keywords are looked up in
the database and substituted for the token names in the URL pattern.
e. Pattern usage
In this example, the usage is for a privacy static page which is displayed under the Store Management tool in Management Center.
Structures of pattern files

Pattern files are in this directory:
WC_eardir/Stores.war/WEB-INF/xml/seo/stores/storedirectory
WCDE_installdir\workspace\Stores\WebContent\WEB-INF\xml\seo\stores\
You can have more than one pattern file for a store, and each file is read in alphanumeric order. If any customizations are required to the default patterns, create a
separate file and ensure that it is listed last alphanumerically to overwrite the default definitions. If no pattern files are found in the current storeDir, the search continues
to look up the pattern files in the related stores.
The pattern file lookup continues until one of the following conditions is satisfied:
Pattern files are found at some level.
A .disable file is found.
All the related stores are searched.
Fixed tokens
An SEO pattern file can contain two sections: A token is an elementary symbol in a URL pattern. Each token has a specific usage and is associated with a keyword and a
value. During SEO-friendly URL construction, the tokens in a URL pattern are replaced by their respective keywords. During URL deconstruction, the keywords are looked
up for their respective token names to match a particular URL pattern and also find the values to be associated to the parameters of the deconstructed dynamic URL. There
are two types of tokens: dynamic and fixed. Dynamic tokens are defined in the SEOTOKENUSGTYPE table, and the fixed tokens are defined in the pattern file.
<seourl:tokenDef>
1 <seourl:token name="PageViewToken">
<seourl:tokenValue value="image"/>
<seourl:tokenValue value="detailed"/>
</seourl:token>
2 <seourl:token name="PrivacyRegistrationToken">
<seourl:tokenValue value="Privacy-Policy-Registration"/>
</seourl:token>
3 <seourl:token name="TopCategoryBooleanToken">
<seourl:tokenValue value="Y"/>
<seourl:tokenValue value="N"/>
</seourl:token>
4 <seourl:token name="BeginIndexToken">
<seourl:tokenValue value="[[0-9]*]"/>
</seourl:token>
5 <seourl:token name="CatEntryIDToken">
<seourl:tokenValue value="[[0-9]*]"/>
</seourl:token>
6 <seourl:token name="ContentOnlyToken">
<seourl:tokenValue value="1"/>
<seourl:tokenValue value="0"/>
</seourl:token>
</seourl:tokenDef>
1. PageViewToken
Can have only two values, image or detailed.
2. PrivacyRegistrationToken
Can have only a value of Privacy-Policy-Registration.
3. TopCategoryBooleanToken
Can have a value of Y or N.
4. BeginIndexToken
Can have numerical values. Enclose the expression in a set of brackets []. The expression [[0-9]*] indicates that the valid value for BeginIndexToken can be any
numerical value. To use an integer, do not use the *.
5. CatEntryIDToken
Can have numerical values. Enclose the expression in a set of brackets []. The expression [[0-9]*] indicates that the valid value for CatEntryIDToken can be any
numerical value. To use an integer, do not use the *.
6. ContentOnlyToken
Can have a value of 1 or 0.
A value of 1 means include header, footer, left and right navigation bar, along with content.
A value of 0 means do not include the header, footer, and left navigation bar. Display the content present at the middle of the page
Dynamic tokens
The SEOTOKENUSGTYPE table bridges the gap between the Management Center user interface, which saves the URL keywords, and the pattern definition files that are
defined in the storefront. The primary gap between Management Center and the storefront is the token names that are used in the pattern definition files. The Management
Center user interface uses the token names to save the URL keywords for catalog entries, category, and static store pages. To distinguish among the various tokens that are
used in the pattern definition, the concept of usage is introduced. The token Usage Type table supplies the Management Center user interface with the token names used in
the pattern definition files. The usage maps a token name to the entities for which the keywords are defined against the set token name. Some of the usages are predefined
in this table and are mapped to the default entities for which the URL keywords are allowed to be defined.
These following predefined usages are found in the table mapping:
Store
Language
Product
Item
Category
7/8/2013 11:59 AM
5 of 16
Privacy
Sitemap
Usage is defined for entities such as catalog entries and categories and for static content in the store, such as privacy pages or site map pages.
The token usages are defined at the store level. Similar to the view store relationship, you can define token usages at the site level and are applicable to all the stores. You
can add more usages to the default usage list. You can also override the token names for these usages for a specific store or for the site.
The store tokens are cached in the SEOConfigurationRegistry instead of the dynamic cache because the tokens are infrequently updated. Always define store tokens at the
site level (zero store-level) because store tokens are always used to resolve the storeId.
The predefined store usage uses StoreToken as the token name. If any complex tokens are defined for the store usage for a specific store, they must contain the
StoreToken. For example, a store might consider merging the store, language, and catalog Id values into the token for the store usage and takes the following form:
StoreToken:LanguageToken:CatalogToken. When the configuration registry caches the token, it looks for the StoreToken string in the token name. The value at the
corresponding position in the token value is treated as the storeId. This behavior is the primary reason for hardcoding the token name for the predefined store token.
The default token for the language usage is LanguageToken. Because the keywords for the language token are taken from the language registry, you do not have to define
them.
By default LanguageTokens are taken from the language registry. The lang code is the keyword. For example, in English, the urlKeyword is en and languageId is -1.
But this default behavior can be overridden by defining separate urlKeywords (other than the default language code) for any language, in SEO URL Pattern files.

<seourl:languageKeywordDef>
<seourl:LanguageKeyword languageId="-7" urlKeyword="zh-CN"/>
<seourl:LanguageKeyword languageId="-8" urlKeyword="zh-TW"/>
</seourl:languageKeywordDef>
The language code for Simplified Chinese and Traditional Chinese is zh. To override the language code define URL keywords in SEOURLPattern files.
Best practices for working with pattern files

Pattern files provide various options. These options can be an area of uncertainty for users who must decide how to construct the URLs.
Pattern files are read when the first request is made. If any modifications are made to the pattern files after that, the changes are not reflected until server startup.
In a development environment, you can add a text file with name = .reload and specify the reload interval by adding this property inside the reloadinterval =
<reloadInterval in seconds> file.
Note: Use the .reload file only during development, not in production environment. Constantly reloading the pattern files severely affect the performance and can
cause unexpected results.
Adding an empty .disable file in the same path, disables the new SEO feature for that particular store. This action requires a server restart or a .reload file.
The backslash (/) and underscore (_) are special keywords that are used in the pattern files. Use these characters to separate the tokens in the URL pattern; however
do not use them in the keyword itself. Similarly, do not use the dot (.) character in the keywords.
patternName ensure that the value is not the same as any action mapping name in the Struts configuration files.
SEO-friendly URL deconstruction overview

When a shopper clicks on a link for a page in the store, they see an SEO-friendly URL. WebSphere Commerce can process the embedded category, store name, language,
and product information only if this SEO-friendly URL is translated to the standard URL format. To translate the SEO-friendly URL to the standard URL, use the SEOURL,
SEOURLKEYWORD and SEOTOKENUSGTYPE) and a URL pattern definition file.
Translating an SEO-friendly URL to a traditional URL:

This example describes how a customer reaches the SEO-friendly URL for the coffee-makers category, http://myhost.com/shop/en/madisons/coffee-makers and how
WebSphere Commerce converts the URL back to its original URL format so that it can be processed.
The following steps explain the process involved in translating SEO-friendly URL to traditional URL.
1. The web server receives the link http://myhost/shop/en/madisons/coffee-makers, replaces shop with the context root: http://myhost/webap/wcs/stores/servlet
/en/madisons/coffee-makers. The web server sends a request to the WebSphere Commerce server for further processing. This example assumes the context root has
been replaced with "shop".
2. When the WebSphere Commerce server receives the URL, it removes the context root and then processes the remaining information. The rest of the information is
divided into keywords (en/madisons/coffee-makers) by using the backslash (/) as a separator to retrieve en, madisons and coffee-makers.
3. The keywords are used for two purposes in translating a URL; to determine the URL pattern, which indicates the kind of URL construction, and to obtain the necessary
values to build the original URL.
URL
type
Catalog
Pattern
LanguageToken/StoreToken:CatalogToken
Sample non-SEO URL

...TopCategoriesDisplay?langId=-1&storeId=10001&catalogId=10002
Category LanguageToken/StoreToken:CatalogToken/CategoryToken
...CategoryDisplay?langId=-1&storeId=10001&catalogId=10002&categoryId=10003
Product
LanguageToken/StoreToken:CatalogToken/CategoryToken
/ProductToken
...ProductDisplay?langId=-1&storeId=10001&catalogId=10002&categoryId=10003&
productId=10004
Contact
Us
LanguageToken/StoreToken:CatalogToken/ContactToken
...HelpContactUsView?langId=-1&storeId=10001&catalogId=10002
4. Determining the URL pattern and values:

a. The keywords are translated into tokens. The keywords are stored in multiple places, depending on the keyword type. Language keywords are stored in the
language registry which pulls contents from the LANGUAGE table, while other keywords are stored in the SEOURLKEYWORD table:
en is found in the language registry. Because only languages are stored here, this determines that its token is LanguageToken. The value for en is -1.
madisons is found in the SEOURLKEYWORD table, where it is listed as a combination of a StoreToken and a CatalogToken (eg. StoreToken:CatalogToken )
with values of 10001 and 10002 respectively and represented as 10001:10002.
coffee-makers is found in the same table, where it is listed as a CategoryToken with a value of 10003.
b. With these tokens, the pattern is LanguageToken/StoreToken:CatalogToken/CategoryToken. To determine the type of URL that is being deconstructed, the
system finds the correct pattern in the pattern file(s). Pattern files contain patterns for every type of web page in the store, such as category, department,
product, help, or other page.
Example of a matching pattern
<seourl:seoUrlPatternDef name="CategoryURL">
<seourl:seoUrlPattern viewName="CategoryDisplay">/LanguageToken/StoreToken:CatalogToken/CategoryToken</seourl:seoUrlPattern>
<seourl:urlToParamMapping>
<seourl:mapping name="langId" value="?LanguageToken?" />
<seourl:mapping name="storeId" value="?StoreToken?" />
<seourl:mapping name="catalogId" value="?CatalogToken?" />
7/8/2013 11:59 AM
6 of 16
<seourl:mapping name="categoryId" value="?CategoryToken?" />

<seourl:paramToUrlMapping>
<seourl:mapping name="LanguageToken" value="?langId?" />
<seourl:mapping name="StoreToken" value="?storeId?" />
<seourl:mapping name="CatalogToken" value="?catalogId?" />
<seourl:mapping name="CategoryToken" value="?categoryId?" />
<seourl:usageDef>
<seourl:usage device="browser">
<seourl:target>Category</seourl:target>
</seourl:usage>
</seourl:usageDef>
5. The viewName attribute of this pattern indicates that the SEO-friendly URL is actually a CategoryDisplay struts action. Using the information found in the section
named urlToParamMapping, the paramaters are extracted from the SEOURLKEYWORD table:
<seourl:urlToParamMapping>
<seourl:mapping
<seourl:mapping
<seourl:mapping
<seourl:mapping
name="langId" value="?LanguageToken?" />

name="storeId" value="?StoreToken?" />
name="catalogId" value="?CatalogToken?" />
name="categoryId" value="?CategoryToken?" />
The values for each parameter is extracted from looking in the SEOURL and SEOURLKEYWORD tables and language registry contents:
a. For the language, langId = LanguageToken which is -1
b. For the store, storeId = StoreToken which is 10001
c. For the catalog, catalogId = CatalogToken which is 10002
d. For the category, categoryId = CategoryToken which is 10003
Keyword
Token Name
madisons
StoreToken:CatalogToken
Token Value
10001 (storeId value):10002 (catalogId value)
coffee-makers
CategoryToken
10003 (categoryId value)
en
LanguageToken
-1 (langId value)
6. With the information found in the SEOURLKEYWORD table, the non SEO-friendly URL is constructed in the formatting found in the pattern file
(LanguageToken/StoreToken:CatalogToken/CategoryToken):
http://myhost.com/webapp/wcs/stores/servlet/CategoryDisplay?langId=-1&storeId=10001&catalogId=10002&catagoryId=10003
WebSphere Commerce server executes the view with the specified parameters and sends the result to the browser.
SEO-friendly URL construction overview

To avoid hardcoding SEO-friendly URLs in the storefront pages, the WebSphere Commerce Search Engine Optimization (SEO) feature provides a wcf:url tag that
constructs SEO-friendly URLs by using the SEO pattern file(s) and tables.
The current wcf:url tag is used by all starter stores to construct SEO-friendly URLs. The UrlTag class has been enhanced to support the use of the new URL pattern
definition to create SEO-friendly URLs.
To use the wcf:url tag you need to know all of the parameters that are required for the URL; for example, categoryId, productId and langId. The following example shows
how this information is used by the wcf:url tag to construct SEO-friendly URLs.
Note: Both the new Feature Pack 3 and previous SEO implementations are supported. You can choose which SEO solution to use by updating the wc-server.xml file.
Constructing an SEO-friendly URL

When a developer is working with a store JSP that displays the header menu, the developer must create anchor tag links for all the site's categories. In this example, the
developer creates a link for the coffee makers sub-category.
This example shows how an SEO-friendly URL for the coffee makers category (.../en/madisons/coffee-makers) is created to replace the original non SEO-friendly URL
http://myhost.com/webapp/wcs/stores/servlet/CategoryDisplay?langId=-1&storeId=10001&catalogId=10002&catagoryId=10024 by using the wcf:url tag with a pattern
name and a series of parameters, which have values that are used to construct the keywords in the defined URL pattern.
1. In the pattern file, locate the pattern for the type of page that you want to create. For the coffee makers subcategory example, find the pattern for categories, which
is CategoryURL. The pattern includes the pattern name, and the parameters required to build the URL, as shown in the table below:
a <seourl:seoUrlPatternDef name="CategoryURL">
b <seourl:seoUrlPattern viewName="CategoryDisplay">/LanguageToken/StoreToken:CatalogToken/CategoryToken</seourl:seoUrlPattern>
- <seourl:urlToParamMapping>
<seourl:mapping name="langId" value="?LanguageToken?" />
<seourl:mapping name="storeId" value="?StoreToken?" />
<seourl:mapping name="catalogId" value="?CatalogToken?" />
<seourl:mapping name="categoryId" value="?CategoryToken?" />
- <seourl:paramToUrlMapping>
c <seourl:mapping name="LanguageToken" value="?langId?" />
d <seourl:mapping name="StoreToken" value="?storeId?" />
e <seourl:mapping name="CatalogToken" value="?catalogId?" />
f <seourl:mapping name="CategoryToken" value="?categoryId?" />
- <seourl:usageDef>
- <seourl:usage device="browser">
<seourl:target>Category</seourl:target>
</seourl:usage>
</seourl:usageDef>
Pattern Pattern Name
Description
seoUrlPatternDef name="CategoryURL"
LanguageToken/StoreToken:CatalogToken/CategoryToken the pattern that determines how the URL will be built
the pattern name used in wcf:url tag
Parameter Parameter Name Description

c
langId
A parameter that is represented in the URL pattern as a LanguageToken
7/8/2013 11:59 AM
7 of 16
Parameter Parameter Name Description

d
storeId
A parameter that is represented in the URL pattern as a StoreToken
catalogId
A parameter that is represented in the URL pattern as a CatalogToken
categoryId
A parameter that is represented in the URL pattern as a CategoryToken
This example assumes that the pattern file contains a pattern definition, and that the following sample values exist in their respective tables for creating the coffee
makers subcategory URL:
Parameter Name
TokenName
TokenValue
categoryId
CategoryToken
10024
storeId:catalogId
StoreToken:CatalogToken 10001:10002
madisons
langId
LanguageToken
en
-1
Keyword
coffee-makers
The sample values are found in multiple locations:

The SEOURLKEYWORD table
Static token definitions of the pattern file
Language information found in: LanguageRegistry.singleton().getLanguageById()
2. To link to coffee makers, the developer inserts the wcf:url tag in the JSP for the kitchenware category by using the pattern name CatergoryURL and the values,
langId, storeId, catalogId, and categoryId:
<wcf:url patternName="CategoryURL">
<wcf:param name="langId" value="-1" />
<wcf:param name="storeId" value="10001" />
<wcf:param name="catelogId" value="10002" />
<wcf:param name="categoryId" value="10024" />
</wcf:url>
3. WebSphere Commerce uses the contents of the wcf:url tag, plus the pattern to create the SEO-friendly URL for coffee makers:
a. Based on the pattern for product categories, the URL is built in this format: LanguageToken/StoreToken:CatalogToken/CategoryToken
b. The three keywords are determined by breaking down the format by the keyword separator:
LanguageToken, with a langId value of -1. Found in the language repository, is en.
StoreToken:CatalogToken, with a value of 10001:10002. Found in the SEOURLKEYWORD table, is madisons.
CategoryToken, with a value of 10024. Found in the SEOURLKEYWORD table, is coffee-makers.
c. All these keywords are combined in the format provided by the pattern to get: en/madisons/coffee-makers.
d. The wcf:url tag combines this to create the full URL of www.myhost.com/shop/en/madisons/coffee-makers. If the developer rewrites the context root to
shorten the URL, the context root appears as shop.
SEO-friendly URL construction with a default catalog

SEO-friendly URLs are constructed by using a pattern to determine how to build the URL. A part of the pattern requires the tokens StoreToken:CatalogToken to be defined
in the SEOURL table and an associated URLKEYWORD in the SEOURLKEYWORD table. With the introduction of a default catalog, a StoreToken: token entry is preconfigured
in the SEOURL table.
For example, in the SEOURL table, there exists a row that resembles the following tokens for the Aurora starter store:
SEOURL_ID TokenName
13227
TokenValue
StoreToken:CatalogToken '10001:'
The token is associated with a URLKEYWORD in the SEOURLKEYWORD table, in this example, 'aurora'. Notice that there is no CatalogToken value in the TokenValue
column. By default, if you do not specify a default catalog in the Catalogs tool, the master catalog is the default catalog.
If your store contains sales catalogs and the catalogs do not have token entries in the SEOURL and SEOURLKEYWORD tables, then an SEO URL cannot be constructed for
your sales categories. But, if you set the sales catalog as your default catalog, then the preconfigured StoreToken: token entry is used and an SEO URL is constructed with
the associated URLKEYWORD, in this case 'aurora'.
For example:
1. In the Catalogs tool, you create a sales category in a sales catalog.
2. In the Search Engine Optimization tab of the sales category, you specify a URL keyword sales-apparel.
3. Set the sales catalog as your default catalog.
The resulting SEO URL that is constructed would be http://www.myhost.com/shop/en/aurora/sales-apparel
However, if you set up tokens in the SEOURL and SEOURLKEYWORD tables for the sales catalog, then the new URLKEYWORD entry is used instead. To set up tokens for
your sales catalog, you must Enable SEO with sales catalogs.
For example, if you enable SEO with a sales catalog and set the URLKEYWORD to 'teststore', then the constructed SEO URL would be http://www.myhost.com/shop/en
/teststore/sales-apparel.
Important: If you plan to set a sales catalog as the default catalog, ensure that your SEOURL table also has a StoreToken:CatalogToken entry for the master catalog. If
not, then SEO URLs cannot be constructed for categories in your master catalog.
Note: SEO URLs for products are always constructed with the URLKEYWORD associated with the default catalog, regardless of the catalog that the product belongs to.
Search engine optimization (SEO) title and meta description (TMD) data for store web pages
Title and metadata information is valuable for allowing your store's pages to stand out on the internet. With the search engine optimization (SEO) feature for WebSphere
Commerce Version 7 Feature Pack 3, each web page in your store is provided with unique content to improve its ranking in search results.
The title and meta description data is comprised of the following elements:
Page title
The page title appears in the browser title bar For example: Large Adjustable Desk Lamp | Madisons
Meta description
Search engines commonly use the meta description on search result pages to provide a concise explanation of the contents of the current web page. The meta
data description is an HTML attribute and is not displayed on the web page.
Meta keyword
The meta keyword is used for the static pages of your store, such as the contact us or help page. This allows for search engines to accurately rank and index the
web page. The meta keyword is an HTML attribute and is not displayed on the web page.
Image alt text
7/8/2013 11:59 AM
8 of 16
Image alt text describes the contents of an image for search engines to accurately rank and index the image. It is viewable by hovering over the image on the
web page and can be used for text-to-speech systems for the visually impaired.
Title and meta description templates

Use templates to generate the title and meta descriptions for your store pages. Use SEO substitution parameters in the template to create unique content from store data. A
different template is required for each page type in your store (for example, Contact us, Help, catalog entry pages or category pages). For more information on creating title
and meta description content, see: Enabling SEO title and meta description information for migration.
SEO property
Template using substitution parameters
Sample for a silver floor lamp in the

Madisons store
page title
<seo: ProductName/> | <seo: StoreName/>
silver floor lamp | Madisons
brown leather couch | Elite
image alt description
Image for <seo: ProductName/> from <seo:

StoreName/>
Image for silver floor lamp from

Madisons
Image for brown leather couch from Elite
Sample for a brown leather couch in the Elite store
Enabling SEO with sales catalogs and extended sites

If the search engine optimization (SEO) feature is enabled, when you create a new extended sites store and sales catalog, you must also manually create a token to store
the new URL keyword mapping for the SEO-friendly URL creation.
Every SEO-friendly URL uses a token that represents the combination of store and catalog in its construction.
Update the SEOURL and SEOURLKEYWORD tables with new tokens when you create the following stores or catalogs:
A new sales catalog in the extended sites catalog asset store and you want to use this sales catalog with the existing extended sites stores. A token is needed for new
sales catalog plus existing extended site store
A new extended sites store with a catalog asset store that has existing sales catalogs. A token is required for the new extended sites store and the existing sales
catalog combination
Procedure
1. Ensure that your SEOURL table has a Store/Catalog token entry for the master catalog. If the master catalog is missing, add the token to the SEOURL and
SEOURLKEYWORD tables with these SQL statements:
INSERT INTO seourl (seourl_id, tokenname, tokenvalue) values (<seourl_id>, 'StoreToken:CatalogToken', '<storeId>:<masterCatalogId>');
INSERT INTO seourlkeyword (seourlkeyword_id, seourl_id, language_id, storeent_id, urlkeyword) values (<seourlkeyword_id>, <seourl_id>, <langId>
For example:
INSERT INTO seourl (seourl_id, tokenname, tokenvalue) values (-2000, 'StoreToken:CatalogToken', '11051:10001');
INSERT INTO seourlkeyword (seourlkeyword_id, seourl_id, language_id, storeent_id, urlkeyword) values (-2000, -2000, -1, 0, 'Saturn IT Master');
Note: For <storeid>, use the store id of your Extended Sites Catalog Asset Store. To find the store id, run the following SQL statement:
select * from storeent;
2. For each WebSphere Commerce extended sites store, issue the following SQL statement. This statement adds a Store/Catalog token to the SEOURL table.
INSERT INTO seourl (seourl_id, tokenname, tokenvalue) values (<seourl_id>, 'StoreToken:CatalogToken', '<storeId>:<salesCatalogId>');
For example:
INSERT INTO seourl (seourl_id, tokenname, tokenvalue) values (201, 'StoreToken:CatalogToken', '11251:10401');
Important:
Ensure that you use the token name StoreToken:CatalogToken
Ensure that the token values are <storeId>:<salesCatalogId>, where <storeId> is the store id of your extended site store.
3. For each WebSphere Commerce extended sites store, issue the following SQL statement. This statement adds a URL keyword to the SEOURLKEYWORD table that
represents both the store id and the catalog id:
INSERT INTO seourlkeyword (seourlkeyword_id, seourl_id, language_id, storeent_id, urlkeyword) values (<seourlkeyword_id>, <seourl_id>, <langId>, 0, '<url
For example:
INSERT INTO seourlkeyword (seourlkeyword_id, seourl_id, language_id, storeent_id, urlkeyword) values (201, 201, -1, 0, 'teststore');
Note:
The store URL keyword must be set up for every sales catalog that is available for the store. If it is not setup, dynamic URLs are constructed when the store is
viewed with that particular sales catalog. When you set up the URL keyword, ensure that you set the storeent_Id to '0'
Care must be taken in the SEOURLKEYWORD table when stores use multiple languages. The URL keyword is looked up in the following manner:
a. The language Id that is specified in the urlLangId parameter during construction.
b. If the keyword does not exist for the urlLangId, then the store default language is looked up.
c. Otherwise, by default, -1 is looked up.
So, if your store supports multiple languages, be sure to maintain keywords in at least one of those three locales.
The SEOURL_ID can be reused for multiple SEOURLKEYWORDs (for different languages) in the same store, but do not reuse SEOURL_ID values across multiple
stores.
4. Repeat step 2 and step 3 for each additional WebSphere Commerce extended sites store that you want SEO enabled.
5. Refresh the SEOConfigurationRegistry.
Results
All extended sites stores now have SEO-friendly URLs.
URL redirects for SEO Overview

Part of the search engine optimization (SEO) solution for WebSphere Commerce Feature Pack 3 includes 301 redirection. If a URL is changed either by WebSphere
Commerce or a business user, a redirect is automatically generated between the original URL and the new URL.
URL redirects are implemented in the following cases:
When the URL of a catalog entry, catalog group or static page is updated, a redirect is automatically generated between the original URL and the new URL.
When an extended-site URL for a catalog entry or catalog group is created, the asset store URL is duplicated to the extended site. Then, a redirect is created between
7/8/2013 11:59 AM
9 of 16
the extended site duplicate of the asset store URL and the new URL
When an extended-site URL is cleared for a catalog entry or catalog group, a redirect is created between the extended site URL and the asset store URL
In all of the above cases, if the URL of a catalog entry or a catalog group is updated multiple times, then all previous redirects are updated to point to the latest URL for that
catalog object. This way, redirection chains are avoided.
You can create a 301 redirect in different ways. A common method is to set up web server mod rewrite rules in the web server configuration file. This method might require
many redirect rules - a rule for each category and product on the site. Usually, it is impossible to create a single redirect rule to handle every redirect to SEO URLs. Another
method is to customize the web application layer to automatically redirect the URLs. For more information see, Redirecting legacy URLs to SEO friendly URLs in WebSphere
Commerce.
Traffic statistics for URL redirects

Traffic statistics are recorded for individual redirect mappings. These statistics are stored in the SEOREDIRECTTRAFFIC table.
This table contains the last used date of each redirect mapping, and the number of times that the redirect mappings are used.
There is no user interface to view these statistics; however, you can create a custom user interface to review the following importation traffic data:
When search engines, affiliate links, and customer personal bookmarks are still referring to old URLs for your catalog entries or catalog groups.
To delete old URLS from the database to improve system performance.
To improve performance, traffic statistics for 301 redirects are not sent to the database each time a redirect rule is applied. Instead, the data is stored in a cache, and is
flushed to the database only when a certain number of redirects has occurred. You can specify the number of redirects by using to the redirectHitCountBatchUpdateSize
parameter in the SEORuntime section of the wc-admin-component.xml infrastructure configuration file.
Removing unused URLs

When redirect mappings are infrequent, you can safely delete both the mapping to the target URL and the original URL to decrease your database footprint. You can remove
any unused redirected URLs automatically after 60 days by running a scheduler job. Sixty days is the default number but you can change it by setting the numberOfDays
value in the SEORuntime section of the wc-admin-component.xml infrastructure configuration file.
Retrieving SEO substitution parameters for populating the Management Center UI

A substitution parameter is SEO-generated content consisting of the desktop URL keyword, page title, meta description and image alt text. After a product is created, saved
and Management Center is refreshed, the substitution parameters for the product will appear in the Search Engine Optimization tab on the product page.
The SEOConfigurationRegistry is used to retrieve substitution parameters. The service returns the following substitution parameters based on the store ID specified:
All the substitution parameters defined for the specific store.
All the substitution parameters defined for the related stores. The store relationship used here is com.ibm.commerce.view.
All the substitution parameters defined for the site.
Because the substitution parameters are not changed frequently, a new registry is created to cache the substitution parameter entries on server startup. The registry also
allows developers to add new substitution parameters or change the implementation of a substitution parameter without restarting the server. The class name for the
registry is SEOConfigurationRegistry. The registry supports two main methods:
getAllSubstitutionParametersApplicableForStore(Integer storeId): This method retrieves all the substitution parameters applicable for the store. This method
is mainly used by the configuration service to return the parameters applicable.
getSubstitutionParameterEntryByNameAndStore(String paramName, Integer StoreId): This method returns the substitution parameter entry given the
parameter name and the store. It is mainly used by the helper class which parses the templates to find the appropriate implementation class for the parameter name
and store Id combination.
Customizing the SEO component configuration properties

Some search engine optimization (SEO) components have customizable configuration properties. These configurable properties control certain component features.
To change any configuration SEO properties, you must change the properties within the infrastructure component (wc-admin-component.xml) configuration file. This
infrastructure component configuration file contains properties that are related to configuring and customizing SEO features. For more information about changing the
properties that are contained in this file, see Changing configuration properties for the Infrastructure component.
To review the components that are contained within the infrastructure component configuration file, see Configuration properties in the infrastructure component.
SEO with Rich Snippets

Search engines help users find relevant results by showing a summary of content from web pages that match the search query. The summary of content is called search
result snippets. To help users understand the content your web page provides and to improve SEO, you can implement rich snippets to highlight important content from
your web page to display in the search result snippet.
You can highlight different content to display in the search result snippet such as:
Product name.
Description.
Price.
Availability.
Review.
For example, you can modify the content that is displayed in a search result to show the rating of a dress as shown in the following image.
Implementing Rich Snippets

To add Rich Snippets support to your existing non-Aurora store, you must update your store JSP files. For more information, see http://www.ibm.com/developerworks
/websphere/tutorials/1108_wan/
There are various ways to mark up data for rich snippets. You can use:
7/8/2013 11:59 AM
10 of 16
Microdata specification
schema.org specification
The web pages in your Aurora starter store use microdata format to mark up the content. The following code shows an example of the tags that are used in your JSP files
to mark up the product name, description, price, availability, and review of a product.
<div itemscope="itemscope" itemtype="http://data-vocabulary.org/Product">
<span itemprop="name">Sleek Occasional Table</span>
<span itemprop="description">
The sleek styling makes this occasional table a perfect addition to your home.
Made of oak wood with a tempered glass top and forest green-finish wood frame.
Measures 48" in width, 24" in length, and 19" in height.
Some assembly required.
</span>
<span itemprop="offerDetails" itempscope itemtype="http://data-vocabulary.org/Offer">
Regular price: $
<span itemprop="price">179.99</span>
<span itemprop="availability" content="in_stock">
In stock! Order now!
</span>
</span>
<span itemprop="review" itemscope
itemtype="http://data-vocabulary.org/Review-aggregate">
<span itemprop="rating">4.4</span> stars, based on
<span itemprop="count">89</span> reviews
</span>
</div>
The following code shows an example of the tags that are used to mark up the product name, description, price, availability, and review of a product in schema.org format.
<div itemscope itemtype="http://schema.org/Product">
<span itemprop="name">Sleek Occasional Table</span>
Product description:
<span itemprop="description">
The sleek styling makes this occasional table a perfect addition to your home.
Made of oak wood with a tempered glass top and forest green-finish wood
frame. Measures 48" in width, 24" in length, and 19" in
height. Some assembly required.
</span>
<div itemprop="offers" itemscope itemtype="http://schema.org/Offer">
<span itemprop="price">$179.99itemprop="price">$179.99</span>
<span itemprop="availability" href="http://schema.org/InStock" content="in_stock"/>
In stock
</span>
</div>
<div itemprop="aggregateRating" itemscope itemtype="http://schema.org/AggregateRating">
Rated <span itemprop="ratingValue">4.4itemprop="ratingValue">4.4</span>/5
based on <span itemprop="reviewCount">89</span> customer reviews
</div>
<div>
To test how your pages appear in Google search results, see Rich Snippets Testing Tool
Search engine optimization (SEO) for WebSphere Commerce Version 7 to Feature Pack 2
Search engines, such as Google, are considered to be one of the most important channels for a site to reach new customers. To build a loyal customer base, the first step is
to reach new customers and search engines provide an effective way to reach new customers.
Dynamic, database-driven URLs, such as those generated by WebSphere Commerce, contain stop characters (?, &, and %) that can easily overwhelm search engine
crawlers. For this reason, search engines limit the amount of dynamic URLs that they index. To overcome this limitation, WebSphere Commerce provides functionality to
help improve the results of search engine indexing.
WebSphere Commerce's search engine optimization feature consists of the following functions:
1. URL mapping that provides the ability to remove the stop characters by mapping WebSphere Commerce's dynamic URLs to static ones so that search engines can
index the dynamic pages.
2. Site map capability that provides an entry point for the search engine crawler to easily follow the links within your Web pages.
3. Page content optimization that facilitates keyword modification so that the page is ranked high in search engine results. It provides the ability to easily modify words
in the locations that are important for crawlers, by using the Product Management GUI, or by using the Change Pages GUI in WebSphere Commerce Accelerator.
We have provided the functionality to remove the inhibitors so that your Web pages can be indexed by search engines and to facilitate the optimization of page content.
The ranking of your pages in the search results depends largely on how you optimize your pages.
URL Mapping
The URL mapping function allows Web pages to be accessed through a static looking URL by converting the URL from static to dynamic based on a mapping file:
7/8/2013 11:59 AM
11 of 16
For example, it can map the following static URL:

webapp/wcs/stores/servlet/product_10001_10001_10032_-1
to the following dynamic WebSphere Commerce URL:
webapp/wcs/stores/servlet/ProductDisplay?storeId=10001&catalogId=10001&productId=10032&langId=-1
Site Maps
A site map is used to address these two challenges:
Changes to the site are not quickly reflected in the search engine indices.
Most Web pages are designed for human visitors, not crawlers, and the design can reject crawlers due to an excessive number of graphics and large page size.
A site map helps to optimize the entire structure of the site for a crawler by providing an alternative set of Web pages built specifically for crawlers to quickly access and
index a large number of embedded pages. Site maps facilitate deep searches of the site. A deep search is when a crawler visits and indexes pages that are deeply embedded
within the site, for example, product pages that are lower in the hierarchy of the site. The following image shows how the site map function is implemented:
An effective site map is built as a high level overview of the different pages in the site and presents a large list of links to the crawler in as few pages as possible. For
example, a site map starter page can list the top categories and the categories directly under the top categories (second level categories), or even third level categories.
This reduces the number of clicks that it takes to get to any page on the site from the site map and also helps customers to navigate through the site, especially those
customers with slower internet connections. As a result, it reduces the time that it takes for the content refresh to be reflected in the search engine. As new content and
products are added to the site, the site map becomes the easiest way to bring this content forward to be indexed by crawlers.
The following image is an example of a site map starter page for a Madisons starter store page that contains links to the main category pages and their product pages.
7/8/2013 11:59 AM
12 of 16
Note: It is possible that the site map might affect positioning within search results in search engines such as Google, as if the search engine finds two URLs that link to the
same content, they might rank that result lower if it assumes the site is attempting to manipulate the search algorithms in repeatedly discovering the same content. If you
discover this to be the case, you might want to reconsider how you deploy your site's site map.
Optimization of page content for search ranking

There are many different factors that search engines use to determine the ranking of pages. Search engines have crawlers that follow the links in a site's Web pages, collect
the content from Web pages, and analyze the content by conducting sophisticated pattern matching.
When a search engine analyzes a page, some specific locations are given more weight than others. It is important to put appropriate keywords in these locations. Some of
the locations that are ranked high in search results are:
Page title
The page title is the text that appears in a browser's title bar. The page title tag is an important consideration in how searches are ranked. Put the most
commonly searched keywords in the title.
Page heading
The page heading is also an important place for keywords that are used by search engines.
First sentence of the body
Use words in the first sentence that describe the purpose of the page and attract visitors to click on this entry in the search results page.
WebSphere Commerce helps you optimize your page content by providing the Change Pages function and the Product Management tool to allow marketing personnel to
easily update text in these locations.
Caching considerations
Dynamic URLs can take full advantage of caching. They can use either WebSphere dynamic caching at the Application Server, or edge caching, including the WebSphere ESI
plug-in at the Web Server and the caching proxy in WebSphere Edge Components. Static URLs can only use WebSphere dynamic caching at the Application Server.
Optimizing your site for search engines

You can optimize your site for search engines, using techniques to make your site easier to index by a search engine.
Before you begin
Ensure that your JSP pages can use search engine optimization. To facilitate optimization of web page locations that are given more weight by search engines when
ranking search results, use the tools described in Updating page content.
If you will use the provided Perl scripts to convert dynamic URLs in JSP pages to static URLs, ensure that your target system has Perl version 5.6 or later installed,
along with the following Perl modules:
HTML::Parser
URI::URL
XML::XPath
File::Find
File::Path
Cwd
Procedure
1. Enable URL mapping.
7/8/2013 11:59 AM
13 of 16
a. Open the WebSphere Commerce configuration file.

b. Ensure that the UrlMapperConfig component is enabled, as shown in the following example:
<component compClassName="com.ibm.commerce.datatype.UrlMapperConfig"
enable="true"
name="UrlMapperConfig">
<property UrlMapperFile="mapper/SEOUrlMapper.xml" display="false" />
</component>
2. Deploy the updated WebSphere Commerce configuration file.
3. Identify the JSP pages that you want the search engine to index. Usually, these are catalog-related pages such as ProductDisplay and CategoryDisplay.
4. Optional: Create a site map.
a. Create a subdirectory for the site map pages; for example: workspace_dir\Stores\Web Content\store
b. Copy each of the JSP pages that you identified in step 4, including any pages contained in them, into the SiteMap subdirectory.
You can now perform any further optimization, including conversion to static URLs in step 7, on the site map pages in place of the original pages.
5. Add URL mappings to the URL mapping file.
a. Open the SEOUrlMapper.xml file. Its location is specified in the WebSphere Commerce configuration file and defaults to the WC_eardir/xml/mapper directory.
b. If you are using a site map, specify the location of the SiteMapsubdirectory with the subDirectory attribute of the pathInfo_mappings element. For example:
<pathInfo_mappings separator="_" subDirectory="SiteMap">
WebSphere Commerce adds the subDir=SiteMap name-value pair, which indicates that the site map JSP pages are located in the SiteMap directory, to the set of
properties associated with the current request.
c. Create or modify a pathInfo_mapping element for each command associated with the JSP pages that you identified in step 4. Typically, these commands are:
ProductDisplay
CategoryDisplay
TopCategoriesDisplay
StoreCatalogDisplay
For example, the ProductDisplay command:
webapp/wcs/stores/servlet/ProductDisplay?storeId=10001&catalogId=10001&productId=10032&langId=-1
should map to
<mappings>
<pathInfo_mappings separator="_" ... >
<pathInfo_mapping name="product" requestName="ProductDisplay">
<parameter name="storeId" />
<parameter name="catalogId" />
<parameter name="productId" />
<parameter name="langId" />
</pathInfo_mapping>
...
</pathInfo_mappings>
</mappings>
Note:
Use the underscore (_) as a separator. If all your JSP pages use absolute paths when referencing URLs and images, you can use forward slash (/) as a separator.
Examples of absolute and relative path are as follows:
absolute path
<a href="../topic/com.ibm.commerce.seositemap.doc/tasks//webapp/wcs/stores/servlet/CategoryDisplay?storeId=10001 ... >
relative path
<a href="../topic/com.ibm.commerce.seositemap.doc/tasks/CategoryDisplay?storeId=10001 ... >
Avoid using reserved URL characters such as &, +, :, ?, and ; when setting your separator. These reserved characters have special meanings and can result in
the web server and application server improperly processing these characters.
While the hexadecimal values of such characters (such as using %3a to represent the : character, etc.) can appear to yield satisfactory initial results, unexpected
errors can still occur over additional applications of its same usage. Use the previously mentioned separators when setting your separator.
6. If you are using a site map, set up separate caching for the site map pages. For each command associated with the JSP pages that you identified in step 4, add a
component element with the ID of subDir to the cachespec.xml file of your site. As an example, the portion of the cachespec.xml file that pertains to the
TopCategoriesDisplay command should now look as follows:

<cache-id>
<component id="" type="pathinfo">
<required>true</required>
<value>/TopCategoriesDisplay</value>
</component>
<component id="storeId" type="parameter">
</component>
<component id="catalogId" type="parameter">
</component>
...
<component id="subDir" type="parameter">
</component>
<component id="DC_lang" type="attribute">
</component>
<component id="DC_curr" type="attribute">
</component>
...
</cache-id>
7. Convert JSP pages with dynamic URLs to JSP pages with static URLs by using any of the following methods:
a. URL Mapping Perl Script for standard JSP (urlmapping.pl)
Prerequisite: Perl application is installed and executable on your machine
Command syntax
perl WC_installdir/samples/urlmapping/bin/urlmapping.pl URL_Mapping_File target_directory starting_directory
7/8/2013 11:59 AM
14 of 16
or
perl WC_installdir/samples/urlmapping/bin/urlmapping.pl URL_Mapping_File target_directory file
Parameters
URL_Mapping_File
The name of the URL Mapping file.
target_directory
The directory where the JSP files will be output.
starting_directory
The name of the directory containing the dynamic JSP files.
file
The name of a specific file to convert.
Command line example:
URL mapping example:
Original a:href URL syntax:
CategoryDisplay?catalogId=<%=catalogId%>&categoryId=<%=category.getCategoryId()%>&storeId=<%=storeId%>
Converted a:href URL syntax:
Category_<%=catalogId%>_<%=storeId%>_<%=category.getCategoryId()%>
Limitations: This script does not handle JSTL or tags generated dynamically by either Java or other scripts such as out.println("<a
href=\"AugInterest?aucItemId=<%=aucId%>\">")
b. URL Mapping Java Application for JSTL (URLMappingConvertor)
Prerequisite: Java executable is allowed to run in the command prompt window or Unix terminal
Command syntax:
java com.ibm.commerce.util.URLMappingConvertor URL_Mapping_File target_directory
Parameters
URL_Mapping_File
The name of the URL Mapping file.
target_directory
The directory where the JSP files will be output. The JSP files in all subdirectories under this target_directory will also be updated.
Important: Ensure that the classpath parameter is set. If the classpath parameter is not set, you will get ClassNotFound exceptions. For example:
java -classpath Enablement-BaseComponentsLogic.jar com.ibm.commerce.util.URLMappingConvertor URL_Mapping_File target_directory
Command line example:
java com.ibm.commerce.util.URLMappingConvertor WC_eardir/xml/mapper/SEOUrlMapper.xml SiteMap
URL mapping example:
Original <c:url> tag syntax:
<c:url var="TopCategoriesDisplayURL" value="TopCategoriesDisplay">
<c:param name="storeId" value="${WCParam.storeId}" />
<c:param name="catalogId" value="${WCParam.catalogId}" />
<c:param name="langId" value="${langId}" />
</c:url>
Converted <c:url> tag syntax:
<c:url var="TopCategoriesDisplayURL"
value="TopCategoriesDisplay_${WCParam.storeId}_${WCParam.catalogId}_${langId}" />
Limitations:
Any tags other than <c:param> within <c:url> are ignored. For example:
<c:url var="ProductDisplayURL" value="ProductDisplay">
<c:param name="productId" value="${product.productID}" />
<c:param name="langId" value="${langId}" />
<c:param name="storeId" value="${WCParam.storeId}" />
<c:param name="catalogId" value="${WCParam.catalogId}" />
<c:if test="${ !empty WCParam.parent_category_rn }" >
<c:param name="parent_category_rn" value="${WCParam.parent_category_rn}" />
<c:param name="view" value="imageView" />
</c:if>
</c:url>
becomes:
<c:url var="ProductDisplayURL" value="ProductDisplay_${product.productID}_${langId}_${WCParam.storeId}_${WCParam.catalogId}_
${WCParam.parent_category_rn}"">
<c:param name="view" value="imageView" />
</c:url>
This script does not handle standard JSP tags or tags generated dynamically by either Java or other scripts. For example:
out.println("<a href=\"AugInterest?aucItemId=<%=aucId%>\">").
c. Manually, change the dynamic URLs in JSP pages to static URLs.
8. If you are using a site map, include a link to the site map starting page from the header, footer, or sidebar.
Updating page content

WebSphere Commerce helps you optimize your page content by providing several tools as part of the WebSphere Commerce Accelerator.
Page
Description
7/8/2013 11:59 AM
15 of 16
Product pages
For catalog entry and category pages, use the Product Management tools to set and appropriate data bean methods to display content in your JSP pages.
In particular, to change the product information, use the Catalog Entry page, as described in Changing a product. Use the appropriate fields to store text
in the different page locations, as follows:
page title
Short Description field
heading
Auxiliary Description field
alt
second Auxiliary Description field
body
Long Description field
meta keyword tag
Keyword field
To display page content in strategic locations on your custom product JSP pages, use the getDescription() method of the ProductDataBean data bean.
Store Home
page
Use the Change Profile function of the WebSphere Commerce Accelerator, as described in Changing the store name and description.
Other pages
Use the Change Pages function of the WebSphere Commerce Accelerator, as described in Changing text in store pages and in notification messages.
WebSphere Commerce integration with sitemaps

In the past, to index your store pages, a search engine spider crawled through the website and indexed every page that it found. With the WebSphere Commerce
integration with site maps, you can create a sitemap XML file, sitemap_ storeID.xml that contains a list of URLs for your site. This way, customers are able to easily find
your site when they perform a search, increasing the probability of sales.
The sitemap_storeID.xml file is placed in the following directory:
WC_eardir/Stores.war
WCDE_installdir/workspace/Stores/WebContent
The location of the file is submitted to the search engine to index all of the URLs in the sitemap_storeID.xml file. Select one of the following links for information about
submitting the location of the file to the search engine:
Google
Yahoo!
The WebSphere Commerce integration with sitemaps is made up of two parts:
A sample site map JSP file that can be used to generate the content of a search engine sitemap XML file. The content is the URL that you want to index, such as the
Catalog, Contact Us, and Help pages. For more information about sample site map JSP files, see Site map integration template.
A SitemapGenerate command that compiles the JSP file, and optionally validates and saves the search engine sitemap XML file. You can schedule the job to run
regularly. For example, you can schedule it to run at night, to sync with your catalog update schedule. There is one sitemap_storeId.xml file per store. However, if
your sitemap XML file exceeds the number of URLs or size that is outlined in the Sitemap Protocol v0.9, the file splits into several different files. If there is no split,
sitemap_storeId.xml.gz is generated. When there is a split, sitemap_storeId.xml.gz is the index file and sitemap_ storeId_i.xml.gz are the sitemap files. The
site map files are numbered sequentially. For more information about the SitemapGenerate command, see Customizing site maps integration. For more information
about scheduling a SitemapGenerate job, see Creating and scheduling the SitemapGenerate job.
Customizing site maps integration

Sample site map JSP files are provided and located under the root of each store, for example, WC_eardir/Stores.war. If your store is not customized, use this sample to
customize your site maps. If your store is customized, for example you have any URLs that contain additional parameters or if there are new commands or views that are
not in the starter stores, you must update the sample site map JSP file in order to generate the correct URLs.
Procedure
When the SitemapGenerate command is executed, the following actions are performed:
1. Writes the content of the rendered JSP file to a temporary location. The command creates a raw site map.
2. Optional: Validates the content. If the value of the validation_ i parameter is true, the JSP file must contain xsi:schemaLocation; otherwise the command fails. If
the validation_i parameter is set to true, a validation check is performed by the predefined command against the defined site map XML schema.
For example, if we run SitemapGeneratecmd?validation=true&..., and the generated site map contains the schema information that is shown below, the generated
site map is validated against the defined schema.
<?xml version='1.0' encoding='UTF-8'?>
<urlset
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.sitemaps.org/schemas/sitemap/0.9
http://www.sitemaps.org/schemas/sitemap/0.9/sitemap.xsd"
xmlns="http://www.sitemaps. org/schemas/sitemap/0.9">
<url>
...
</url>
</urlset>
3. Performs post-processing on the created raw site map, such as splitting a large site map into smaller ones with site map index files. If there is no split,
sitemap_storeId.xml.gz is generated. When there is a split, sitemap_storeId.xml.gz is the index file and sitemap_storeId_i.xml.gz are the site map files. The
site map files are numbered sequentially.
4. Validates the created site maps. A site map can be split into smaller pieces plus an index file after post-processing in step 3. Therefore, the validation is repeated to
ensure that the split files and the generated index file are valid according to the defined schemas.
5. Adds the created site maps to the EAR file. The IEARUpdater Java class is called to update the EAR file and the master EAR (collapsed EAR) so that all nodes are
updated properly.
Site map integration template
7/8/2013 11:59 AM
16 of 16
Use the Sitemap.jsp file to generate all of the URLs that you want a search engine, such as Google, to index. The .jsp file is located under the root of each store for which
you have generated a site map; for example, WC_eardir /Stores.war.
The Sitemap.jsp file uses a storeId, or a list of catalog IDs as its parameters, and generates URLs that access all the categories and catalog entries of the store, in all the
languages supported by the store. The Sitemap.jsp files provided are samples based on the URLs in the ConsumerDirect and AdvancedB2BDirect starter stores only. You can
add or update any URLs in these files provided that they conform with the Sitemap Protocol v0.9.
If you have customized your store, and have to create your own Sitemap.jsp file, you must adhere to the following conventions outlined at the Sitemap Protocol v0.9 web
site:
The Sitemap.jsp file must be encoded in UTF-8.
Each URL must be absolute such as http://example.com.
Use the W3C Date and time formats such as YYYY-MM-DD.
All URLs should be properly escaped using entity escape codes, and follow the RFC-3986 standard for URIs, the RFC-3987 standard for IRIs, and the XML standard.
The generated site map does not contain URLs that start with HTTPS protocol. URLs starting with https are ignored if they are in a site map whose URL starts with
http, and vice versa. For example, if the site map is under http://example.com, any URL that starts with https://example.com in the site map is ignored. To avoid
incomplete crawling, you must list only one type of URL.
If the catalogIds are not passed by the command, the master catalog for the store is used to generate the URLs. In the following example the catalogIds are provided,
and the site map is generated using the URLs of the pages in those catalogs.
/Sitemap.jsp?storeId=10101&catalogIds=10101,10151&hostName=chutes.torolab.ibm.com
Where:
storeId_i
The ID of the store for which the site map is generated, such as 10101.
catalogId_i
The catalogId for a store with storeId_i. Multiple values can be provided for the same i, such as catalogId_i=value1&catalogId_i=value2
hostname
The host name of the production server later used to host the sitemap.xml files. This parameter is required when the command is executed on a staging
server and the sitemap.xml file is hosted on a production server. Specify the host name as name.domain .
The following example shows how a Sitemap.jsp generates an XML file:
<?xml version="1.0" encoding="UTF-8"?>
<urlset
xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
<url>
<loc>http://www.example.com/</loc>
<lastmod>2005-01-01</lastmod>
</url>
</urlset>
Where:
<loc>
URL of the page. All the URLs that the merchants want the Google search engine to index. The following views are included in the site map for WebSphere
Commerce:
TopCategoriesDisplay
CategoryDisplay: the URLs for CategoryDisplay are generated for each top category and subcategory.
ProductDisplay: the URLs for ProductDisplay are generated for each product, item, bundle, and package.
PrivacyView
ContactView
HelpView
<lastmod>
The date the JSP page was modified last. For the CategoryDisplay page, the field LASTUPDATE of the table CATGROUP can be used as the last modification date.
For the ProductDisplay page, the field LASTUPDATE of the table CATENTRY can be used as the last modification date.
7/8/2013 11:59 AM

Searchengineoptimizationseo 130820015428 Phpapp02

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Searchengineoptimizationseo 130820015428 Phpapp02

Uploaded by

Copyright:

Available Formats

Search engine optimization (SEO)