Welcome to the Q&A Forum

Thanks for the additional input Everett, we've done what we can to mitigate consumer clicks, but the search patterns and intent are so similar it's nearly impossible to weed out unqualified visits.

Thanks everyone. That's good to hear they will be replaced the link - based on what Google suggests. I appreciate the answers.

Thanks Angular Marketing, and Everett... very helpful feedback and much appreciated. Luke

I think we'll need to see the site in order to provide any meaningful and specific advice in this case.

Haven't tried that, but that's not a bad idea, thanks. I assumed I wouldn't hear back.

Thanks everyone for your helpful feedback - much appreciated.

Hi there. Hreflang must only be used pointing to the same page/article. Not to point to the root/homepage. does it aswer what you've that what you've asked? Best Luck. GR.

Hi, Andy. Thank you so much for the insights

Hi Egol, Thanks for the message and I get your point. None is actually forwarded to the other. .com has a for sale sign on it and .com.br is a site. Of course, not sure what went on in the past, beyond OSE says .com has no link profile.

That was kind of my thought as well but with the drop in traffic I have to look at everything. SO strange.

Hi there, Welcome to Q&A! Hopefully we get some more specific suggestions from the community, but have you have the chance to check out our Learn section yet? I'd especially recommend reading through the Beginner's Guide to SEO, which shouldn't take too long.

That's ok. I understand that. I may have to run this by my developers. Thanks for your input!

Just wondering if what I have proposed above is feasible...

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

Google might consider this to be a "link scheme".... One part of their definition of a link scheme is.... "Widely distributed links in the footers or templates of various sites..."     You can read their full document on link schemes here... https://support.google.com/webmasters/answer/66356?hl=en If the "seals" have a link in them with nofollow then they will not be considered to be manipulative.

Thank you for your answers!

Hey! You can add a new one but it wouldn't make any sense as the data is still the same for the old site so you can just keep on going with this one and update a lot of stuff in there so your new site will validate better. Martijn.

Pleasure. Keep me posted.

Hi, How significant did the ranking increase? Would you be able to go into more detail on how you approached the websites. Since each one would be in different location. Would you take a different approach from a destination location then a high traffic area location. Thank You! Scott

Thank you so much!