Advanced URL Configurations

AEM CIF Core Components provides advanced configurations to customize the URLs for product and category pages. Many implementations will customize these URLs for search engine optimization (SEO) purposes. The following video details how to configure the UrlProvider Service and features of Sling Mapping to customize the URLs for product and category pages.

Configuration

To configure the UrlProvider service according to the SEO requirements and needs a project must provide an OSGI configuration for the CIF URL Provider configuration.

Product Page URL Format

This configures the URLs of the product pages and supports the following options:

• {{page}}.html/{{sku}}.html#{{variant_sku}} (default)
• {{page}}.html/{{sku}}/{{url_key}}.html#{{variant_sku}}
• {{page}}.html/{{sku}}/{{category}}/{{url_key}}.html#{{variant_sku}}
• {{page}}.html/{{sku}}/{{url_path}}.html#{{variant_sku}}
• {{page}}.html/{{url_key}}.html#{{variant_sku}}
• {{page}}.html/{{category}}/{{url_key}}.html#{{variant_sku}}
• {{page}}.html/{{url_path}}.html#{{variant_sku}}

In the case of the Venia Reference store:

• {{page}} will be replaced by /content/venia/us/en/products/product-page
• {{sku}} will be replaced by the product’s sku, for example, VP09
• {{url_key}} will be replaced by the product’s url_key property, for example, lenora-crochet-shorts
• {{url_path}} will be replaced by the product’s url_path, for example, venia-bottoms/venia-pants/lenora-crochet-shorts
• {{variant_sku}} will be replaced by the currently selected variant, for example, VP09-KH-S

Since the url_path got deprecated, the pre-defined product URL formats use a product’s url_rewrites and pick the one with the most path segmenents as alternative if the url_path is not available.

With the above example data, a product variant URL formatted using the default URL format will look like /content/venia/us/en/products/product-page.html/VP09.html#VP09-KH-S.

Category Page URL Format

This configures the URLs of the category or product list pages and supports the following options:

• {{page}}.html/{{url_path}}.html (default)
• {{page}}.html/{{url_key}}.html

In the case of the Venia Reference store:

• {{page}} will be replaced by /content/venia/us/en/products/category-page
• {{url_key}} will be replaced by the category’s url_key property
• {{url_path}} will be replaced by the category’s url_path

With the above example data, a category page URL formatted using the default URL format will look like /content/venia/us/en/products/category-page.html/venia-bottoms/venia-pants.html.

Store Specific Configuration

The systen wide category and product page URL formats set by the CIF URL Provider configuration can be changed for each store.

In the CIF Configuration, an editor can select an alternative product or category page URL format. If nothing is selected there the implementation will fallback to the system-wide configuration.

Changing the URL format of a live website may have a negative impact on the organic traffic of your site. Please refer to the Best Practices below and carefully plan the change of the URL format in advance.

Category-Aware Product Page URLs

Since it is possible to encode category information in a product URL, products that are in multiple categories may be addressed with multiple product URLs as well.

The default URL formats will select one of the possible alternatives using the following scheme:

• if the url_path is defined by the e-commerce backend use it (deprecated)
• from the url_rewrites use those URLs that end with the product’s url_key as alternatives
• form these alternatives use the one with the most path segments
• if there are multiple, take the first one in the order given by the e-commerce backend

This scheme will select the url_path with the most ancestors, based on the assumption that a child category is more specific than it’s parent category. The so selected url_path is considered canonical and will always be used as the canonical link on product pages or in the product sitemap.

However, when a shopper navigates from a category page to a product page, or from one product page to another related product page in the same category, it is worthwhile to retain the current category context. In this case the url_path selection should prefer alternatives, that are within the current category context over the canonical selection described above.

This feature must be enalbed in the CIF URL Provider configuration. If enabled the selection will score alternatives higher, when

• they match parts of a given category’s url_path from the beginning (fuzzy prefix matching)
• or they match a given category’s url_key anywhere (exact partial matching)

For example, consider the response for a products query below. Given the user is on the “New Prodcuts / New in Summer 2022” category page and the store uses the default category page URL format, the alternative “new-products/new-in-summer-2022/gold-cirque-earrings.html” would match 2 of the context’s path segments from the beginning: “new-products” and “new-in-summer-2022”. If the store uses a category page URL format that only contains the category url_key, the same alternative would still be selected as it matches the context’s url_key anywhere. In both cases the product page URL would be created for the “new-products/new-in-summer-2022/gold-cirque-earrings.html” url_path.

{
  "data": {
    "products": {
      "items": [
        {
          "sku": "VA18-GO-NA",
          "url_key": "gold-cirque-earrings",
          "url_rewrites": [
            {
              "url": "gold-cirque-earrings.html"
            },
            {
              "url": "venia-accessories/gold-cirque-earrings.html"
            },
            {
              "url": "venia-accessories/venia-jewelry/gold-cirque-earrings.html"
            },
            {
              "url": "new-products/gold-cirque-earrings.html"
            },
            {
              "url": "new-products/new-in-summer-2022/gold-cirque-earrings.html"
            }
          ]
        }
      ]
    }
  }
}

Specific Category and Product Pages

It is possible to create multile category and product pages for only a specific subset of categories or products of a catalog.

Selection Criteria

The selection of a specific category page is straight forward, based on the category’s url_path or url_key. Matching sub-categories is supported only for URL formats that contain the full category url_path. Otherwise only an exact matching of the url_key is possible.

Specific product pages are selected either by the product’s sku or category. The later requires some category information to be encoded in the product URL. This is only available for some of the default URL formats. Please refer to the table below for a comparision which URL format supports specific page selection by sku or category.

Deep Linking

The UrlProvider is pre-configured to generate deep links to specific category and product pages on author tier instances. This is useful to editors, that browse a site using Preview mode, navigate to a specific product or category page and switch back to Edit mode to edit the page.

On publish tier instances on the other hand, catalog page URLs should be kept stable to not lose gains on search engine rankings for example. Because of that publish tier instances will not render deep links to specific catalog pages per default. To change this behaviour, the CIF URL Provider Specific Page Strategy can be configured to always generate specific page URLs.

Multiple Catalog Pages

When editors want to have full control of the top level navigation of a site, using a single catalog page to render the top level categories of a catalog may not be desired. Instead editors can create multiple catalog pages, one for each category of the catalog they want to include in the top level navigation.

For that use case, each of the catalog pages may have a reference to a product and category page specific to the category configured for the catalog page. The UrlProvider will use these to create links for the pages and categories in the configured category. However, for performance reasons only the direct catalog page children of a Site’s navigation root / landing page are considered.

It is recommended that the product and category pages of a catalog page are descendant to that catalog page, otherwise components like the Navigation or Breadcrumb may not work correctly.

Customizations

Custom URL Formats

To provide a custom URL format a project can implement etiher the ProductUrlFormat or the CategoryUrlFormat service interface and register the implementation as OSGI service. Those implementations, if available, will replace the configured, pre-defined format. If there are multiple implementations registered, the one with the higher service ranking replaces the one(s) with the lower service ranking.

The custom URL format implementations must implement a pair of methods to build a URL from given parameters, and to parse a URL to return the same parameters respectively.

Combine with Sling Mappings

In addition to the UrlProvider, it is also possible to configure Sling Mappings in order to rewrite and process URLs. The AEM Archetype project also provides an example configuration to configure some Sling Mappings for port 4503 (publish) and 80 (dispatcher).

Combine with AEM Dispatcher

URL rewrites can also be achieved by using AEM Dispatcher HTTP server with mod_rewrite module. The AEM Project Archetype provides a reference AEM Dispatcher config which already includes basic rewrite rules for the generated size.

Best Practices

Choose the best URL Format

As mentioned before selecting one of the available default formats, or even implementing a custom format, highly depends on the needs and requirements of a store. The following suggestions may help to make an educated descision.

Use a product page URL format that contains the sku.

The CIF Core Components use the sku as primary identifier in all components. If the product page URL format does not contain the sku, a GraphQL query is necessary to resolve it. This may impact the time-to-first-byte. Also, it may be desired, that shoppers can find products by sku using search enignes.

Use a product page URL format that contains the category context.

Some features of the CIF Url Provider are only available when using product URL formats, that encode the category context, like the category url_key or the category url_path. Even if those features may not be required for a new store, using one of these URL formats in the beginning helps to reduce migration efforts in the future.

Balance between URL length and encoded information.

Depending on the catalog size, in particular the size and depth of the category tree, it may not be reasonable to encode the full url_path of categories into the URL. In that case the URL length could be reduced by including only the category’s url_key instead. This will support most of the features that are available when using the category url_path.

Additionally, make use of Sling Mappings in order to combine the sku with the product url_key. In most e-commerce systems the sku follows a particular format and separating the sku from the url_key for incoming requests should eaesily be possible. With that in mind, it should be posible to rewrite a product page URL to /p/{{category}}/{{sku}}-{{url_key}}.html, and a category URL to /c/{{url_key}}.html respecitively. The /p and /c prefix are still necessary in order to distinguish product and category pages from other content pages.

Migrating to a new URL Format

Many of the default URL formats are somehow compatible with each other, meaing that URLs formatted by one may be parsed by another one. That helps migrating between URL formats.

On the other hand, search engines will need some time to re-crawl all catalog pages with the new URL format. To support this process and also to improve the end user experience, it is recommended to provide redirects that forward the user from the old URLs to the new ones.

One approach for that could be, to connect a stage environment to the production e-commerce backend and configure it to use the new URL format. Afterwards obtain the product sitemap generated by CIF products sitemap generator for both the stage and the production environment, and use them to create an Apache httpd rewrite map. This rewrite map can than be deployed to the dispatcher together with the rollout of the new URL format.

Example

The Venia Reference store project includes sample configurations to demonstrate the usage of custom URLs for product and category pages. This allows each project to set up individual URL patterns for product and category pages according to their SEO needs. A combination of CIF UrlProvider and Sling Mappings as described above is used.

Additional Resources

• Venia Reference store
• AEM Resource Mapping
• Sling Mappings

Business.Adobe.com resources