Sitemap.xml und robots.txt mit .htaccess aus dem Google Index verbannen

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.

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"

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

<IfModule mod_headers.c>
# test
</IfModule>

reinschreiben. Wenn dann kein Fehler kommt, dann passt das schon mal.

Danach dann nur

<IfModule mod_headers.c>
Header append X-Test "test"
</IfModule>

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.

Ä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

<IfModule mod_headers.c>
Header append X-Test "test"
</IfModule>

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.

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.

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.

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:

Zitat

Unsupported or invalid URI (Unsupported URL scheme ''):

Dann gibt die URL so an, wie es da steht, also mit Scheme... Sprich.

https://beispiel.rocks/beispiel.rocks/www.domain.de

P.s. Das steht sogar vorher schon da:

Zitat

Enter 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.