Siehst, nu hat es klick gemacht und macht auch Sinn, ich war der vermulich irrigen Meinung, dass beim noindex im header das Crawlen mit einlesen dieses tags abgebrochen wird.
Sitemap.xml und robots.txt mit .htaccess aus dem Google Index verbannen
-
-
Dann würde "noindex - follow" überhaupt keinen Sinn mehr ergeben. Weil, wenn direkt das Lesen abgebrochen würde, könnten auch keine weiterführenden Links mehr gefunden und verfolgt werden.
-
FAlls das Apache Modul " mod headers" verfügbar isst
dann
falls sitemap.xml
da ist
sende den header
Robros "noindex" -
Hier der Scan, nach einfügen des sitmaps codes
Zitat# Robots noindex sitemap.xml
<IfModule mod_headers.c>
<FilesMatch "sitemap\.xml$">
Header append X-Robots-Tag "noindex"
</FilesMatch>
</IfModule>in die .htaccess Datei.
[ATTACH=CONFIG]304[/ATTACH]
Wird der zweite CodeZitat
# Robots noindex robots.txt
<IfModule mod_headers.c>
<FilesMatch "robots\.txt$">
Header append X-Robots-Tag "noindex"
</FilesMatch>
</IfModule>eingefügt, kommt ein kompletter Server Error.
-
Also das ist aber mehr als seltsam.
Erster Bereich und da muss ich nun Gegenfragen stellen.
1. Welche URL hast Du da im web-sniffer abgerufen? Die sitemap.xml?
2. Wenn ja, warum kommt da ein Status 403? Da müsste entweder ein 200 kommen, wenn gefunden oder ein 404, wenn nicht gefunden. Der 403, also ein Zugriff verweigert, egal ob da oder nicht ist hier gänzlich falsch.Zweiter Block
Wird auch nicht besser. Denn es gibt hier keinen Grund, einen Servererror zu senden. Welcher kommt denn, der 500 ? Ebenso, welche URL wurde hier abgefragt?Kommt der Servererror auch, wenn nur der zweite Block drinnen ist und der erste nicht?
Ehrlich gesagt bin ich hier fast schon überfragt. Steht in der .htaccess noch mehr drinnen? Kannst Du die mal komplett und unverändert posten?
Ansonsten könntest Du Dich ranarbeiten und den Fehler eventuell eingrenzen.
Also z.B. einfach mal ein
reinschreiben. Wenn dann kein Fehler kommt, dann passt das schon mal.Danach dann nur
da müsste im Web-Sniffer dann einfach ein Test-Header erscheinen. Der tut nicht weh und stört auch nicht. Ist nur zum Testen.Also Dich quasi langsam an die Fehlerursache heranarbeiten.
-
Huch, noch eine Gegenfrage...
AllowOverride FileInfo
bzw.
AllowOverride All
ist aber vorhanden, oder? Eines von beiden wird benötigt, damit Du überhaupt den Header verändern darfst. Das steht entweder in der Server-Config, in der vHost.conf.
-
Server abgeschossen
Das war nicht gerade lustig für den Hoster, der fast den Server damit abgeschossen hat
Mit chmod 755 funktioniert der erste Test.
Der X-Test nicht mehr., da erscheint bereits ein
We'll be back soonTemporarily out of service
Es dürften mehrere Hoster damit Probleme zu haben, dieses Service zur Verfügung zu stellen. Werde mich weiter Schlau machen :autsch:
-
Äm, ich verstehe gerade nicht mehr viel.
Von chmod habe ich doch gar nichts geschrieben und die anderen auch nicht. chmod hat auch nichts mit der htaccess zu tun.Aber, wenn ein
einen Server zum Absturz bringt, dann würde ich mir mal Gedanken über den Hoster machen.
Erstens. Das kann eigentlich gar keinen Serverfehler (500) ergeben, da geprüft wird (IfModule), ob das Modul geladen ist. Nur wenn es geladen ist, wird die Anweisung ausgeführt.
Serverfehler kommen nur, wenn man auf ein Modul zurückgreift, das nicht geladen ist, also die Anweisung unbekannt ist oder wenn es einen Schreibfehler / Syntaxfehler gibt, und somit eben auch unbekannt ist.
Dann und nur dann gibt es einen Serverfehler. Dieser betrifft aber nicht den ganzen Server, sondern nur den Account, in dem Die htaccess liegt. Zudem ist das kein Hexenwerk und für den Server gar kein Problem. Schreibfehler passieren immer wieder mal. Die Auslieferung der Fehlers ist für jeden Server ein Kinderspiel.
Und jein, mehrere haben damit keine Probleme. Es gibt welche, die das Modul nicht geladen haben, bei denen passiert dank der IfModule-Abfrage aber gar nichts, da der Block einfach ignoriert wird. Bei den anderen läuft das fehlerfrei.
Also ich würde mir da ehrlich gesagt weniger Gedanken über die htaccess machen und viel mehr über den Hoster.
-
Das hatte ich ein einziges mal, das eine <IfModule xxx.c>-Abfrage den Server gekillt hat.
Und das war, als ich mir selbst - ganz frei von belastendem Vorwissen - einen Server local aufgesetzt hatte :pfeif: -
catcat
Genau das wollte ich damit sagen. Das kann also nur sein, dass das Modul zwar vorhanden aber fehlerhaft ist. Das sind aber Dinge, die den Hoster angehen und nicht den Kunden. -
Offizielle Mitteilung eines Webhosters
wir haben Ihre Anfrage zur Konfiguration des Servers auf dem Ihr Webspace liegt geprüft. Wir können die Anpassung der Server - Konfiguration nach Ihrem Wunsch zur Zeit nicht durchführen. Durch die geforderte Anpassung würde der Schutz des Servers gefährdet.
Wir können Ihnen momentan leider keine andere Nachricht geben, da die Server - Sicherheit höchste Priorität hat.Das ist kein Scherz, da Webhoster offensichtlich Probleme damit haben. Hat jemand ein Hoster, wo das Script funktioniert?
-
So, das hört sich aber nun nach was anderem an. Bei dem Hoster scheint grundsätzlich mod_headers aktiv zu sein, sonst würde der ifmodule-Block ignoriert werden. Ignoriert wird er aber nicht, da ja anscheinend die "header append"-Anweisung ausgeführt wird. Und diese bringt dann den Serverfehler. Da bleibt also nur noch der Punkt, dass "AllowOverride" deaktiviert wurde. Das macht aber keinen Sinn, denn ohne braucht man das mod_headers auch nicht, bzw. kann es sich sparen, da es nicht funktioniert. Ohne "AllowOverride" aber mit "mod_headers" ist das in etwa so: "Ja, Modul ist vorhanden, Du darfst auch drauf zugreifen. Aber nein, ändern darfst Du nichts, denn die Rechte geben wir Dir nicht". Das wäre wie eine Bücherei, in der man zwar ein Buch ausleihen, dieses dann aber nicht lesen darf.
Aber das gehört für mich auch zum Hoster. Daher kann ich Dir hier nun auch nicht wirklich einen sagen, denn ich persönlich gehe davon aus, dass wenn man schon ein Modul bereitstellt, dass man dann auch die Rechte erteilt, es zu nutzen.
Die meisten Hoster bieten mod_headers an, die Minderheit nicht. Bei denen, wo es nicht angeboten wird, geht es auch nicht... Bei denen wo es angeboten wird kommt nun die Frage nach dem "AllowOverride" und das sieht man von außen nicht. mod_headers ja oder nein steht in der phpinfo(), AllowOverride steht dort nicht.
Im Zweifel such Dir einen Hoster und frage bei denen direkt nach.
-
Provider Behauptung
Ein Provider behauptet, das Script funktioniert, obwohl der Test über web-sniffer.net folgendes zeigt:
[h=2]We'll be back soon[/h] Temporarily out of service
-
hmm, irgendwie verstehe ich dich nicht..
also was du jetzt meinst..
da steht doch nur das der service nicht verfügbar ist.
das heisst doch nicht das dsa script nicht funktioniert -
Ich jetzt langsam auch nicht mehr.
"We'll be back soon
Temporarily out of service"Das ist kein Meldung vom Server von Dir, sondern von Web-Sniffer, eben dass der Dienst Web-Sniffer derzeit nicht zur Verfügung steht. Das hat nichts mit der aufgerufenen Seite zu tun, diese Meldung kommt bei allen Seiten! Ich hoffe nun wirklich, dass sich Deine ganzen Fehlermeldungen und "Serverabstürze" nicht darauf beziehen....
Nimm doch einfach einen anderen...
*** Link veraltet ***
*** Link veraltet ***Und, verlasse Dich nicht auf Sniffer, sondern auf Deine Augen und Deinen Verstand. Wenn Du Die Seite aufrufst, die das "We'll be back soon. Temporarily out of service" brachte, wirst Du sehen, dass das im normalen Browser nicht kommt.
-
REDbot streikt ebenfalls: Unsupported or invalid URI (Unsupported URL scheme ''):
Rex Swain's HTTP Viewer aber funktioniert mit den Standard Optionen:
GET (Header & Content)
HTTP/1.1
Auto-Detect
Auto-Follow Location
Hier wird eine ganze Liste angezeigt. Welche Daten sind nun relevant?
Danke! -
wie testest du denn?
ich hab da eine vermutung aber ich bin ja artig -
Hecht,
also, bitte, mal lesen. redbot streikt garantiert nicht, den habe ich vorhin selbst benutzt:ZitatUnsupported or invalid URI (Unsupported URL scheme ''):
Dann gibt die URL so an, wie es da steht, also mit Scheme... Sprich.P.s. Das steht sogar vorher schon da:
ZitatEnter a https://beispiel.rocks/beispiel.rocks/ or https://beispiel.rocks/ URL to check
Welcher interessant ist?
Na der "Receiving Header:", oder ? Du willst doch wissen, was der Server sendet, oder? Darüber steht, was der Browser gesendet hat und ganz unten der Quelltext. -
REDbot gibt nun richtig aus:
ZitatHTTP/1.1 200 OK
Date: Mon, 24 Sep 2012 20:07:19 GMT
Server: Apache
X-Powered-By: PHP/5.3.13-pl0-gentoo
Keep-Alive: timeout=15, max=50
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/htmlRex Swain's HTTP Viewer gibt aus:
ZitatReceiving Header:
HTTP/1.1·200·OK(CR)(LF)
Date:·Mon,·24·Sep·2012·20:27:45·GMT(CR)(LF)
Server:·Apache(CR)(LF)
X-Powered-By:·PHP/5.3.13-pl0-gentoo(CR)(LF)
Connection:·close(CR)(LF)
Transfer-Encoding:·chunked(CR)(LF)
Content-Type:·text/html(CR)(LF)
(CR)(LF)Das war eine schwere Geburt, die ich ohne dieses Forum nicht geschafft hätte :wall:. Danke!
-