So your friendly marketing executive calls to say he needs a Vanity URL for a page on your AEM hosted site. And you cringe. How do you get this done right without getting penalized by Search Engines? Should you do this at the Load Balancer level? Within AEM Dispatcher configurations? within AEM Publish instance? What about horizontal replication of these configurations? And oh, who’s going to maintain this? It’s not like your Dev Ops team is necessarily twiddling their thumbs waiting for work.
This post will address a few different ways to accomplish Vanity URLs within an Adobe AEM implementation and discuss some pros and cons.
Most well-architected AEM implementations have a 80-20 or even a 90-10 rule. ie., serve 80 or 90% of web traffic from your Dispatcher without hitting the AEM publish instance. That means it is best to implement URL rewrites (ie., Vanity URLs) at the Webserver or the Dispatcher level.
Here’s a good resource on how it can be done using in Apache HTTP server (note that this has nothing to do with Adobe AEM):
http://httpd.apache.org/docs/2.0/misc/rewriteguide.html
However, if you want to approach this entirely from an AEM product stack perspective, you can achieve that as follows.
1. Setting Vanity URLs within the AEM page properties:
Here’s a screenshot that shows how the Vanity URL for a page is set. This is a great technique WHEN you are fine with the content authors having the ability to change this property.
In addition CQ5 provides the “Alias” page property. See screenshot below.
Aliases do not change the path to the page, but rather provide an alternate name to the page. For example, this is useful when you would like the pagename to be different in different languages.
2. Now, let’s say you are positive that you do not want your content team making changes to vanity URLs or Aliases, you could rely on Apache Felix (the underlying application server that hosts your Publish and Author instance). These configurations are typically only allowed for Administrators. The following screenshot of the Sling Resource Resolver should help you with this configuration.
Programmatically, you may access the mapping like so:
resourceResolver.map(slingRequest,path);
3. Now, there’s yet another way to accomplish rewrites within AEM, which is to configure your /etc/map. Here are the steps:
1. configuration tree located below /etc/map
2. create a new folder: type sling:Mapping
3. define sling:match – partial regular expression which is used instead of the node’s name to match the incoming request
4. define sling:redirect or sling:internalRedirect depending on the type of redirect
I hope that gave you an idea on different ways in acheiving similar goals.
Until next time!