Posts Tagged ‘410’

Samstag, 7. Juli 2018

AhrefsBot und SEMrush Spider mit .htaccess blocken

Diese zwei Spider, deren Zweck (und Hintermänner) ich trotz folgender zwei erläuternden Seiten immer noch nicht verstehe, gehören geblockt:

Hauptgrund ist, dass sie (immer wieder) uralte URLs aufrufen, die nicht mehr existeren, obwohl dies von meinem CMS auch korrekt mit dem HTTP-Code 410 Gone zurückgemeldet wird:

The HyperText Transfer Protocol (HTTP) 410 Gone client error response code indicates that access to the target resource is no longer available at the origin server and that this condition is likely to be permanent.

If you don’t know whether this lack is temporary or permanent, a 404 status code should be used instead.

Quelle: 410 Gone

Nun gut, dann bleibt halt nur noch das drastischste Mitte mittels .htaccess:

...
RewriteCond %{HTTP_USER_AGENT} SemrushBot [OR]
RewriteCond %{HTTP_USER_AGENT} AhrefsBot
RewriteRule .* - [R=429]
...

Noch kurz getestet:

$ wget "https://www.domain.tld/" --user-agent "Mozilla/5.0 (compatible; AhrefsBot/5.2; +http://ahrefs.com/robot/)"
--2018-07-07 13:34:33--  https://www.domain.tld/
Auflösen des Hostnamens www.domain.tld (www.domain.tld)… 1.2.3.4
Verbindungsaufbau zu www.domain.tld (www.domain.tld)|1.2.3.4|:443 … verbunden.
HTTP-Anforderung gesendet, auf Antwort wird gewartet … 429 Too Many Requests
2018-07-07 13:34:33 FEHLER 429: Too Many Requests.
$ wget "https://www.domain.tld/" --user-agent "Mozilla/5.0 (compatible; SemrushBot/2~bl; +http://www.semrush.com/bot.html)"
--2018-07-07 13:34:52--  https://www.domain.tld/
Auflösen des Hostnamens www.domain.tld (www.domain.tld)… 1.2.3.4
Verbindungsaufbau zu www.domain.tld (www.domain.tld)|1.2.3.4|:443 … verbunden.
HTTP-Anforderung gesendet, auf Antwort wird gewartet … 429 Too Many Requests
2018-07-07 13:34:52 FEHLER 429: Too Many Requests.

Passt. Und jetzt herrscht hier Ruhe (und meine Log-Files bleiben leer).

Ah, und vielleicht sollte man sich noch vergewissern, dass alle anderen Browser durchkommen — Kollateralschäden wollen wir ja wennmöglich vermeiden:

$ wget "https://www.domain.tld/"
--2018-07-07 13:47:31--  https://www.domain.tld/
Auflösen des Hostnamens www.domain.tld (www.domain.tld)… 1.2.3.4
Verbindungsaufbau zu www.domain.tld (www.domain.tld)|1.2.3.4|:443 … verbunden.
HTTP-Anforderung gesendet, auf Antwort wird gewartet … 200 OK
Länge: nicht spezifiziert [text/html]
Wird in »index.html« gespeichert.

index.html.1                                                       [ <=>]  21,90K  --.-KB/s    in 0,005s  

2018-07-07 13:47:31 (4,07 MB/s) - »index.html« gespeichert [22421]

Tags: , , , , , , , , , , ,
Labels: Web

Keine Kommentare | neuen Kommentar verfassen

Mittwoch, 18. Dezember 2013

Google crawlt einmal entdeckte URLs auf immer und ewig

Seit Monaten plagten mich die Log-Dateien eines von mir betreuten Web-Projektes: Bestimmte URLs wurden von Googlebot periodisch wiederkehrend aufgerufen, obwohl die Informationen dieser Web-Seiten vor langer Zeit deaktiviert worden waren (kurz: Die Objekte wie Personen und Referate waren nicht mehr in der Datenbank vorhanden und generierten beim Aufruf eine PHP-Exception, welche zwar abgefangen wurde, aber meine Log-Dateien vollmüllte) und das Script seit einigen Wochen einen HTTP 404-Fehler zurückgab.

Wie zum Teufel kam der Googlebot immer wieder auf diese verflixten URLs zurück?

Ich hatte eine verdächtige Subdomain des Projektes im Visier, welche eine archivierte Version der Web-Site bereitstellte. Deshalb passte ich die URLs auf dieser Web-Seite dort an und fügte ihnen eine GET-Variable hinzu, welche unmissverständlich aufzeigen sollte, ob der Googlebot die URLs von dieser Web-Site bezog. Leider stellte sich heraus, dass die Ursache des Übels nicht von dieser Web-Site herrührte.

Daraufhin wählte ich URLs aus, welche eine ganz bestimmte, möglichst einmalige Zeichenkette enthielten und gab diese in der Google-Suche ein. Tatsächlich lieferte Google die Seite der Web-Site als Resultat aus — obwohl die Seite seit Wochen HTTP 404 retournierte. Ein Blick auf den Zeitpunkt des Caches bestätigte, dass Google eine mehrere Wochen alte Version aufbewahrte, welche kurz vor dem Einbau der 404-Routine gecrawlt wurde.

Nun gut, sagte ich mir: Irgendwann einmal muss ja der Googlebot akzeptieren, dass eine URL permanent einen 404er zurückliefert und diese URL dann nicht mehr regelmässig anpingen. Falsch gedacht:

Once Googlebot finds and crawls a URL, they will periodically come back and crawl it again forever. Even after you remove the page and have been returning 404 status for years, Googlebot will still crawl the URL from time to time.

Quelle: Google Crawls my disabled products on my Magento website [closed]

So ist das. Gibt es also wirklich nichts, was ein besorgter Webmaster tun kann? Doch, durchaus:

I followed up on the 404 vs 410 thing with the team here. As mentioned by some others here & elsewhere, we have generally been treating them the same in the past.

However, after looking at how webmasters use them in practice we are now treating the 410 HTTP result code as a bit „more permanent“ than a 404. So if you’re absolutely sure that a page no longer exists and will never exist again, using a 410 would likely be a good thing. I don’t think it’s worth rewriting a server to change from 404 to 410, but if you’re looking at that part of your code anyway, you might as well choose the „permanent“ result code if you can be absolutely sure that the URL will not be used again. If you can’t be sure of that (for whatever reason), then I would recommend sticking to the 404 HTTP result code.

In the worst case, the 410 will be treated the same as a 404; in the best case it’ll be a bit quicker & stickier :-).

Quelle: Does it make sense to return a 410 instead of 404 when some page has been permanently removed?, Via: Does it make sense to return a 410 instead of 404 when some page has been permanently removed?

Ich passte also meinen try-catch-Block im Script an, welcher neu heisst:

...
header("HTTP/1.0 410 Gone");
...

Tags: , , , , ,
Labels: Programmierung

Keine Kommentare | neuen Kommentar verfassen