Full Guide: Redirecting www to non-www in AWS
Maintaining a consistent URL structure is crucial for website management and search engine optimization (SEO). This guide explores five methods to redirect the "www" subdomain to the root domain (e.g., from www.cloudplexo.com to cloudplexo.com) using AWS services.
SEO Implications of www vs. non-www Redirects
The choice between www and non-www URLs, and implementing proper redirects, can significantly impact your website's SEO:
- Consistency: Search engines view www and non-www versions as separate URLs. Choosing one version and consistently redirecting to it prevents duplicate content issues, which can dilute your SEO efforts.
- Link equity: Proper redirection ensures that all link equity (ranking power) is consolidated to your preferred domain, rather than being split between www and non-www versions.
- User experience: Consistent URLs create a better user experience, which is a factor in SEO rankings.
- Canonical URLs: While using canonical tags can help, redirects are a stronger signal to search engines about your preferred domain.
- HTTPS considerations: If you're also moving from HTTP to HTTPS, implementing both changes simultaneously (e.g., from http://www.cloudplexo.com to https://cloudplexo.com) can be done with a single redirect, improving site speed.
- 301 vs. 302 redirects: For SEO purposes, always use 301 (permanent) redirects rather than 302 (temporary) redirects when standardizing on www or non-www. 301 redirects pass maximum link equity to the target URL.
- Crawl budget: Proper redirection helps search engines crawl your site more efficiently by avoiding unnecessary crawls of duplicate URLs.
- Analytics accuracy: Consistent URLs ensure more accurate tracking in analytics tools, providing better data for SEO analysis and decision-making.
When implementing any of the following redirection methods, ensure they result in proper 301 redirects to maximize SEO benefits. Also, after implementation, update your Google Search Console and other webmaster tools to reflect your preferred domain.
1. Amazon S3 and CloudFront
Implementation:
- Create two S3 buckets: one for the root domain (example.com) and another for the www subdomain (www.example.com).
- Configure the www bucket for static website hosting with a redirect to the root domain.
- Create a CloudFront distribution for the root domain.
- Set up another CloudFront distribution for the www subdomain, pointing to the www S3 bucket.
- Configure SSL certificates for both distributions using AWS Certificate Manager.
Pros:
- Scalable and cost-effective for static websites
- Leverages AWS's global CDN network
Cons:
- Requires management of multiple AWS services
- Not ideal for dynamic websites
2. Amazon Route 53 with Alias Records
Implementation:
- Create a hosted zone for your domain in Route 53.
- Create an A record for your root domain, pointing to your website's endpoint (e.g., EC2 instance or load balancer).
- Create another A record for the www subdomain, setting it as an Alias to the root domain record.
Pros:
- Simple setup and management
- Integrates well with other AWS services
Cons:
- Doesn't provide actual redirection, just resolves both to the same IP
- May not be suitable for true 301 redirects needed for SEO
3. Application Load Balancer (ALB)
Implementation:
- Create an Application Load Balancer in your VPC.
- Set up listeners for both HTTP (port 80) and HTTPS (port 443).
- Create two target groups:
- One for your main website (e.g., example.com)
- Another empty target group for the www subdomain (www.example.com)
- Configure listener rules: For the HTTP listener: a. Add a rule to redirect all HTTP traffic to HTTPS For the HTTPS listener: a. Add a rule to handle requests for www.example.com:
- Condition: host-header equals www.example.com
- Action: redirect to https://example.com/#{path}?#{query} b. Add a default rule to forward requests to your main website target group
Example rule:
IF (host-header == 'www.example.com')
THEN
redirect (https://example.com/#{path}?#{query})
Pros:
- Provides true 301 redirects
- Highly configurable and suitable for dynamic websites
Cons:
- More expensive than S3/CloudFront for static sites
- Requires management of VPC and EC2 instances
4. AWS Lambda@Edge with CloudFront
Implementation:
- Create a CloudFront distribution for your website.
- Write a Lambda function to check the host header and redirect if necessary.
- Configure the Lambda function to trigger on viewer request events.
Example Lambda function (Node.js):
exports.handler = async (event) => {
const request = event.Records[0].cf.request;
const headers = request.headers;
const host = headers.host[0].value;
if (host.startsWith('www.')) {
const newHost = host.slice(4);
return {
status: '301',
statusDescription: 'Moved Permanently',
headers: {
'location': [{
key: 'Location',
value: `https://{newHost}{request.uri}`
}]
}
};
}
return request;
};
Pros:
- Highly customizable and powerful
- Provides low-latency redirects at the edge
Cons:
- More complex setup and management
- Requires JavaScript/Node.js knowledge
5. CloudFront Functions
Implementation:
- Set up a CloudFront distribution for your website.
- Create a CloudFront Function with the following code:
function handler(event) {
var request = event.request;
var headers = request.headers;
var host = headers.host.value;
if (host.startsWith('www.')) {
var newHost = host.slice(4);
var response = {
statusCode: 301,
statusDescription: 'Moved Permanently',
headers: {
'location': { value: https://{newHost}{request.uri} }
}
};
return response;
}
return request;
}
Associate the function with your CloudFront distribution's Viewer request event.
Pros:
- Extremely fast execution (sub-millisecond startup times)
- Cost-effective for simple operations
- Simpler setup compared to Lambda@Edge
Cons:
- Limited functionality compared to Lambda@Edge
- Only supports JavaScript
Cannot make network calls or use external libraries
Comparison of Edge Computing Options
Conclusion
Each method has its strengths and is suited to different scenarios:
- For static websites, the S3/CloudFront approach is often cost-effective.
- For dynamic sites, ALB provides more flexibility.
For edge-level redirects:
- CloudFront Functions are ideal for simple redirects like www to non-www.
- Lambda@Edge offers more power for complex scenarios.
When choosing the best approach, consider your specific needs, traffic patterns, performance requirements, and management capabilities.