Länge von GET-Variablen?

Josh

Josh

Legendäres Mitglied
Hi alle

Kommt es darauf an, wie lange eine GET-Variable ist, wenn ich nur eine einzige davon verwende? Also wenn ich z.B.

www.was-weiss-ich.xx?menu=information/lexikon/tiere/saeugetiere/baeren/fortpflanzung/paarung/

verwende, hat die relativ lange GET-Variable einen besonderen Einfluss auf das Ranking der Seite? Wäre eine kürzere Var besser, z.B. eine schlichte ID?

www.was-weiss-ich.xx?menu=1234

Was denkt ihr dazu?
smile.gif


Vielen Dank für Infos.
Josh
 
Also nom Browser/Server sind URLs ja schon meist auf 127 Zeichen begrenzt. Mehr kannman somit nciht nehmen, bzw. wäre nicht zu empfehlen.
Aber zum Einfluß aufs Ranking kann ich ncihts sagen...
 
QUOTE Beachten Sie, wenn Sie dynamisch erzeugte Seiten verwenden (d.h., wenn der URL das Zeichen '?' enthält), dass einige Crawler dynamische Seiten im Unterschied zu statischen Seiten nicht durchlaufen. Verwenden Sie wenige und kurze Parameter.

http://www.google.ch/intl/de/webmasters/guidelines.html

Google gibt sich auch bedeckt.

Bin aber auf Deine Erkenntnisse gespannt...
 
Nun, rein technisch (&theoretisch) gesehen gäbe es da keine Limite, sowohl für Post als auch Get. Dennoch wird empfohlen, insgesammt nicht über 255bytes (URL) zu gehen. Guckst du

Ältere IE's hatten glaubs probleme ab 127 Zeichen, sollte aber ausgestorben sein das Problem.

Was es für einen Einfluss auf das Ranking hat --> Nimmt mich auch wunder
wink.gif


Persönliche Anmerkung.
Ich mag eher numerische ID's, die übergeben werdem. Das hällt die URL kompakt, lässt sich leicht absichern, leicht verarbeiten (sofern eine DB dahinter steckt) und verrät dem Besucher auf den ersten Blick nix.
 
Danke euch allen.

@ Alonso:

QUOTE Persönliche Anmerkung.
Ich mag eher numerische ID's, die übergeben werdem. Das hällt die URL kompakt, lässt sich leicht absichern, leicht verarbeiten (sofern eine DB dahinter steckt) und verrät dem Besucher auf den ersten Blick nix.


Kommt drauf an, welchen Zweck die URL hat. Handelt es sich um Administrationsvariablen, welche möglicherweise als Hackversuch modifiziert werden könnten, dann empfiehlt es sich schon, unauffällige Codes zu verwenden. Will man aber dem Benutzer ein klar strukturiertes Web vorgaukeln, dann finde ich meine lange Variante schöner, da sie bei der Suche auch sofort im Link widerspiegelt, was der Benutzer vorfinden wird.
smile.gif
 
QUOTE (Josh @ Mo 14.2.2005, 10:52)
QUOTE Persönliche Anmerkung.
Ich mag eher numerische ID's, die übergeben werdem. Das hällt die URL kompakt, lässt sich leicht absichern, leicht verarbeiten (sofern eine DB dahinter steckt) und verrät dem Besucher auf den ersten Blick nix.


Kommt drauf an, welchen Zweck die URL hat. Handelt es sich um Administrationsvariablen, welche möglicherweise als Hackversuch modifiziert werden könnten, dann empfiehlt es sich schon, unauffällige Codes zu verwenden. Will man aber dem Benutzer ein klar strukturiertes Web vorgaukeln, dann finde ich meine lange Variante schöner, da sie bei der Suche auch sofort im Link widerspiegelt, was der Benutzer vorfinden wird.
smile.gif


Naja, dynamische Webseiten und deren indexierung durch Suchmaschinen ist grundsätzlich ein leidiges Thema. Die meisten Suchmaschinen integrieren bewusst nix, was ein ? oder .php/.asp etc. in der URL hat. Daher kann die URL noch so "sauber" aussehen, wenn sie einen dynamischen Eindruck hinterlässt ist Empfangspause beim Robot.

Ich hab mich mal mit mod_rewrite rumgehauen, habs aber ohne brauchbaren Erfolg wieder eingestellt.

Momentan verfolge ich folgende Methode;
Ich detektiere jeweils, ob es sich beim Request um ein Robot oder um einen effektiven Benutzer handelt. Die Robots sehen sozusagen anschlissend eine ganz eigens für Sie angepasste Version der Seiten. Ebenfalls mit eigenen Pfadangaben, wie beispielsweise domain.xx/content.php/superseite. Kommt nun ein Benutzer auf diese Seite, wird er entsprechend weitergeleitet auf domain.xx/index.php?seite=1.

Das Prinzip läuft momentan im Test - scheint sich aber zu bewähren. .
 
@ Alonso:

ich arbeite praktisch nur mit mod_rewrite bei allen Seiten, finde ich eine super Sache und garantiert besser als jede andere Methode. Da ich aber ein Mini-CMS entwickle für mich, welches evtl auch auf Servern funzen muss, auf welchen mod_rewrite nicht läuft, so soll die Menüstruktur auch per GET-Variable übergeben werden können.
Ich würde dir in jedem Fall auch mod_rewrite empfehlen, ist genial! Einfach per (.*) den gesamten URL-String an PHP weiterleiten und die URL dann mit PHP auseinandernehmen; viel einfacher gehts kaum mehr.
wink.gif
 
Ich arbeite offenbar in die gleiche Richtung wie du
wink.gif
CMS über alles!
biggrin.gif


Wie du bereits erwähnt hast, hat man nicht immer die Möglichkeit, auf das mod_rewrite einfluss zu nehmen. Zudem verhällt sich die Funktion je nach Serversetup irgendwie nicht konstant. (Meine Erfahrung)

"Meine" erwähnte Version ist mal ein Test, in dem ich aber relativ viel Potenziel sehe. (E-Mailadresse nur bei echten Benutzer anzeigen, zusätzliche Keywords für einzelne Seiten für die Robo-Ansicht, ausblenden von bestimmten Seiten für die Robots usw. Und das ganze kann über das CMS-Adminpannel konfigurierbar gemacht werden., ohne einfluss auf das Serversetup. Zudem kann ich bei der Clientversion bei meinen geliebten ID's bleiben
cool.gif


Manchmal bin ich halt ein bisschen Bluna
huh.gif
 
ich bin genau deiner meinung, alonso. nur die sache mit den ID's gefällt mir eben nicht. ich meinerseits mag einen mod_rewrite link à la

www.xxx.ch/lexikon/tiere/saeugetiere/baeren/

100x mehr als einen link

www.xxx.ch/?id=12345

oder so ähnlich. ich mag nichts mehr, als dem user eine saubere ordnerstruktur hinter dem web vorzugaukeln und in wahrheit nur auf wenige php-files zurück zu greifen.
biggrin.gif
 
Meine Domain ist seit Anfang Februar Online und Google & MSN-Search Indiziiert mir alle Seiten, also auch Seiten wie:
./index.php?page_id=316&m=forum&um=2&tid=6

Yahoo-Basierende Suchen haben schon Probleme damit ...

Und ich glaube die User haben kein Problem damit wenn da irgend ne ID anstatt nem Pfad ist, weil die können sich die URL so oder so nicht merken...
 
@ glimax:

Da ich ein CMS erstelle, auf welchem die meisten meiner zukünftigen Projekte laufen werden, soll dieses auch möglichst perfekt in den Details sein. Auch wenn nur 1% der User etwas auf schönes URL-Design geben, so macht das, je mehr Projekte auf dem CMS laufen werden, doch immer mehr aus!
Aber ich gebe zu, ich bin da ein kleiner Fetischist!
wink.gif
 
QUOTE @ glimax:

Es heisst Qlimax.


QUOTE ich bin da ein kleiner Fetischist

Und ich dachte in dem Thread geht es um die "Länge von GET-Variablen" ..
wink.gif
.


QUOTE Da ich ein CMS erstelle

Yoo .. ich meine ... es wird dann halt immer schwieriger das ganze Durchzuziehen. Vor allem wenn du mit der Zeit viel Plugins benutzt wird das irgendwann ... nicht mehr gehen. (Vor allem wenn man nicht alle Plugins selber schreiben will).

Ich kenne Foren die haben dann URLs wie:
"http://www.domain.de/forum-985-dj_tiesto_live___
smirnoff_experience_08_02_2004_und_sven_vaeth_live___flex_vienna_vom_08.12.2004.html"

und ich meine .. dann doch lieber http://www.domain.de/?display=forum&topic=4 oder net..
 
@ Qlimax:

das q ist unterstrichen kaum von einem g zu unterscheiden...
rolleyes.gif
... wieso eigentlich qlimax? klimax?

das cms bietet folgende 4 möglichkeiten, die links zu designen:

1) www.xxx.xx/sehr/ausfuehrliche/version/mit/mod_rewrite/
die ID des anzuzeigenden inhalts wird im script ermittelt
2) www.xxx.ch/?menu=sehr/ausfuehrliche/version/ohne/mod_rewrite/
wie 1)
3) www.xxx.ch/1234/
die ID wird direkt mit mod_rewrite übergeben
4) www.xxx.ch?menu=1234/
wie 3)

so sind alle zufrieden.
smile.gif
 
QUOTE
a) www.xxx.ch/1234/

cool.gif
www.xxx.ch?menu=1234/



ich glaube nicht dass google da einen unterschied macht. "äre auch kein vorteil, weil kein suchwort im link ist.


QUOTE
www.xxx.ch/?menu=sehr/ausfuehrliche/version/ohne/mod_rewrite/


wer macht schon solche URLs. Mach mal so ne URL für ein Forum. (Siehe oben *g*). Dann brauchst du statt ner ID einfach immer einen kurzen unique string .. und denn kannst du ja schlecht immer automatisch generieren.
 
mein lieber mensch, ich mache ja gar kein forum, sondern ein cms! und zwar ein cms, welches 100% auf meine bedürfnisse zugeschnitten ist.
 
QUOTE
wieso eigentlich qlimax? klimax?



Qlimax ist ne Party in den Niederlanden (www.hardstyle.net)


QUOTE
ich mache ja gar kein forum, sondern ein cms



Ich mache auch ein CMS, muss mir noch durch den Kopf gehen lassen ob ich das Zeugs (mod_rewrite) auch implementiere. Jedenfalls statt der Seiten-Id.


QUOTE
meine bedürfnisse



Aha.


QUOTE
bei meinen links kannst du an meine präferierte linkform

www.xxx.xx/sehr/schoener/link/

noch soviele GET-Vars anhängen wie du möchtest, und zusätzlich kannst du an den letzten link-teil noch weitere params anhängen:

www.xxx.xx/sehr/schoener/link/?show=bla&page=4&sort=asc
www.xxx.xx/sehr/schoener/link,show-bla,page-1,sort-asc/
www.xxx.xx/sehr/schoener/link,show-bla/?page=4&sort=asc

werden alle genau auf denselben content zeigen. also sind alle möglichkeiten offen, nur die "root-seite" (www.xxx.xx/sehr/schoener/link/) soll von google indiziert werden.
konzept verstanden?
tongue.gif




Ja du hast recht, ich meine so ist das ganze wieder sehr einfach zu implementieren. (Das hab ich mir vorher nicht so überlegt, dass man trotzdem noch mit id-parametern arbeiten kann)

Gruess,
Joel
 
jo das ist so eine sache.
wink.gif


das einfachste finde ich, ist, die bilder immer mit absolutem pfad

/public_html/pfad/zu/bilderordner/pic.gif

anzugeben.
dann musst du aber noch darauf achten, dass mod_rewrite im bilderpfad nicht auch eine url zu finden glaubt, welche es dann weitersenden will! sonst findest du die pics nie mehr!
wink.gif


obige lösung muss nicht zwingend die beste sein, beschreibe doch dein problem etwas genauer.
smile.gif
ich arbeite mit templates, und habe mir angewöhnt, gleich bei jedem template die globale variable

{G_ABSOLUTE_PATH}

zu assignen, welche den pfad bis zum web-root beinhält. dann kann ich in jedem template einfach

<img src="{G_ABSOLUTE_PATH}images/pic.gif">

verwenden.
smile.gif
 
Sie müssen sich einloggen oder registrieren, um hier antworten zu können.
Zurück
Oben