Peter Nack: Redirect, Localization, SEO

Hallo allerseits,

ich hatte vor gut zwei Monaten schon mal ein paar Fragen hinsichtlich des Aufbaus fuer unterschiedliche Sprachen in Bezug auf den Apache.

Diesmal geht es um das Stichwort SEO und Subdomains fuer die jeweiligen Sprachen*.
In meiner Apache htaccess habe ich folgendes stehen:

RewriteCond %{HTTP_HOST} www.example.orgv$ [NC]
RewriteRule ^(.*)$ http://en.example.org/$1 [R=301,L]

Das bewirkt, das eine Anfrage wie www.example.org nach en.example.org umgeschrieben wird**.

Nun moechte ich dem Benutzer meiner Seite natuerlich in der von ihm in seinem Browser eingestellten Sprache anzeigen.

Angenommen, ein Benutzer hat die Sprache "deutsch" als Default angegeben.
Er ruft nun www.example.org auf.
Der Apache verweist dann auf en.example.org (standard)
Dort wuerde ich dann die Brwoserdaten auswerten, und den Benutzer auf de.exmaple.org weiterleiten.

Nun meine Frage:

1. Ist das nicht ein wenig "doppelt gemoppelt"?

2. Wie reagieren Suchmaschinen auf die letzte Weiterleitung? (Ich nehme an die wuerde ich mit PHPs Header-Location-Angabe machen)

Besten Dank & MfG
Peter

* Uber Pro/Contra dieser Variante bin ich mir nun im Klaren.

** btw: Kann ich die gleiche Condition auch unterbringen, dass example.org-Anfragen (also ohne www) auf die en.example.org weitergeleitet werden ?

  1. hi,

    Nun meine Frage:

    ok, ich sehe 2 Fragen ;-)

    1. Ist das nicht ein wenig "doppelt gemoppelt"?

    2. Wie reagieren Suchmaschinen auf die letzte Weiterleitung? (Ich nehme an die wuerde ich mit PHPs Header-Location-Angabe machen)

    Wenn ich ein Suchmaschinist wäre, ich würde Seiten mit Weiterleitung nicht indizieren, jedoch ab und zu mal schauen, ob solche Seiten irgendwann einmal eine festen Platz im Internet gefunden haben.

    Hotti

    1. Guten Tag Hotti,

      ok, ich sehe 2 Fragen ;-)

      Ich bin auf einem Auge blind ;-)

      Wenn ich ein Suchmaschinist wäre, ich würde Seiten mit Weiterleitung nicht indizieren, jedoch ab und zu mal schauen, ob solche Seiten irgendwann einmal eine festen Platz im Internet gefunden haben.

      Genau das ging mir naemlich auch durch den Kopf.

      Nun suche ich schon seit einiger Zeit nach einem Code-Schnipsel, auf den ich bei meinem letzten Posting gestoszen bin - leider finde ich ihn nicht wieder.
      Es ging um eine htaccess-Loesung, in der die Servervariable HTTP_ACCEPT_LANGUAGE abgefragt wurde. Anhand des Wertes wurde dann auf eine Subdomain weitergeleitet. Das interessante daran war, dass auch der Fall bedacht wurde, wenn der Benutzer bereits manuell eine Sprache ausgewaehlt hat - dafuer wurde dann auf HTTP_COOKIE zugegriffen.

      MfG
      Peter

      1. Nun suche ich schon seit einiger Zeit nach einem Code-Schnipsel, auf den ich bei meinem letzten Posting gestoszen bin - leider finde ich ihn nicht wieder.
        Es ging um eine htaccess-Loesung, in der die Servervariable HTTP_ACCEPT_LANGUAGE abgefragt wurde. Anhand des Wertes wurde dann auf eine Subdomain weitergeleitet.

        Böse. Zuerst bitte berücksichtigen, was ein User durch seine aktive Sprachwahl via deine Sprach-Links ausgewählt hat.
        Sowas gehört also nicht ins .htaccess.

        Falls dir das jetzt neu ist, solltest du zwei Schritte von deiner Absicht zurückstehen, Sprachinformation in Subdomains abzulegen.
        Sprachinformation in Pfadteilen ist bedeutend pflegeleichter. Unter anderem bekommst du keine Same-Origin-Policy vor den Kopf geknallt und brauchst nicht mit Cookie Domains rummurksen.

        mfg Beat

        --
        ><o(((°>           ><o(((°>
           <°)))o><                     ><o(((°>o
        Der Valigator leibt diese Fische
        1. Hallo Beat,

          Böse. Zuerst bitte berücksichtigen, was ein User durch seine aktive Sprachwahl via deine Sprach-Links ausgewählt hat.

          Glaube du hast mich ein wenig falsch verstanden.
          Meine Vorgehensweise soll ja wie folgt sein:

          • User ruft Seite auf
          • Es wird ueberprueft ob LANG-Cookie gesetzt ist
              - Ja: Subdomain anhand dessen bestimmen
              - Nein: Browser-Einstellung abfragen
                - Vorhanden: entsprechende Subdomain bestimmen
                - Nicht vorhanden: Default Subdomain
          • Beim manuellen Aendern der Sprache wird das Cookie via PHP gesetzt

          Unter anderem bekommst du keine Same-Origin-Policy vor den Kopf geknallt und brauchst nicht mit Cookie Domains rummurksen.

          Da ich sowieso - unabhaengig von dem aktuellen Anliegen mit der Sprache - laufende Sitzung ueber Subdomains hinweg verteilen muss, spielen diese Kriterien keine grosze Rolle fuer mich.

          Danke & MfG
          Peter

          1. Meine Vorgehensweise soll ja wie folgt sein:

            • User ruft Seite auf
            • Es wird ueberprueft ob LANG-Cookie gesetzt ist

            Und warum gehst du davon aus, dass alleine dadurch, dass ein user einen Sprachlink betätigt, auch das Cookie gesetzt ist, dass dieser Sprache entspricht?

            - Ja: Subdomain anhand dessen bestimmen

            Hier hast du den CGI Parameter im Link verworfen.
            Einmal Cookie, niemaher Sprachwahl... das ist nicht Anwenderfreundlich.
            Und es ist auch zum Testen unfreundlich.

            - Nein: Browser-Einstellung abfragen
                - Vorhanden: entsprechende Subdomain bestimmen
                - Nicht vorhanden: Default Subdomain

            • Beim manuellen Aendern der Sprache wird das Cookie via PHP gesetzt

            Und hier schickst du den Anwender erstmal auf die falsche Sprachseite, nachdem er einen Sprachlink betätigt hat. Ach die Sprachlinks kannst du dir ja schenken, da du ja dem Cookie der alten Sprache immer Vorrang gibst.

            mfg Beat

            --
            ><o(((°>           ><o(((°>
               <°)))o><                     ><o(((°>o
            Der Valigator leibt diese Fische
            1. Hi Beat,

              [..]

              Danke fuer deine Veranschaulichung.

              Ich glaube ich setz mich jetzt erstmal in Ruhe hin und ueberlege mir was ich eigentlich genau moechte. Erst dann gehe ich weiter ueber zur Implementierung und werde ggfs. nochmals hier anfragen.

              MfG
              Peter

            2. Hallo Beat,

              was ich jetzt nach mehrmaligem Ueberdenken immernoch nicht so ganz verstanden habe, ist, wie denn dann initial ueberhaupt automatisch jene Sprache aktiviert werden kann, welche der Benutzer in seinem Browser angegeben hat - und zwar OHNE einen Redirect auf PHP's Seite?

              Hierbei beisst sich doch dann der Hund in seinen Schwanz oder habe ich jetzt einen Denkfehler?

              Besten Dank nochmal!

              MfG
              Peter

              1. was ich jetzt nach mehrmaligem Ueberdenken immernoch nicht so ganz verstanden habe, ist, wie denn dann initial ueberhaupt automatisch jene Sprache aktiviert werden kann, welche der Benutzer in seinem Browser angegeben hat - und zwar OHNE einen Redirect auf PHP's Seite?

                Es ist im Grunde eine der Aufgaben deiner mehrsprach-bewussten Seiten zu entscheiden.
                a) Es ist ein CGI-Parameter angekommen.

                • ich bin zuständig
                • ich bin nicht zuständig
                    Ich muss einen redirect senden auf eine URL, die dafür zuständig ist.
                  b) Kein CGI-Parameter
                • aber auch kein Cookie.
                      Ich sniffe mal an Accept-Language
                      - Ich bin eine akzeptable Sprache. ich bin zuständig
                        und setze ein Cookie
                      - ich bin nicht erste Wahl.
                        Ich muss einen Redirect senden auf eine URL, die dafür zuständig ist.
                • ein Cookie
                    oh - das Cookie lautet aber anders
                         Ich muss einen Redirect senden auf eine URL, die dafür zuständig ist.
                    Ich bin die richtige Version für dieses Cookie.

                Jetzt müssen sich einfach alle Seiten informieren können, welche Sprachen implementiert sind, um die Content-Negotiation zu betreiben.
                Achtung Fallback-Mechanismus. Was, wenn eine Sprache implementiert ist, aber nicht die konkrete Seite?

                • Error-Seite muss Cookie setzen auf Fallback-Sprache.

                Wenn deine Sprachinfo im Pfad vorliegen würde, bräuchtest du den Keks gar nicht.
                Ein einfacher filetest in htaccess könnte ermitteln, ob eine Seite existiert.

                Du kannst es natürlich auch so handhaben, dass das Formular für die Sprachwahl immer auf ein Sprachwahlscript zeigt, das dann die Konversion von CGI-Parameter zu Redirect nach Subdomain oder Pfad vornimmt.
                Das entlastet die konkreten Sprachseiten von dieser Aufgabe.

                mfg Beat

                --
                ><o(((°>           ><o(((°>
                   <°)))o><                     ><o(((°>o
                Der Valigator leibt diese Fische
      2. Moin!

        dafuer wurde dann auf HTTP_COOKIE zugegriffen.

        Why?

        www.example.org wird aufgerufen -> accept language festellen und nach de.example.org umleiten.

        de.example.org wird aufgerufen? Süßes Nichtstun. Ein Sprachwähler baut nur den passenden Subdomain-Teil um.
        en.example.org wird aufgerufen? dito.
        la.example.org wird aufgerufen? dito.

        Bessere Alternative:

        'www.' Sprachsubdomains sind rein virtuell (verweisen auf gleiches Verzeichnis im Dateisystem)
        www.example.org oder example.org wird aufgerufen -> Session-Cookie, wenn nicht vorhanden accept language feststellen und korrekte Sprachversion anzeigen.

        Ein Sprachwähler setzt das Session-Cookie und leitet zur vorherigen Seite zurück, wo nach Auswertung des Cookies die gewünschte Sprachversion angezeigt wird.

        en.example.org, de.example.org können _auch_ aufgerufen werden, stehen als

          
        <link rel="alternate" lang="de" href="de.example.org" title="Zu den Sternen!" />  
        <link rel="alternate" lang="la" href="la.example.org" title="Ad astra!" />  
        <link rel="alternate" lang="en" href="en.example.org" title="To the stars now!" />  
        
        

        (siehe http://de.selfhtml.org/html/kopfdaten/beziehungen.htm; )http://de.selfhtml.org/diverses/sprachenlaenderkuerzel.htm

        für die Suchmaschine im Header - dorthin kommen dann auch die Besucher von der Suchmaschine und die Suchmaschine kennt die deutschen Seiten unter de.example.org, die lateinischen unter la.example.org und so weiter...

        Natürlich wird die Subdomain vor accept language aber NACH dem Session-Cookie ausgewertet.

        Reihenfolge der Auswertungen:

        session cookie? -> Sprache setzen und Ende der Prüfung
        Subdomain ist bekannte Länderkennung? -> Sprache setzen und Ende der Prüfung
        accept language? -> Sprache setzen und Ende der Prüfung
        Nichts von alledem? -> Deine Defaultsprache setzen

        oder halt:

        Deine Defaultsprache setzen und Prüfungen beginnen
        accept language? -> Sprache setzen und nächste Prüfung
        Subdomain ist bekannte Länderkennung? -> Sprache setzen und nächste Prüfung
        session cookie? -> Sprache setzen

        MFFG (Mit freundlich- friedfertigem Grinsen)

        fastix

        --
        Als Freiberufler bin ich immer auf der Suche nach Aufträgen: Schulungen, Seminare, Training, Development
        1. Hallo Fastix,

          herzlichen Dank fuer deine ausfuehrliche Antwort!

          <link rel="alternate" lang="de" href="de.example.org" title="Zu den Sternen!" />
          <link rel="alternate" lang="la" href="la.example.org" title="Ad astra!" />
          <link rel="alternate" lang="en" href="en.example.org" title="To the stars now!" />

          Interessant. Doch handelt es sich bei dem Alternate-Verweis nicht um die Kennzeichnung von verschiedenen Versionen - und nicht von verschiedener Sprachen?

          Ich habe mich nun den allgemeinen Ratschlaegen gebeugt und die Localization bis auf weiteres ueber die URL geregelt - sprich auf die verwendung von Subdomains verzichtet.

          Hierzu habe ich noch mal eine kurze Frage, vielleicht moechtest du sie mir ja beantworten.

          Der Ablauf ist wie folgt

          -> Aufruf http://example.org

          -> Im RequestHandler wird die im Browser mitgelieferte Sprache ueberprueft

          -> Wenn Sprache gefunden wurde und von der Applikation unterstuetzt wird, leite ich mit PHP weiter. Beispiel fuer "de":
          header( 'Location: http://example.org/de/', true, 301 );

          -> Wenn Sprache entweder nicht ausgewertet werden konnte oder nicht vom System unterstuetzt wird, greift der Fallback auf die Default-Sprache
          Auch hier eine 301er Redirect auf http://example.org/en/

          -> Direkter Aufruf von http://example.org/en/ liefert englischen Kontent

          -> Direkter Aufruf von http://example.org/de/ liefert deutschen Kontent

          -> Weitere Adressen ohne Sprachangabe sind nicht valide und schmeissen einen 404er.

          -> Die Sprachweiche wird ausschlieszlich ueber PHP geregelt

          Meine Frage nun:

          Vom Aufbau her finde ich es durchaus logisch, dass zb die Adresse http://example.org nicht vorhanden ist, denn es wurde keine Sprache angegeben (auch wenn es sich um das Root handelt) - aber ist das auch korrekt?

          Und was genau hat es mit den 301-Redirect auf sich bzw. wie reagieren die Suchmaschinen darauf? Ein moved permanently, so habe ich es gelesen, bewirkt, dass die Suchmaschinen sich lediglich die Folgeadresse merken (in meinem Beispiel also http://exmaple.org/en/)

          Besten Dank & MfG
          Peter

          1. Moin!

            <link rel="alternate" lang="de" href="de.example.org" title="Zu den Sternen!" />
            <link rel="alternate" lang="la" href="la.example.org" title="Ad astra!" />
            <link rel="alternate" lang="en" href="en.example.org" title="To the stars now!" />
            Interessant. Doch handelt es sich bei dem Alternate-Verweis nicht um die Kennzeichnung von verschiedenen Versionen - und nicht von verschiedener Sprachen?

            Es sind verschiedene Sprach-Versionen der selben Seite. Das ist also korrekt.

            Ich habe mich nun den allgemeinen Ratschlaegen gebeugt und die Localization bis auf weiteres ueber die URL geregelt - sprich auf die verwendung von Subdomains verzichtet.

            Auch eine übliche Idee. Und nicht die schlechteste.

            Hierzu habe ich noch mal eine kurze Frage, vielleicht moechtest du sie mir ja beantworten.
            Der Ablauf ist wie folgt
            -> Direkter Aufruf von http://example.org/en/ liefert englischen Kontent
            -> Direkter Aufruf von http://example.org/de/ liefert deutschen Kontent
            -> Weitere Adressen ohne Sprachangabe sind nicht valide und schmeissen einen 404er.

            Wenn der 404er zu http://example.org/ führt und dort etwas ist, was drauf wartet, ist das auch o.k.

            Vom Aufbau her finde ich es durchaus logisch, dass zb die Adresse http://example.org nicht vorhanden ist, denn es wurde keine Sprache angegeben (auch wenn es sich um das Root handelt) - aber ist das auch korrekt?

            Korrekt ist es, würde ich aber nicht machen. Stichwort Suchmaschine. Die wundert sich, wenn auf der Startseite der Domain nichts kommt. Wie wäre es mit einem mehrsprachigen "Please select your language?". Bitte mit schönen Links für den robot. If you doubt say "Yes". Du kannst ggf. von dort aus zusätzlich (mit PHP und/oder Javascript) auch eine Umleitung per window.href= zur im Browser eingestellten Sprache machen, wenn die unterstützt ist. Das unterstützt den Benutzer (die Sprache kann er meist) und stört die Suchmaschine nicht.

            Und was genau hat es mit den 301-Redirect auf sich bzw. wie reagieren die Suchmaschinen darauf?
            Ein moved permanently, so habe ich es gelesen, bewirkt, dass die Suchmaschinen sich lediglich die Folgeadresse merken (in meinem Beispiel also http://exmaple.org/en/)

            Ja. Manche übernehmen auch das "Pageranking" von der alten Seite, wenn diese eines hatte und löschen die alte Seite, weil die ja permanent nicht mehr da ist. Das wäre zumindest logisch. Google z.B. reagiert sehr gut auf einen semantisch sauberen, informativen (z.B. lang-Attribute) und logischen Aufbau des Webs.

            MFFG (Mit freundlich- friedfertigem Grinsen)

            fastix

            --
            Als Freiberufler bin ich immer auf der Suche nach Aufträgen: Schulungen, Seminare, Training, Development
            1. Hallo Fastix,

              danke fuer deine Antwort.

              Wenn der 404er zu http://example.org/ führt und dort etwas ist, was drauf wartet, ist das auch o.k.

              Wie meinen? Der 404er wird ja geschmissen, wenn ich auf exmaple.org zugreife. Daher verstehe ich nicht so ganz was du jetzt damit meinst (dass er zu example.org fuehren solle).

              Korrekt ist es, würde ich aber nicht machen. Stichwort Suchmaschine. Die wundert sich, wenn auf der Startseite der Domain nichts kommt.

              Ja, das ergibt Sinn. Aber eine extra Seite dazwischenzuschalten finde ich auch nicht so schoen. Zumal dort dann lediglich die Sprachauswahl und ein paar Links reinkaemen - nicht gleichzusetzen mit meiner eigentlichen Startseite.
              Und wenn ich unter example.org und example.org/en den identischen Inhalt anzeigen wuerde (also englischer Content), dann wuerde das als duplicate Content gelten?

              Besten Dank!

              MfG
              Peter

              1. Moin!

                Wie meinen? Der 404er wird ja geschmissen, wenn ich auf exmaple.org zugreife.

                Du musst das Problem aber lösen, denn die Suchmaschinen werden Deine Startseite "sehen" wollen und es für unseriös halten, wenn da nichts ist. Also musst Du der Maschine und dem Benutzer dort etwas anbieten. Für die Suchmaschine muss es etwas sein, was diese nicht übel nimmt - also entweder eine Umleitung, optimal mit Statuscode 302, auf die Sprachversion, die Du auf Grund der bereits benannten Kriterien auswählst. Das ist auch für den Benutzer gut oder halt eine Seite, wo die Sprache gewählt werden kann. Hat die dann noch den Meta-Tag

                <meta name="robots" content="noindex,noarchive,follow" />

                Dann wird die Seite nicht archiviert, nicht indexiert (und von den Suchmaschinen nicht angeboten) aber es wird den Links auf die Sprachversionen gefolgt. Sind die noch mit dem Attribut lang (<a href="/de/" lang="de">Deutsche Version</a><a href="/la/" lang="la">In lingua latina</a>) versehen, dann sollte einer freundlichen Bewertung nichts entgegen stehen.

                Du kannst dann die Weiterleitung auch per Javascript machen - dass ist hinsichtlich der Suchmaschinen aber sehr heikel (Stichwort: Cloaking).

                fastix

                --
                Als Freiberufler bin ich immer auf der Suche nach Aufträgen: Schulungen, Seminare, Training, Development
                1. Hallo Fastix,

                  Du musst das Problem aber lösen [..]

                  Eben, deswegen bohre ich ja auch schon einiger Zeit hier im Forum nach ;-)

                  Für die Suchmaschine muss es etwas sein, was diese nicht übel nimmt - also entweder eine Umleitung, optimal mit Statuscode 302, auf die Sprachversion, die Du auf Grund der bereits benannten Kriterien auswählst.

                  Ich fasse nochmal kurz zusammen:

                  a)
                  Anfrage www.example.org wird im htacces an example.org weitergeleitet

                  RewriteCond %{HTTP_HOST} www\.example\.org$ [NC]  
                  RewriteRule ^(.*)$ http://example.org/$1 [R=301,L] 
                  

                  b)
                  example.org ruft index.php auf

                  c)
                  index.php bemerkt, dass in der URL keine Sprachangabe existiert

                  d)
                  index.php wertet http_accept_language aus

                  e)
                  und leitet dann weiter auf die entsprechende Sprachversion wie zb example.org/de
                  header( 'Location: '.$newUrl, true, 302 );

                  Zu Punkt (a):
                  An dieser Stelle sollte ich dann wohl auch besser 302 statt 301 angeben wenn ich das richtig verstanden habe?

                  Ist - aus der Sicht der Suchmaschinen - an dem allgemeinen Ablauf jetzt noch etwas auszusetzen?

                  Nochmal besten Dank fuer dein Interesse!

                  MfG
                  Peter

                  1. Moin!

                    Ist - aus der Sicht der Suchmaschinen - an dem allgemeinen Ablauf jetzt noch etwas auszusetzen?

                    Nein.

                    MFFG (Mit freundlich- friedfertigem Grinsen)

                    fastix

                    --
                    Als Freiberufler bin ich immer auf der Suche nach Aufträgen: Schulungen, Seminare, Training, Development
                    1. Hallo fastix,

                      Ist - aus der Sicht der Suchmaschinen - an dem allgemeinen Ablauf jetzt noch etwas auszusetzen?
                      Nein.

                      Sauber!

                      Nochmal besten Dank fuer die Unterstuetzung!

                      MfG
                      Peter