Am pretty sure that Moz just unifies DA stats in some circumstances when they have no 'actual' data for the subdomain in question. Sites which are very important, which have a number of sub-domains (but not hundreds or thousands) often render different results for DA metrics. For some blog platforms (blogger is a good example, also "blogname.wordpress.com" WordPress hosted blogs) - they have thousands or hundreds of thousands of sub-domains and Moz can't index all of them

In these situations, if Moz comes across a subdomain which is well-linked across the web it will separate it out and ascribe unique values. For the rest (of which Moz holds no data), it probably just unifies the DA metric with the root domain

It's a symptom of an incomplete index of the web. That being said, no one has a complete index of the web - you have to work with what you got

Yeah definitely don't do it the other way around. To be honest if the landing pages are orphaned, Google probably won't rank them anyway. If Google 'is' ranking them instead of the other ones, the real question is why does Google find them more useful, and what can you add from the landing pages to the organic pages - to make them better!

In response to your second question, it's fine to have /usa/ although /us/ or /en/ would be a more typical deployment (lots of people go like, /en-us/ and /en-gb/ as that structure allows for really granular international deployment!)

As long as the hreflangs are accurate and tell Google what language and region the URLs are for, as long as the hreflangs are deployed symmetrically with no conflicts or missing parts - it should be ok

Note that Google will expect to see different content on different regional URLs, sometimes even if they're the same language but targeted at different countries (tailor your content to your audience, don't just cut and paste sites and change tags and expect extra footprint). Stuff like shipping info and prices (currency shown) should also be different (otherwise don't even bother!)

Your hreflangs, if you are doing USA as your EN country, should not use 'en-gb' in the hreflang (instead they should use 'en-us')

If you're thing God the HTML implementation will make the code bloated and messy, read this:

https://support.google.com/webmasters/answer/189077?hl=en

There are also HTTP header and XML sitemap deployment options (though IMO, HTML is always best and is the hardest, strongest signal)

Yep every page should reference every language, including its own language. but obviously with different URLs in the link fields, as different pages should have different regional equivalents (hope that makes sense)

Basically the canonical tags should self reference, so long as they are also supported by hreflangs.

So for example if you had these two URLs:

site.com/en/category/product

site.com/fr/category/product

... then on site.com/en/category/product you'd need:

**... and on site.com/fr/category/product you'd need:**

It's pretty simple really! Remember, only canonical URLs (usually not parameter-based child URLs) should self-reference with a canonical tag. Remember that Hreflangs need to be mutually agreed between pages for them to work (so if the FR page links to the EN page with a hreflang, but there's no hreflang coming back - it fails!) - Keep hreflangs simple and exactly symmetrical

Hard to tell what to do without seeing specifically where this error is coming up, but it usually has something to do with font sizes being too small on mobile devices. Mobiles have much more densely packed pixels on their screens (images are sharper, the pixels are smaller and more numerous). This means that 12 pixels (font-size) on desktop can look like 5 or 6 pixels on mobile devices (or even smaller)

This is why, with responsive design, many people don't specify a pixel-based font-size. They'll make the font size relative (rather than absolute) somehow, be that by calculating pixel width against screen width as some percentage, or by working with newer font-sizing specifications (there are many, and many ways to use them). It's all about inflating font-sizes on devices with more densely packed pixel screens, so that the fonts don't come out looking minuscule

Sometimes you can get errors where, even though the site's design is responsive, as someone was writing text in the CMS text editor - it appended styling info including the px font-size, which is then inlined (overruling all your perfectly thought out font-sizing CSS rules)

If it's not mobile related at all, it's likely that the font is just generally too small

Pretty sure it would be:

• User-agent: Rogerbot
• Disallow: /*?ajaxCalendar
• Disallow: /*&ajaxCalendar

That would pretty much handle OPs concern there

As long as you could prove that you're not breaking the law (using legal definitions, not your own) and that you have permission to use that content - I don't see why not. If you buy the expired domain and restore it, that can work very well from an SEO POV - however there may be legal ramifications and the original owner may be able to come in later and remove your site or take it over

From an SEO POV I have seen this tactic work when re-buying the expired domain and restoring it. I can imagine, however - that the main issues would be legal challenges

Never seen this error but, having the answer saved (in the entry box) and not posted does sound like it could be an actual Google bug. Someone might know more here - https://www.en.advertisercommunity.com/t5/Google-My-Business/ct-p/GMB

Other than that, other fellow Mozzers might have a better answer. I just wanted to leave that link there, in-case no one here can answer (as your query is quite technical and specific!)

This is a common and over-zealous implementation of GDPR tracking compliance. Lots of people have lost lots of data, by going slightly overboard in a similar way. Basically you have taken GDPR compliance too far!

GDPR is supposed to protect the user's data, but in terms of - is there a 1 or a 0 in a box in an SQL database for whether an anonymous user visited your site or not (traffic data, not belonging to the user) - it's actually fine to track that (in most instances) without consent. Why? Because the data cannot be used to identify the user, ergo it's your website data and not the user's user data

There used to be a GA hack which Google patched, which forced GA to render IP addresses - but even before it was patched, they banned people (who were using the exploit) from GA for breaking ToS. That kind of data (PII / PID), unless you have specifically set something up through event tracking that records sensitive stuff - just shouldn't even be in Google Analytics at all (and if you do have data like that in your GA, you may be breaking Google's ToS depending upon deployment)

If the data which you will be storing (data controller rules apply) or sending to a 3rd party to store (in which case you are only the data processor and they are the data controller) does not contain PID (personally identifiable data - e.g: email addresses, physical addresses, first and last names, phone numbers etc) - then it's not really covered by GDPR. If you can say that these users have an interest in your business and show that a portion of them transact regularly, you're even less at risk of breaking GDPR compliance

If you're worried about cookie stuff:

• https://developers.google.com/analytics/devguides/collection/analyticsjs/cookie-usage

"Note: gtag.js and analytics.js do not require setting cookies to transmit data to Google Analytics."

It's possible with some advanced features switched on like re-marketing related stuff, this might change. But by default at least, it seems as if Google themselves are saying that the transmission of data and the deploying of any cookies are not related to each other, and that without cookies the later scripts can send data to GA just fine without cookies

If you are not tracking basic, page-view level data which is not the user's data (which is not PII / PID), then you are over-applying GDPR. The reason there aren't loads of people moaning about this problem, is that it's only a problem for the minority of people who have accidentally over-applied GDPR compliance. As such it's not a problem for others, so there's no outcry

There'**s lots more info here: **https://www.blastam.com/blog/gdpr-need-consent-for-google-analytics-tracking

"This direction is quite clear. If you have enabled Advertising features in Google Analytics, then you need consent from the EU citizen first. Google defines ‘Advertising features’ as:

• Remarketing with Google Analytics.
• Google Display Network Impression Reporting.
• Google Analytics Demographics and Interest Reporting.
• Integrated services that require Google Analytics to collect data for advertising purposes, including the collection of data via advertising cookies and identifiers.

-"

If you aren't using most, many or any of the advanced advertising features, your implementation is likely to be way too aggressive. Even if you are using those advanced features, you only need consent for those elements and specifically where they apply and transmit data. A broad-brush ban on transmitting all GA data is thoroughly overkill

Think about proposing a more granular, more detailed approach. Yes it will likely need some custom dev time to get it right and it could be costly, but the benefit is not throwing away all your future data for absolutely no reason at all

Don't forget that, as the data 'storer' (controller), a lot of the burden is actually on Google's side

**Read more here: **https://privacy.google.com/businesses/compliance/#!?modal_active=none

Hope this helps

This is a long and detailed query so I think, it will be best to annotate your question with my responses:

"Dear friends, We have a multi-regional website in English language only having the country selector on the top of each page and it adds countrycode parameters on each url. Website is built in Magento 1.8 and having 1 store with multiple store views." - it is probably better to go with a folder-structure based regional deployment as Google doesn't tend to weight parameter URLs very strongly at all, unless there are link / citation signals which prove the child page version (parameter based) is more popular than the parent (in which case, they can shuffle around)

"There is no default store set in Magento as I discussed with developer. Content is same for all the countries and only currency is changed. In navigation there are urls without url parameters but when we change store from any page it add parameters in the url for same page hence there are total 7 URLs." -this sounds incredibly complicated. It sounds like at some point, someone will leave or forget how things work and you will be in a big mess

"6 URLs for each page (with country parameters) and 1 master url (without parameters) and making content duplicity." - yes I can see how that would be a problem. Also you said there was no default URL, but now says there is a master URL. Surely master is default? This may need more explaining for myself or others to help your properly. By the way, something very important here - if you're just planning to use hreflangs on their own and change pricing, very often Google won't consider that a good enough effort to give you an international footprint. Google think, hmm if you really have identified these new audiences across the world, even if they speak the same language - they are different people with a different culture. Should your content really be EXACTLY the same? No. If you do bother to do different content for different audiences (even if they speak the same language) which is tailored to their cultural nuances - you will probably get more international rankings. If you don't and you're just doing the cheapest fastest thing, you have no value proposition for Google and thus don't expect to win big (or even at all)

"We have implemented hreflang tags on each page with url parameters but for canonical we have implemented master page url as per navigation without url parameters Example on this page." - just so you know, a canonical tag acts almost like no-index tags. It says to Google: I am not the main version of this page, so please never index me. Instead index this canonical URL I am linking to instead. As such, with your current implementation, all of your regional URLs will be taken out of Google's index unless popularity signals contradict your canonical tags (in which case they may be overridden). Think about it. With hreflangs you are telling Google: go over here and index my other language version. So Google goes over to another page, but that page says: Google I am not canonical, why are you even here? Go to the canonical master only don't look at me. So you are really confusing Google by telling them to index pages with Hreflangs, then telling them not to with canonical tags

"I think this is correct for master page but we should use URL parameters in canonical tags for each counry url too and there should be only 1 canonical tag on each country page url. Currently all the country urls are having master page canoncial tag as per the example. Please correct me if I am wrong and in this case what has to be done for master page? as google is indexing the pages without parameters too." - with your current implementation, Google should (most of the time, this is not absolute) only be indexing the master pages and not indexing any of the regional pages. The regional pages all tell Google that they are not canonical and not good for indexing, by using the canonical tags you are telling Google to only index the master. I would personally remove all canonical tags from all regionally appended parameter URLs. If you have parameters firing for other reasons (e.g: changing tabbed content, moving a carousel, UTM campaign tracking) then those should be trimmed out of Google's index using canonical tags. That being said; for your regional parameter URLs, it's a different story. You want your regional pages to rank - right? So don't tell Google they are non-canonical, by putting canonical tags on them pointing to the master. In-fact I might even put some of them in a Sitemap.XML and feed them to Google. I would only do this, where the regional modifier is the ONLY parameter in the URL. If there are others, I might still use canonical tags - but for just the regional modifier on its own, they should be stripped of canonical tags (if you want them to rank ever)

"We are also using GEOIP redirection for each store with country IP detection and for rest of the countries which are not listed on the website we are redirecting to USA store. Earlier it was 301 but we changed it to 302. Hreflang tags are showing errors in SEMRush due to redirection but in GWT it's OK for some pages it's showing no return tags only. Should I use x-default tags for hreflang and country selector only on home page like this or should I remove the redirection? However some of the website like this using redirection but header check tool doesn't show the redirection for this and for our website it shows 302 redirection. Sorry for the long post but looking for your support, please." - Support is here! Two main things. Firstly code 303 might be more appropriate than codes 302 or 301. I would not bother with X-Default unless you really know what you are doing, since you are already in one Hell of a mess I would not touch that yet. Fix the basics, wait for the dust to settle! Finally, all you need to do for Google is to exempt Google's user-agent of "googlebot" from your regional redirects. That way they don't get bounced around, but users still do