nicht angemeldet
Ulysses
Ulysses
Gunnar Bittersmann
Ulysses
Ulysses
Gunnar Bittersmann
Hallo Forum,
da ich mich in letzter Zeit vermehrt mit ModRewrite und HTTP-Codes beschaeftigt habe, wuerde ich hier gerne einmal fachmaennisch ueberpruefen lassen, ob ich alles korrekt umsetze oder doch noch ein paar Verstaendnisprobleme habe.
Primaer gehts es um Language-Negotiation, aber auch um Standard-Requests.
In meinem Beispiel benoetigt die Seite example.org stets eine Sprachangabe in Form von example.org/de - eine Root-Seite ohne Sprachangabe existiert folglich nicht.
Nochmal zur Uebersicht die HTTP-Response-Codes:
200 - OK
301 - moved permanently
302 - found
404 - not found
403 - forbidden
1. Initial, ohne Sprach-ISO
example.org --> 301 --> example.org/en
Hierbei wird die Client-Sprache ausgelesen.
Ist das OK wenn keine tatsaechliche Root-Seite existiert (also nur ausschlieszlich mit Sprach-ISO)?
2. Normal, mit gueltigem Sprach-ISO
example.org/en --> 200
Alles fein.
3. Mit falscher/keiner Sprache
example.org/ws/test --> 301 --> example.org/en/ws/test --> 404
Da der Server keine gueltige Sprache findet, fuegt er sie hinzu (auch hier wird Client ausgelesen).
Anschlieszend wird festgestellt, dass die Seite nicht existiert.
Hier wuerde ich gerne bereits beim ersten Redirect (mittels PHPs header) einen 404er als Code angeben, aber das fuehrt zu Problemen, da der Apache an dieser Stele den Request bereits abgearbeitet hat und die ErrorDocument-Angaben somit auszer Kraft gesetzt wurden.
4. Zugriff auf existierenden Ordner
example.org/gui --> 301 --> example.org/gui/ --> 403
Apache erkennt, dass gui ein existierender Ordner ist und fuegt den abschlieszenden Slash hinzu, anschlieszend wird ein forbidden geschmissen
5. Zugriff auf nicht existierenden Ordner
Identisch mit Punkt 3.
6. Zugriff auf existierendes File
example.org/gui/images/test.png --> 200
7. Zugriff auf nicht existierendes File
example.org/gui/images/test2.png --> 404
Und hier meine .htaccess
RewriteEngine on
RewriteBase "/"
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.+)/$ http://example.org/$1 [R=301,L]
RewriteCond %{HTTP_HOST} ^www.example.org [NC]
RewriteRule ^(.*) http://example.org/$1 [R=301,L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_URI} !.
RewriteRule ^(.*)$ index.php [L,QSA]
ErrorDocument 401 /Error/Index/401
ErrorDocument 403 /Error/Index/403
ErrorDocument 404 /Error/Index/404
Fallen euch unter dieser Konfiguration signifikante Probleme auf, oder evtl. Sachen die man verbessern oder vereinfachen koennte?
Vielen Dank schon mal im Voraus.
Mit freundlichen Grueszen,
Guenter
moin,
- Initial, ohne Sprach-ISO
example.org --> 301 --> example.org/en
[..]
Fallen euch unter dieser Konfiguration signifikante Probleme auf, oder evtl. Sachen die man verbessern oder vereinfachen koennte?
Ja, ich würde keine Umleitung (30x) machen, sondern generell die Seiten, soweit vorhanden, mit Status 200 ausliefern. Die Sprachaushandlung muss dazu in dem Script erfolgen, welches die Seiten erstellt.
Hotti
Hallo Hotti,
- Initial, ohne Sprach-ISO
example.org --> 301 --> example.org/en
Ja, ich würde keine Umleitung (30x) machen
Wenn ich dich richtig verstanden habe, hiesze das dann aber, dass ich duplicate content haette.
Beispiel (ausgehend von einem englischen Client):
example.org
example.org/en
Gruesze,
Guenter
Wenn ich dich richtig verstanden habe, hiesze das dann aber, dass ich duplicate content haette.
Und was ist daran schlimm? Glaubst du etwa, Suchmaschinen wären nicht in der Lage das entsprechend zu erkennen?
hi,
- Initial, ohne Sprach-ISO
example.org --> 301 --> example.org/en
Ja, ich würde keine Umleitung (30x) machen
Wenn ich dich richtig verstanden habe, hiesze das dann aber, dass ich duplicate content haette.
Nein, indes: Gleicher Inhalt, nur andere Sprache.
Beispiel (ausgehend von einem englischen Client):
example.org
example.org/en
Nein, so würde ich das nicht machen, das ist ja die Umleitung. Was ich meine ist sowas:
example.com/index.html wird in englisch ausgeliefert,
example.com/index.html wird in deutsch ausgeliefert,
example.com/index.html wird in zulu ausgeliefert....
immer dann, wenn der UA eine Sprachkennung dem Request mitgibt. Und alles mit Status 200.
Horst Hauser
example.com/index.html wird in englisch ausgeliefert,
example.com/index.html wird in deutsch ausgeliefert,
example.com/index.html wird in zulu ausgeliefert....immer dann, wenn der UA eine Sprachkennung dem Request mitgibt. Und alles mit Status 200.
Das ist für Google im speziellen aber dämlich - deren Bot kommt fast immer mit einem englischsprachigen Agent daher und listet dann die Startseite nur 1x - und zwar auf englisch.
hi,
immer dann, wenn der UA eine Sprachkennung dem Request mitgibt. Und alles mit Status 200.
Das ist für Google im speziellen aber dämlich - deren Bot kommt fast immer
Naja: "fast immer" ;)
Viele Grüße,
Horst Hauser
Das ist für Google im speziellen aber dämlich - deren Bot kommt fast immer
Naja: "fast immer" ;)
Das hat aber bei den SERP den nachteiligen Effekt, dass bei "Seiten auf Deutsch" englischsprachige Seiten aufgelistet werden.
Hallo,
Das ist für Google im speziellen aber dämlich - deren Bot kommt fast immer
Naja: "fast immer" ;)
Das hat aber bei den SERP den nachteiligen Effekt, dass bei "Seiten auf Deutsch" englischsprachige Seiten aufgelistet werden.
Google hat sowieso eine eigenwillige Art, die vom UA per "Accept-Language" mitgeteilte(n) bevorzugte(n) Sprache(n) zu berücksichtigen. Ich habe in meinen Browsern Englisch als bevorzugte Sprache eingestellt, Deutsch erst an zweiter Stelle. Okay, Google redet Englisch mit mir. Aber nicht nur das - Google listet mir auch Suchtreffer in englischer Sprache weit vorn, während gleichwertige deutsche Alternativen erst unter "ferner liefen" auftauchen.
Ich würde erwarten, dass die Sprache des Dokuments keine Rolle spielen sollte, wenn ich nach einem bestimmten Ausdruck suche (es sei denn, ich schränke das in den Suchparametern explizit ein), und der Accept-Language-Header sich nur unmittelbar auf die Sprache beziehen darf, in der der Server eine gegebene Ressource ausliefert.
So long,
Martin
Hallo,
OK, doppelten Content habe ich also nicht zu befuerchten, da auf selber Domain (wie ich u.a. im Archiv nachlesen konnte).
Aber das mit dem Bot ist ja mehr als unschoen. Welche Alternativen gaebe es denn hierfuer (auszer mir fuer jede Sprache eine eigene Domain anzuschaffen)?
Danke & Grusz,
Guenter
Aber das mit dem Bot ist ja mehr als unschoen. Welche Alternativen gaebe es denn hierfuer (auszer mir fuer jede Sprache eine eigene Domain anzuschaffen)?
Wenn du eine findest, sag es mir bitte :)
Hallo suit,
Wenn du eine findest, sag es mir bitte :)
;-)
Grusz,
Guenter
Wenn du eine findest, sag es mir bitte :)
;-)
Aber eventuell hilft das:
http://www.google.com/support/forum/p/webmasters/thread?tid=69947d38b15d775f&hl=de
Wenn du eine findest, sag es mir bitte :)
;-)Aber eventuell hilft das:
http://www.google.com/support/forum/p/webmasters/thread?tid=69947d38b15d775f&hl=de
Und der hier:
http://www.google.com/support/webmasters/bin/answer.py?hl=de&answer=182192
Wie man jetzt aber eine mehrsprachige Startseite mit automatischer Sprachwahl erstellen soll wird nicht gesagt :)
Hi!
Das ist für Google im speziellen aber dämlich - deren Bot kommt fast immer mit einem englischsprachigen Agent daher
Das ist jetzt aber nur eine Behauptung von dir - oder?
Gegenbehauptung: Der Google Bot sendet meist gar keinen HTTP_ACCEPT_LANGUAGE-Header. (Beweis)
Yahoo! Slurp schon eher.
http://www.google.com/support/webmasters/bin/answer.py?hl=de&answer=182192
Wie man jetzt aber eine mehrsprachige Startseite mit automatischer Sprachwahl erstellen soll wird nicht gesagt :)
Das ist für Google im speziellen aber dämlich - deren Bot kommt fast immer mit einem englischsprachigen Agent daher
Das ist jetzt aber nur eine Behauptung von dir - oder?
Gemeint war "wenn überhaupt einer kommt, dann meistens englisch" :)
Ja.
Scherzkeks: genau das hat zur Folge, dass in den deutschsprachigen SERP eine englischsprachige Description und ein englischsprachiger Title auftaucht.
Hi!
Gemeint war "wenn überhaupt einer kommt, dann meistens englisch" :)
Eben nicht englisch, sondern neutral!
Und dann sollte er die Sprache bekommen die als Default ausgeliefert wird. Und das sollte die sein, die dem Websitebetreiber am wichtigsten ist.
Scherzkeks: genau das hat zur Folge, dass in den deutschsprachigen SERP eine englischsprachige Description und ein englischsprachiger Title auftaucht.
Sorry, aber da kann ich dir nicht folgen... Warum sollte das so sein?
FG Ulysses
Sorry, aber da kann ich dir nicht folgen... Warum sollte das so sein?
Das _ist_ so - warum das so ist kann ich dir aber nicht beantworten, ist aber meine praktische Erfahrung.
Sobald man mit Content Negotiation arbeitet - genauer gesagt mit type maps - dreht Google in den Suchergebnissen durch. Unabhängig davon ob die Fallback-Sprache "de" ist, wird in deutschsprachigen Suchergebnisseiten dann eine englischsprachige Description und ein englischsprachiger Titel angezeigt.
Lösung dafür habe ich noch keine - nur Tonnenweise leute in den Google-Newsgroups die dasselbe Problem haben.
Die einzige Möglichkeit ist scheinbar auf Inhalsvereinbahrung auf der Startseite zu verzichten und diese per Scriptsprache nachzubauen mit einer "echten Umleitung". Aber stillschweigend unter derselben Ressourcen unterschiedliche Sprachen ausliefern funktioniert nicht.
@@suit:
nuqneH
Aber stillschweigend unter derselben Ressourcen unterschiedliche Sprachen ausliefern funktioniert nicht.
Der Suchmaschine mitzuteilen, den generischen URI nicht zu indizieren, sondern nur die sprachspezifischen, funktioniert auch nicht?
Qapla'
Der Suchmaschine mitzuteilen, den generischen URI nicht zu indizieren, sondern nur die sprachspezifischen, funktioniert auch nicht?
Das in einem Feldversuch auszuprobieren war mir bisher zu risikoreich und Informationen ob das zuverlässig funktioniert oder nicht irgendwelche unerwünschten Nebeneffekte haben kann, habe ich bisher nicht gefunden.
Du meinst:
example.com/ -> nicht indexieren
example.com/de/ -> indexieren
example.com/en/ -> indexieren
Hallo,
example.com/ -> nicht indexieren
example.com/de/ -> indexieren
example.com/en/ -> indexieren
Das waere dann ja so wie ich es bisher hatte?
Auf der Root-Seite ein moved permanently mit einer Weiterleitung entsprechend der ACCEPTED_LANGUAGE auf example.org/$lang.
Grusz,
Guenter
example.com/ -> nicht indexieren
example.com/de/ -> indexieren
example.com/en/ -> indexierenDas waere dann ja so wie ich es bisher hatte?
Auf der Root-Seite ein moved permanently mit einer Weiterleitung entsprechend der ACCEPTED_LANGUAGE auf example.org/$lang.
Das problem ist, das du mit dem 301 auf die Unterseite die Wurzelseite vollig aus der Gleichung nimmst.
Ich weiß nicht, welche konseqenzen es hat, wenn man nur Unterseiten hat, aber unter einem leeren Pfad oder / als Pfad nichts anbietet, außer einer Weiterleitung.
Moin!
Ich weiß nicht, welche konseqenzen es hat, wenn man nur Unterseiten hat, aber unter einem leeren Pfad oder / als Pfad nichts anbietet, außer einer Weiterleitung.
Kein Problem, mache ich auf mehreren Seiten so. Bei den Suchergebnissen taucht sogar die "Hauptseite" (Weiterleitung) mit dem meta/description-Text von example.com/en auf.
Tommi
Kein Problem, mache ich auf mehreren Seiten so. Bei den Suchergebnissen taucht sogar die "Hauptseite" (Weiterleitung) mit dem meta/description-Text von example.com/en auf.
In den deutschsprachigen Suchergebnisseiten taucht die englischsprachige Variante auf? ;)
In den deutschsprachigen Suchergebnisseiten taucht die englischsprachige Variante auf? ;)
Ja, wenn ich nach "example.com" suche. Mit "echten" Suchbegriffen erscheinen dann schon die jeweiligen Unterseiten in der richtigen Sprache. OK, das wäre noch eine Verbesserung für Google, wenn sie anhand der Spracheinstellung die Beschreibung der Seite anzeigen würden, auf die weitergeleitet wird.
Tommi
Ja, wenn ich nach "example.com" suche. Mit "echten" Suchbegriffen erscheinen dann schon die jeweiligen Unterseiten in der richtigen Sprache.
Dann such bitte mal ohne Suchbegriffe nur nach dem Domainnamen oder nach dem was in der Second-Level-Domain steht.
OK, das wäre noch eine Verbesserung für Google, wenn sie anhand der Spracheinstellung die Beschreibung der Seite anzeigen würden, auf die weitergeleitet wird.
Und genau das ist der Knackpunkt - wenn du dafür eine Lösung hast, bitte raus damit :)
Dann such bitte mal ohne Suchbegriffe nur nach dem Domainnamen oder nach dem was in der Second-Level-Domain steht.
Wie gesagt:
Ja, wenn ich nach "example.com" suche.
Und genau das ist der Knackpunkt - wenn du dafür eine Lösung hast, bitte raus damit :)
Ebenfalls wie gesagt:
das wäre noch eine Verbesserung für Google
Liegt also nicht in meiner Hand. Kann ich aber mit leben. Wenn eine Vermischung nicht vorkommen darf, muss man halt sauber trennen, also die Inhalte auf verschiedenen Domains bereitstellen.
Tommi
Wenn eine Vermischung nicht vorkommen darf, muss man halt sauber trennen, also die Inhalte auf verschiedenen Domains bereitstellen.
Das ist keine Option - denn es muss trotzdem eine Sprachvereinbahrung geben, die dann halt auf die andere Domain umleitet.
Wir sind also der Lösung keinen Schritt näher - denn ich kann _nicht_ damit leben.
Frei nach Salomon: entweder du hast falsche Ergebnisse in den SERP oder du hast keine automatische Sprachwahl für deine Kunden.
Frei nach Salomon: entweder du hast falsche Ergebnisse in den SERP oder du hast keine automatische Sprachwahl für deine Kunden.
Wenn ich meine Inhalte in verschiedenen Sprachen anbiete, muss ich eben damit rechnen, dass diese auch angezeigt werden.
Tommi
Wenn ich meine Inhalte in verschiedenen Sprachen anbiete, muss ich eben damit rechnen, dass diese auch angezeigt werden.
Ja, aber nicht in der falschen Sprache :)
Denn Google ist offenbar unwillentlich, Sprachangaben zu beachten - sie ermitteln die Sprach eines Dokuments einzig und allein aus dem Inhalt sowie aus dem Domainnamen bzw. dem Pfad und ignorieren sämtliche anderen für die Sprache relevanten Information.
Ich habe nichts dagegen, dass bei mehrsprachen Seiten alle Sprachen gefunden werden - nein, das will ich sogar - aber ich will doch bitte bei den Suchergebnisseiten die Ergebnisse in den richtigen Sprachen gelistet haben.
Wenn ich "Seiten auf Deutsch" suche, möchte ich keine Ergebnisse in englischer Sprache dazwischen haben - und umgekehrt natürlich auch nicht. Das macht kein gutes Bild und verwirrt den Suchenden.
Das ist zwar primär ein Problem von Google, dennoch wird genau dieser Umstand immer wieder von Kunden bemängelt - die suchen leider permanent nach ihrem eigenen Domainnamen und schauen was da steht :)
Also geht man - wider besserem Wissens - dem Endkunden auf den Senkel damit der Kunde zufrieden ist.
Wenn ich "Seiten auf Deutsch" suche, möchte ich keine Ergebnisse in englischer Sprache dazwischen haben - und umgekehrt natürlich auch nicht.
Stimmt, in diesem Fall ist das etwas unschön. Aber wie Du selbst sagst: das ist ein Problem von Google. Das muss man dem Kunden eben klar machen.
Tommi
Das muss man dem Kunden eben klar machen.
95 % aller Kunden sind Beratungsresistent :D
@@suit:
nuqneH
Das muss man dem Kunden eben klar machen.
95 % aller Kunden sind Beratungsresistent :D
Bei der Frage, ob ihre Website für Menschen oder für Roboter gedacht ist, sollten sie keiner Beratung bedürfen.
Qapla'
Bei der Frage, ob ihre Website für Menschen oder für Roboter gedacht ist, sollten sie keiner Beratung bedürfen.
Du hast nicht viel mit der Art Kunden zu wie ich es habe oder?
Hauptsache die Seiten sehen am Notebook des Chefs gut aus - wie bedienbar die Seite ist, ist völlig egal.
Dann wollen sie auch noch "SEO", weil sie so wenige Besucher haben - wenn man ihnen dann erklärt, dass SEO selbst schön und gut ist, aber man seine Besucher besser an die Seite bindet, wenn man sie benutzbar macht und einen Anreiz für einen Wiederbesuch schafft, wollen die das nicht hören - weil die Mitbewerber machen auch SEO :D
Hi!
..., ist aber meine praktische Erfahrung.
Da kann ich natürlich nicht ganz mithalten.
Ich hab bisher nur eine mehrsprachige Webpräsenz.
Sobald man mit Content Negotiation arbeitet - genauer gesagt mit type maps - dreht Google in den Suchergebnissen durch. Unabhängig davon ob die Fallback-Sprache "de" ist,...
Genau das kann ich aber auf dieser einen Webpräsenz nicht nachvollziehen.
Da werden unter example.com/ je nach Sprachvereinbarung (Fallback-Sprache = "de") die Inhalte der Ressourcen example.com/index.de oder example.com/index.en ausgeliefert und die jeweils andere Ressource direkt verlinkt.
Google, dessen Bot keinen HTTP_ACCEPT_LANGUAGE-Header sendet, hat in seinem Cache unter example.com/ die deutsche Seite. Die englische Variante scheint in den SERPs unter example.com/index.en auf - wie gewünscht.
Yahoo hingegen kommt mit ACCEPT_LANGUAGE "en" daher und bekommt unter example.com/ die englische Seite ausgeliefert, was sich über den Yahoo-Cache für example.com/ überprüfen lässt. Eigentlich dumm, dass ein Bot eine bevorzugte Sprache hat. Egal - die deutsche Seite scheint unter example.com/index.de auf.
Und jetzt wird's interessant:
...wird in deutschsprachigen Suchergebnisseiten dann eine englischsprachige Description und ein englischsprachiger Titel angezeigt.
Das kann ich momentan weder bestätigen, noch dementieren, weil auf den genannten Seiten sowohl Titel als auch Description nur die Firmenbezeichnung enthalten, welche auf beiden Seiten gleich ist.
Um einen Unterschied feststellen zu können habe ich diese heute geringfügig verändert. Bis sich das in den SERPs niederschlägt werden aber sicher Wochen vergehen. Ich hoffe, der Thread ist bis dahin nicht schon in's Archiv gewandert.
FG Ulysses
Hi!
...wird in deutschsprachigen Suchergebnisseiten dann eine englischsprachige Description und ein englischsprachiger Titel angezeigt.
Das kann ich momentan weder bestätigen, noch dementieren,...
Aber jetzt kann ich!
Google listet in den SERPs ganz brav, wie gewünscht unter
example.com/
die deutschsprachige Seite mit deutschem "title" und "description"
unter
example.com/index.en
wird das englische Pendant gelistet.
Ich kann also kein Fehlverhalten von Google ausmachen!
FG Ulysses
@@hotti:
nuqneH
example.com/index.html wird in englisch ausgeliefert,
example.com/index.html wird in deutsch ausgeliefert,
example.com/index.html wird in zulu ausgeliefert....immer dann, wenn der UA eine Sprachkennung dem Request mitgibt. Und alles mit Status 200.
Generischer URI für alle Sprachversionen, ja.
Wie willst du aber dem begegnen, wenn der Accept-Language-Header nicht die vom Nutzer tatsächlich gewünschte Sprache angibt? Dann muss der Nutzer selbst umschalten können.
Einfach geht dies, wenn jede Sprachversion auch über einen sprachspezifischen URI erreichbar ist. Jede Seite verlinkt dann zu ihren anderssprachigen Pendants.
Dadurch finden dann auch Suchmaschinen alle Sprachversionen und nehmen sie in ihren Index auf.
Qapla'
hi,
Wie willst du aber dem begegnen, wenn der Accept-Language-Header nicht die vom Nutzer tatsächlich gewünschte Sprache angibt? Dann muss der Nutzer selbst umschalten können.
Auf jeden Fall. Machbar ist alles, ggf. wird die manuelle Sprachauswahl in einem Cookie gespeichert, auch das spricht für meinen Vorschlag, die Sprachaushandlung per Script zu machen und auf den Einsatz von Location-Header zu verzichten.
Viele Grüße,
Hotti
Der Martin