Problem: www.example.com and example.com are not the same
When configuring your native web delivery systems (your "Origin Server"), the front end should be configured in such a way as to ensure your domain (top level subdomain or SOA, i.e.; example.com) redirects to the traditional web serving subdomain (www.example.com) properly and optimally. Indeed, default configurations should include this structure.
This is a necessary and beneficial configuration feature:
- necessary – to ensure requests are passed to the Instart system, thus enabling our application delivery service to optimize client requests along with www requests.
- beneficial for SEO optimization, Google Analytics, etc. – the two names (www.example.com and example.com) are separate in the eyes of Google et. al. Without redirection at the application level, search results of interest to our customers will be diluted (spread across two separate “properties”) and thus potentially move them down in the search results order. Similarly, information returned from tracking tools like Google Analytics is also split into two reports.
- beneficial for performance – a small performance gain is to be had due to having redirection occur nearest the client (at our PoP) rather than traversing all the way back to the origin server, which will generally be less robust than the Instart PoP nearest the client. Thus the performance benefit, while normally small, is consistent.
Solution: Application-level edge redirection for top-level subdomains
Due to its high degree of configurability, the Instart application delivery service can be readily enabled to provide an application level redirection at the very front of the client request. This feature will cause all domain requests to be redirected to the www subdomain (or whichever subdomain is desired) without the need for the client to be sent all the way to the origin for the redirection. Additionally, this will cause bots to hit the same URL for SEO purposes. If the domain and the subdomain remain separate, two discrete versions of every object may be cached, and two separate paths are tracked. The configuration of redirection must be coordinated with the customer, and ideally is explained and configured during the Activation phase of customer onboarding.
Redirection can be readily configured for your SOA domain (example.com) upon request. You will need to obtain the anycast IP address related to your service, as you will need to update/modify your existing A-Record for the SOA domain (example.com IN A xxx.xxx.xxx.xxx) to indicate this address. Thus this needs to be coordinated with your Instart technical representative, so please do not implement this without first coordinating with us.
- If you are still in the activation phase of onboarding, please contact your Sales Engineer or his/her supporting team to let them know you require this feature to be enabled.
- If you are an existing customer, please open a ticket with Support and we will get this feature enabled for you.
|SSL NOTE||For SSL/HTTPS purposes, this redirection feature requires the inclusion of your (SOA) domain in our Global SAN Certificate, i.e.; example.com in addition to www.example.com or *.example.com (preferred).|