Suchmaschinen indizieren unnötige Seiten/ URIs mit sid-Param

  • Mir ist eben durch einen Suchmaschinentreffer auf dieses Forum aufgefallen, dass nahezu alle gelisteten URIs eine Session-ID in Form des sid-Parameters enthalten. So sind viele Threads unter mehreren URIs mit unterschiedlicher sid erreichbar und andere gar nicht, weil die Spider aufgrund der sich aus ihrer Sicht häufig wiederholenden Inhalten die Lust an dem Forum verlieren.

    Ich kenne mich mit dem phpBB nicht aus, aber man wird doch bestimmt irgendwie die sid-Parameter für Gäste (oder zumindest für bestimmte User-Agents) deaktivieren können? Wenn nicht, wird es dafür bestimmt einen Hack geben, in dem Zustand ist die Software sonst ja extem suchmaschinenfeindlich.

    Auch werden mehr oder weniger unnötige URIs indiziert, die ggf. auch zu einer unnötigen Serverlast führen. Da wären z. B. die URIs mit folgenden Dateinamen:

    search.php
    viewonline.php
    profile.php
    posting.php
    privmsg.php
    login.php

    ggf. lassen sich durch site:http://www.firefox-browser.de inurl:forum -inurl:viewforum.php -inurl:viewtopic.php -inurl:search.php -inurl:profile.php ... bei Google noch mehr unnötige URIs finden.

    Diese Dateien sich schon mal sehr einfach über die robots.txt ausschließen. Es wäre schade, wenn sonst weiterhin die vielen interessanten Threads zum Teil gar nicht oder nur mit extrem niedrigen Ranking in den Suchergebnissen auftauchen.

  • Das ist keine Funktion, die phpbb bereitstellen müßte, sondern etwas, das Suchmaschinen beim Crawlen berücksichtigen müssen.

    Hast Du eine paar Beispiele? Deine Parameter hören sich nach Google an und soweit ich weiß kann Google Session-IDs beim Crawlen ignorieren, insofern wundert mich das etwas.

  • Schön, dass der Thread nicht unbeantwortet in der Versenkung verschwindet. :)

    Google indiziert durchaus Seiten mit SIDs, siehe http://www.google.com/search?q=site%….de+inurl%3Asid Das ist aber kein Google-spezifisches Problem und auch die Syntax funktioniert bei den anderen großen Suchmaschinen:
    http://search.yahoo.com/search?p=site%….de+inurl%3Asid
    http://search.msn.com/results.aspx?q….de+inurl%3Asid

    Was sollte ein Spider denn tun, wenn er auf solche URIs trifft? Sie ignorieren? Wäre eine Möglichkeit, aber das ist hier nicht unbedingt wünschenswert. Den SID-Parameter selbstständig entfernen? Wäre hier vorteilhaft, ist imo aber etwas vorschnell, wenn ein sich Spider selbstständig URIs generiert, eventuell ist der Parameter ja sogar notwendig. Das einfachste ist, wenn er sie einfach aufruft, solange die Domain ein ausreichend hohes Ranking hat. Wie man sieht waren die Spider hier auch schon recht fleißig aber irgendwo setzen die auch ihre Grenzen.

    Ich habe mich zwischenzeitlich auch schon mal schlau gemacht, was es bei phpBB für Möglichkeiten gibt. Die SID für Gäste ist wohl nur dann notwendig, wenn auch Gäste Schreibrechte haben sollen. Das ist hier ja nicht der Fall, daher könnte der Parameter problemlos entfernt werden. Offenbar gibt es dafür sogar eine Einstellmöglichkeit in dem Admin-Menü, das habe ich allerdings noch nicht ausprobiert.

    Auch existieren mehrere Modifikationen um phpBB suchmaschinenfreundlicher zu gestalten. Das geht los mit Einzeilern bis hin zu mehreren kB an Code. Die Einzeiler entfernen nur die SIDs für bestimmte als Spider bekannte User-Agents, die komplexen erstellen auch insgesamt schönere URIs (u. a. auch kanonische URIs für die Links zum vorigen und nächsten Thema und zu den einzelnen Postings). So weit bräuchte man ja gar nicht mal zu gehen, das Entfernen der SID sowie das Erstellen einer robots.txt sollte schon mal einen Großteil der Duplikate eliminieren. Ein

    *&view=previous
    *&view=next
    *p=

    wäre in der robots.txt vielleicht auch angebracht um Doppeleinträge zu vermeiden. Auch sollte man nach dem Entfernen der SIDs ein

    *sid=

    in die robots.txt aufnehmen, um den Suchmaschinen den Ballast abzugewöhnen. Schöner wären natürlich 301er-Redirects, aber die müsste man dann wieder an die User-Agents der Suchmaschinen binden, um angemeldete Benutzer ohne Cookies nicht auszusperren.