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");
...