Ich bin gerade am Meta optimieren und nutze dazu das plug-in von *** Schleichwerbung an *** werbe-markt.de *** Schleichwerbung aus *** mein Shop ist zweisprachig, deutsch und englisch für jede Sprache gibt es eine eigene Twitter Card und Meta / Facebook Eintrag wenn ich nun einen deutschen Link aufrufe, wird der englische Produktlink für die Card gezogen. Bei Facebook/Twitter (oder auch bei Telegram) Zunächst dachte ich, es liegt an der automatischen Sprachauswahl im Shop anhand der Browsersprache, also mal abgestellt - gleiches Ergebnis. Selbst die Twitter Validierung meckert, dass es eine Umleitung gebe. https://cards-dev.twitter.com/validator Ich finde jedoch keinen Fehler im deutschen Quelltext. Wer es freundlichweise mal ausprobieren möchte https://www.corno.de/shop/Etueden/rom033.html -> für Deutsch https://www.corno.de/shop/Etudes/rom033.html -> für englisch Warum wird beim ersten Link also nicht die korrekte und vorhandene deutsche Twittercard geladen? Facebook wie gesagt identisches Problem.
Falls "gleiches Ergebnis" heißt "gleiches Vorschau-Snippet bei Facebook & Twitter": Bei Facebook gibt's ja im Sharing Debugger die Option "Erneut scrapen". Das muss man tatsächlich machen, um die Änderungen zu sehen. Bei Twitter weiß ich leider nicht. Eigentlich ist die Sprache ja eindeutig anhand der URL erkennbar. Aber Gambio leitet bei aktivierter Option "Sprache anhand der Browsersprache automatisch auswählen" leider trotzdem weiter. Ist die Option deaktiviert, wird die Sprache anhand der URL aber korrekt erkannt und "ausgewählt". Zumindest in 4.7. Also ich würde es doch nochmal mit Deaktivieren der Option probieren.
Das halten wir nicht für einen Bug, das ist stattdessen gewolltes Verhalten. Was menschliche Besucher angeht hat die Browsersprache in aller Regel einfach am stärksten recht. So können sich sogar Westschweizer und Ostschweizer Links hin- und herschicken und sehen die Seiten in jeweils für sie angenehmer Sprache.
Bei mir war die Sprachauswahl abgestellt, es brachte keinen veränderten Effekt, deutsche Seite wurde auf englische umgestellt bzw. so erkannt. Das beschränkt sich übrigens nicht nur auf Twitter/Facebook Cards. Beim Seiten SEO Check auf Seobility ist das Verhalten gleich. Was hilft, ist der Linkanhang https://www.corno.de/shop/Etueden/rom033.html?language=de
Hat jemand etwas anderes behauptet? Aber wenn Du möchtest, kann ich es gerne nachreichen: Wenn ich Dir einen Link schicke, dann möchte ich, dass Du denselben Inhalt siehst wie ich und nicht ungefragt auf eine andere Seite umgeleitet wirst. Und so wie mir geht es bestimmt vielen Leuten Eigentlich ging es mir aber um eine Lösungsfindung. @robert Das Problem scheint, dass die URL Keywords der Kategorie nicht in Betracht gezogen werden, sondern nur die des Artikels. Also mit deaktivierter Option erfolgt keine Weiterleitung bei Aufruf der Kategorie https://www.corno.de/shop/Etueden/ bzw. https://www.corno.de/shop/Etudes/ wohl aber bei Aufruf der Artikelseite, weil "rom033" für de und en identisch ist. Mit etwas wie "rom033-en" als URL Keywords sollte es also klappen.
Die Artikelurl soll aber gleich bleiben, da es die Artikelnummer ist. Naja für einen Twitterlink den ich selber schreibe gibt es ja eine Lösung, für einen Tweet mit dem Twitterbutton leider nicht.
Ich frage mich gerade ob du es gleich tust, denn du sagst... Für mich bliebe das die gleiche Seite, nur in einer anderen Sprache. Ich lande immerhin im selben Element. Blabla Argument ohne Wert. Weisst du auch Mit Dominik kann ichs sowieso machen, man kennt sich, aber für alle anderen kann ichs auch kurz erklären: "DAS WERDEN TAUSEND ANDERE LEUTE DOCH GENAUSO SEHEN!!!1!!1!elf!!" überlese ich immer geflissentlich. Höchstens ein kleiner Seufzer, zieht aber sonst bei mir und Kollegen immer exakt 0. Wir haben irgendwann vor langem mal eruiert ob wir auch ohne explizite Sprachkennzeichnung in URLs (also weder /de/ noch ein ?language=de Abschnitt) Anzeigensprache rein aus den URL Keywords ableiten wollen. Die Antwort war da nein, zu fehleranfällig und zuviele andere Sachen die man dann ausschliessen muss und niemand je kapiert. Das wird also bewusst nicht supported, wenn da überhaupt irgendwas tut ist es letzlich mehr Zufall...
Je später der Abend, umso rauer der Ton? ist wohl gleichwertig mit Ok, was bei der netten Beurteilung anscheinend übersehen wird, dass ich schlechte Karten bei der Wahlmöglichkeit habe. Entweder baue ich die Links um (mit /de/ und /en/ bzw. als Dateianhang rom033-de.html bzw. rom033-en.html) und verliere die externen Links oder ich muss damit leben. Weil die Abschaltung der automatischen Browsersprachenerkennung wie beschrieben keine Änderung gibt. Edit: Gerade eine Ticketantwort bekommen. Gefühlt werde ich abgewimmelt. Grundtenor: Es ist kein Problem von Gambio, sondern von Google /Twitter etc. pp. und damit Drittanbieter. Mal eine neue Sitemap machen wurde noch empfohlen.
Mir ist aufgefallen, dass es egal ist was du aus ../Etudes/.. machst, es wird immer auf die englische Seite umgeleitet. Als Beispiel: https://www.corno.de/shop/Etuxxxxxxxxxxdes/rom033.html. Aber auch bei https://www.corno.de/shop/rom033.html, also ohne /Etudes/ wird auf https://www.corno.de/shop/Etudes/rom033.html umgeleitet. Kann es sein, dass in der .htaccess-Datei etwas dies verursacht?
@Marias Einkaufsparadies Wenn das URL-Keyword im Artikel identisch ist, kann der Shop anhand der URL die Sprache nicht erkennen, der Shop braucht unbedingt eine Erkennung der Sprache in der URL oder ein eindeutiges URL-Keyword für die entsprechende Sprache. Beipiele: (Link nur für registrierte Nutzer sichtbar.) Wie bereits einige hier schon geschrieben haben, erkennt der Shop den Artikel nur anhand des letzen Paramaters in der URL, der in deinem Fall für beide Sprachen identisch ist und deshalb wird die Sprache ausgewählt die in der Datenbank für den Shop als erstes existiert, meist ist das Englisch, weil es die ID 1 hat. Also um dein Problem zu lösen, musst du die Sprachcode in der URL aktivieren. Jede andere Lösung führt unweigerlich zu Fehlfunktionen und wird nicht offiziell von uns unterstützt.
Den Gedanken hatte ich auch schon, glaube ich aber nicht. Soweit ich sehe: Gambio erkennt anhand der .html-Endung (und weder "info" noch "popup"), dass es sich um eine Produktseite handelt. Bei der Erkennung, welche Produkt und welche Sprache scheint der Kategorie-Part in der URL außen vorgelassen zu werden. Das Produkt wird anhand von "rom033" gefunden. Aber genau das macht die GMSEOBoost::get_language_data() doch? Nur dass sie bei Produktseiten wohl nur die URL Keywords der Produkte prüft und den Kategoriepfad ignoriert. Wenn sich Deine Aussage auf diese "erweiterte Erkennung" bezieht: okay Externe Links… die Seiten antworten ja jetzt schon teilweise mit einem 301er Redirect. Und die URL Keywords der alten URLs würden auch nach der Umstellung auf Sprachkürzel (de/en) noch gefunden werden. Also es ist nicht so, dass jetzt alle externen Links perfekt wären und nach der Umstellung alle ins Nirvana führen würden. Es gäbe schon noch eine Möglichkeit, aber die halte selbst ich für ziemlich heftig: Man könnte /Etueden/rom033.html via RewriteRule auf /Etueden/rom033.html?language=de weiterleiten bzw. dann gleich auf product_info.php?gm_boosted_product=Etueden/rom033&language=de. Bei Interesse daran kann ich mal entsprechenden Code posten. "Rauen Ton" habe ich btw. weder von Wilken noch von mir wahrgenommen.
Für mich erschließt sich irgendwie nicht die Technik hinter der Anlage der Sprachen. ! Ich bekomme für meinen Shop 1200 indexierte Seiten und 2300 nicht indexierte. Viele tragen den Anhang language=de bzw. language=de&products_id=182. Diese Anhänge finden sich bei beiden Index Varianten. Sind das nicht relativ viele Seiten - 3600? Ich habe etwa 420 Produkte. Und das Verhältnis von 1/3 indexiert zu 2/3 nicht indexiert?
Man erhöht damit an anderen Stellen die Not von sprachlicher Eindeutigkeit drastisch, die eigentlich eher weg soll. Stell dir vor du hast nen Bäckershop und in deutscher und französicher Sprache. Nun willst du eine Kategorie Baguette aufnehmen. Das ginge dann nur für eine Sprache, aber in der anderen müsste die zwangsweise anders heissen. Das ist uncool, das wollen wir eigentlich aber erlauben können und dahin, dass genau das eben tut. Da zeichnen wir lieber die Sprache eigenständig und explizit aus, das stört normal auch keinen.