Welcome to the Q&A Forum

Hreflang tags should point to the canonical version of the page. So yes, please remove the ?d=Womens from all your Hreflang URLs. Here are the results of a test run on this URL to check for Hreflang errors: https://app.hreflang.org/results.php?runid=f622e3d03dbf4a03958c6a6d2d180bd020160719202039 You will see that all errors are because of the ?d=Womens in the URLs.

Not the parameter, specifically speaking, You need to have the canonical on the mobile URL exactly match the primary URL of the non-mobile page. So removing the /mobile/ directory from the URL. (Technically, a parameter is something added at the end of a URL with a "?" so /product/product-code?sort=desc for example, which you didn't show on your examples. Canonical URLS should never include such parameters. In fact one of the main reasons for using canonicals is to fix issues with extra unwanted parameters being indexed as separate page. Didn't want to risk confusion here.) Paul

Hi Paul! It sounds like ThompsonPaul has answered your question. Are you all set, or can we be of more help?

See https://moz.com/community/q/in-google-search-console-https-or-non-https The HTTP:// will be added on to any non-HTTPS URL Automatically. I always type it in HTTP://  because of habit, however, it does not make a difference because Google ads it the only time this makes a difference is when adding HTTPS:// So it makes no difference whatsoever as long as you have the four versions of your encrypted site you can choose between Google is indexing more than one of the four below. http:// https:// http://www. https://www. just be certain that all four are there do not worry about the non-encrypted http:// https://moz.com/ugc/accidental-seo-tests-when-on-page-optimization-ceases-to-matter https://www.deepcrawl.com/knowledge/news/https-when-to-act/ https://www.deepcrawl.com/knowledge/best-practice/https-dilemma-security-seo/ I hope that answers your question. All the best, Thomas

Thanks Mike!

Thanks Jordan, Unfortunately that article doesn't say much. I'm more interested in case studies. From what I've read, it's definitely not the sole reason for ranking BUT can be a ranking factor. Correct me if I'm wrong, but I feel like it would be great for "internal links" and long tail keywords.

While we'd all prefer a world in which there weren't messy parameters everywhere, they're often necessary for all kinds of reasons — tracking being a good example. So: Take a note of each of the parameters. Go to the 'Crawl' section in Google Search Console and then to 'URL Parameters'. Enter each of your tracking parameters there. When asked whether the parameter changes the page content seen by the user, answer honestly. If these are just tracking parameters, you should be OK to answer "No" in every case. Make sure that there is a canonical tag in place (which it sounds like there is, from your question). The canonical version shouldn't have any parameters. If you have a feature for users to share a page — "share this page on Facebook", for example — try and ensure that the shared URL is the canonical version. You have a bigger issue with duplicate URLs. These pages should not co-exist: sitename.com/productname-xyz/ sitename.com/productname-xy-z/ If I understand your question correctly, these pages are both of the same product. Pick a preferred URL and stick with it. Permanently redirect the other URL. A canonical tag will deal with the parameters, but you can't rely on it to solve duplicate page paths like this.

And so would I run the OLD site into screaming frog or I'd go with the new site? Thanks.

It should be fine, but if you want to be certain, check the info:sitea.com query in Google for a random selection of URLs from sitea.com so that you can make sure they are all properly indexed now as Site B.

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

Hi Jarred! We'd love an update on this. Did Eric's response help?

Jarred, Whenever you move to a new domain name Google will keep the old domain name indexed for up to a year (or longer!). It's just the way that Google does it, I suspect that it's because you may change your mind and go back to the old domain. Having the old domain indexed in Google isn't a problem, as users should be redirected to the content on the new domain. It will take up to a year for Google to stop indexing the old domain. By the way, make sure you use the Google Change of Address Tool in Google Search Console, it will really help.

I suggest you to dig into the possible issues Dirk is talking about, especially if there are some JavaScript and cookies on the works. In fact, I have seen several cases where a not perfect JavaScript use may end up screwing things. i.e.: I go to domain.com - english - and then go to its russian version - domain.ru - from the selector and then go back to domain.com, but now the version I see is the russian in domain.ru because of bad JScript and cookie management.

The Dirk answer points to some potential answers. Said that, when I click on your SERP's link, I see others sitelinks (just two): the first >>> Robes the second >>> Вся распродажа. As Dirk pointed out, your site has detected my IP (quite surely, but maybe it is user agent), and when I click on the second sitelink I see this url: http://www.revolveclothing.es/r/Brands.jsp?aliasURL=sale/all-sale-items/br/54cc7b&&n=s&s=d&c=All+Sale+Items. The biggest problem, when it comes to IP redirections, is that they are a big problem in terms both of SEO and usability: SEO, because googlebot (and others bots) will mostly be redirected to the USA version due to their IPs, even though Google crawls site also from datacenters present in other country (but much less); Users, because you are making impossible, for instance, to a Spanish user to see the Spanish site whenever they are not in Spain. And that really sucks and pisses off users. There's a solution: making the IP redirection just the first time someone click on a link to your site and if that link is not corresponding to the version of the country from were users and bots are clicking; presenting the links to the others country versions of your site, so that: bots will follow those links and discover those versions (but not being redirected again); users are free to go to the version of your site they really need (but not being redirected again if coming from those country selector links). Said that, it would be better using a system like the one Amazon uses, which consists not forcing a redirection because of IP, but detecting it and launching an alert on-screen, something like: "We see that you are visiting us from [Country X]. Maybe you will prefer visiting [url to user's country site]". Then, i just checked the hreflang implementation, and it seems it was implemented correctly (at least after a very fast review with Flang). I tried to search for "Resolve clothing" in Spain incognito and not personalized search, and it shows me the Spanish website and Spanish sitelinks correctly; I tried the same search from Spain but letting Google consider my user-agent (setup for English in search), and I saw the .com version and English sitelinks (which is fine). Remember, sitelinks are decided by Goggle and we can only demote them. To conclude, I think the real reason has to be searched not in a real international SEO issue (but check out the IP redirection), but to a possible and more general indexation problem.