Welcome to the Q&A Forum

Hi Donna, Thankyou so much for your reply.

thank you!

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

Hi Paula! And great answer, Blue! Fresh Web Explorer is your best bet for brand & mentions however, I'm guessing you're referring to the old "Brand and Mentions" feature, yeah? If so, I'm afraid it was deprecated in August 2015. For more details about the removal, please visit the announcement from our product manager here: https://moz.com/community/q/brand-and-mentions-is-being-retired Hope this helps! Adriana

For anybody who's curious, my editor got a link from an external source pointing to our home page. Her name, next to a link to Edwardsturm.com, must have decreased my site's relevance for the branded keyword of my name. The decrease in rank for this branded keyword happened at the same time that my editor was mentioned in this external source, so I'm assuming they're related. Kind of crazy.

So sorry Cody!! Sub-directories allow you to consolidate domain authority and often provide ease of maintenance. With the proper markup, you can create a clear signal to Google for the geotargeting.  I understand this isn't an option for you. With subdomains, you lose some of the shared domain authority that gives sub-directories their advantage, and generally have to maintain separate installs, etc..  You can specify a geo within search console, but it won't be as effective as a ccTLD. With ccTLDs, you can create a much quicker signal for geotargeting your traffic, but the domain authority for each site is generally wholly independent and will require more substantive effort to build the initial authority of each ccTLD, etc..  ccTLDs tend to earn better CTR from the SERPs in the geo, as they seem more likely to be relevant. In your case, I would go with the ccTLDs.. -Jake

Hi Lesley, I think Google would be pretty good at handling things like this on e-commerce sites, so I wouldn't worry about it (as long as those page elements are plain text and not using heading tags, for some reason). Also, google:off/on tags are only used by Google Search Appliance, and are ignored by Google Bot. You will still have content within off/on tags indexed in normal Google search. Cheers, David

Hi Cornelius, Good question! Virtual offices are not permitted by Google's guidelines as they are not deemed to be real physical locations. If you have a client who doesn't have an official office, they will be better served using their home address and listing themselves on those directories that allow the address to be hidden, rather than using a virtual office which is a Local SEO taboo! Phil Rozek has written a couple of good articles over the years on which directories allow one to use their home address while hiding it: http://www.localvisibilitysystem.com/2013/04/22/private-local-citations-where-can-you-list-your-business-but-hide-your-address/ http://www.localvisibilitysystem.com/2012/08/13/can-you-rank-well-in-local-google-without-revealing-your-street-address-anywhere/ Hope this helps, and please let our community know if you have any further questions about this important topic.

Hi Cornelius! It looks like there are some alternatives in this Quora thread: https://www.quora.com/What-are-some-sites-offering-free-video-distribution-services-similar-to-those-formerly-offered-by-TubeMogul/ Does that help at all?

Hi Cornelius, You'll have to apply schema markup in order to get these to show up. You can read about how to implement this here: https://developers.google.com/search/docs/guides/intro-structured-data How long it takes will vary on how frequently Google crawls your site.

Hi Cornelius! Another great question from you. Here's how to understand this: If these are 3 legally distinct businesses (a lawyer, a bakery and a chiropractor) all at the same physical location, and each is staffing the office during stated business hours and each has its own unique phone number, you should be A-OK. Google is pretty sophisticated at parsing out multiple businesses at the same address these days. But... If you ever suspect that these are NOT 3 legally distinct businesses, hold on. If, for example, a legal firm is trying to pretend that its personal injury services, estate services and criminal law services are 3 distinct businesses, then they are being spammy as all get-out trying to list them as 3 different businesses. It's the Local SEO's job to tell them they shouldn't do this and that they are headed for a listing takedown if Google, competing Local SEOs or the public notices what they have done. Another example of this would be an HVAC company trying to bill itself as two different business: one for heating and one for cooling. Eligibility for local business listings revolves around physical location, not the number of services a company offers. So, one physical location for a single business = a single local business listing. There are some exceptions to the above, like a multi-practitioner office or a multi-department campus. Happily, you'll find that the Guideline For Representing Your Business On Google lay this all out in pretty clear terms, and these are what Local SEOs study and refer to in creating local search marketing strategies that keep clients safe from penalties and takedowns. If you're just getting started marketing local businesses, start with the guidelines. Google has been the dominant player in Local Search for over a decade, and so their definitions of good vs. bad practices have, perforce, become industry definitions in many, many ways. Hope this helps!

Thanks Rand! That tells it all

Hi there! Tawny from Moz's Customer Support team here. I think it's pretty unlikely that we'll change the behavior of our crawler, unfortunately. When we crawl your site we adhere to the “Politeness Policy” so that we don't impact the performance of your site: We do this by dynamically controlling (throttling) the number of URLs that we crawl per minute, per hour. If we determine that your site is responding slowly or there are network issues, we extend the crawl intervals. Following the Politeness Policy protects your site from excessive load. Roger Mozbot schedules and crawls thousands of sites a day. Other items can affect the crawl, including changes to your site, network conditions, how your site crawl is scheduled compared to other crawls, etc. Hope this helps!

As Logan pointed out, the most likely cause of this is because of the canonical tags pointing to the HTTP variation. I'd probably suggest carrying out the following: Download a tool like Screaming Frog SEO Spider and crawl your full website - https://www.screamingfrog.co.uk/seo-spider - Once the crawl has run, export the data and check both the URLs and the Canonicals across all pages to ensure only HTTPS variants appear. If you find http variants, then it's likely that the redirect rules you have in place aren't working. This is a global rewrite rule that can be applied to force the https:// version to show at all times, so you shouldn't need to make the changes once by one. I'd also make sure that if you're linking to any pages internally, that you're linking to them using a relative path, or straight to the https:// version. If your canonicals are causing issues, just ensure they're always choosing the HTTPS version and you shouldn't have any issues! Finally, in GSC, just make sure you've got the HTTPS version of the site setup and that your sitemap includes only HTTPS URLs. Hope this helps!

Hi there! Ahrefs is a link index, similar to our Mozscape index. If you're not using Ahrefs for any metrics, you should be safe to block it.

Hi Ralph, As Gaston mentioned, it's very, very possible—probably, even—this what you're seeing is a result of this month's somewhat smaller index (161 billion vs. 92 billion URLs). I'd really recommend this Rand post on PA/DA fluctuations, along with the ones Gaston has already mentioned. A PA/DA of 1 almost always means we don't have information on the URL in question in the index. If the sites linking to you weren't indexed, then it's likely your site wasn't, either. It's very likely that your site will be back in the index after the next update.