Skip to main content

URL Structure and Templating

A human-readable and SEO-friendly URL structure and template mechanism can improve the user experience by making it easier for users to navigate to the desired page or content, help search engines understand the content of the page and rank it appropriately, and reduce the risk of duplicate content by ensuring that each page has a unique URL accurately reflecting the content of the page.

The Ucraft Next system comprises the following page types:

  • Blank or Standard
  • Product
  • Category
  • Item

Each page type has defined human-readable and SEO-friendly URLs and templating mechanism.

Each of the system Blank pages has a unique alias, which makes it accessible on the Web.

Each Product and Collection Item, as well as Category, contains a field for a unique alias to be accessible on the Web.

If a product has more than one category, one of them is selected as the default (starred) to be used in the canonical URLs.

If a product is uncategorized, the product URL does not include the category alias, for example: www.example.com/e/ticket-one

Family Type Delimiters

The type of product family (e.g., product, event, digital, item) is part of the URL.
The uniqueness of the alias includes aliases from all entity types (e.g., pages, categories, products, and items).
The list of delimiters is presented below:

  • 'physical' => '/p/'
  • 'collection' => '/i/'
  • 'digital' => '/d/'
  • 'subscription' => '/s/'
  • 'booking_appointment' => '/a/'
  • 'booking_event' =>'/e/'
  • 'booking_table' => '/t/'
  • 'booking_rental' => '/r/'

URL Examples​

The domain of the website is www.example.com.

If there is a page with the alias "About Us," the URL is www.example.com/about-us.

If there is a category of books, then the URL is www.example.com/books.

If there is a product called "PHP Book" under the Books category, then the URL is www.example.com/books/p/php-book.

Here, the delimiter /p indicates the family type (physical) to which it belongs.

If the category has a parent, then the parent is also included in the URL.

www.example.com/books/math/p/php-book

Here, the delimiter /d indicates the family type (digital) to which it belongs.

www.example.com/music/classic/d/98-hits

If multiple categories are attached to the same product, it has multiple URLs. The URL, including the default category, is the canonical URL.
In cases where a product is uncategorized, the category part is omitted from the URL.
www.example.com/music/d/98-hits

📘 The same logic is also true for collections.

Templating

Templating is manipulated via categories and product families.

Every product family or collection has its own item template. The item template is used to render items for a specific product family or collection. Static templates for every product family type are generated when creating a project.

There are two root categories: one for products and one for collection items.

Root categories for products and collection items own one template each. The templates are the defaults for all the categories in the tree. The second-level categories (that are directly under the root) create their own templates. By default, the second-level categories inherit the template of the corresponding root category (i.e., collection item root category and product root category). Every child category inherits the template of its parent category.

When a parent category becomes a child category (move), the related templates are soft deleted.

Here is the diagram:

There is no need to create a category template when creating the second-level category. The template creation can be delayed and implemented on the Builder side when publishing the page. When the user modifies and publishes a category template for a second-level category, the Builder back end recognizes the change and creates a new template for the specific category with the given layout content.

The category templates are created for root categories (products and items) during project creation, and it is impossible to remove them.

The rest of the categories inherit the templates of their closest parents in the tree from bottom to top.

This inheritance is similar to the JavaScript prototype chain.

Suppose the category C is under the category B, and the category B is under the category A, and A is under the Root category.

If none of the categories overrides the template, then all the categories inherit the Root category template.

When category A overrides the template, then B and C get the new version of the template from category A (not from the Root).

Later, if we create the category D under the Root category and the category E under the category D, then both E and D inherit the Root template by default.

Implementation and Handling

When creating a product, category, collection item, or page, the entity URLs per the unique project names are stored in the distributed-store folder, which is shared between back-end servers and is the easiest place to access in Redis.
All product, category, collection item, and page aliases are stored in the aliases, which is a set that eliminates duplicates, thus ensuring uniqueness.

Each entity has its own paths: category-paths, item-aliases, page-paths, product-aliases and their reverses: category-paths-reverse, item-aliases-reverse, page-paths-reverse, and product-aliases-reverse.
paths stores the URLs used to access the given product, category, collection item, or page on the Web. The data is received according to the information included in the URL.
reverse is used to return the data according to the ID received.

Consequences

Positive:

  • Flexible URL management
  • Flexible template management

Negative:

  • The product family management (creation and removal) includes template management.
  • During category management, URLs and sitemap generation are applied.
  • After every URL modification, the Redis cache is cleared.