nicht angemeldet
2 Domains auf eiinem Webspace - Frage zu .htaccess / robots.txt
Hallo zusammen,
ich hatte bei meinem Webprovider bisher nur die Domain www.domainX.de
Nun habe ich mir die www.domainY.de dazu bestellt. Ich möchte den Domains unterschiedlichen Inhalt anbieten.
In habe nun auf meinem Webspace folgende Struktur angelegt.
-- htdocs---
|
--- domainX--
|
-- css
-- geheim
|
--- domainY--
|
-- css
-- projekte
Per Menüeinstellungen des Providers habe ich eingerichtet, dass
www.domainX.de auf htdocs/domainX
und
www.domainY.de auf htdocs/domainY
verweisen soll. Der Aufruf/die Umleitung klappt.
Ich möchte nun für jede Domain eine .htaccess und robots.txt anlegen. Dazu habe ich in htdocs/domainX und htdocs/domainY je eine .htaccess und robots.txt hineinkopiert.
Wenn die robots.txt in domainX liegt, muss es dann heissen:
Disallow: /geheim/ oder Disallow: /htdocs/geheim/
Oder muss .htaccess und robots.txt immer in /htdocs liegen?
Vielen Dank im voraus!
-
Oder muss .htaccess und robots.txt immer in /htdocs liegen?
die .htaccess muss in dem Ordner liegen, in dem sie wirksam sein soll.
Die Robots.txt muss im Rootverzeichnis des virtuellen Servers liegen, also da, wo deine Domain auf dem Server eingerichtet ist, bei dir also htdocs/domainX oder htdocs/domainYEntsprechend müssen deine Pfadangaben von dortaus ausgehen, weil diese Ordner das Root darstellen.
Nach deinem Beispiel wäre also
Disallow: /geheim/
richtig.
-
Hallo Mega,
vielen Dank für deine Info.
die .htaccess muss in dem Ordner liegen, in dem sie wirksam sein soll.
Ich habe in htdocs/ eine .htaccess definiert. In dieser Datei sind Anweisungen wie:
IndexIgnore *
<FilesMatch ".(gz|zip|RAR)$" >
ForceType application/octet-stream
</FilesMatch>DirectoryIndex index.htm index.html index.php
Durch Tests habe ich festgestellt, dass diese Anweisungen auch für die beiden Domains www.domainX.de und www.domainY.de gelten. Also gelten die Anweisungen auch für die Unterordner oder nicht?
In die "Domainordner" habe ich dann je weitere .htaccess kopiert mit "domainabhängigen" Anweisungen wie:
Bei htdocs/domainX z.B.
ErrorDocument 401 "<br /><br />falsches Passwort: Zugriff verweigert!
ErrorDocument 402 http://www.domainX.de
ErrorDocument 403 http://www.domainX.de
ErrorDocument 404 http://www.domainX.deIst das so o.k.?
Viele Grüße!
-
Also gelten die Anweisungen auch für die Unterordner oder nicht?
Ja, Anweisungen in der .htaccess gelten auch für Unterordner
Ob man das beeinflussen kann, wis ich jetzt aber nicht, da müsste ich auch erstmal nachlesen. -
Moin!
Bei htdocs/domainX z.B.
ErrorDocument 401 "<br /><br />falsches Passwort: Zugriff verweigert!
ErrorDocument 402 http://www.domainX.de
ErrorDocument 403 http://www.domainX.de
ErrorDocument 404 http://www.domainX.deIst das so o.k.?
Das ist ok vom Ort her, nicht OK vom Inhalt. Du lieferst Redirects für die Fehler 402, 403 und 404 aus, nicht die Statuscodes selbst. Dadurch "entstehen" diese nicht vorhandenen Seiten praktisch, weil Spiderbots dem Redirect folgen, die "falsche" URL also nutzbaren Inhalt bieten.
- Sven Rautenberg
--
"Love your nation - respect the others."-
Dadurch "entstehen" diese nicht vorhandenen Seiten praktisch, weil Spiderbots dem Redirect folgen, die "falsche" URL also nutzbaren Inhalt bieten.
- Sven Rautenberg
Hallo Sven Rautenberg,
ich verstehe leider nicht was du damit meinst.
Kannst du mit bitte erklären, warum ich bei Fehler 402-404 nicht die Home-URL einragen soll?
Viele Grüße!
-
Moin!
Dadurch "entstehen" diese nicht vorhandenen Seiten praktisch, weil Spiderbots dem Redirect folgen, die "falsche" URL also nutzbaren Inhalt bieten.
ich verstehe leider nicht was du damit meinst.
Kannst du mit bitte erklären, warum ich bei Fehler 402-404 nicht die Home-URL einragen soll?
Ein HTTP-Client (darunter fallen Browser genauso wie Suchmaschinen-Spider) sendet einen Request an den Server und erhält als Antwort immer einen HTTP-Statuscode, der über den Erfolg oder Mißerfolg des Requests Auskunft gibt. Zusätzlich zu diesem Code können noch so praktische Dinge wie der Inhalt einer HTML-Datei an der Antwort dranhängen - das muß aber nicht so sein.
In jedem Fall ist aber der eventuell mitgelieferte Inhalt immer im Lichte des HTTP-Statuscodes zu betrachten. Vor allem von den Suchspidern, denn die haben keine menschliche Intelligenz und können nicht "raten, was wohl gemeint war", selbst wenn man es ihnen explizit mit menschlichen Worten in den Inhalt reinschreibt, der mitgeliefert wird.
Status 200 ist der häufigste Statuscode. Er signalisiert das erfolgreiche Ausliefern der angeforderten URL. Das gilt übrigens auch für alle anderen Statuscodes der Reihe 2xx.
Die Reihe 3xx signalisiert ebenfalls Erfolg, allerdings auf einer etwas anderen Ebene, denn es wird nicht der tatsächliche Inhalt mitgeliefert. Typische sind:
Status 304 signalisiert, dass der Cache des Clients noch korrekt aktuell ist.
Status 301 und 302 sagen, dass die URL existiert, aber (temporär oder dauerhaft) eine andere URL verwendet werden soll.Die Statuscodes der Reihe 4xx signalisieren, dass ein Problem aufgetreten ist, dass dem Client (und nicht dem Server) in die Schuhe zu schieben ist. Der Klassiker hierbei ist Status 404: Ressource nicht gefunden. Aber auch Status 401 (Authentifizierung fehlt oder ist falsch) und 403 (Zugriff absichtlich verweigert) gehören dazu. Auch nicht verkehrt: Status 410 für "Ressource wurde absichtlich entfernt und ist jetzt weg".
Zum Schluß noch die Reihe 5xx: Das sind Probleme, deren Grund dem Server in die Schuhe zu schieben ist. Bekannt ist hier Status 500 "Internal Server Error" für alles mögliche, was schiefgelaufen sein könnte.
Der menschliche Nutzer vor seinem Browser bekommt von diesen Statuscodes nichts mit. Wenn Statuscodes mit anzeigbaren Seiten geliefert werden, wird die Seite angezeigt, der Statuscode verschwindet irgendwo intern im Browser und wird nicht genutzt. Dabei ist es egal, ob das nun ein Status 200, 304 oder 404 war: Allenfalls durch den Seiteninhalt kann man als Mensch erkennen, ob der Request so erfolgreich war, wie man es sich wünscht. Bei den Redirect-Statuscodes ist der Browser sogar so freundlich und lädt die in der Antwort angegebene neue Adresse direkt ohne Nachfrage beim User nach.
Der Suchspider sieht die Welt anders. Für ihn sind die ausgelieferten Inhalte irrelevant, die hat er lediglich dem Indexer zur Verarbeitung vorzulegen. Interessant sind für ihn aber die HTTP-Statuscodes, denn die sagen ihm, ob die gelieferten Inhalte nutzbar sind, oder nicht.
Alles, was mit Status 200 ausgeliefert wird, ist nutzbarer Inhalt, wird also indiziert.
Alles, was mit Status 4xx ausgeliefert wird, ist KEIN nutzbarer Inhalt, wird also nicht indiziert.
Alles, was mit Status 301/302 ausgeliefert wird, ist eine Weiterleitung, der der Spider folgen wird.Deine Konfiguration sagt jetzt dem Webserver: Wenn ein Request reinkommt, der EIGENTLICH mit Status 404 zu beantworten wäre, dann liefere dem Client (Browser, Spider) NICHT den Status 404 aus, sondern gib ihm ein Redirect auf die Startseite.
Wenn der Spider jetzt also http://www.example.org/blafasel-gibtsnich.html anfordert, erhält er NICHT die Statusantwort "404", sondern eine Weiterleitung auf die Startseite http://www.example.org/. Dieser Weiterleitung folgt er und schickt einen NEUEN Request für die Startseite. Und da die Startseite existiert, wird sie mit Status 200 ausgeliefert und indiziert.
Das bedeutet für den Spider: Die eigentliche URL kann erfolgreich (allerdings mit einer Weiterleitungsbefolgung) abgerufen werden, sie existiert also. Er erfährt NICHT, dass die URL auf dem Server in Wirklichkeit nicht existiert und deshalb auch nicht indiziert werden sollte - oder dass sie, falls sie früher mal existierte, aus dem Index entfernt werden sollte.
Schlaue Suchmaschinenspider prüfen mittlerweile auf das 404-Verhalten der Webserver, weil es zu viele unwissende Admins gibt, die durch die ungewollte Konfiguration solcher Weiterleitungen den Detektionsmechanismus für "nicht (mehr) existierende Inhalte" in die Irre führen. Es ist aber trotzdem keine gute Idee, Status 404 durch eine Weiterleitung zu ersetzen.
- Sven Rautenberg
--
"Love your nation - respect the others."-
Hallo Sven,
ich sag vielmals DANKE!
Da hast du dir aber viel Mühe mit der Erklärung gemacht.
Wünsche dir noch einen schönen Abend!
Steve
-
-
-
-