Welcome to the Q&A Forum

seoelevated is correct. Reference example from Google here: https://support.google.com/webmasters/answer/189077?hl=en

Let them land there (you don't really have a choice in that from search). But if the page really isn't relevant and there is no equivalent, think about popping a message to them telling them that you think they are in the US and that the area for the US users is here and link them there. Also give them a way to contact some sort of help. Either a Help area or an email address.

You raise valid concerns here and the truth is, it may not be hreflang related - but before we look at anything else, you do technically have a lang / hreflang conflict Look at this example: view-source:https://mediabrosonline.com/en/ (view source links only open in Chrome) Here's your self-referencing hreflang: rel="alternate" hreflang="en" href="https://mediabrosonline.com/en/" /> Here's your lang tag: lang="en-US" Your hreflang says the page is EN international (for all EN users) but your language tag says the page is only for EN speaking users geographically located within the US. So which is it? Confusing for Google Let's look at an example where the site 'does it right': view-source:https://mediabrosonline.com/mx/ (view source links only open in Chrome) Here's your self-referencing hreflang: rel="alternate" hreflang="es-mx" href="https://mediabrosonline.com/mx/" /> Here's your lang tag: lang="es-MX" See! They correctly match. So this shows that on the EN page, implementation is technically wrong. I know, I know - I am really 'splitting hairs' here. But before we look at other factors, let's make your original statement: "I have the correct hreflang tags" ... actually true! That way we can rule it out

Ok great thanks for clarifying Kate!

Thanks for the detailed response Nick - great summary! "If you choose to try to guess at the user’s language preference when they enter your site, you can use the browser’s language setting or the IP address and ask the user to confirm the choice. Using JavaScript to do this will ensure that Googlebot does not get confused." I presume web developers would know how to do this?

Thanks Rajesh! Very clear, will pass that on to developers!

It could easily be possible. Google usually takes the most specific directive when multiple directives contradict each other If you previously had your site targeting 'international' in GSC and you had US hreflangs, Google would have still targeted to USA as US directive is more specific Since you say you had targeting set to USA (and still do) and you may have had US hreflangs which were removed, this is a bit odd. Even without hreflangs, the GSC target US users directive is still more specific and thus Google 'should' default back to that That being said, hreflangs might be a bit of a harder directive as they are actually coded onto your web pages. It may also be Google ignoring GSC directives for some sites to try and 'encourage' more webmasters to embrace hreflangs and proper internationally targeted websites Google won't look at your bounce rate I don't think. Certainly not from Google Analytics (as that's your own data and it's also really easy to manipulate, e.g: you could use JS to detect what country people are connecting from and when you serve the pages you could strip out the analytics tracking script, thus lowering the bounce rate). Google use their own data, mostly the metrics from Search Console (clicks, impressions etc) People talk about bounce rate being bad because it's bad UX (usually) and Google wants sites built with proper UX, sites that are useful to people. But the aim is to make your site better so that real people won't bounce as easily, not to get better GA bounce-rate metrics (which aren't used in Google's algorithm). Of course Google must have a way to evaluate something similar, but that number in that database wouldn't be 'the one' that they factor I would try embedding the relevant hreflangs to support your geo-targeting and additionally checking what GSC property has your US settings in.  You can always block traffic from other countries, like how if you try to view a certain series on Netflix from the UK which is only available in the USA - it says "this show isn't available in your region". If you really care that much, just do something similar (this page is not available in your region)

Yes, your understanding of x-default is correct. The purpose of including it everywhere you have alternate HREFLANG links, is to handle any locales you don't explicitly include (to tell the search engine which is the default version of the page for other non-specified locales). And it should be included on each version of the page, along with the other specified alternate links for each locale. Alternatively, you could collect all of these centrally into the sitemap file, rather than inserting into each page. Both types of implementation are valid (but anecdotally I've had better luck with on-page tags instead of sitemap implementation).

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

I agree with Robin, I don't think there's a solid way to do what you want - or one that is infinitely superior to GA (which also doesn't damage conversion rates). IP addresses by and large, are sometimes inaccurate at the city / town level but they are 'usually' accurate at the national level. The only other option you have in GA is looking at browser language settings and that's incredibly misleading due to most PCs being shipped on US English by default

Hi, This has happened to me too. Before the changes to domains, I had over 24,000 links showing on my internal links in the Links research. Now I have less than 3000. I have checked on Search Console and that is still showing as 24,000, but they aren't registering on Moz. What's changed? Thanks Lydia

Hi Thomas, So you're saying you've added all of your language specific subfolders (and have specified language targeting) but you aren't receiving Google Search Console data for all of them? e.g impressions, clicks, keywords. Can I just ask what your overall strategy is here with the localisation? From taking a quick peak, I can see that you basically have English versions targeted at different countries; which elements have you specifically tailored to each country? Hreflang and scaling is never easy and I can't say definitely, but it seems like you might have duplicated quite a lot of your efforts here. Surely it might make more sense to make English the x-default/internalisation version and then ensure each page is translated into the target language e.g Italian or Estonian. Kind regards, Nick

I currently manage a site which is localized per region, as opposed to country. For some regions, like US and Australia, it is 1:1 with country, so we do not have issues there. But for Europe, that is where we do have some issues currently. We took the following approach (below), but I have to first say that it is quite problematic and has not performed very well so far (implemented about 1 year ago). The approach we took was to implement HREFLANG within our sitemap, and for Europe, we generate specific alternate locations for each of the countries where we do business in that region, all with the same URL. Here (below) is a redacted version of one page's LOC node in our sitemap (I've only included a partial list, and only showing English, as the full list of alternate URLs for this one LOC has 150 alternate links to cover every EU country x 5 languages we support). But, the general approach is that for Europe, we create one alternate link for each EU country, in each of our supported languages (we support 5 languages). So, we don't assume, for example, that German speakers are only in Germany, or that English speakers are only in the UK. We cover every country/language combination and point many of these to the exact same alternate link. Again, as I mentioned, this hasn't achieved all we had hoped. But sharing the approach for a reference point here, as an option, and open to any other ideas from the community. We also struggle with EU in terms of Google Search Console geographic targeting. Unfortunately, Google does not allow a property to be targeted to "Europe". And they only allow one single country per property. In our case, we really need to target a single domain to "Europe", not to a specific country. But we can't, and that is a problem currently. Here is the example from our Sitemap (partial cut-and-past of the first few entries from one URL node): <loc>https://www.example.com/example-page-path</loc> <priority>1</priority> ... remainder of alternate links removed to shorten list here |   |

Sorry Lisa, this got lost in my email box. You are looking for tips for how to set things up for an international site? Can you tell me more about your site and what you are looking to get out of your Moz account when it comes to international search?

Hi there. Hreflang is only for pages with multiple languages. So, in your case, it would be homepage only. No need to add "fake" hreflangs to other pages.

Unfortunately yes. We have a number of clients who went 'geo-mad' and in almost all situations, it has caused problems for them. Sometimes it has created colossal site footprints which Google doesn't care to index (unless you're a household name, don't expect Google to care about your hundreds of thousands of URLs). Sometimes that has also caused server-load issues for them too, irrespective of Google Other issues include Google ignoring their canonical tags and setting one language URL as the 'canonical' result (and thus de-indexing the other language URLs). This can happen due to link signals and similar content, stuff like that Many clients in such a position have **seen their pages devalued as a result of them going against Google's content guidelines **(and simplicity guidelines). If you're not super important, Google don't want to waste 4x, 6x or 20x crawl budget in your site just because you decide to serve in more combinations of language and geo-location. Even with perfect Hreflang deployments, a lot can go wrong if you go nutty so cherry-pick your language/geo combinations and don't be greedy with it If your brand is powerful online and you have loads of SEO authority / ranking power, then you can deploy hreflangs extensively and usually you can make real gains. Not everyone is in that position, most aren't Having unique content (not powered by some crappy auto-translate plugin) per deployment is strongly, strongly recommended. By the way if you have less ranking power than most sites which have 'successful' broad-reaching hreflang deployments, you need to adhere to Google's guidelines more strictly than those sites do. You need to make up for you lack of trust and authority, by doing things by the book Too many people look at big international sites and say: "well Google lets them use relatively thin content so I should be alright too". Nope, you are likely standing upon a platform of radically different stature to those guys, so don't over-reach too quickly or you'll stumble and fall Also if you are planning to use canonical tags to 'canonical' from one language to another, don't do that. If a page points to another, separate URL with its canonical tag - then it tells Google that it (the active page) is the non-canonical version and usually de-indexes itself Be very careful how you proceed. If you increase your footprint too far, all the great authority you have built up may bleed out over a sprawling site and you could end up with nothing

We actually found that, whilst it require strict management in terms of file transfers, GDPR wasn't as scary as everyone said it would be One thing we did was to sign up for Wizuda, a GDPR compliant file-transfer system (previously we just sent stuff to clients through Dropbox links, Sync.com links or WeTransfer links). It's important to note that a compliant file transfer system, doesn't 'make' all your file transfers GDPR compliant. It provides a platform which records certain info and erases files past a certain date, thus 'enabling' you to be GDPR compliant (but not necessitating that your actions will make it so) We also asked clients whom wanted to transfer data to us, to sign up to it and to send a covering note (through Wizuda mail) on every single file which they fired through to us. If they don't include the note we delete the file and reject the transfer The note they must send to us goes something like this: https://d.pr/i/tIhQBK.png (screenshot from Wizuda Mail - redacted) We also initially got a lot of pressure whereby, our Account Managers were going directly to analysts (whom were, at the time - managing GDPR transfers) and trying to 'push through stuff that the client just wanted' without the client having properly proven - that they owned the data and had the 'right' to transfer it to us for marketing activities. Needless to say we immediately clamped down on that with full force, by creating an interactive (digital or printable) 'fillable' PDF form which AMs 'have' to get filled in (by the client) before we accept ANY inbound data which contains any PID https://d.pr/i/1nkG5F.png (PDF screenshot - redacted) Since only Account Managers have a relationship with a client and can tell them 'no you do not have permission to legally do this, and we will not support you with illegal data transfers' - it made sense to unburden those 'physically' transferring the data and leave it up to higher level AMs / ADs and clients to sort out between themselves We have now adopted more advanced approaches but all this stuff was an integral stop-gap This all prevented two things: 1) Us transferring data which was not GDPR compliant to clients 2) Clients being able to get us to 'work on' illegally transferred data, which would make us an accessory to their malpractice Some think we went crazy and went way too far, but I'm pleased that we're taking more steps every day to ensure full GDPR compliance. That being said even our initial steps were really strong The truth is, no one knows whose practices are / are not safe. Most of this GDPR stuff hasn't worked its way through the courts yet - and until that happens, whose to say which approach is most compliant? I think we're doing well, though At the beginning we were quite scared that our email marketing would die off. But actually that's not the case! It just has much less churn than before. To be honest, the people whom were targeted before GDPR came into play, who may have not given explicit permissions for our client(s) to share their data, were the group who never really converted anyway. The people who signed up to be contacted, whom demonstrated their interest, supplied far more of our client(s) conversions. So in a way it was kind of irrelevant, just meant we spent less of firing out emails in the first place. Most ethical, strong-performing email marketing is re-targeting and usually users have to interact and give consent for that to happen anyway (subscribe to our newsletter, etc.)

Oh how I dislike Imgr and wish Moz made sharing images easier. See if this works. If not, go to https://imgur.com/ItJ0dyS. I'm using the Mozbar to show the redirect. ItJ0dyS

Huh. You have a really good head on your shoulders. They are both good options. Unless there is something that makes the .lu/fr imperative to have for the users, I think I prefer option 1. Your logic sounds good there and is customer first. Good luck!