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 code snippet is a sample pattern definition for a privacy policy page URL:


Structures of pattern files

Pattern files are in this directory:

We can have more than one pattern file for a store, and each file is read in alphanumeric order. If any customization is 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 file is found, a lookup searches the store directories for a pattern file. The pattern file lookup continues until one of the following conditions is satisfied:

(Enterprise) In an extended sites store, the pattern file lookup first searches the store directories for the extended sites store. If no pattern file is found, the lookup then searches the asset store directories.


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. The keywords are also looked up to find the values that are 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.


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 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 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:

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, we can define token usages at the site level and are applicable to all the stores. We can add more usages to the default usage list. We 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 a hardcoded token name as the predefined store token.


Languages

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.

See Use new languages with SEO-friendly URLs.


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.


Related concepts
SEO
SEO-friendly URL deconstruction overview


Related reference
Creating descriptive storefront URLs when duplicate keywords exist