ABAKUS

eanst hat geschrieben:kann ich evtl. auch einfach mit der robot.txt arbeiten? wenn ja, wie?

Die betroffenen URLs werden von einigen Suchmaschinen auch weiterhin gelistet, zwar ohne jeglichen Inhalt und damit außer mittels site: nicht zu finden, nichtsdestotrotz verschwinden sie bisweilen nicht gänzlich. Der Grund ist normalerweise, dass noch irgendwo Verweise auf die ausgeschlossenen URLs existieren.

So oder so ist das Flickschusterei, genauso wie mit der URL-Konsole, und es ist mir unverständlich, warum Du lieber an den Symptomen rumdokterst anstatt erstmal zu versuchen, die Ursache zu beheben, den einfachsten Weg zu gehen und mit dem Status 404 antworten zu lassen.

wie kann man mit der robot.txt mehrere ähnliche urls definieren. so wie in meinem ertsen beitrag definiert...

Welche Möglichkeiten Du hast, steht in der robots.txt-Anleitung und in der Google-Anleitung zur robots.txt. Beachte bitte, dass das, was Google an Funktionalität anbietet, nicht unbedingt von anderen angeboten wird.

ok, ich würde gerne das mit dem errordocument durchführen.

über plesk kann mna das anscheinend nicht!? deswegen habe ich mir via ftp ein den ordner "err_docs" heruntergeladen.

nur leider habe ich nicht soviel mit apache und co zu tun

wo kann ich nun die 404 definieren?

eanst hat geschrieben:ok, ich würde gerne das mit dem errordocument durchführen.

über plesk kann mna das anscheinend nicht!?

Über Plesk geht das folgendermaßen:

Die Plesk-Anleitung hat geschrieben:To configure Plesk’s web server to show your custom error pages:
1 Switch on support for custom error documents through Plesk. On your Home page, click the domain name you need, and then click Setup. Select the Custom Error Documents check box. Click OK.
2 […] connect to your FTP account on the Plesk server, and go to the error_docs directory.[…]
3 Edit or replace the respective files. Be sure to preserve the correct file names:
* 400 Bad File Request - bad_request.html
* 401 Unauthorized - unauthorized.html
* 403 Forbidden/Access denied - forbidden.html
* 404 Not Found - not_found.html
* 500 Internal Server Error - internal_server_error.html
4 Wait for a few hours till your web server is restarted. After that, the web server will start using your error documents.

Existiert die index.php noch, sieht's allerdings etwas anders aus, weil der Knackpunkt dann in diesem Skript steckt.

Lege eine Sicherheitskopie der index.php an, öffne das Original (nicht die Kopie) in einem Texteditor und schau nach, wo die drei Parameter open, id und vertragid verarbeitet werden (üblicherweise werden sie mit $_GET["parametername"] abgefragt).
Suche vielleicht als erstes nach $_GET["open"] und einer Stelle, an der je nach Inhalt von open die entsprechende Seite ausgegeben wird. Direkt danach könnte sich auch eine mit if oder else eingeleitete Passage finden, die, falls es keine entsprechende Seite gibt, eine Standardseite (hier: Startseite) ausgibt. In dieser Passage müsste am Anfang header("HTTP/1.0 404 Not found"); eingefügt werden, vielleicht auch noch ein echo "Die gewünschte Seite wurde nicht gefunden"; an passender Stelle.

Eventuell wird das Skript aber auch bei bekannten open-, id- und vertrag-id-Daten mit die() oder exit() beendet, nachdem die gewünschte Seite ausgegeben wurde. In dem Fall müsstest Du einen else-Block mit besagter header()-Zeile einbauen (else { header("404 Not found"); } ).

Gleiches Verfahren mit den Parametern id und vertragid.

Falls Du im Umgang mit PHP nicht sicher bist, frage jemanden, ob er Dir die index.php anpassen kann (oder schicke sie mir per PM).

hallo haha und danke für deine antwort.

also in plesk ist das häkchen bereits drin (benutzerdfinerte errors also aktiv). in dem err_docs ordne rgibts ebenfalls schon eine "404 Not Found - not_found.html"

die parameterübergabe von open, vertragid etc. (also die in den alten urls) werden von meinen momentanen scripten nicht mehr verwendet!

also muss ich da wohl nix umschreiben.

kann es sein das der google es nun seit über einem jahr noch nicht geschafft hat die fehlerhaften, alten urls aus seinem index zu entfernen?

Schreibe in die robots.txt einfach die URL "/index.php?open=" und benutz die URL Console.
Schon werden alle URLs die so beginnen gelöscht.

Wobei ich jetzt natürlich davon ausgehe, dass deine neuen URLs nicht mit /index.php?open= anfangen.

SUPER!
DANKE nX... genau das wollte ich ja eigentlich wissen!

also ich mach einen disallow für alle robots für die url "/index?open="

und in der url-konsole dann die robots.txt angeben?

so müsste die robot.txt aussehen:
--------------------------------------
User-agent: *
Disallow: /index.php?open=

User-agent: googlebot
Disallow: /index.php?open=
---------------------------------

ist das korrekt?

eanst hat geschrieben:die parameterübergabe von open, vertragid etc. (also die in den alten urls) werden von meinen momentanen scripten nicht mehr verwendet!

Wenn das so ist, reichen dreieinhalb Zeilen am Anfang der index.php:

if (isset($_GET["open"]) || isset($_GET["vertragid"]) || isset($_GET["id"])) {
header("HTTP/1.0 404 Not found");
exit;
}

kann es sein das der google es nun seit über einem jahr noch nicht geschafft hat die fehlerhaften, alten urls aus seinem index zu entfernen?

Wenn Du keinen Fehler lieferst sondern immer mit OK antwortest, sind die URLs aus Googles Sicht nicht fehlerhaft.

Jetzt hab ich doch mal eine dumme Frage: Warum die Seite nicht einfach löschen?
Dann erscheint halt der Text: Die Seite wurde nicht gefunden......

und somit ist die Seite weg, oder sehe ich das falsch?

ja, das siehst du falsch. die seiten gibts ja nicht mehr. deswegen kann man die auch nicht löschen. da es sich um über 1.000 seiten handelt, macht es auch keinen sinn diese manuell über die konsole zu löschen

Ich habe ein ähnliches Problem, allerdings ist es bei mir noch viel schlimmer und ich wäre froh, wenn sich mal jemand meinem Problem annehmen könnte...

Ehe ich bemerkt habe, dass Google auf einmal alle Seiten auch mit dem phpsessid-Anhängsel indexiert (was über 2 Jahre lang nicht der Fall gewesen ist!), waren schon gut 200.000 doppelte Seiten im Index, die Page besteht aber nur aus ca. 20.000 Seiten. Nach der Behebung des Problems und dem Verbot, die phpsessid Sache zu spidern, wurden es auch täglich weniger bis es schon auf ca. 15.000 doppelte Seiten mit diesem phpsessid-Anhängsel heruntergefahren war. Plötzlich waren aber wieder rund 80.000 dieser doppelten Dateien im Index, wo es nun schon seit vielen Wochen unverändert festhängt.

Rund 80.000! doppelte Dateien kleben also seit Ewigkeiten im Index fest, was mir beim letzten großen Update vor gut zwei Wochen natürlich einen gehörigen Ärger gebracht hat, ein Besuchereinbruch von 80%. Die Domain jetzt total abgestraft wegen DC, dabei war sie jahrelang eine Autorität mit einer riesigen Linkpop, Content ist bis zum Abwinken dar und von Spam kann keine Rede sein. Einzig und allein dieser technische Fehler von mir, dass ich dem Google Bot nicht rechtzeitig die phpsessid-Dateien verboten habe aufzunehmen, bereitet mir nun einen Ärger von immensem Ausmaß, schließlich wurde in die Website jahrelang viel Arbeit und Geld investiert.

Wie bekomme ich die rund 80.000 Dateien mit der phpsessid Endung nun aus dem Index? Die phpsessid Endung zu spidern habe ich ja verboten, also werden die 80.000 im Index befindlichen Seiten ja nicht mehr besucht, aber rausfliegen tun sie halt nicht, an der Anzahl der doppelten Seiten tut sich überhaupt nichts mehr.

Für jeden kleinen Tipp oder Erfahrungsbericht Eurerseits wäre ich dankbar!

Fisch hat geschrieben:Wie bekomme ich die rund 80.000 Dateien mit der phpsessid Endung nun aus dem Index?

Wenn die robots.txt-Lösung als nicht ausreichend empfunden wird, Nägel mit Köpfen machen:

1. Grundübel beseitigen: Überlegen, ob eine Session-ID zum Anschauen der Webseiten tatsächlich unabdingbar ist. In Fällen, in denen sogar Robots eine ID gegeben wird, ist das meist nicht der Fall.

2. PHP untersagen, die ID in die URL zu kleben (mittels session.use_only_cookies). Sie hat da nichts zu suchen, dafür hat Netscape vor vermutlich bald einem Jahrzehnt Cookies erfunden, eine Technik, die mittlerweile von so ziemlich allen Browsern unterstützt wird (und selten abgechaltet ist bzw. für sinnvolle Funktionalitäten auch gerne eingeschaltet wird).

3. Suchmaschinen das Abrufen von URLs mit phpsessid-Parameter erlauben.

4. Sämtliche URLs, die "phpsessid=" enthalten, in 410-Rente schicken, beim Apache mit mod_rewrite:

RewriteEngine on
RewriteBase /
RewriteCond %{QUERY_STRING} (^|[;&])phpsessid=
RewriteRule .* - [G]

Bei anderen Webservern analog vorgehen.

so, habe nun mit der robots.txt gearbeitet. scheint zu klappen. es sind nun 2.000 seiten weniger im index und anscheinend hat g* die richtigen rausgeschmissen!

danke euch!