Neue (?) WMT-Meldung

Das gibt es schon länger

Das muss nicht sein. Hab das nur mal so beiläufig gelesen. Selbst hatte ich so eine Meldung auch noch nicht. "Gibt es schon länger" liegt auch im Auge des Betrachters... Ich hatte das Anfang März mal gesehen. Die gibt es auch umgedreht, also wenn der Traffik extrem gefallen ist.

Mir gefällt ja die neue Fehlerliste sortiert nach Priorität. Die hat endlich mal einen richtigen Mehrwert. Was hab ich mich da früher immer durchwühlen müssen.

mir nicht. Gut, die ist schön, nur wie löscht man da über 140.000 Fehlermeldungen.... Jeden Tag 1.000, mehr geht nicht.

gut, bei mir ist es eine Null weniger

Frank-L
Ok, dann hast Du da auch recht viele. Was denkst Du denn über die Priorität? Bei mir ist das alles andere als sinnig. Meine ganzen Fehler beruhen auf einem Kalenderscript das per Ajax eingebunden war und Google meinte, er müsse alle Monate (0 bis 12) und alle Jahre von 0 bis 6xxx durchgehen. Dass das Script aber gleichzeitig auch einen 404 meldete interessierte wohl nicht, daher nun die ganzen Meldungen. Nur, die sind laut Priorität sehr weit oben angesiedelt. Ich lösche nun schon seit 8 Tagen, also 8.000 Seiten bisher, und da waren gerade mal 20 echte Seiten dabei, die es nicht mehr gab. Wobei auch von den 20 der Großteil aus 2010 oder Anfang 2011 war.

So etwa auch wieder die Top1000 von heute...

1 js/kalender.php?id=db&y=2211&m=4&typ=ddmm 404 03.01.12
2 js/kalender.php?id=dv&y=1180&m=4&typ=ddmm 404 04.01.12	
3 js/kalender.php?id=db&y=5232&m=8&typ=ddmm 404 03.01.12
4 js/kalender.php?id=db&y=2806&m=12&typ=ddmm 404 03.01.12

Und eben wieder. Alle 1000 sind nur der Kalender. Und der sendet schon seit 8 Monaten einen 404. Google macht aber weiter. Gut, jetzt ist das Script komplett gelöscht und Ruhe...

Kannste google da nicht einfach mit einem freundlichen Eintrag in der .htaccess aussperren?

Bei mir lief der googlebot auch Amok in einem Magento:
Der fing an, alle Artikel miteinander zu vergleichen...
Da jeder Artikel in zig Formaten und 123² Farben erhältlich war und der bot meinte, er müsste jetzt jeden Artikel mit bis zu 10 anderen Artikeln vergleichen, kam ich mit löschen in den WMT gar nicht mehr nach.

Ne, sperren geht nicht, weder mit htaccess noch mit robots.txt, denn bei beiden laufen dann die Einträge eben in die entsprechende andere Liste. Ich will die aber nicht in einer anderen Liste, sondern ganz weg aus den WMT. Aber nach aktuellem Stand, wenn denn nichts Neues hinzukommt, bin ich ja in gut 130 Tagen fertig :grummel:

Kannste nicht die ganzen bot-IPs per .htaccess umleiten?
Wenn die auf /js/kalender.php zugreifen wollen, gibts nen permanently moved auf die Startseite.

Gut, das wäre noch eine Möglichkeit - habe ich noch nicht versucht. Nur, ist das sinnvoll? Scheint mit ein wenig suboptimal. Das Script gibt es ja wirklich nicht mehr. Und wenn ich da nun über 100.000 Seiten auf die Startseite umleite... weiß nicht, bekomme da ein ungutes Gefühl in der Magengegend...

Dann leite sie halt zur Konkurrenz um und guck, was passiert. :holly:

Ich hatte damals immer ein Problem mit den Session IDs von Oscommerce, seitdem sperre ich sowas eigentlich immer gleich via. robots.txt . Mach ich heute auch noch so, bei meinem neuen Krams. Evtl. mal diesen js gedöns via. robots.txt sperren und einen Löschantrag stellen? Würde es aber vorher mal auf einer Subdomain ausprobieren..

Die Priorität ist echt hammer genial! Bin ja von phpbb zu vbulletin gewechselt. Meine Jungs hatten immer, wenn einer was gefragt hatte und es die Lösung eigentlich schon gab, mit einem Link darauf verwiesen. Leider war es immer der Suchlink mit dem Highlightning..
Dieser Fehler mit diesen "kack Links" steht nun auf Platz 1 und die nächsten 100 Fehler habe ich nun auch schon abgearbeitet und muss bisher sagen TOP!
Vor ein paar Wochen dachte ich da immernoch, das ich das Feld von hinten aufrolle und immer nur "Glück" hatte einen richtigen Brocken zu finden.

Zitat von Synonym;17739

Frank-L
Ok, dann hast Du da auch recht viele. Was denkst Du denn über die Priorität? Bei mir ist das alles andere als sinnig. Meine ganzen Fehler beruhen auf einem Kalenderscript das per Ajax eingebunden war und Google meinte, er müsse alle Monate (0 bis 12) und alle Jahre von 0 bis 6xxx durchgehen. Dass das Script aber gleichzeitig auch einen 404 meldete interessierte wohl nicht, daher nun die ganzen Meldungen. Nur, die sind laut Priorität sehr weit oben angesiedelt. Ich lösche nun schon seit 8 Tagen, also 8.000 Seiten bisher, und da waren gerade mal 20 echte Seiten dabei, die es nicht mehr gab. Wobei auch von den 20 der Großteil aus 2010 oder Anfang 2011 war.

So etwa auch wieder die Top1000 von heute...

Code

1 js/kalender.php?id=db&y=2211&m=4&typ=ddmm 404 03.01.12
2 js/kalender.php?id=dv&y=1180&m=4&typ=ddmm 404 04.01.12    
3 js/kalender.php?id=db&y=5232&m=8&typ=ddmm 404 03.01.12
4 js/kalender.php?id=db&y=2806&m=12&typ=ddmm 404 03.01.12

Und eben wieder. Alle 1000 sind nur der Kalender. Und der sendet schon seit 8 Monaten einen 404. Google macht aber weiter. Gut, jetzt ist das Script komplett gelöscht und Ruhe...

Frank-L.
Das Thema ist ja bei mir nicht neu, hatte das schon im anderen Forum.

Die ganzen Scripte im Ordner /js/ sind in der robots.txt gesperrt. Daraufhin lief das Log wegen den Sperrungen voll (ist gut ein Jahr her). Keine Ahnung warum Google da immer wieder drauf zugriff. Erster Einstig ja, aber dann die Navigation hoch und runter normalerweise nicht, da in der robots.txt gesperrt. War aber so, keine Ahnung.

Dann war mir das zu blöd und ich habe die in der robots.txt freigegeben und einen 404 gesendet (vor ca. 8 Monaten). Dann wanderten die Meldungen ins andere Log, verschwanden aber nicht.

Nun ist das Script komplett gelöscht (seit ca. 4 Monaten) und die Fehler noch immer da.

Ich weiß nicht wo Google das alles her hat, denn das können keine Links in der Navi gewesen sein (abgesehen davon, dass ja eh gesperrt war). Die ging immer nur max. 36 Monate vorwärts. Zudem ist in PHP bei Date gar kein Datum 3000+ möglich. Scheint fast so, als ob Google da die Ziffern selbst aussuchte.

Seltsam auch, dass die meisten Fehlermeldung am 2.1. und 3.1 kamen, zumindest laut WMT. Zu diesem Zeitpunkt gab es das Script aber gar nicht mehr.

Auch bei einer anderen Domäne haben sich die Fehlermeldung an den gleichen Tagen extrem vervielfacht, aber ist dennoch unter 1000. Aber irgendwas muss speziell an den Tagen gewesen sein.