There are many acceptable ways to structure your site for both SEO and internationalization. Each have advantages and disadvantages.
Top Level Domains
Buy the same domain name at multiple top level country domains like example.com, example.es and example.de.
Fully supported by Google. You can add the sites to Google Webmaster Tools where ...
If you canonicalise appropriately, it is fine. Use rel="canonical" to specify that the pages are identical, and hreflang for the alternate languages.
<link rel="canonical" href="https://example.org/es/ads/2">
<link rel="alternate" hreflang="en" href="https://example.org/en/ads/2">
<link rel="alternate" hreflang="es" href="https://example.org/...
It is more user friendly to translate slugs, but don't expect, it will bump your site's ranking like a bomb.
Google is able to translate URLs by itself, so it can match a meaning of a page with english URL and italian content.
URL translation could lightly improve your user metrics and user experience, which are ranking factors too.
Also, if you do it, do ...
With the rel=canonical across languages (eg, de -> canonical -> en), you're saying that these pages are equivalent and that you have a preference regarding which URL to index. If that's the case, if you think the translated boilerplate doesn't add more value (which might be the case), then that (I'd call it "canonical language") seems like a good setup.
The Googlebot can submit forms, but it generally doesn't unless it can detect a reason to do so.
So from the links, if your translations were AJAX'd and built properly, Googlebot may very well submit the form to see what the results would be. However, this behavior (especially on POST), is not guaranteed and you should probably use GET to make things more ...
I'm going to try and answer all three questions at once:
If you really want to "optimize" your domains then have each domain live, accessible (non-directed), hosted in their own counties, with their own carefully translated content based on the language of that country. Costly.
If you want to keep things as simple as possible (like Apple), then pick the ....
The problem with your set-up (from an SEO standpoint) is that search engines don't accept cookies, so whenever a bot follows a link to your root domain, it'll be sent to your English content. Hopefully, there's an abundance of links to the other language content, too, but in my experience, this situation nevertheless seems to lie at the root of a lot of ...
Canonical tags are no longer needed in the mark up for multilingual sites, you can see here where Google no longer recommends using canonicals in multilingual markup (the struck out section):
new markup for multilingual content (old blog post)
So this just leaves you with two options, use either rel="alternate" hreflang="x" tags or use the rel="alternate" ...
The typical format for a locale is comprised of the two letter language code followed by the two letter country code. For example, here is a list of all the locales supported by Java:
Language Country Locale ID
Albanian Albania ...
Splash screens are acceptable according to Google. They do offer some best practices however, when using multi-language/multi-regional sites.
In this article, Google recommends the use of the hreflang tag within <link rel="alternate" ... /> tag in the head. The specific excerpt from the article is below:
For language/country selectors or auto-...
From Google Webmaster Tools Support page on Multi-region and multilingual sites
Managing multilingual versions of your site
Make sure the page language is obvious
Google uses only the visible content of your page to determine its
language. We don’t use any code-level language information such as
Lang attributes. You can help Google determine ...
Definitely keep the <link> tags in your <head> section. I've never read anywhere that Google actually acknowledges rel="alternate" on <a> tags. Also many other bots may only retrieve the <head> of your documents, so if those <link> tags aren't in the header, they may never actually see them. But I don't think that having the rel=...
It is a confusing state of affairs, but here are some pointers:
Don't use the canonical tag in the way you were thinking. Content translated into several languages is not duplicate content. So you don't want to be pointing /fr/ --canonical--> /en/ at all. Use rel="alternate" hreflang="en" instead. Use canonical within a given language to account for ...
You should use the lang attribute (e.g., on the html element) to declare the language, not a meta tag.
This allows you to overwrite the language declaration for other parts on the page (note the lang attributes in my example markup for a language switcher).
Anyway, having a few words in a different language shouldn’t affect your SEO at all, whether you use ...
You need to give the translated versions separate URLs if you want Google to index them. From Google's "Working with multilingual websites" blog post:
To make all of your site's content more crawlable, avoid automatic
redirections based on the user's perceived language. These
redirections could prevent users (and search engines) from viewing all
I believe the problem might be due to auto redirecting the root url ('/') or automatically setting the language, should I exclude robots somehow?
Correct. Googlebot et al don't send an Accept-Language header, or accept cookies, so it'll see whatever the site defaults to without it, which would appear to be English in this case. You can verify this using ...
As of Jun 10, 2014 Google recommends either ccTLDs, Subdomains with gTLDs or Sub-directories with gTLDs. URL parameters such as ?lang=en are not recommended:
(Funny that the page which says that it's not recommended to use URL parameters for this, is actually doing exactly this.)
Here's Google's own tips for multilingual sites. In summary:
Make sure the page language is obvious by sticking to one language per page.
Tell Google if your site is targeting a ...
Bing absolutely does. Before I told it not to it would continually submit both a contact form and a survey form. I knew it was Bingbot because I included $_SERVER['HTTP_USER_AGENT'] in the $_POST information. No other spider ever submitted those forms.
It's my understanding that we at Google don't use any of the language meta-information within PDF files. You can, however, use the hreflang information via HTTP header or Sitemaps file for non-HTML content too.
This is the language which dominates because there are many countries which use the same language. That's why, you need to specify to language first and then precise with the country.
Thus, the most appropriate is http://www.example.com/en-in/.
However, there is no impact on SEO, it's just a standard.
For this kind of stuff, you can just take a look how ...
Many multi-lingual sites don’t have the language tag for the default/primary language in the URL¹, but I think it’s better to include it. So yes, in my opinion, it’s not only good design, it’s the best.
Its suggesting itself to use the root page as a site/language chooser. I think there are three ways how this page can work:
Redirect (based on certain ...
If duplicating the image really is unnecessary then you could still perhaps have the best of both worlds... only store the image once, but have it referenced by different filenames, for the different languages - using mod_rewrite (Apache) and an internal rewrite.
Based on unor's example:
These would ...
You're going about it the wrong way.
The proper way to set up a multilingual site is, as toomanyairmiles' links outline, to set up different localized subsites, either in separate directories or subdomains, e.g.
en.example.com / example.com/en/
de.example.com / example.com/de/
Google will recognize each subsite's targeted locale based on the content. ...
If you don't have a specific locale, you can just specify the language. Google give an example here: rel="alternate" hreflang="x"
If you have several alternate URLs targeted at users with the same
language but in different locales, it's a good idea to provide a
generic URL for geographically unspecified users. For example, you may
have specific ...
You need to include the "/" URL in your Sitemap file and specify it as the hreflang "x-default". That way, Google will know that this is a part of your set of pages, and will be able to handle it appropriately. Note that hreflang is a signal, and not a directive for Google, so it might be that the "/" URL still occasionally shows up.