The Catalog pages can be bookmarked. Each collection or product page can be accessed via a re-written URL.

Example:

http://server:port/cameleonUI/en/myCat/Cat1…/descr-of-the-product.html?ref=

34ZERZEFDSFSC

It is possible to control the meta tags generated in the header of each collection / product pages of the Catalog.

Reference: Please refer to Indexing Policy chapter.

The rmoUserType specified in the indexing Policy is used to generate the page header.

• The RMO attached to a root configurableProduct is used to generate the meta tags of the corresponding configurable product page
• The RMO attached to a collection is used to generate the meta tags of the corresponding collection page
• The RMO attached to a standard item is used to generate the meta tags of the corresponding product page

SITEMAP AND ROBOT EXCLUSION STANDARD

Definition:

The Robot Exclusion Standard (or Robots Exclusion Protocol or robots.txt protocol) is a convention to prevent cooperating web spiders and other web robots from accessing all or part of a website which is otherwise publicly viewable.

A site map (or sitemap) is a list of pages of a web site accessible to crawlers or users. It helps visitors and search engine bots find pages on the site.

Several siteMaps can be listed and gathered in a robots.txt which will be the entry point of a search engine bot.

HOW TO CREATE THE SITE MAPS?

Pre-requisites

CPQ is able to manage the creation of robots.txt and siteMap.xml.

The list of ‘public’ catalogs have to be listed in a dedicated file: indexing.xml

Definition:

The indexingPolicy xml file (under $CPQ_HOME\conf) lists the catalogs for which we want to generate a siteMap.

For each catalog to be indexed, the following information has to be specified:

• list of internationalSettingsID (to generate URLs in order to access the catalog in several languages)
• [optional] the hostingContext. The value of this parameter corresponds to a service ID of type Catalog from the quote. It can be retrieved in cartServices.properties. (if the catalog is

  integrated into a hosting application, then the hosting context is used to retrieve the catalog.xml and catalogUI.xml – corresponding to the service ID - before calling the CPQUI web service).

  Example:

XML Sample

<indexingPolicy

xmlns="com.cameleon.framework.commons.log.messageCategories"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:schemaLocation="com.cameleon.framework.commons.log.messageCategories messageCategories.xsd">

<catalog workspace="xxxx" name="myCatalogl"

hostingContext="hostingCatalog1">

<settings>

<internationalSettings name='frenchSettings' />

<internationalSettings name='englishSettings' />

</settings>

</catalog >

<catalog workspace="wksCatalog2" name="catalog2"

hostingContext="hostingCatalog2">

<settings>

<internationalSettings name="englishSettings" />

</settings>

</catalog>

<catalog>

…

</catalog>

</indexingPolicy>

siteMaps generation mechanism

The siteMaps are generated per catalog version, once a version has been imported by the subscriber machine (1). The subscriber calls a WS on the CPQUI server (the address of the WS is specified in the cameleon.properties).

On the CPQUI server, the siteMaps of the imported version are generated based on the content of the indexingPolicy file (2) and the catalog.xml. The applicationDate corresponds to the activation date of the version.

One site map is generated per 1st level sub-collection. The siteMaps are gathered in a robot.txt.

The siteMaps and robot.txt of all versions are stored in a dedicated directory ($CPQ_HOME/indexing/) (3).

At runtime, when a user or a robot wants to access a site map (4), CPQ UI automatically retrieves the siteMap corresponding to the version which is active at the time of the access (5).