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.

PyLucid supports the new "Dynamic Sites" Feature from the django-tools project.

With "Dynamic Sites" you can serve multiple sites with only one page instance. The SITE_ID would be set dynamic by the current Domain Name. You can also specify domain name alias as a simple string or as a regular expression.

More info: https://github.com/jedie/django-tools/blob/master/django_tools/dynamic_site/README.creole

↑ update instruction  #

You must Update django-tool and then run syncdb:

Use ./upgrade_pylucid_env.sh for upgrade packages in these order:

1. first upgrade PyLucid (updates the requirements information)
2. restart upgrade_pylucid_env.sh and then upgrade django-tools

After this, create the new site aliases table:

1

/var/www/YourSite$ ./manage.py syncdb

Otherwise you will get the error like DatabaseError: (1146, "Table 'dynamic_site_sitealias' doesn't exist")

If you would like to use the "Dynamic Sites" Feature, add this to your local_settings.py:

1
2

# activate django-tools DynamicSiteMiddleware:
USE_DYNAMIC_SITE_MIDDLEWARE = True

↑ 500 Bugfix  #

We fixed a ugly bug with some commits:

You will get 500 error pages on several requests. Seems without rules behind it.

The real Problem: We create IP ban entries in the model manager with:

1

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

And the model attribute looks like this:

1

createtime = models.DateTimeField(auto_now_add=True)

Don't know why, but the creattime is often None. It raised a 500, because it is always assumed that there is a date and no None ;) The error message will be AttributeError: 'NoneType' object has no attribute 'year'

Now, we set createtime explicit in save(). We also add a work-a-round if it's None, but we remove this in the future.

↑ Bugfix in comments  #

We fixed with 61e1809 a bug in the comments system: A user gets CSRF error if he tries to create a comment.

TODO: We must flush the cache after a comment created.

In the past we haven't update the version number of PyLucid in the right way.
For a very long time (24.03.2009 - 29.12.2011) we used v0.9, see: development history summary of PyLucid.

Good intention for the new year: We want to set the numbers by this scheme:

• major.minor.maintenance.build

We hope you can easier see, if you can Update, and whats todo on a update.

Changes in v0.10.2: We merged the "context_middlewares" branches with commit ceaf6a52. The goals of this branch are:

• No work-a-round in template inheritance needed for context middlewares (issues 13)
• optimized render process (issues 51)

This is not "backward incompatible", but the work-a-round described in issues 13 is obsolete, you can remove it if you have used it.

We have done some changes in PyLucid.

We add "DynamicSiteMiddleware" with commit 0b7be16 (but it must be enabled in local_settings.py): With it you can use one vHost entry for more than one site. The middleware set SITE_ID for every request.

Some security related updates:

• commit 2643708: Auto cleanup Log Table to protect against overloading.
• commit da20884: We auto ban IP addresses which cause many exceptions in a short time.
• commit aca07abf: Limit the number of tag filters in blog plugin.

Today we merged the "split_blog_model" branch.

The goal of this changes are to get a better language support in the blog plugin: Now you can really translate a blog entry and the user get the content in his preferred language.
We changed the urls, too. We remove the ID and insert the date into url. We add archive pages, too.

It's needed to startup a schema/data migration. Run this commands:

1
2

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

Otherwise you will get a error like this, if you access the blog without migration: Table 'blog_blogentrycontent' doesn't exist