Bei Suchmaschinentricks.de wurde kuerzlich meine Site bzw das seit August dieses Jahres installierte "neue Gesicht" diskutiert.
Was in dem Artikel ueber meine Qualifikation steht, sollten Sie ignorieren. Ich habe sicherlich kein Monopol auf zuverlaessige Arbeit. Ich unterscheide mich hoechstens durch die Art meines Angebots - die Betonung auf so langfristige wie dauerhafte Ziele, da fuer mich seit vielen vielen Jahren Zeit wichtiger als Geld ist. Und dadurch, dass ich nicht fuer jeden arbeite und schonmal Kunden vor die Tuere setze.
Ein paar der bei Suchmaschinentricks gemachten Aeusserungen haben mich ueberrascht, weil sie inkorrekt sind. So heisst es in einem Posting:
"Schade auch, dass er seine Site "revamped" hat, sie war so angenehm puristisch und allein vom Schriftbild her sehr gut zu lesen ..."
Wer einen Blick auf den Quellcode der neuen Seiten wirft, sollte auf Anhieb erkennen, dass es wohl puristischer kaum geht. Das alte, auf Tabellen basierende Layout war trotzt kompakter Seiten suboptimal.
Mit der Umstellung sind jetzt wirklich alle Hinweise auf Gestaltung verschwunden, sprich wurden in ein externes Style Sheet verlegt. Dabei habe ich mir zwar den Luxus geleistet, ein zusaetzliches Print CSS einzubinden, das beim Ausdruck der Seiten Unwesentliches unterdrueckt und so fuer erhoehte Lesbarkeit sorgt, aber davon abgesehen wird Praesentation jetzt ausschliesslich ueber 2 im HEAD jeder Seite eingebundene CSS-Dateien kontrolliert.
Auch in Sachen Lesbarkeit muss ich - zusammen mit einer grossen Zahl von Anwendern - widersprechen. Ich stelle es zwar nirgendwo besonders heraus, aber wenn Ihnen die Schriftart oder Groesse nicht zusagen, koennen Sie diese jederzeit und permanent aendern. Selbst die Farben lassen sich so kontrollieren, falls meine Voreinstellung tatsaechlich nicht gefallen sollte.
Urspruenglich sollte auch der Austausch des Layouts einstellbar sein - die Beta steht seit Ende August - aber wie das im Leben so ist, kommt es manchmal anders als erhofft, und dann auch noch aus heiterem Himmel.
Ein anderer Poster meint, die Layout-Aenderung habe Positionen im Ranking gekostet. Auch hier darf ich, aufgrund woechentlicher Aufzeichnungen meiner Position fuer gut ein Dutzend Formulierungen ueber viele Jahre hinweg, widersprechen. So zeigt sich fuer zwei meiner Positionen, dass es, wenn man selbst mal entsprechenden Code geschrieben hat, aus nachvollziehbaren Gruenden immer zyklische Schwankungen der Positionen geben wird. Diese werden nur durch Veraenderungen der Ranking-Parameter verursacht, selbst wenn alle der in Frage kommenden Seiten und ihre Verlinkung auf den, sagen wir mal, ersten 20 Positionen, unveraendert bleiben.
Schliesslich sind keine der Seiten identisch und sicherlich genausowenig identisch verlinkt. Wenn die Ranking-Parameter einer Suchmaschine beim Ranking-Lauf so veraendert werden, dass Faktor X [z.B. Worthaeufigkeit] jetzt 3% hoeher, Faktor Y [z.B. Pagerank] aber 2% weniger und Faktor Z [z.B. TITLE] ebenfalls um 1% reduziert wird, kratzen sich 20 [oder mehr] Leute am Kopf und wundern sich, was passiert ist.
In der Praxis laesst sich beobachten, dass meine Position fuer zwei Formulierungen immer im Abstand von mehreren Monaten schwanken. Zumal die juengste Veraenderung - eine Verbesserung uebrigens - am 22.11. erfolgte, also kaum direkt mit dem neuen, Anfang August auf den Server gepackten, Layout in Verbindung gebracht werden kann.
Und dann ist da noch die robots.txt Datei, die ich zuletzt am 24.9. erweitert habe. Denn manche Bereiche meiner Site sollen mangels Aktualitaet nicht mehr in den Datenbestand [auch wenn sie teils gut verlinkt sind]. Mehr als zwei Drittel meiner Kunden finden zu mir heute eigenartigerweise durch Empfehlungen Bekannter oder auch auf Webseiten, die sich mit dem Thema befassen. Dass ich auch in den wichtigen Suchmaschinen gefunden werde, ueberrascht solche Kunden umso mehr.
Fazit: lassen Sie sich durch Aeusserungen in Foren auf gar keinen Fall davon abhalten, CSS [Style Sheets] einzusetzen. Konsequenzen fuer die Suchmaschinen-Position sind im schlimmsten Fall neutral, koennen aber, wenn der jetzige Seitenaufbau voller Ballast steckt, sehr positiv wirken.
Setzt natuerlich voraus, dass Sie Style-Sheets nur dafuer nutzen, wofuer sie entwickelt wurden, naemlich die _absoloute_ Trennung von Inhalt und Layout und die Kontrolle des letzteren ueber hierfuer eingesetzte Dateien. Style-Anweisungen bei jedem HTML-Element, das eingesetzt wird, direkt in der Seite zu verdrahten, ist nicht nur unpraktisch [weil Sie bei Layout-Aenderungen jede Seite anfassen muessen], sondern vor allem auch fuers Ranking kaum von Vorteil.
Und wer's nicht lassen kann, Texte ausserhalb oder hinter dem im Browser sichtbaren Inhalt zu verstecken, kann auch gleich in roten Lettern verkuenden, "Ohne Spam wissen wir uns nicht zu helfen".
Trotzdem haette ich auf meiner Site manches besser machen koennen. Das theoretische Ideal der reduzierten Bandbreite habe ich verfehlt. Wer sich ins Auto setzt, weiss, dass man durch Betaetigung von Knoepfen und Hebeln die Sitzposition komfortabler gestalten kann. Aber fast jeder, der sich an den Browser setzt, faehrt sofort los.
Und zwar in der ab "Werk" gelieferten Standard-Einstellung. Unter Windows heisst das, dass Ihr Rechner Tueren und Tore aufsperrt und Dritten die Fernbedienung erlaubt. Und dass obendrein Dateien wieder und wieder geladen haben, obwohl bekannt ist, dass sie seit dem letzten Abruf nicht veraendert wurden und eine bestimmte Gueltigkeit haben. Nur etwas mehr als 10% der Anwender haben einen Browser [oder diesen so konfiguriert], der konditionale Abrufe macht, d.h. der HTML, CSS und Grafik nur einmal holt und der vor jedem weiteren Einsatz die entsprechenden Dateien so abruft, dass sie nur geliefert werden, falls eine Aenderung erfolgt ist.
Fuer den Anwender hat das den Vorteil, dass alles doppelt so schnell erfolgt. Fuer _die_ Anwender als Gruppe hat das Verhalten bzw die Einstellung den Vorteil, dass Server nicht durch voellig unnoetige Anfragen belaestigt werden und schneller reagieren.
Die Auslagerung der CSS-Anweisungen in externe Dateien hat also in der Praxis nur den Vorteil, dass Aenderungen des CSS-Anweisungen immer noch auf nur eine Datei begrenzt sind, die Datenmenge aber durch dummerweise voellig unnoetig wiederholtes Nachladen nicht reduziert wird. Schlimmer noch, wenn ich mitzaehle und der Web Server beim 2. Nachladen der CSS-Datei den Status-Code 304 [Not Modified] statt die eigentliche Datei schickt, haben solche Browser ganz vergessen, welche CSS-Anweisungen fuer die zuletzt gelieferte Seite ausgefuehrt wurden. Das Layout sieht _dann_ puristischer aus, als jedes andere ;)
CMS [Content Management Systeme] eignen sich wunderbar, das Denken abzuschalten. Man schuettet oben Text rein, erhaelt unten eine Datei, die in .html endet und folglich webtauglich sein _muss_, und schon wird man nicht gefunden.
Wer staendig fremden HTML-Code vor Augen hat, kann sich nur wundern, was alles falsch gemacht werden kann - vor allem, wenn es so einfach ist, diese Fehler zu vermeiden. Offenbar werden CMS nur fuer Anwender geschrieben, die Seiten bereitstellen wollen, und nicht fuer solche, die Wert auf Informationsverbreitung legen. Das ist ein grosser Unterschied.
Denn auch wenn Suchmaschinen heute dazu uebergegangen sind, URLs mit GET-Parametern [?name=wert&name2=wert2...] zu spidern, gibt es, da Kombinationen von "name" und "wert" infinitiv sind, eine genauso infinitive Zahl an Inhalten, die ueber eine Basis-URL erreichbar sind - zumindest theoretisch. Also setzt man [nicht veroeffentlichte] Limits fuer die Zahl der Seiten, die in den Datenbestand einer Suchmaschine duerfen.
Waehrend aehnliche Limits zwar auch fuer "normale" Seiten gelten, ist man bei URLs mit GET-Parametern umso vorsichtiger, je groesser die Zahl der Parameter-Paare ist. Lange Rattenschwaenze solcher Anhaengsel werden es sehr schwer haben, indexiert zu werden, solange eine Site nicht gut verlinkt ist.
Hier ergibt sich die Frage, warum solche Parameter ueberhaupt notwendig sind. Bei mit PHP oder aehnlichen Sprachen erstellten Seiten werden die eigentlichen Inhalte oft und gerne aus einer Datenbank geholt und vor Auslieferung zu Seiten zusammengeschraubt.
Apaches mod_rewrite erlaubt zwar die Moeglichkeit, kryptische URLs in [fast] lesbare ohne ? und & umzuwandeln, was aber nicht nur Site- sondern auch Suchmaschinen-Betreibern bekannt ist. Warum ist eigentlich noch niemand auf die Idee gekommen, aus Datenbanken fertige Seiten mit "festen" URLs zu erstellen, die nicht bei jedem Seitenabruf neu erstellt werden - und den Server ergo umso flotter machen?
Ein bei solchen Loesungen oft uebersehenes Problem ist das der Datensicherung. Wenn der Server abschmiert, der Provider seinen Laden schliesst oder mit der Hardware durchbrennt - alles schon dagewesen und kein Einzelfall - ist auch Ihre Datenbank schlecht erreichbar.
Ich betrachte die Konzeption der meisten CMS daher als unnoetig komplex und obendrein inhaerent unsicher. Was man auf dem Web Server hat, auf den jeder [hoffentlich eingeschraenkt] zugreifen kann, darf nie mehr als eine Kopie der Daten sein, die Sie vor Ort und auf Backups haben. Wer faengt heute schon gerne ganz von vorne an?
Ein gutes CMS sollte:
Falls Sie weitere Anforderungen haben, wuerden mich diese interessieren.
© Copyright 1998 - 2008 Klaus Schallhorn.