Welcome to the Q&A Forum

Hi Max! Which will work the best? I think your second plan of action will be a better strategy in the beginning. Getting backlinks from guest bloggers (who have authoritative websites) is an easy way to get quality backlinks. Don't forget that your backlink profile should be about quality, not quantity. These blogs will naturally incorporate the most important keywords, which will help those pages to rank organically and drive more traffic to the website. Social media, email marketing, etc. are all great ways to get your brand in front of users quickly. The first strategy is great, and will have longer lasting results than the second strategy, but it will take more time to develop and more time to see the results. I would choose your plan of attack based on how quickly you want results. Do you want them now? Or are you willing to have slower results initially but have them be longer lasting? What changes should be made to the strategy? For whichever strategy you choose, I think you hit the nail on the head. Both plans of attack should help to increase website rankings. How to perform a perfect keyword research for product pages? Use Moz's keyword explorer tool. This will tell you the difficulty of certain keywords and whether or not you have a high opportunity to rank for these keywords. This will be your best tool for narrowing down which keywords you should be targeting up front, and which keywords are of secondary importance. Hope this helps!

http://www.redirect-checker.org/index.php http://www.contentforest.com/seo-tools/redirect-checker See http://i.imgur.com/mIqqCla.png Redirecting all traffic to the www SSL domain You can force all of your traffic to go to the www domain, and to use SSL, even if they did not request it initially. ensure www. RewriteCond %{HTTP_HOST} !^www. [NC] RewriteRule ^ https://www.%{HTTP_HOST}%{REQUEST_URI} [L,R=301] ensure https RewriteCond %{HTTP:X-Forwarded-Proto} !https RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301] Redirecting all traffic to the bare SSL domain With dedicated load balancers or who have purchased a slot on the UCC certificate on shared load balancers have the option of redirecting all traffic to the bare domain using the HTTPS protocol: # Redirecting http://www.domain.com and https://www.domain.com to https://domain.com RewriteCond %{HTTP_HOST} ^www\.(.+)$ [NC] RewriteRule ^(.*)$ https://%1%{REQUEST_URI} [L,R=301] Redirecting http://domain.com to https://domain.com RewriteCond %{HTTPS} off RewriteCond %{HTTP:X-Forwarded-Proto} !https RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301] An example of how the requests work The preceding examples of how and when you would use a rewrite are complex; here's a breakdown of the scenarios, which may help you determine what your website really needs. A security warning will occur on a bare domain only if the request specifically includes the https protocol, like https://mysite.com, and there's no SSL certificate on the load balancer that covers the bare domain. A request for http://mysite.com using the http protocol, however, will not produce a security warning because a secure connection to the bare domain has not been requested. | Domain | DNS record type | IP/Hostname | | www.mysite.com | CNAME | dc-2459-906772057.us-east-1.elb.amazonaws.com | | mysite.com | A | 123.45.67.89 | For AWS ELB, www.mysite.com has a CNAME record that points to the hostname of the elastic load balancer (ELB), because that's where the SSL certificate is installed when it's uploaded using the self-service UI. But, bare domains/non-FQDNs like mysite.com can't have CNAME records without something like Route 53, so it must point to the elastic IP address of the balancer pair behind the ELB. If there's a redirect in the .htaccess file that will take all requests for the bare domain and redirect them to www, due to how the DNS records are set up, this is what happens if you request http://example.com: The request for http://mysite.com hits the load balancers behind the ELB. The .htaccess rule 301 redirects request to https://www.mysite.com. A new request for https://www.mysite.com hits the ELB where the certificate lives and everything is happy, secure, and green. But, if a specific request is sent to https://mysite.com with the https protocol, here's what happens: A request for https://mysite.com hits the load balancers behind the ELB. Your browser displays the normal security warning. You examine the certificate and decide to move ahead. The .htaccess rule 301 redirects request to https://www.mysite.com. A new request for https://www.mysite.com hits the ELB where the cert lives and everything is happy, secure, and green. Redirecting all HTTP traffic to HTTPS In the following example, the server variable HTTP_X_FORWARDED_PROTO is set to https if you're accessing the website using HTTPS, the following code will work with your Redirect HTTP to HTTPS RewriteCond %{HTTPS} off RewriteCond %{HTTP:X-Forwarded-Proto} !https RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301] Redirecting all HTTPS traffic to HTTP In addition, if visitors to a customer's website are receiving insecure content warnings due to Google indexing documents using the HTTPS protocol, traffic may need to be redirected from HTTPS to HTTP. The rule is basically the same as the preceding example, but without the first Rewrite condition. If no SSL certificate is installed, the value of %{HTTPS} is always set to off, even when you are accessing the website using HTTPS. Use the following rule set in this case: Redirect HTTPS to HTTP RewriteCond %{HTTP:X-Forwarded-Proto} =https RewriteRule ^(.*)$ http://%{HTTP_HOST}%{REQUEST_URI} [L,R=301] Redirecting from a bare domain to the www subdomain SSL certificates can not cover the bare domain for websites unless you are using Route 53 or some other similar provider. This is because the SSL certificates for Acquia Cloud Professional websites are placed on an Elastic Load Balancer (ELB). While ELBs require CNAME records for domain name resolution, bare domains require an IP address in an A-record for the domain name (DNS) configuration and cannot have CNAME records. Therefore, it's not possible to terminate traffic to bare domains on the ELB where your SSL certificate is located without Route 53. Even if all requests for the bare domain are redirected to www, visitors to ELB websites that explicitly request the bare domain using the HTTPS protocol, like https://mysite.com, will always receive a security warning in their browser before being redirected to https://www.mysite.com. For a more detailed explanation of why this happens, refer to the An example of how the requests work section. Redirect http://domain.com to http://www.domain.com RewriteCond %{HTTP_HOST} !^www. [NC] RewriteRule ^ http://www.%{HTTP_HOST}%{REQUEST_URI} [L,R=301] Redirecting all traffic to the www SSL domain You want this! You can force all of your traffic to go to the www domain, and to use SSL, even if they did not request it initially. ensure www. RewriteCond %{HTTP_HOST} !^www. [NC] RewriteRule ^ https://www.%{HTTP_HOST}%{REQUEST_URI} [L,R=301] ensure https RewriteCond %{HTTP:X-Forwarded-Proto} !https RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301] Redirecting all traffic to the bare SSL domain AWS dedicated load balancers or who have purchased a slot on the UCC certificate on our shared load balancers have the option of redirecting all traffic to the bare domain using the HTTPS protocol: Redirecting http://www.domain.com and https://www.domain.com to https://domain.com RewriteCond %{HTTP_HOST} ^www.(.+)$ [NC] RewriteRule ^(.*)$ https://%1%{REQUEST_URI} [L,R=301] Redirecting http://domain.com to https://domain.com RewriteCond %{HTTPS} off RewriteCond %{HTTP:X-Forwarded-Proto} !https RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301] As an example, if you wanted to ensure that all the domains were redirected to https://www. except for Acquia domains acquia-sites.com, you would use something like this: ensure www. RewriteCond %{HTTP_HOST} !prod.acquia-sites.com [NC] # exclude Acquia domains RewriteCond %{HTTP_HOST} !^www. [NC] RewriteRule ^ https://www.%{HTTP_HOST}%{REQUEST_URI} [L,R=301] ensure https RewriteCond %{HTTP:X-Forwarded-Proto} !https RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301] elb 2.2.15 | intermediate profile | OpenSSL 1.0.1e | link Oldest compatible clients : Firefox 1, Chrome 1, IE 7, Opera 5, Safari 1, Windows XP IE8, Android 2.3, Java 7 This Amazon Web Services CloudFormation template will create an Elastic Load Balancer which terminates HTTPS connections using the Mozilla recommended ciphersuites and protocols. { "AWSTemplateFormatVersion": "2010-09-09", "Description": "Example ELB with Mozilla recommended ciphersuite", "Parameters": { "SSLCertificateId": { "Description": "The ARN of the SSL certificate to use", "Type": "String", "AllowedPattern": "^arn:[^:]*:[^:]*:[^:]*:[^:]*:.*$", "ConstraintDescription": "SSL Certificate ID must be a valid ARN. http://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html#genref-arns" } }, "Resources": { "ExampleELB": { "Type": "AWS::ElasticLoadBalancing::LoadBalancer", "Properties": { "Listeners": [ { "LoadBalancerPort": "443", "InstancePort": "80", "PolicyNames": [ "Mozilla-intermediate-2015-03" ], "SSLCertificateId": { "Ref": "SSLCertificateId" }, "Protocol": "HTTPS" } ], "AvailabilityZones": { "Fn::GetAZs": "" }, "Policies": [ { "PolicyName": "Mozilla-intermediate-2015-03", "PolicyType": "SSLNegotiationPolicyType", "Attributes": [ { "Name": "Protocol-TLSv1", "Value": true }, { "Name": "Protocol-TLSv1.1", "Value": true }, { "Name": "Protocol-TLSv1.2", "Value": true }, { "Name": "Server-Defined-Cipher-Order", "Value": true }, { "Name": "ECDHE-ECDSA-CHACHA20-POLY1305", "Value": true }, { "Name": "ECDHE-RSA-CHACHA20-POLY1305", "Value": true }, { "Name": "ECDHE-ECDSA-AES128-GCM-SHA256", "Value": true }, { "Name": "ECDHE-RSA-AES128-GCM-SHA256", "Value": true }, { "Name": "ECDHE-ECDSA-AES256-GCM-SHA384", "Value": true }, { "Name": "ECDHE-RSA-AES256-GCM-SHA384", "Value": true }, { "Name": "DHE-RSA-AES128-GCM-SHA256", "Value": true }, { "Name": "DHE-RSA-AES256-GCM-SHA384", "Value": true }, { "Name": "ECDHE-ECDSA-AES128-SHA256", "Value": true }, { "Name": "ECDHE-RSA-AES128-SHA256", "Value": true }, { "Name": "ECDHE-ECDSA-AES128-SHA", "Value": true }, { "Name": "ECDHE-RSA-AES256-SHA384", "Value": true }, { "Name": "ECDHE-RSA-AES128-SHA", "Value": true }, { "Name": "ECDHE-ECDSA-AES256-SHA384", "Value": true }, { "Name": "ECDHE-ECDSA-AES256-SHA", "Value": true }, { "Name": "ECDHE-RSA-AES256-SHA", "Value": true }, { "Name": "DHE-RSA-AES128-SHA256", "Value": true }, { "Name": "DHE-RSA-AES128-SHA", "Value": true }, { "Name": "DHE-RSA-AES256-SHA256", "Value": true }, { "Name": "DHE-RSA-AES256-SHA", "Value": true }, { "Name": "ECDHE-ECDSA-DES-CBC3-SHA", "Value": true }, { "Name": "ECDHE-RSA-DES-CBC3-SHA", "Value": true }, { "Name": "EDH-RSA-DES-CBC3-SHA", "Value": true }, { "Name": "AES128-GCM-SHA256", "Value": true }, { "Name": "AES256-GCM-SHA384", "Value": true }, { "Name": "AES128-SHA256", "Value": true }, { "Name": "AES256-SHA256", "Value": true }, { "Name": "AES128-SHA", "Value": true }, { "Name": "AES256-SHA", "Value": true }, { "Name": "DES-CBC3-SHA", "Value": true } ] } ] } } }, "Outputs": { "ELBDNSName": { "Description": "DNS entry point to the stack (all ELBs)", "Value": { "Fn::GetAtt": [ "ExampleELB", "DNSName" ] } } } } You can get managed Magento hosting here. https://www.armor.com/security-solutions/armor-complete/ https://www.mgt-commerce.com/ https://www.rackspace.com/en-us/digital/magento https://www.cogecopeer1.com/en/services/managed-it/ecommerce/magento/ https://www.cogecopeer1.com/en/services/cloud/mission-critical/ https://www.engineyard.com/magento https://www.cloudways.com/en/magento-managed-cloud-hosting.php https://www.rochen.com/magento-hosting/ http://www.tenzing.com/ecommerce-hosting-2/magento-optimized-hosting-on-aws/ https://www.siteground.com/dedicated-hosting.htm#tab-3 https://www.siteground.com/cloud-hosting.htm#tab-2 https://www.siteground.com/speed mIqqCla.png