Neu JTL-Shop 5.7.2: Unterschiedliche Standardsprachen in tsprache – widersprüchliche Canonical- und Hreflang-Ausgabe der Startseite

  • Ersteller des Themas Ersteller des Themas surus
  • Erstellungsdatum Erstellungsdatum

surus

Sehr aktives Mitglied
28. September 2016
535
49
Hallo zusammen,

wir betreiben einen mehrsprachigen JTL-Shop 5.7.2 mit Deutsch und Englisch. Als Template wird SALEPIX AVIA mit Child-Template eingesetzt.

Der Shop besteht schon seit vielen Jahren und wurde ursprünglich mit Englisch als Standardsprache eingerichtet. Später wurde Deutsch in der Verkaufskanalverwaltung als Standardsprache festgelegt. Von einer vollständigen nachträglichen Umstellung der ursprünglichen Standardsprache wurde uns früher wegen möglicher Folgewirkungen abgeraten.

Aktuell zeigt die JTL-Wawi Deutsch als Standardsprache des Verkaufskanals an. In der Shop-Datenbank stehen in der Tabelle tsprache jedoch folgende Werte:


Deutsch:
cISO = ger
cStandard = N
cShopStandard = Y
active = 1

Englisch:
cISO = eng
cStandard = Y
cShopStandard = N
active = 1


Wir möchten klären, ob diese Kombination bei einem historisch gewachsenen Shop normal und unterstützt ist oder ob dadurch die folgende widersprüchliche Startseitenlogik entsteht.

Die normale URL-Struktur des Shops ist flach. Deutsche und englische Artikel bzw. Inhaltsseiten haben unterschiedliche SEO-URLs, aber grundsätzlich keine Sprachverzeichnisse wie /de/produkt oder /en/product.

Die Startseite ist jedoch ein Sonderfall.

Verhalten der Startseiten-URLs​

Bei deutscher Sitzung liefert:


https://example.com/
Canonical: https://example.com/de
Hreflang de: https://example.com/
Hreflang en: https://example.com/?lang=eng
Hreflang x-default: https://example.com/


Die URL:


https://example.com/de


liefert:


Canonical: https://example.com/de
Hreflang de: https://example.com/
Hreflang en: https://example.com/en
Hreflang x-default: https://example.com/


Die englische URL:


https://example.com/en


liefert:


Canonical: https://example.com/
Hreflang de: https://example.com/
Hreflang en: https://example.com/en
Hreflang x-default: https://example.com/


Wenn die Root-URL / mit englischem Sprachcookie geöffnet wird, zeigt sie englische Inhalte und canonicalisiert auf sich selbst:


https://example.com/
Canonical: https://example.com/


Das Canonical der Root-URL ist damit abhängig von der gewählten Sprache bzw. vom Cookie.

Sprachumschalter​

Der Sprachumschalter enthält normale HTML-Links, zum Beispiel:


<a href="https://example.com/?lang=eng" rel="nofollow">


und:


<a href="https://example.com/?lang=ger" rel="nofollow">


Je nach vorheriger Navigation erscheinen beim Sprachwechsel teilweise die Parameter-URLs /?lang=eng und /?lang=ger, teilweise aber auch /en und /de.

Auch Logo und Menüpunkt „Home“ verlinken nicht immer identisch:


Deutsch:
Logo → /de
Home → /

Englisch:
Logo → /
Home → /


Google und Sitemap​

Die XML-Sitemap enthält ausschließlich die Root-URL / als Startseite. /de, /en und die Sprachparameter-URLs sind nicht als Startseiten in der Sitemap enthalten.

In der Google Search Console ergibt sich folgendes Bild:


/:
indexiert
vom Shop angegebenes Canonical: /de
von Google ausgewähltes Canonical: /

/de:
nicht indexiert, Duplikat
vom Shop angegebenes Canonical: /de
von Google ausgewähltes Canonical: /

/en:
indexiert
vom Shop angegebenes Canonical: /
von Google ausgewähltes Canonical: /en


Google ignoriert somit aktuell sowohl das Canonical von / auf /de als auch das Canonical von /en auf /.

Unsere Fragen:

  1. Ist die Kombination cStandard = Y bei Englisch und cShopStandard = Y bei Deutsch ein regulär unterstützter Zustand, wenn die Verkaufskanal-Standardsprache nachträglich geändert wurde?
  2. Welche Bedeutung haben cStandard und cShopStandard in JTL-Shop 5.7.2 genau?
  3. Welche dieser beiden Angaben steuert die Canonical- und Hreflang-Ausgabe der Startseite?
  4. Ist es vorgesehen, dass die Root-URL / je nach Sprachcookie unterschiedliche Inhalte und unterschiedliche Canonicals ausliefert?
  5. Ist es normales JTL-Verhalten, dass /en auf / canonicalisiert und die deutsche Root-Seite auf /de?
  6. Sollte bei einer flachen URL-Struktur die bevorzugte Zuordnung stattdessen so aussehen?

Deutsch: https://example.com/
Englisch: https://example.com/en


jeweils mit Self-Canonical und konsistentem Hreflang?

  1. Werden Canonical und Hreflang für die Startseite vollständig durch den JTL-Core erzeugt, oder kann das Template diese Werte verändern?
  2. Sind die mit rel="nofollow" versehenen Links des Sprachumschalters JTL-Standard oder eine Template-Anpassung?
Wir möchten ausdrücklich keine direkte Änderung an tsprache oder an der Standardsprache vornehmen, bevor die technischen Zusammenhänge geklärt sind.

Hat jemand eine vergleichbare Konstellation nach einer früheren Änderung der Standardsprache gehabt? Wie wurde das gelöst, ohne bestehende SEO-URLs und Sprachzuordnungen zu gefährden?

Vielen Dank für eure Einschätzung.
 

surus

Sehr aktives Mitglied
28. September 2016
535
49
Wir haben inzwischen eine Antwort von JTL Support bekommen.

zunächst einmal, dass cStandard und cShopStandard sich unterscheiden ist in Ordnung und eine Sache der Konfiguration.
cStandard ist die Standardsprache der Wawi, cShopStandard ist die eingestellte Standardsprache des Shops.

Dadurch kommt es aber offenbar im Code zu inkonsistenzen.

Folgenden Hotfix könnten Sie einmal ausprobieren:

In der includes\src\Router\Controller\AbstractController.php ~Zeile 544

if (!LanguageHelper::isDefaultLanguageActive(languageID: $this->languageID)) {

mit

if (!LanguageHelper::isDefaultLanguageActive(shop: true, languageID: $this->languageID)) {

ersetzen

Mich interessiert nun die Mögliche Umsetzung. Eine Core Datei zu ändern ist nicht ohne. Beim nächsten Update wird diese Datei möglicherweise überschrieben,
Wie macht man so etwas am besten? Auf eine weitere Anfrage ob diese Änderung in den kommenden Versionen enthalten ist, wurde mit Nein geantwortet. Zumindest die nächste Version ist schon in der Testphase und hat diese Änderung nicht drin. Wie ich JTL kenne ist es absolut unklar wann und ob diese Änderung in absehbarer Zeit offiziell kommen wird. Daher müssen wir es irgendwie updatesicher einbauen und ich habe keine Vorstellung wie.
 

NoOne

Sehr aktives Mitglied
16. März 2024
673
231
Geht nicht updatesicher. Du musst das nach dem Update wieder patchen, bis das in eine Release-Version einfließt.
 
  • Gefällt mir
Reaktionen: surus

Ähnliche Themen