Ich hab ein kleines Problem mit Suchmaschinen Bots, die meine Webseiten Indexieren.

Mein Blog kann man nach Tags filtern, dabei kann man die Tags kombinieren. Bsp.:

Das Problem: Die Suchmachinen reihen tags an tags und gehen so immer "tiefer", obwohl das natürlich keinen Sinn macht.

Ich habe deswegen mehrere Maßnahmen getroffen:

• Die Tag Filter URLs sind mit rel="nofollow" markiert.
• Die Seiten werden mit <meta content="noindex,nofollow" name="robots"> Ausgeliefert.

Die Änderungen sind nun schon eine weile Aktiv. Es sollte also jede Suchmaschine sie registriert haben. Dennoch Indexieren viele fröhlich weiter.

Deswegen werden Links zu einem weiteren Tag-Filter ab einer frei einstellbaren Anzahl nicht mehr eingebaut. Bsp:

• Die Seite mit 2 Filtern enthält noch Filter-Links: http://www.pylucid.org/de/blog/tags/pylucid/development/
• Diese Seite mit 3 Filtern nicht mehr: http://www.pylucid.org/de/blog/tags/pylucid/development/visible%20changes/

Wird dennoch mehr als 3 Filter verwendet, erhält man einen 500 und das ganze wird geloggt. Kommt es zu oft vor, wird die IP für eine einstellbaren Zeit gebannt.

Doch auch das scheint nicht richtig zu helfen. Deswegen habe ich eine statische robots.txt angelegt: http://www.pylucid.org/robots.txt darin ist u.a.:

Disallow: /de/blog/tags/
Disallow: /en/blog/tags/
Disallow: /*/blog/tags/*

Aber auch das beachten anscheinend nicht alle Bots.

Letztlich sehe ich diese Möglichkeiten:

1. Die Tags nicht mehr per URL, sondern als GET Parameter nutzten
2. Bots per "User Agent" feststellen und für diese überhaupt keine Tag-Filter-Links einbauen
3. Das Filtern nur noch als AJAX view zulässig

Zu 1. Die Frage ist ob das die Suchmaschinen auch wirklich ignorieren. Dazu habe ich in der robots.txt: Disallow: /*? Aber ob das reicht?

Zu 2. Wie erkennen? Man müßte eine ganze Liste an möglichen Strings im User Agent führen. Dann ist dennoch die Frage, ob man damit alle erreicht.

Zu 3. Das wird IMHO noch am besten klappen, wobei Suchmaschinen langsam auch JS beherrschen? Schade ist, das ohne JS kein Filtern mehr Funktionieren würde. Aber naja, wer hat es schon aus?

Meinungen/Ideen dazu?

(Crosspost: http://www.python-forum.de/viewtopic.php?f=5&t=28530 )

EDIT: Dank einiger Tipps aus den Python-Forum, gibt es nun die ersten Änderungen, mit v0.11.2, siehe commit 1267cb:

• Die Tags in der URL werden sortiert. Wenn aktuelle URL nicht "Canonical" ist, gibt es ein Redirect.
• es wird 404 zurück gegeben, wenn ein Tag Filter zuviel in der URL ist, bei mehr als einer zuviel dann wiederum SuspiciousOperation, welches geloggt wird.
• Es werden nur die [+] nicht mehr in der Seite eingebaut, wenn die Anzahl der max. Tag Filtern erreicht wurden.
• Für das alles gibt es nun unittests

Es scheint aber auch so zu sein, das es wirklich Wochen dauern kann, bis alle Bots das schnallen. Denn es schient so das jetzt erst einige der schon vor Tagen gemachten Änderungen ziehen.

↑ 500 Bugfix  #

Wir haben einen dummen Bug mit einigen Commits gefixed:

Man erhält hin und wieder eine 500 Fehler. Man kann scheinbar keine Regel dahinter ausmachen.

Das eigentliche Problem: Wir erstellen IP Ban-Einträge im Model Manager so:

1

self.model(ip_address=remote_addr).save()

...und im Model haben wir das:

1

createtime = models.DateTimeField(auto_now_add=True)

In dem Falle wird oft createtime zu None, keine Ahnung warum... Es kommt zu 500, weil immer davon ausgegangen wird, das es ein Datum ist und nicht None ;) Der Fehler lautet: AttributeError: 'NoneType' object has no attribute 'year'

Nun setzten wir das Datum explizit in save(). Außerdem gibt es temporär einen Work-A-Round, wenn kein Datum existiert. Der kommt aber später wieder weg.

↑ Bugfix in Kommentaren  #

Mit 61e1809 ist ein Bug im Kommentar System gefixed: Ein normaler User erhält einen CSRF Fehler

TODO: Wir müssen noch den Cache löschen, nachdem ein Kommentar geschrieben wurde.

In der Vergangenheit haben wir die Versionsnummern von PyLucid nicht mehr richtig aktualisiert. Für einen sehr langen Zeitraum (24.03.2009 - 29.12.2011) haben wir immer nur v0.9.xxx genommen. Siehe auch: Entstehungs Geschichte von PyLucid

Vorsatz für das neue Jahr: Wir wollen wieder gescheite Versionnummern machen, nach dem Schema:

• major.minor.maintenance.build

Es gibt einige Update in PyLucid.

Neu ist die "DynamicSiteMiddleware" (commit 0b7be16) (muß in local_settings.py aktiviert werden): Damit kann man einen vHost für mehr als einer Seite verwenden. Die Middleware setzt die SITE_ID bei jedem request zur verwendeten Domain.

Ein paar Sicherheitskritische Updates:

• commit 2643708: Automatische Bereinigung der Log Tabelle, schützt vor volllaufen.
• commit da20884: Automatisches bannen von IP Addressen, die viele Exceptions in kurzer Zeit erzeugen.
• commit aca07abf: Anzahl der "Tag"-Filter im Blog Modul begrenzen.

Heute haben wir den "split_blog_model" branch gemerged.

Das Ziel war es, eine bessere Sprachunterstützung im Blog Plugin zu ermöglichen. Damit man auch wirklich einen Blog Eintrag Übersetzten kann und der Betrachter den Artikel in seiner Sprache erhält.
Wir haben auch die URLs geändern: Raus mit der ID und rein das Datum des Artikel. Dazu kommt noch eine Archiv Ansicht.

Die Datenbank Tabellen haben sich geändert, deswegen ist eine Migration notwendig. Dazu diese Befehle ausführen:

1
2

./manage.py migrate pylucid_project.pylucid_plugins.blog 0001 --fake
./manage.py migrate pylucid_project.pylucid_plugins.blog

Wenn man ohne die Migration auf das Blog zugreift erhält man einen Fehler in der Richtung: Table 'blog_blogentrycontent' doesn't exist