Welcome to the Q&A Forum

But using sitemaps you will not be using this method? The return tag will be in a sitemap...

Hi Enjin! If Martijn's response answered your question, mind marking it a "Good Answer?" Otherwise, how can we help more?

Hi Paul, Both are a bit unconventional. If you would use .com/fr/mobile/ then the mobile version would become part of the regular site. if you would use .com/mobile/fr/ you would basically do the same but with the default language, non-mobile version of the site. You would have to make absolutely sure that you ise your canonical tags to prevent duplicate content. This setup might be more difficult to check and maintain. I would therefore never use this setup but go for "mobile.domain.com/fr/". This way both structures are clearly separated. You would still have to make sure you use canonical tags to prevent duplicate content but at least this way the mobile and non-mobile version are clearly separated. Bas

Correct answer. I would only add that implementing the breadcrumb data vocabulary/structured data can help Google understanding the structure of a site, hence facilitate also the "creation" of good sitelinks. On the other hand, it is plausible thinking that Google will present as sitelink those Urls that tend to be more clicked via search. The sitelinks, in fact, has also the function to help users clicking to the most "popular" Urls for the brand name/homepage search snippet. We cannot control what sitelink Google will show, but we can demote those Urls Google is showing if we consider they are wrong or not useful. Finally, your suggestion about geotargeting should not be taken into account if the site is multilingual.

Thank you,

Hi Thomas, If a page doesn't have an equivalent on the other country version then you don't need to specify hreflangs really, you can just specify the one of the page that exist if you want, to keep the consistency, although if you see: the goal of the hreflang is to specify Google which is the "best" URL to show in their results when a search is done and there are many that could be relevant as they target the same queries, but should be targeted to different audiences, since in this case there will be only one, then it's not necessary to do it. Thanks, Aleyda

it does make sense: my point is that bycicletrip.com/france is a good Landing Page url.

Hey David, Sorry for the delayed response on this. Before we get started, I should point out that htaccess's syntax is very particular and you should be extremely careful when messing with it. even a single space out of place can cause massive errors. If you're planning changes, please consult with a developer or three on your team! I think the best way to explain this is to go through exactly what the htaccess Rewrite calls are doing. RewriteCond %{REQUEST_URI} ^/(En|Es)$ [NC] RewriteCond - The condition of which a rewrite will take place %{REQUEST_URI} - The URI that is requested from the server (everything after the domain and TLD i.e. moz.com/community 's URI would be /community) ^ - Denotes the beginning of a regular expression (regex) / - literally just / (En|Es) - the '()' are simply a grouping and the '|' means OR. So this is saying En OR Es $ - Denotes the end of a regex [NC] - Means no case, so everything in this is not case sensitive So literally this is saying execute this rewrite when the requested URI (after the .com or whatever TLD you use) is either /En OR /Es then whatever, with no attention to case RewriteRule ^(En|Es)/(.*)$ $2?lang=$1 [L,R=301] RewriteRule - The executed rule when the aforementioned RewriteCond is met. ^ - Denotes the beginning of a regular expression (regex) (En|Es) - the '()' are simply a grouping and the '|' means OR. So this is saying En OR Es / - literally just / (.) - This is a wildcard. Once again the () is a grouping, but here the . means zero or more arbitrary characters $ - Denotes the end of a regex $2 - this is the second captured grouping in this line. Meaning whatever is defined within (.*), which is everything after En/ or Es/ ?lang= - this is literally writing '?lang=' without the 's. $1 - this is the first captured grouping from this line. Meaning whichever En OR Es was captured will be written here. [L] - Tells the server to stop rewriting after the preceding directive (rule) is processed [R] - Instructs Apache to issue a redirect, causing the browser to request the rewritten URL [301] - Corresponds to a Moved Permanetly Header Code [L,R=301] - Combines all 3 of these into one. For this I think it's easiest to just use an example. moz.com/En/htaccess-is-fun will be our example Since this url passes the RewriteCond, it goes on to the RewriteRule where it finds En OR Es and stores that value as $1 (En) then takes whatever is left and stores it as $2 (htaccess-is-fun). It then writes htaccess-is-fun?lang=En and replaces the original selection (which is En/htaccess-is-fun) with the new rewrite making the result moz.com/htaccess-is-fun?lang=En . The new URL is served as a 301-ed redirect. RewriteCond %{REQUEST_URI} !(.[a-zA-Z0-9]{1,5}|/)$ RewriteCond - The condition of which a rewrite will take place %{REQUEST_URI} - The URI that is requested from the server (everything after the domain and TLD i.e. moz.com/community 's URI would be /community) ! - declares negation. i.e. "!cheese" matches everything except "cheese" () - is again a grouping \ - escapes a special character. So "." means a literal dot. a-zA-Z0-9 - matches all lowercase letters, all uppcase letters, and all numbers {1,5} - matches one to five of the previous designation. Meaning that there can be any combination of a-z, A-Z, or 0-9 in a sequence of one to five. i.e. A2ps OR 12345 OR AbC etc. | - Means OR / - literally just / $ - Denotes the end of a regex RewriteRule ^(.*)$ $1/ [L,R=301] ^ - Denotes the beginning of a regular expression (regex) (.) - This is a wildcard. Once again the () is a grouping, but here the . means zero or more arbitrary characters $ - Denotes the end of a regex $1 - this is the first captured grouping from this line. / - literally just / [L] - Tells the server to stop rewriting after the preceding directive (rule) is processed [R] - Instructs Apache to issue a redirect, causing the browser to request the rewritten URL [301] - Corresponds to a Moved Permanetly Header Code [L,R=301] - Combines all 3 of these into one. So whenever the RewriteCond is met, this rule will select everything and then rewrite it as a 301 with a / trailing it. Hope this helps! Let me know if you have any other questions. Regards, Trenton

Ah, thank you so much! Our developer had a feeling the problem had something to do with the whole http/https thing but couldn't quite figure it out. I'll ask him to make the change you suggested and we should be all set! Thanks again - troubleshooting this was turning out to be really time-consuming, so I finally posted the question here out of desperation.

Hi Rebekkah, Sounds like you already understand the pros&cons of using GWT country targeting. Obviously it is hard to make any recommendations without first knowing your niche and auditing the off-page SEO metrics of your competitors, since the big G acts in its own way per niche. There might be some indicators which will make your life harder or easier to rank well for a variety of keywords in US and India at the same time. I would suggest making an off-page audit to understand where your well ranking competitors are getting their links from (where are they hosted, what is their targeted audiance, what kind of social signals they are getting, what language is their anchor keywords?  etc..)

Hi Alex, Sounds like you've already got the nav changes under control which is great! Technically DA is based on your link profile so that won't change, though if you mean just the overall strength of the site, it will drop away from the SERPs once the 301 to the subfolder is in place. In case you haven't already thought of it too, once that redirect is in place, consider reaching out to any valuable referring domains pointing to .ae and ask if they can update the link to .com/ae since the site has moved. This is some easy low-hanging fruit and a great way to drive links directly to subpages as I'd mentioned doing earlier. You will retain most of the strength from these links using the 301 anyway but why sacrifice that 10-20% loss in strength if the referring sites are happy to update a single href?

Hi Aleyda, What you've said makes perfect sense. Thank you so much for your response.

Canonicals and hreflangs must be treated separately. My rule, and this what I said at LearnInbound, from where SEMRush tweeted the tweet you embedded in your post, is this: First set up and/or solve all canonicalization issues your site may have; Once you have solved the canonicalization issues, you can work on implementing the hreflang only on canonical URLs (not canonicalized) In that case of pagination the pages 1, 2, 3, 4, et al have self-referential rel="canonical", so - ideally - the hreflang must reference to the corresponding pages 1, 2, 3, 4, et al of the same pagination in the other country and/or language version. Finally, you are correct regarding the "view all" being the canonical URL of a paginated series.

First off, you're talking about two things here. It sounds like you have two sites that are geo-targeted to two different countries. There might be some translation in there, but if you have a .co.uk and a .com, those need to be treated like different sites as they are targeted at two different markets. Second, please never use an automated IP redirect. Google only crawls from the US, it's asking to not get your .co.uk crawled. In addition to that, it's a poor user experience for some people. As the other commenter mentioned, there is a big chance someone is traveling and needs to see the .com, wants to, and gets redirected to the .co.uk because they are traveling. If you want to attempt to put people in the right place, detect their IP and use javascript to pop up a message if they are going to the other site that asks them if they'd prefer to be on the one associated with their IP. Flags in the header is the best way to go about this in conjunction with the IP detect and javascript prompt. You can even set a cookie after the prompt that will always put them on that country site when they come back.

I have had similar issues with a client.  Take a look at all the information on this thread https://moz.com/community/q/hreflang-for-multple-countries-but-single-language  It might help you to start untangling your particular issue.

Hi Joel, We don't get a lot of questions in this forum about Baidu. That said, I'm a little surprised we haven't had a response to your question yet, as our community of marketing experts is quite diverse in terms of areas of expertise (including international SEO), and includes folks from around the world. I'm reaching out to our team of Associates to see if someone may be able to help you sort this out. Thanks so much for your patience! Christy

Thank you for the responses! It does appear that the number of errors for "au" is decreasing and the tool showed me that things are set up properly. I will update if I see the decreasing errors trend reverse.

If your girlfriend wants to target Russian living in Russia, then you have to go for a .ru domain name and optimize the website thinking at Yandex as main search engine, even though Google is growing very fast right now in Russia too, especially thanks to Android Smartphones, which obviously have Google as main search engine. Here you have the Yandex guide for webmasters. The problem of a .ru domain is that - in Google - it is automatically geo-targeting Russia, so it would be impossible (or very hard) to have a subfolder like www.domain.ru/en/ being able to rank well in Google.com or Google.ca. For that reason, my suggestions is to create the English version using a generic domain. Regarding to your question about hosting the .ru domain in Russia or in the US, you could go for a third option: Hosting in the USA but with a Russian Ip. Finally, ranking in russian in Yandex is not all that easy as you may imagine

Implementing those right away, hope it will work

Hi Edward, It's not recommended to rely on Google capacity "processing" scripts to show any key content on your site, in this case, additional language or country versions. If the information shown in the HTML code and the Google cache version of the pages is not the relevant one -and only one is shown the whole time for example- then it's not being correctly rendered. You can also verify this with the "Fetch as Googlebot" functionality from the Google Search Console. If you want to make sure that each of your language/country versions are really accessible then the best is to make sure each piece of content is published as text in their own specific HTMLs whether in ccTLDs, subdirectories or subdomains for country versions or also, subdirectories or subdomains for language versions; making sure to use the relevant terms and topics for each language/country audiences (which might not necessarily be the literal translations among them, so a unique keyword research, content writing and optimization process by a native speaker is required) Thanks!