Welcome to the Q&A Forum

Great, thanks!

This sounds like the best approach. Typically, most crawlers won't save or interact with cookies, so Google etc will just see the site they've requested.

You only need the HREFLANG for the pages that you have translations for.

First of all, a caveat: if your site is ranking even moderately well, I would not change the URL structure. Once search engines have indexed content, they really don't like it when you play around with the URLs later. The exception would be your language URLs - if you're not already consistent about those or you don't already have those set up, then by all means set up whatever works for you, thinking as much as possible about how you might need to expand in the future so you can solve for that now, and not be in the same boat of wanting to change URLs again later. At the very least, in your shoes, I would first dive deep into analytics and find out what the most-visited folder structure is. Then if you decide to standardize them all, at least go with that version of the structure, and make sure you're putting in one-to-one redirects so you can preserve as much link juice as possible. As to your more specific questions - these are answers more to what I would do if I were setting up a new site, and not if I were thinking about optimizing by changing a ton of the hierarchy. 1. Language URL - I lean toward #2, language in a folder, for a couple of reasons. To me it intuitively feels like everything in that language would be in that folder - in your example, .com/fr/ - and thereby grouped structurally, a signal to both search engines and humans that they are in the (insert language name here) language version of your site. Another reason is that after a certain point, parameters can get truncated, so if you're using other parameters - some that come to mind are Google Analytics' utm_source, utm_campaign, utm_medium - you may end up exceeding the max characters if you go the alternate route of language in a query string. 2. I would stick with either option 1 or option 3. While search engines are getting smarter about parsing, just like with the language folder, I think there's a lot to be said for showing some sort of structure and hierarchy by using a folder structure rather than mixing category with product name. Option 3: I'd suggest .com/toplevelcategory/product-name/ - and not include any of the subcategories as in .com/toplevelcategory/childcategory/grandchildcategory/product-name/ because it makes the URLs so long. Some of the benefits of having long URLs are that your tech-savvy users will visually recognize the hierarchy more easily and can quickly jump up a couple of levels just by chopping off a couple of folders in their address bar, and of course you can include more keywords the more folders you have. Drawbacks, though, are that in SERPs the full URL gets chopped off and looks less appealing to end users. On a related note, using Schema breadcrumbs (which are also visible to the user) is a great way to give additional signals to both search engines and users about what all those various levels are. 3. Just the fact that you used the term "keyword stuffing" would make me quite cautious. It's not about stuffing, it's about optimizing for both humans and spiders. In your shoes, I would again go to analytics and figure out what is already bringing you the most success - a combination of pages with the most organic traffic along with pages that convert really well. From there, I'd see what traits they have in common. Do all of them have longer content? Do you have some sort of special tags or something that is clearly working well? If you don't want to get into the weeds and start optimizing pages individually, look hard at your Product Detail Page template. Make sure it pulls a decent title and meta description from a template (but that you can override it later if you ever have time to do one-by-one page optimization). By far the biggest thing you can do on any of your pages, besides getting basic page structure clean and clear, is to add Schema markup. A few tweaks to your PDP template and you should be able to show price, reviews, etc. to both humans and spiders. If for some reason you can't edit the template, look for similar gains through Google Search Console. They have a content highlighting tool that will let you highlight a series of pages to show it where to find certain information, and they'll then understand (and presumably rank) your content much better. It varies by site, but if you're using old markup (say an XHTML transitional 1999 doctype) or lots of tables or tons of nested divs, that type of optimization can give you pretty decent gains as well. Cleaning up the codebase is often a huge ranking signal because it affects a ton of pages and shows you care about modernizing and improving UX.

Hello there, I'd advise against using a ccTLD that is not used generally as a gTLD. It might be more tricky to rank globally. Take into consideration that .ag ccTLD reffers as the country code domain of Antigua an Barbuda. And its listed as a ccTLD: Delegation Record for .AG - IANA Also, google may consider that TLD as a generic, as stated here: International Targetting - Search Console Help. There might be another TLD that suit a variation of that idea. Hope it helps. Best luck. GR.

Thanks for the advice Gianluca! That would be ideal (not even create a clone). The problem with that approach is that the UX would break if a user lands on the Russian versions and then tried to navigate to a page which doesn't exist (like a none translated page in the top nav). How would you handle that? Not too worried about crawl budget as it's a very small site. Would you agree there is no cause for concern for a site which only has around 120 pages? Good idea re "implementing the hreflang and setting it up to "en-ru" for the English pages targeting Russia and simply "en" in the ones targeting the English speaking users in the rest of the world."

thanks Nigel

In fact, what the client really wants is this... ... any user in the UK who: clicks on a link from social media (which goes to domainname.com) searches google for domainname.com types in the URL domainname.com ... ALWAYS be redirected to "domainname.co.uk" so they only see what the client sells direct from the UK. This sounds to me way beyond just hreflang. This sounds like it might need some kind of redirection based on IP?

I see a lot of confusion in all the answers :-). The .ie domain is never treated as a generic domain name by Google. It's the country code domain for Ireland. Stop. A country code domain name is geo-targeted by default on its corresponding regional version of Google, but Google doesn't "block" its visibility also in others Google (i.e.: Google.com or Google.co.uk), however, a ccTLD will have more difficulties in ranking higher in another Google than its own. In other words: domain.ie is targeting by default Google.ie; but, it can be shown in Google.co.uk too; however, for ranking in Google.co.uk - because of its geo-targeted nature - it must have stronger signals like mentions and backlinks to justify its visibility than a domain.co.uk or domain.com.

I suspect you didn't understood the question. MTBE was asking if schema.org structured data items must be in the language used in the subfolder. For instance, in www.domain.com/en/, will be the items written in English and in www.domain.com/es/ in Spanish? The answer is yes.

Albeit your answer is correct, Google itself states in its guidelines page about Multilingual and Multiregional websites that - due to the diffusion and mainstream use of cloud hosting - that the physical localization of a server is not anymore considered as a prominent geotargeting factor. Therefore, I would consider having a server in a hosting located in the same country we are targeting, if the latency really may mean the difference between a slow and a fast website. If it doesn't... I would not worry about its location.

Anyone?

Hello Steph, I'm assuming you have read about hreflang tags. This is the correct action for your site. On each domain that you have, you will need to have three link elements in the source code on each page. For example, on the homepage of every domain name, you would need the following tags: And on every other page on the site, you would need to replace the web address with the corresponding address of each language version of the page. This tells search engines the relationship between each page, and the language of each. By using hreflang tags correctly, you will not be penalised for having duplicate content on each page. That said, make sure that any text that should be different on each international version is indeed different. Ensure things like localised spelling, currency, and any country-specific information are specific to each country. I hope this helps.

Yup, that makes sense to me. It's a bit of a grey area and an unusual case, but I think that this approach makes more sense - otherwise you're actively trying to stop people who aren't in the 'correct' country for a phone number to find/access that page.

Hi poliedric, I seem to remember a situation when it was loading by ajax, could that be your case? that could explain you not finding it in the source code and GSC still showing you the tag. Info on extentions for finding ajax content https://stackoverflow.com/questions/7830864/jquery-load-data-not-showing-up-in-page-source I´m not a coder though so could be other reasons Hope this helps

It would be useful to see an example of what you mean, but the answer is probably not. What to do first is: Ensure you set up hreflang correctly, so that Google understands your Chinese-language page on New York and your English-language page on New York are functionally equivalent. Use a good rank tracker, and configure it to check your keywords on each of the country-level Google sites you're interested in (Google.co.kr for Korea, and so on). See whether the correct page is showing up when you track ranks for the foreign-language name, and for the phonetically-translated name. Check Search Console for the appropriate pages, using the country filter to look only at the kinds of queries and clicks you're getting from each of the countries you're interested in. See whether people are actually searching with the Asian-language name for the city, or with a phonetic translation. See whether people are searching for the English name (they might be). If, after looking at your rank tracking and search console results, you think there are many people in Asia putting English-language city names into their queries, at that point you could consider going ahead with this idea. Even then, try it on just a few of your city pages at first—not all of them—and continue to refer back to your rank tracker. What you don't want to see is any direct competition between different language versions of the same page, in the same SERP.

I think it's your handling of the /ar/ version and multilingual setup. On https://new-waves.net/ you have: rel="alternate" hreflang="ar" href="https://new-waves.net/ar/" /> But you should self reference the English version: <code>https://new-waves.net/" /></code> And you should also add that to the /ar/ version of every page. Here's Google full documentation on hreflang: https://support.google.com/webmasters/answer/189077?hl=en