[QUOTE=leofonic;111904]Dass der Controller erreichbar ist, heißt ja nicht dass er was ausgeben muss. Bei einem System das eine Anzahl von x Seiten produziert, sollten genau x Seiten plus eine Fehlerseite aufrufbar sein.[/QUOTE]
Richtig …
Ein CMS z.B. spielt halt den Inhalt aus, den es ausspielen soll. Genauso spielt OXID das Kontaktformular aus, wenn man es aufruft. Das beim CMS ein 404-Fehler ausgespielt wird, wenn eine “nicht existierende virtuelle Seite” aufgerufen wird, ist genauso konsistent, dass OXID aktuell immer das Kontaktformular ausspielt. Denn jeder aufrufbare Controller, wird auch immer eine Aktion auslösen … Bis jemand dafür Fehlerroutinen baut, die aber eben aktuell nicht “Standard” sind oder den Controller einfach hart entfernt.
eigentlich peinlich für den Bund und die Uni … und dann gibt es ja diese tollen Trojaner vom Bund, die hochprofessionellen Leute bei der Bundeswehr etc die Backtrack einsetzen … ich würde da verzweifeln bei so dummen Kollegen D
[QUOTE=WBL_BjoernLange;111914]Bis jemand dafür Fehlerroutinen baut, die aber eben aktuell nicht “Standard” sind oder den Controller einfach hart entfernt.[/QUOTE]
Die sollten aber imho Standard sein, auch ohne Featurerequest wäre es sinnvoll wenn man z.B. das Gästebuch abschalten könnte.
[QUOTE=leofonic;111923]Die sollten aber imho Standard sein, auch ohne Featurerequest wäre es sinnvoll wenn man z.B. das Gästebuch abschalten könnte.[/QUOTE]
Finde ich auch. Denn an den Oxid Dateien wie Controller usw was zu ändern ist nicht gerade so gut und updatesicher
EDIT: Und der robots.txt Vorschlag etc. ist hier nicht sinnvoll. Souleater beschwer sich darüber, dass Leute einfach die OXID-Struktur kennen und trotzdem “unerwünschte” Seitentypen aufrufen (können). Die robots.txt macht es dann vermutlich sogar noch einfacher, auch für Leute die die OXID-Struktur nicht kennen, auf diese Seiten zu kommen.[/QUOTE]
das ist falsch … er beschwert sich darüber wegen DC … und DC kannste vermeiden, wenn man die URL via robots.txt verbietet…
ob dann die seite noch aufrufbar ist, ist für den DC wurscht
Gästebuch wegen DC zu deaktivieren wäre mir neu.
Ich gehe dann jetzt auf die Seiten der Konkurrenz und poste in deren Gästebücher 1:1 die Sachen von meinem Gästebuch, damit sie wegen DC im Ranking nach unten rutschen
Er beschwert sich ja auch wegen Spammern und Angreifern. Aber so ein Shop ist nunmal leider eine interaktive Sache und es macht wenig Sinn GB und Kontaktformular wegen Angreifern zu sperren und das Form im Checkout aktiv zu lassen.
Das sicherste ist wohl, statische HTML-Seiten und das Bestellformular als PDF zum ausdrucken
er kann auch via htaccess diese urls einfach auf die indexseite umleiten … so passiert ihm auch nichts … wie auch immer … es gibt genügend einfache möglichkeiten da kein problem zu haben…
Gästebuch hatte jetzt nichts wegen dem Duplicate Content zu tun, und DC kann man nur mit einem richtigen 301 Redirect via htaccess vermeiden, eine robots.txt enthält nur Indizierungsanweisungen für Suchmaschinen, mehr nicht
Es waren auch nur Beispiele.
Mir ging es nur um die Möglichkeit bei Oxid direkt von sich aus entsprechende URLs umzuleiten ohne so ein Plugin oder eigene Anpassungen, andere Sachen lassen sich ja auch deaktivieren. Aber bleibt ja nur die Lösung per htaccess und redirects.
DC hast du schon wenn die Webseite ohne 301 Redirect unter www. und ohne www. erreichbar ist.
Außer man erstellt eine Subdomain www. auf eine ganz andere Inhaltsseite.
Und wenn eine der beiden Varianten ins Nirvana führt wie bei den Beispielen vom Bund ist es noch schlimmer.
