Vanities of Vanity URL

A Vanity URL is a short URL alias for an otherwise lengthy URL. Vanity URLs are friendly, easy to use and easy to remember.

For a page at /content/mysite/procuct-catalog/product1, a vanity URL can be defined as /product1 and instead of using the URL
http://host:port/content/mysite/procuct-catalog/product1.html
to access the Product1 page, it can be directly accessed through the url
http://host:port/product1

Defining vanity URL in AEM is simple and can be defined directly on the page by setting the Vanity URL page properties setting


Note that DAM assets does not provide option to define vanity URL. The vanity URL definition option is available only for pages. However, URL mapping through Sling Resource Resolver configuration can be used to assign URL alias for any JCR resource – including DAM.

Dispatcher caching
Vanity URLs do not follow any pattern and obviously does not fall into any meaningful hierarchy. Dispatcher needs to be specially configured to handle requests to vanity URL for the
- Allowing the requests to vanity URLs to pass through
- Response of the vanity URL requests to get cached

All vanity URLs would not be known at the time of dispatcher cache configuration setup as Vanity URLs can be authored and published any time.

The service to fetch list of all vanity URLs defined
/libs/granite/dispatcher/content/vanityUrls.html

This service provides a listing of all vanity URLs configured in the AEM instance. Use this service to configure the dispatcher to pull all vanity URLs periodically and use it for allowing the requests to pass through & for caching the response.

Check https://docs.adobe.com/content/help/en/experience-manager-dispatcher/using/configuring/dispatcher-configuration.html#enabling-access-to-vanity-urls-vanity-urls for detailed instructions for configuring dispatcher for vanity URL handling.

With the above configuration done, the request to the vanity URL passes through the dispatcher to the AEM instance. On AEM, the request gets processed to produce a response which gets returned to the dispatcher. The Dispatcher caches this response to serve for subsequent requests to the same URL.

So far so good. An issue arises in the mismatch between the path at which the cache gets created for vanity URLs and the path used for invalidating the cache on subsequent modifications.

Assuming the previous example of the resource at /content/mysite/procuct-catalog/product1 getting accessed through the vanity URL of /product1,

The dispatcher caches the response to the request /product1 at $docroot/product1. When the resource pointed to by this URL which is /content/mysite/procuct-catalog/product1 gets activated or deactivated, only the original path is sent in the invalidation request for the dispatcher. Thus the invalidation request to flush the dispatcher cache at /content/mysite/procuct-catalog/product1 would not correctly map to and flush the cache created at $docroot/product1

The solution options available for handling this case at the moment are

- Define /statfileslevel as 0. This would invalidate the complete cache on any page invalidation thus invalidating the cache of the vanity URLs as well
- Use custom invalidation scripts to implement your own logic
- Use TTL cache invalidation using /enableTTL configuration. This would invalidate the cache of vanity URLs based on expiry time and not immediately on page activation

Duplication of Vanity URL
It is up to the Author user to make sure that the Vanity URLs defined across pages are unique and do not get duplicated. AEM does not enforce unique vanity URL constraint. i.e., Author users can use the same vanity URL for more than one page.

When accessing through vanity URL one of the page that maps to the given vanity URL gets rendered. It’s usually the first page in the node hierarchy but for all practical purpose we can take it as one of multiple pages that maps to the given vanity URL gets picked up at random.

This could lead to serious issues of page breaking and wrong pages getting served. Be mindful of this issue and make sure proper review processes are put in place for controlled use if vanity URLs.

Refer https://blogs.adobe.com/contentmanagement/2012/08/27/how-to-prevent-users-from-entering-duplicate-vanity-urls/ which talks about putting in custom code to alert the Author user when entering duplicate vanity URLs

Launch copies of pages with Vanity URL
Launches created including pages with vanity URLs invariably results in duplicate copies of the page with same vanity URL. And we would ideally not want the vanity URL to be changed in the launch version of the page.

Design the workflow process for handling launches such that it is not impacted by vanity URL. Do not use Vanity URL to access the launch copy of the page – you cannot be sure which version of the page gets rendered when accessed through vanity URL

Live Copy / MSM
Vanity URLs do not work well with Live copy and MSM sites. Essentially Live copy and MSM sites are copies of main site and if the main site has pages with Vanity URLs we end up in scenario where multiple pages (main and copies of the page) having the same vanity URL.

Define and design carefully when Live Copy / MSM has to done including pages with Vanity URLs. Clearly define how the vanity URL should be handled for each of the copies.