Multilanguage / Unterverzeichnis JTL 3 / SEO

[BBB]

HI !

Aktuell bin ich auf der Suche nach einer Möglichkeit bzw. einem Lösungsweg, wie man mehrsprachige Shops aus Sicht der SEO mit JTL bestmöglich präsentieren kann. Ich habe mir bereits sämtliche Beiträge im Forum zum Thema SEO und Unterverzeichnisse bzw. Subdomains durchgelesen,konnte aber noch keine brauchbare Lösung finden.

Parallel zu JTL betreibe ich noch einen alten XTC, der unter anderen das SEO-URL Modul von Shopstat einsetzt.

Shopweit findet hier eine Untsercheidung der Sprache (Content, Produkte, Kategorien) statt, ausschließlich via eines kurzen PHP Skripts und entsprechenden Einträgen in der HTACCESS werden die Url's neu gebildet:

www.xyz.de/de/Artikel-1.html
www.xyz.de/en/Article-1.html

Da ich an den Quellcode von JTL nicht selbt herankomme, ich derzeit leider keine Zeit habe mich in das Plugin Developement einzuarbeiten: Hat jemand eine Idee, wie man dies bei JTL bewerkstelligen könnte? Bei erfolgreicher Lösung soll es natürlich auch nicht kostenlos sein.

Als Umweg müsste ich das Multilanguage Modul beziehen und für jedes Unterverzeichnis "en", "de" eine eigenene Installation vornehmen. Das MUSS doch auch via htaccess möglich sein??

LG

 

[casim]

AW: Multilanguage / Unterverzeichnis JTL 3 / SEO

und wofür sollen die Sprach-Unterverzeichnisse gut sein?

Der JTL-Shop3 verzichte konsequent auf zu lange/verschachtelte URLs

 

[testjo]

AW: Multilanguage / Unterverzeichnis JTL 3 / SEO

Vielleicht weil laut viele seo Artikel auch gogole und co über mehrsprachen und country zuweisung dazu sagen.

Am besten soweit ich mich die errinere dieser Reihefolge:
1- country tdl 's als domain
2- subdomain wie de. shop.de en.shop.de unsw
3- ein sprachverzeichnis wie shop.de/de shop.de/en unsw.

So viel extra

lange/verschachtelte URLs

ist es nicht mit den eine Verzeichnis 2 Buchstaben , wen man ob es sin macht die www. noch streicht. ( glaube da gibt auch einiges dagegen) ist es fast gleich. ( Ok Subverzeichnis, aber den Länge

Ob es alles stimmt tja ein andere shop und System von Uns in Ausland (ausland tld und server aber ein /de Sprach Verzeichnis) gleiche Produkten Beschreibungen unsw. dan den Deutsche Jtlshop.
Die Ausland shop scheint immerhin so einiges von Deutschsprachige Kunden zu locken. ( Ob es den Country Verzeichnis ist oder dass Shopsystem teils ein bessere SEO zulässt/ an board hat ( oder nur einfacher zu händlen) wissen wir so nicht) Shop in Ausland ist nicht so alt wie die IN Deutschland, Produkten schalten wir meist erst Frei in Deutsche Shop unsw.
(
Am meisten war dies aufgefallen nach update jtlshop v3.15 nach v3.19, aber über den SEO und mehrsprachen auch wen man Seo erweiterung in WAWI hat da sind wir selbe mit den jtlshop und wawi scheinbar nicht so Gut in den settings und alles was man dan noch mehr an Aufwand dazu hat wen es überhaupt alles an Uns liegt, glaube vor allem Hersteller und Kategorie

Wir können damit leben da Uns egal ob über den DE shop oder Deutsch über Ausland shop kaufen, ob es besser kan ja naturlich immer, teils selbst schuld vielleicht glauben wir auch

Tja dan gehen wir nach den Plaudern über Neue Shopconnector nen lieber nicht ist zu spät abends...

Wen Sprachverzeichnis kan man sich auch gleiche produktnamen / kategorie / hersteller unsw leisten in verschiedene Sprachen wen es sein muss ohne den ....


Was besser ist, meinungen gehen auseinander also da kan ich nur zu sagen was man übliche drüber sagt, und Unsere Erfahrung ( und Arbeitsvorgang andere ShopSYSTEM), die nicht 1 auf 1 auf dass zurück zu leiten ist aber doch vielleicht..

Genau Messen tun wir nur wen etwas wirklich nicht lauft oder im Grobe sachen wie den Auswertung besucher ( serverseitig) oder Google WMT problmen gibt die man ohne scheinbar nicht 123 beheben kan. Weis gibt mehr an info's aber auch aufwand und noch so einiges wie den privacy und co. Den wirkliche Verkauf ist eben wichtig. Wen das nicht stimmt gibt es soviele faktoren neben den SEO ....

 

[BBB]

AW: Multilanguage / Unterverzeichnis JTL 3 / SEO

und wofür sollen die Sprach-Unterverzeichnisse gut sein?

Damit die Unterscheidung der Sprachen klar in den URLs definiert wird. Derzeit wird nur die Url erweitert, beispielsweise mit einem "_1", wenn das Produkt den selben Namen hat, was ja oftmals vorkommt. Zusätzlich wird die Content Language in den Meta Tags automatisch definiert. Ich habe bei einigen, nicht auf JTL basierenden Shops, die Erfahrung gemacht, dass die jeweiligen Sprachvarianten wesentlich mehr Autorität von Google erhalten, wenn diese eben (virtuell) in einem Unterverzeichnis liegen.

Am besten soweit ich mich die errinere dieser Reihefolge:
1- country tdl 's als domain
2- subdomain wie de. shop.de en.shop.de unsw
3- ein sprachverzeichnis wie shop.de/de shop.de/en unsw.

Meiner Meinung nach völlig korrekt. Hier hat man bei den ersten beiden Varianten wieder das Problem, dass man nicht um den Kauf von zusätzlichen Lizenzen herumkommt.

Gibt es denn hier nicht einen Coder, der Lust hätte ein solches Plugin zu basteln?

 

[karabey]

AW: Multilanguage / Unterverzeichnis JTL 3 / SEO

Korrekt wäre (für Google Suchmaschine) das die Sprachen mit www.domain.com/de oder www.domain.com/en getrennt werden.
Durch Bindestriche oder Zahlen kann man für z.B. Google keine Sprache definieren.

Zitat Google Webmasters

What is international targeting?

If you manage one or more websites designed for users in a specific country speaking a specific language, you want to make sure that search results display the relevant language and country version of your pages. To ensure that your content reaches the correct audience, you will use two general mechanisms:

• URL-level targeting
  You can use three implementation mechanisms for this:
  1. Page-level markup
     Use the <link rel="alternate" hreflang="x" href="alternateURL"> tag in the <head> section of your pages to list alternate language versions for each page. Each page should provide an hreflang tag that links to all other language variants of itself, as well as a tag that refers back to itself. For more granular targeting, you can use the hreflang attribute to indicate language and country combinations (e.g. en-ie, en-ca, en-us). Read more about the hreflang tag in our Content guidelines section.
  2. Sitemaps
     You can use sitemaps to submit language and regional alternates for your pages. Read more about using a sitemap to indicate alternate language pages in our Content guidelines section.
  3. HTTP headers
     If you publish non-HTML files (like PDFs), you can use an HTTP header to indicate a different language version of a URL.
• Site-wide targeting
  In addition making sure your site URLs map to alternate language variants, you will also likely use geographic-specific domains or configure your entire site structure to deliver content to a specific geographic and language preference. To learn more, read the best practices as explained in Multi-regional and multilingual sites in our Content guidelines.

Quelle: https://support.google.com/webmasters/answer/6059209

Multi-regional and multilingual sites

A multilingual website is any website that offers content in more than one language. Examples of multilingual websites might include a Canadian business with an English and a French version of its site, or a blog on Latin American soccer available in both Spanish and Portuguese.
A multi-regional website is one that explicitly targets users in different countries. Some sites are both multi-regional and multilingual (for example, a site might have different versions for the USA and for Canada, and both French and English versions of the Canadian content).
Expanding a website to cover multiple countries and/or languages can be challenging. Because you have multiple versions of your site, any issues will be multiplied, so make sure you test your original site as thoroughly as possible and make sure you have the appropriate infrastructure to handle these sites. Following are some guidelines and best practices for creating multilingual and/or multi-regional sites.


Managing multilingual versions of your site

Here are some tips for making sure that your localized content appears in search results for the appropriate language.


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 the language correctly by using a single language for content and navigation on each page, and by avoiding side-by-side translations. Translating only the boilerplate text of your pages while keeping the bulk of your content in a single language (as often happens on pages featuring user-generated content) can create a bad user experience if the same content appears multiple times in search results with various boilerplate languages.
Use robots.txt to block search engines from crawling automatically translated pages on your site. Automated translations don’t always make sense and could be viewed as spam. More importantly, a poor or artificial-sounding translation can harm your site’s perception.


Make sure each language version is easily discoverable

Keep the content for each language on separate URLs. Don’t use cookies to show translated versions of the page. Consider cross-linking each language version of a page. That way, a French user who lands on the German version of your page can get to the right language version with a single click.
Avoid automatic redirection based on the user’s perceived language. These redirections could prevent users (and search engines) from viewing all the versions of your site.


Carefully consider your choice of URL

Google uses the content of the page to determine its language, but the URL itself provides human users with useful clues about the page’s content. For example, the following .ca URLs use fr as a subdomain or subdirectory to clearly indicate French content: http://example.ca/fr/vélo-de-montagne.html and http://fr.example.ca/vélo-de-montagne.html.
Signaling the language in the URL can also help you to discover issues with multilingual content on your site.
It’s fine to translate words in the URL, or to use an Internationalized Domain Name (IDN). Make sure to use UTF-8 encoding in the URL (in fact, we recommend using UTF-8 wherever possible) and remember to escape the URLs properly when linking to them.


Targeting site content to a specific country

If Google is aware of the country targeted by a site, we can use this information to improve the quality of our search results in different countries. Google generally uses the following elements to determine a website’s targeted country:

• Country-code top-level domain names (ccTLDs). These are tied to a specific country (for example .de for Germany, .cn for China), and therefore are a strong signal to both users and search engines that your site is explicitly intended for a certain country. (Some countries have restrictions on who can use ccTLDs, so be sure to do your research first.) We also treat some vanity ccTLDs (such as . tv, .me, etc.) as gTLDs, as we've found that users and webmasters frequently see these as being more generic than country-targeted (we don't have a complete list of such vanity ccTLDs that we treat as gTLDs, because such a list would change over time). See a full list of domains Google treats as generic.
• Geotargeting settings. You can use the Country targeting tool in Webmaster Tools to indicate to Google that your site is targeted at a specific country. Do this only if your site has a generic top-level domain name. However, don’t use this tool if your site targets more than a single country. For example, it would make sense to set a target of Canada for a site about restaurants in Montreal; but it would not make sense to set the same target for a site that targets French speakers in France, Canada, and Mali.Note: Because regional top-level domains such as .eu or .asia are not specific to a single country, Google treats them as generic top-level domains.
• Server location (through the IP address of the server). The server location is often physically near your users and can be a signal about your site’s intended audience. Some websites use distributed content delivery networks (CDNs) or are hosted in a country with better webserver infrastructure, so it is not a definitive signal.
• Other signals. Other sources of clues as to the intended audience of your site can include local addresses and phone numbers on the pages, the use of local language and currency, links from other local sites, and/or the use of Google My Business (where available).

Google does not use locational meta tags (like geo.position or distribution) or HTML attributes for geotargeting.


URL structures

Consider using a URL structure that makes it easy to geotarget parts of your site to different regions. The following table outlines your options:

URL structure	Example	Pros	Cons
Country-specific	example.ie	Clear geotargeting Server location irrelevant Easy separation of sites	Expensive (can have limited availability) Requires more infrastructure Strict ccTLD requirements (sometimes)
Subdomains with gTLDS	de.example.com	Easy to set up Can use Webmaster Tools geotargeting Allows different server locations Easy separation of sites	Users might not recognize geotargeting from the URL alone (is "de" the language or country?)
Subdirectories with gTLDs	example.com/de/	Easy to set up Can use Webmaster Tools geotargeting Low maintenance (same host)	Users might not recognize geotargeting from the URL alone Single server location Separation of sites harder
URL parameters	site.com?loc=de	Not recommended.	URL-based segmentation difficult Users might not recognize geotargeting from the URL alone Geotargeting in Webmaster Tools is not possible

Geotargeting isn’t an exact science, so it's important to consider users who land on the "wrong" version of your site. One way to do this could be to show links on all pages for users to select their region and/or language of choice.


Duplicate content and international sites

Websites that provide content for different regions and in different languages sometimes create content that is the same or similar but available on different URLs. This is generally not a problem as long as the content is for different users in different countries. While we strongly recommend that you provide unique content for each different group of users, we understand that this might not always be possible. There is generally no need to "hide" the duplicates by disallowing crawling in a robots.txt file or by using a "noindex" robots meta tag. However, if you're providing the same content to the same users on different URLs (for instance, if both example.de/ and example.com/de/ show German language content for users in Germany), you should pick a preferred version and redirect (or use the rel=canonical link element) appropriately. In addition, you should follow the guidelines on rel-alternate-hreflang to make sure that the correct language or regional URL is served to searchers.

Quelle: https://support.google.com/webmasters/answer/182192