Inhalte von HP sollen nicht über Suchmaschinen gefunden werden können

[KJK]

Liebe Leutz, ich hoffe ich bin hier im richtigen Teil des Forums.
Ich habe eine mit iWeb erstellte Homepage, die ziemlich umfangreich ist. Aus verschiedenen Gründen würde ich diese jetzt gerne mit einer reinen Medienseite ergänzen, die nicht über das iWeb-Menü aufrufbar sein soll, sondern nur mit einem direkten Link. Sinn dieser Übung ist, den Zugang zum Inhalt der Seite nicht der breiten Öffentlichkeit, sondern nur einem handverlesenen Personenkreis zugänglich zu machen. Es handelt sich hier nicht um irgendwelche pornographischen oder sonstwie zweifelhafte Inhalte, sondern um eine ziemlich umfangreiche Sammlung an (noch gemafreien) Musikdemos, bei der ich gerne die Kontrolle behalten möchte, wer sich da eventuell bedient hat.
Nur - wie stelle ich es an, dass das auch so funktioniert und die Seite nicht über die Suchmaschinen gelistet wird.
Einmal kommen mir da Befehle für die Suchrobots in den Sinn, habe aber von der Syntax für diese keine Ahnung. Andere Möglichkeit wäre ein Passwortschutz nur für diese eine Unterseite, bei dem ich aber nicht weiß, ob und wie das mit iWeb funktioniert. Und ein anderer Editor kommt für mich nicht in Frage, weil mir die Zeit und die Lust fehlt, die komplette Seite (mit 200 Unterseiten) nochmal neu aufzubauen.
Vielleicht hat der eine oder andere einen Tip für mich?

 

[Rupp]

Ein Passwortschutz über .htaccess und somit über das Webinterface deines Providers geht mit jeder Art von Webseite, auch mit iWeb Seiten. Sollte dein Provider einen sogenannten „Verzeichnisschutz“ in seinem Kundenadmincenter bereitstellen sollte das Einrichten für dich sehr einfach sein.

Die von dir angesprochenen Steuerbefehle für Suchmaschinen-Bots sind leider alles nur optionale Methoden. D.h. du richtest die robots.txt Datei lang und breit ein und ob der Suchbot sich daran hält entscheidet er dann trotzdem für sich selbst.

Der Passwortschutz ist meines Erachtens nach die einzig sichere Lösung bei so etwas.

 

[KJK]

Danke für die schnelle Antwort!
Sieht allerdings so aus, als wenn sich das bei mir nicht realisieren lässt, weil mein Provider t-online ist, und bei denen funktioniert das nicht. Und der dort gebotenen Alternative traue ich nicht so recht, weil die Herrschaften mit OSX ihre Schwierigkeiten zu haben scheinen.

 

[KJK]

Und der Nachtrag: ich habe es zwischenzeitlich auch noch mal über den Dateimanager von t-online versucht. Passwort lässt sich einrichten, ruft man die entsprechende geschützte Seite mit Safari auf, wird auch brav nach dem Passwort gefragt und die Inhalte erst nach dessen Eingabe freigegeben. Klasse, funktioniert!
Die Ernüchterung folgt auf dem Fusse: Seite geschlossen, neu aufgerufen, und Safari stellt sie sofort ohne Passworteingabe dar.
Auch wenn man Safari schließt und dann die Seite neu aufruft, ist von einem Passwortschutz nichts zu merken. Nebenbei -geht man mit dem IPhone auf die entsprechende Seite, wird erst gar nicht nach dem Passwort gefragt.
Hiiilfe!!!!!!

 

[Till00]

ist bei meiner mit .htacces geschützten Seite auch so, liegt aber an safari, einfach mal cache leeren, dann sollte er wieder nach deinem Passwort fragen

 

[rpoussin]

Ein Passwortschutz über .htaccess und somit über das Webinterface deines Providers geht mit jeder Art von Webseite, auch mit iWeb Seiten. Sollte dein Provider einen sogenannten „Verzeichnisschutz“ in seinem Kundenadmincenter bereitstellen sollte das Einrichten für dich sehr einfach sein.

Ich möchte den Beitrag nochmal hochholen, weil ich das gleiche Musik"problem" wie der TE habe.
Ich will Dateien und Listen einem Einladungskreis per Passwortzugang bereitstellen. Das geht mit dem beschriebenen Verzeichnisschutz.

Ich will aber unbedingt, daß alle Inhalte, auch Emaillinks, Weblinks und Downloaddateien nicht bei Google etc erscheinen.
Löst der Verzeichnisschutz dieses Vorhaben?

 

[Difool]

Löst der Verzeichnisschutz dieses Vorhaben?

Ja. Ohne Passwort kommt da keiner "einfach" rein – Suchmaschinen auch nicht.
Alles, was innerhalb des Passwortschutzes liegt ist nicht indexierbar.

 

[rpoussin]

Vielen Dank für die Antwort.

ist bei meiner mit .htacces geschützten Seite......liegt aber an safari, einfach mal cache leeren, dann sollte er wieder nach deinem Passwort fragen...

Gibt es eine Möglichkeit, nach dem Verlassen dieses geschützten Webseitenbereiches das Zugangsfenster auf jeden Fall wieder neu anzufordern?
Dies Name/PW-Kombination wird ja anscheinend irgendwo in den Cookies oder Caches *dieses Rechners* "verwahrt".

 

[ruerueka]

Für den Anwender: Durch Leeren des Caches / Löschen der Cookies.
Durch den Server:
Nicht mit den "Bordmitteln" der über .htaccess gesteuerten "Basic Authentication.
Mit php oder Ähnlichem kannst du den gesetzten Cookies einen Timestamp als "Gültigkeitsdatum" mitgeben.
Aber dann kannst du auch gleich einen richtigen Login/Logout Mechanismus verwenden und serverseitig einen Sessiontimeout einstellen, der deinen Vorstellungen entspricht.

 

[rpoussin]

...kannst du den gesetzten Cookies einen Timestamp als "Gültigkeitsdatum" mitgeben.

Kann ich das Setzen des Cookies nicht von Vornherein unterbinden?

Mit php oder Ähnlichem kannst du den gesetzten Cookies einen Timestamp als "Gültigkeitsdatum" mitgeben.
Aber dann kannst du auch gleich einen richtigen Login/Logout Mechanismus verwenden und serverseitig einen Sessiontimeout einstellen, der deinen Vorstellungen entspricht.

Dann müßte ich Code in die Webseite integrieren. (?)

Ich werde mal sehen und lesen, ob HostEurope eine Erweiterung des .htaccess anbietet.
Automatischer Logout beim Verlassen der Webseite. Das wär's. Kann doch nicht so schwer sein )

 

[ruerueka]

Soweit ich weiss kannst du das Verhalten der BASIC Authentificazion nicht beeinflussen. Du müsstest eine "richtige" Webanwendung erstellen (oder eine fertige einsetzen, wie dieses Forum hier), jedenfalls ist das Ganze komplizierter, als es auf den ersten Blick scheint....

 

[riyuk]

TLR - sorry
Aber.. Wenn es nur darum geht, Suchmaschinen auszusperren reicht es, wenn du im Hauptverzeichnis eine "robots.txt" (Bsp: http://bliblablub.t-online.de/robots.txt) erstellst mit dem Inhalt:

User-agent: *
Disallow: /

Das verbietet den (freundlichen) Suchmaschinen den Inhalt deiner Seite zu indizieren. Unter anderem auch google.
Ebenfalls gibt es die Möglichkeit dies noch zusätzlich über die META-Tags anzugeben.

Falls es bereits zu spät ist kannst du die Seite bei Google hier entfernen.

 

[ruerueka]

Na ja, man sollte eher sagen: es bittet die Suchmaschinen darum..., du kannst damit technisch nicht sicherstellen, dass sich die Robots daran halten.

 

[BenVo3l]

Ich habe keine eigene Website, ich machen aber Hobbymäßig viele Bilder, auch von Diversen Veranstaltungen (Geburtstage, Ausflüge, Exkursionen etc.) und will auch nicht das die Bilder an jedermann gehen.
ich Lad dann einfach die Ordner verpackt als .zip in meine Dropbox und geb den Leuten welche die Bilder haben wollen den Downloadlink. ist eine Einfache Variante ohne rumgebastel.

 

[riyuk]

Na ja, man sollte eher sagen: es bittet die Suchmaschinen darum..., du kannst damit technisch nicht sicherstellen, dass sich die Robots daran halten.

Jein. Alle Robots die wirklich von seriösen Suchmaschinen sind, werden diese Datei beachten.
Die Robots, die diese Datei ignorieren sind so genannte "bad robots" deren Augenmerk allerdings nicht auf das Indizieren der Seite liegt, sondern viel mehr darin, E-Mail Adressen, Telefonnummern oder sonstiges auszulesen um diese später zu missbrauchen.

... Die in der "robots.txt"-Datei festgelegten Anweisungen werden von allen seriösen Robots unterstützt ...

Kleine Lektüre dazu gibt's noch hier: http://support.google.com/webmasters/bin/answer.py?hl=de&answer=156449

 

[Atarimaster]

Auch, wenn sich die Frage erledigt haben sollte…

Gibt es eine Möglichkeit, nach dem Verlassen dieses geschützten Webseitenbereiches das Zugangsfenster auf jeden Fall wieder neu anzufordern?
Dies Name/PW-Kombination wird ja anscheinend irgendwo in den Cookies oder Caches *dieses Rechners* "verwahrt".

Weder im Cache, noch in den Cookies. Deshalb stimmt es leider auch nicht, dass man diese Passwörter durch Leeren des Caches oder Löschen der Cookies entfernen könnte.

Es stimmt allerdings auch nicht, dass das Passwort nach Schließen von Safari erhalten bleibt. Dieses Missverständnis beruht höchstwahrscheinlich darauf, dass KJK damals zwar alle Safari-Fenster geschlossen hat und nach Windows-Manier wähnte, dass damit auch das Programm beendet sei; aber das ist auf dem Mac ja nicht so. Wenn Du Safari aber tatsächlich beendest und neustartest, wird das Passwort beim nächsten Besuch erneut angefordert.

Nur, dass Du sofort beim Verlassen der Website ausgeloggt wirst, das geht halt über diesen Mechanismus nicht. Ist aber auch logisch, denn für den Webserver »verlässt« Du eine Website, sobald sie fertig geladen ist. Anders gesagt: Der merkt es gar nicht, ob Du das Browserfenster schließt oder noch drei Stunden geöffnet lässt.
Das hängt damit zusammen, dass HTTP ein »zustandsloses Protokoll« ist. Es ist mir jetzt zu spät, das zu erklären, aber danach kann man googlen.

Aber wenn’s nur darum geht, das Auftauchen bei Google und anderen (seriösen!) Suchmaschinen zu verhindern, würd ich wohl auch eher zur robots.txt greifen…